This is what I assumed he was talking about, given the other times he's mentioned it in other threads.tepples wrote:There are three issues all under the banner of "black bars".nicklausw wrote:Not sure what this means. Is that a hardware issue?psycopathicteen wrote:Something that doesn't have black bars
- 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.
Whatcha want in a fighting game?
Moderator: Moderators
Forum rules
- For making cartridges of your Super NES games, see Reproduction.
Re: Whatcha want in a fighting game?
- Señor Ventura
- Posts: 233
- Joined: Sat Aug 20, 2016 3:58 am
Re: Whatcha want in a fighting game?
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.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.
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
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
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.
Last edited by psycopathicteen on Fri Oct 06, 2017 6:17 pm, edited 1 time in total.
- Señor Ventura
- Posts: 233
- Joined: Sat Aug 20, 2016 3:58 am
Re: Whatcha want in a fighting game?
Depending of the complexity, maybe you can keep all the necessary tiles in VRAM, saving bandwidth.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.
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.
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.
- 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.
SNES NTSC 2/1/3 1CHIP | serial number UN318588627
- Señor Ventura
- Posts: 233
- Joined: Sat Aug 20, 2016 3:58 am
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.
And stretching the image more or less at the size of a crt:
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?.
-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.
And stretching the image more or less at the size of a crt:
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?.
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
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.
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.
Re: Whatcha want in a fighting game?
How computationally intensive is your average fighting game, excluding graphics decompression?
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
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.
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.
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?
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?
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
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.
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.
Last edited by psycopathicteen on Fri Oct 20, 2017 10:05 am, edited 1 time in total.
Re: Whatcha want in a fighting game?
You're right, if you don't need compression it's how much data you can transfer in VRAM who's counting .I don't think fighting games are that CPU intense.
if you want a well suited on the fly depacker for the 65816 you can look at this :Do you know if anyone ever tried Stef's LZ4W on the SNES?
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: Select all
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
Re: Whatcha want in a fighting game?
Huffman based on adjacent color... Are you a codemaster by any chance?psycopathicteen wrote:Each color would have a list of the most to least frequent adjacent color (excluding itself) with a hardcoded huffman tree.
But seriously: I'd be interested to see what ratio you get for real images using this technique.
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
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.
I also thought that perhaps I should make the color huffman tree slightly less risky, by making sure colors never exceed 5 bits.
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.
Code: Select all
1: 0
2: 10
3+x: 11xxxx
Code: Select all
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
-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.
Re: Whatcha want in a fighting game?
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.)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.
I also thought that perhaps I should make the color huffman tree slightly less risky, by making sure colors never exceed 5 bits.Code: Select all
1: 0 2: 10 3+x: 11xxxx
I've thought about using 3 different 8x8 tile types, with type 4 being an end marker.Code: Select all
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
-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.
(Free Hero Mesh - FOSS puzzle game engine)