nesdev.com
http://forums.nesdev.com/

Whatcha want in a fighting game?
http://forums.nesdev.com/viewtopic.php?f=12&t=16472
Page 2 of 3

Author:  Revenant [ Fri Sep 15, 2017 5:19 pm ]
Post subject:  Re: Whatcha want in a fighting game?

tepples wrote:
nicklausw wrote:
psycopathicteen wrote:
Something that doesn't have black bars

Not sure what this means. Is that a hardware issue?

There are three issues all under the banner of "black bars".

  1. Some games set forced blanking on the top and bottom 8-24 scanlines to buy additional time for DMA to VRAM. Battletoads did this on NES, as do Capcom fighters for Super NES.

This is what I assumed he was talking about, given the other times he's mentioned it in other threads.

Author:  Señor Ventura [ Thu Oct 05, 2017 1:44 pm ]
Post subject:  Re: Whatcha want in a fighting game?

93143 wrote:
Based on some preliminary calculations, it is suspected by some that even Street Fighter Alpha 2 could have been done at full size without letterboxing on SNES if the engine had been optimized properly.


Street fighter alpha 2 in snes has a brutal bandwidth that could let all the animations of the arcade game, with the original size of the characters.

Seriously, even two zangiefs are within the requeriments... the only thing is the limit of sprites per scanline if both of them fall to the ground at the same time, maybe could be possible to collapse all the drawing thing during that frames xD

Author:  psycopathicteen [ Fri Oct 06, 2017 8:25 am ]
Post subject:  Re: Whatcha want in a fighting game?

I think a lot of fighting games waste a lot of time re-uploading the entire HUD every frame instead of just stuff that needs to be changed. You just need to change the health bars when a player gets hit, and change the timer once a second.

Author:  Señor Ventura [ Fri Oct 06, 2017 8:36 am ]
Post subject:  Re: Whatcha want in a fighting game?

psycopathicteen wrote:
I think a lot of fighting games waste a lot of time re-uploading the entire HUD every frame instead of just stuff that needs to be changed. You just need to change the health bars when a player gets hit, and change once a second.


Depending of the complexity, maybe you can keep all the necessary tiles in VRAM, saving bandwidth.

After all, a yellow/red bar is the succession of one tile repeated a determined number of times.

But, well seen, i never thought about that.

Author:  HihiDanni [ Sat Oct 07, 2017 8:10 am ]
Post subject:  Re: Whatcha want in a fighting game?

So I thought about this for a bit. You can have some pretty big characters with full screen height, but you'll only have the bandwidth to upload graphics for one at a time. However, you also want to be fair to both players by not preferring early updates for one over the other. So here is my idea for a simple algorithm that won't introduce any input lag (though occasionally the sprite change will be delayed by one frame for both players). It involves looking one frame in advance into the animation data:

- Each player sprite is 4 KiB max.
- If only one of the two players is changing their sprite on this frame, go ahead and change it this frame.
- If both players are changing their sprite either on this frame, or the next frame, buffer player 1's sprite this frame (but don't display it). Next frame upload player 2's sprite as if it were on the same frame as player 1's and display both at once.

There will be a one frame sprite change delay if both players perform an input on the same frame. Outside of input changes, there should be no delay, assuming a max animation rate of 30 FPS.

Author:  Señor Ventura [ Sun Oct 08, 2017 5:05 am ]
Post subject:  Re: Whatcha want in a fighting game?

Yeah, something like:

-Character 1 upload the tiles ot it animation during odd frames. Character 1 starts its animation during odd frames.
-Character 2 upload the tiles of it animation during pair frames. Character 2 starts its animation during pair frames.
-In the third frame is mixed all the computing to evaluate all the thing about prioritys, so nobody really punchs first. Character 1 made effective it animation during frame 1, and character 2 made effective it animation during frame 2 (one frame later), but only counts during third frame, where the character 2 already have too the same animation before deciding the result.

With animations at even 3 ticks, there could not have conflicts... except that sometimes seems that one player punchs first, and sometimes the other, but being always a double punch.
It has its coherence in the fact that at that level is impossible to appreciate differences except recording at high speed (but, please...), and after all there isn't any cheating, and this even counting with the fact that is truly hard to do the same move just in the same frame.


Both the sprites in this photo are about 4KB (warning: i say in this photo shrinked at 256x224, not in the original at 384x224)... so, doubling its size we go over 8KB for sure, BUT, uploading tiles by turns, you can do it without change resolution or refresh, all at 256x224 and 60fps.
Image

And stretching the image more or less at the size of a crt:
Image


The thing is, in the photo every one of the two characters are about 2,5KB, but doing it during succesive frames every character could upload until 5,5KB without risks of artifacts... so, Could be possible hugo vs hugo doing one of them with a plane to don't overdraw?.

I said something interesting?.

Author:  psycopathicteen [ Wed Oct 18, 2017 9:57 am ]
Post subject:  Re: Whatcha want in a fighting game?

Every time fighting games get brought up, it makes me think about compression algorithms and how there is no guaranteed way of knowing which algorithm is best because luck is involved. You can even take a sprite, rotate it by 90 degrees and get completely different results with algorithms that don't accommodate for both horizontal and vertical detail.

I'm throwing ideas out. Maybe we can make an algorithm that separates a sprite into 3 layers. A horizontal RLE layer, a vertical RLE layer, and a fine detail layer, that has both runs of uncompressible pixels and sporadic single pixels.

Author:  93143 [ Wed Oct 18, 2017 7:52 pm ]
Post subject:  Re: Whatcha want in a fighting game?

How computationally intensive is your average fighting game, excluding graphics decompression?

Author:  psycopathicteen [ Wed Oct 18, 2017 8:38 pm ]
Post subject:  Re: Whatcha want in a fighting game?

I don't think fighting games are that CPU intense.

I think it should decompress roughly 4kB per frame.

Something just occurred to me. I can save sprites as PNG and ZIP files and use that as a benchmark.

Author:  93143 [ Wed Oct 18, 2017 9:17 pm ]
Post subject:  Re: Whatcha want in a fighting game?

It seems like that might require an extra frame of lookahead, or at least more frequent lag frames. 4 KB per frame isn't enough to fill VBlank, and you'd want to be able to rely on the data being there in the maximal load case.

This is why I like the S-DD1 - you don't have to worry about that. The SA-1 would be good at decompression too, though it might be overkill if your only problem is that you have too much graphics data.

But I know you tend to be more hardcore than me when it comes to pushing the unassisted S-CPU. It seems like every time I come up with an idea for something that could be done with a special chip, you come up with an idea about how to do the same thing without one...

...

Do you know if anyone ever tried Stef's LZ4W on the SNES?

Author:  psycopathicteen [ Thu Oct 19, 2017 8:41 pm ]
Post subject:  Re: Whatcha want in a fighting game?

I have an idea for a huffman-RLE format.

Each color would have a list of the most to least frequent adjacent color (excluding itself) with a hardcoded huffman tree.

1: 00
2: 01
3: 100
4: 1010
5: 1011
6: 1100
7: 1101
8: 11100
9: 111010
10: 111011
11: 111100
12: 111101
13: 111110
14: 1111110
15: 1111111

...and the length is encoded like this

1: 0
2+x: 1xxxx

If the length is 17 or more, there would be an additional 4 bits, etc

EDIT: Dang it I forgot 12.

Author:  TOUKO [ Fri Oct 20, 2017 2:42 am ]
Post subject:  Re: Whatcha want in a fighting game?

Quote:
I don't think fighting games are that CPU intense.

You're right, if you don't need compression it's how much data you can transfer in VRAM who's counting .

Quote:
Do you know if anyone ever tried Stef's LZ4W on the SNES?

if you want a well suited on the fly depacker for the 65816 you can look at this :
https://www.brutaldeluxe.fr/products/cr ... index.html

the decompression part is in 65816 asm,and all the tools are supplied and the stef's lz4w is based on this algo .

Code:
Here is the LZ4 unpacker source code, ready to be assembled into Merlin 16+ or Orca M :
Before calling the unpack code function, you have to allocate 2 memory banks of 64 KB, one containing the LZ4 file (Source Bank) and one ready to receive the Uncompressed Data (Destination Bank). Because we are only processing file with a size < 64 KB, we don't need more space and we don't have to deal with bank boundary. The LZ4 file will be loaded at the beginning of Source bank and the uncompressed data will be written at the beginning of the Destination bank. We also need to provide the Header size (16 bytes) and the LZ4 file size (used to stop the unpacking process) :

                 MX   %00
*-------------------------------------------------------------------------------
LZ4_Unpack       STA  LZ4_Literal_3+1   ; Uncompress a LZ4 Packed Data buffer (64 KB max)
                 SEP  #$20              ; A = Bank Src,Bank Dst
                 STA  LZ4_Match_5+1     ; X = Header Size = 1st Packed Byte offset
                 STA  LZ4_Match_5+2     ; Y = Pack Data Size
                 XBA                    ;  => Return in A the length of unpacked Data
                 STA  LZ4_ReadToken+3   
                 STA  LZ4_Match_1+3     
                 STA  LZ4_GetLength_1+3
                 REP  #$30
                 STY  LZ4_Limit+1
*--
                 LDY  #$0000            ; Init Target unpacked Data offset
LZ4_ReadToken    LDAL $AA0000,X         ; Read Token Byte
                 INX
                 STA  LZ4_Match_2+1
*----------------
LZ4_Literal      AND  #$00F0            ; >>> Process Literal Bytes <<<
                 BEQ  LZ4_Limit         ; No Literal
                 CMP  #$00F0
                 BNE  LZ4_Literal_1
                 JSR  LZ4_GetLengthLit  ; Compute Literal Length with next bytes
                 BRA  LZ4_Literal_2
LZ4_Literal_1    LSR                    ; Literal Length use the 4 bit
                 LSR
                 LSR
                 LSR
*--
LZ4_Literal_2    DEC                    ; Copy A+1 Bytes
LZ4_Literal_3    MVN  $AA,$BB           ; Copy Literal Bytes from packed data buffer
                 PHK                    ; X and Y are auto incremented
                 PLB
*----------------
LZ4_Limit        CPX  #$AAAA            ; End Of Packed Data buffer ?
                 BEQ  LZ4_End
*----------------
LZ4_Match        TYA                    ; >>> Process Match Bytes <<<
                 SEC
LZ4_Match_1      SBCL $AA0000,X         ; Match Offset
                 INX
                 INX
                 STA  LZ4_Match_4+1
*--
LZ4_Match_2      LDA  #$0000            ; Current Token Value
                 AND  #$000F
                 CMP  #$000F
                 BNE  LZ4_Match_3
                 JSR  LZ4_GetLengthMat  ; Compute Match Length with next bytes
LZ4_Match_3      CLC
                 ADC  #$0003            ; Minimum Match Length is 4 (-1 for the MVN)
*--
                 PHX
LZ4_Match_4      LDX  #$AAAA            ; Match Byte Offset
LZ4_Match_5      MVN  $BB,$BB           ; Copy Match Bytes from unpacked data buffer
                 PHK                    ; X and Y are auto incremented
                 PLB
                 PLX
*----------------
                 BRA  LZ4_ReadToken
*----------------
LZ4_GetLengthLit LDA  #$000F            ; Compute Variable Length (Literal or Match)
LZ4_GetLengthMat STA  LZ4_GetLength_2+1
LZ4_GetLength_1  LDAL $AA0000,X         ; Read Length Byte
                 INX
                 AND  #$00FF
                 CMP  #$00FF
                 BNE  LZ4_GetLength_3
                 CLC
LZ4_GetLength_2  ADC  #$000F
                 STA  LZ4_GetLength_2+1
                 BRA  LZ4_GetLength_1
LZ4_GetLength_3  ADC  LZ4_GetLength_2+1
                 RTS
*----------------
LZ4_End          TYA                    ; A = Length of Unpack Data
                 RTS

Author:  tepples [ Fri Oct 20, 2017 6:24 am ]
Post subject:  Re: Whatcha want in a fighting game?

psycopathicteen wrote:
Each color would have a list of the most to least frequent adjacent color (excluding itself) with a hardcoded huffman tree.

Huffman based on adjacent color... Are you a codemaster by any chance?

But seriously: I'd be interested to see what ratio you get for real images using this technique.

Author:  psycopathicteen [ Fri Oct 20, 2017 9:34 am ]
Post subject:  Re: Whatcha want in a fighting game?

I thought a little bit more about this. I think the run lengths should be done like this, as opposed to the above, to avoid runs of 2 pixels causing bloat.

Code:
1:     0
2:     10
3+x: 11xxxx


I also thought that perhaps I should make the color huffman tree slightly less risky, by making sure colors never exceed 5 bits.

Code:
1:  00
2:  01
3:  1000
4:  1001
5:  1010
6:  10110
7:  10111
8:  11000
9:  11001
10: 11010
11: 11011
12: 11100
13: 11101
14: 11110
15: 11111


I've thought about using 3 different 8x8 tile types, with type 4 being an end marker.
-horizontally compressed tiles
-vertically compressed tiles
-uncompressed tiles

EDIT:
I was wrong with thinking that this tree is "safer" because "safeness" can be calculated by averaging the code size for each color. It should have the worst case scenario only slightly worst than uncompressed code.

EDIT:
Nevermind, I forgot 12 in the previous post. The new tree is indeed safer.

Author:  zzo38 [ Fri Oct 20, 2017 11:38 am ]
Post subject:  Re: Whatcha want in a fighting game?

psycopathicteen wrote:
I thought a little bit more about this. I think the run lengths should be done like this, as opposed to the above, to avoid runs of 2 pixels causing bloat.

Code:
1:     0
2:     10
3+x: 11xxxx


I also thought that perhaps I should make the color huffman tree slightly less risky, by making sure colors never exceed 5 bits.

Code:
1:  00
2:  01
3:  1000
4:  1001
5:  1010
6:  10110
7:  10111
8:  11000
9:  11001
10: 11010
11: 11011
12: 11100
13: 11101
14: 11110
15: 11111


I've thought about using 3 different 8x8 tile types, with type 4 being an end marker.
-horizontally compressed tiles
-vertically compressed tiles
-uncompressed tiles

EDIT:
I was wrong with thinking that this tree is "safer" because "safeness" can be calculated by averaging the code size for each color. It should have the worst case scenario only slightly worst than uncompressed code.

EDIT:
Nevermind, I forgot 12 in the previous post. The new tree is indeed safer.
If you provide some example data (in any format supported by Farbfeld Utilities), then I can try to implement this, and see if it is working. (Some name to call such format also should be needed.) (With this new Huffman table, a forty byte header (5 times 16 times 4 bits) to specify which colours are most common next to another one, should be sufficient.)

Page 2 of 3 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/