It is currently Thu Oct 19, 2017 7:35 am

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 25 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Fri Sep 15, 2017 5:19 pm 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 327
Location: FL
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.


Top
 Profile  
 
PostPosted: Thu Oct 05, 2017 1:44 pm 
Offline
User avatar

Joined: Sat Aug 20, 2016 3:58 am
Posts: 34
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


Top
 Profile  
 
PostPosted: Fri Oct 06, 2017 8:25 am 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2286
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.

Top
 Profile  
 
PostPosted: Fri Oct 06, 2017 8:36 am 
Offline
User avatar

Joined: Sat Aug 20, 2016 3:58 am
Posts: 34
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.


Top
 Profile  
 
PostPosted: Sat Oct 07, 2017 8:10 am 
Offline
User avatar

Joined: Tue Apr 05, 2016 5:25 pm
Posts: 121
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.

_________________
SNES NTSC 2/1/3 1CHIP | serial number UN318588627


Top
 Profile  
 
PostPosted: Sun Oct 08, 2017 5:05 am 
Offline
User avatar

Joined: Sat Aug 20, 2016 3:58 am
Posts: 34
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?.


Top
 Profile  
 
PostPosted: Wed Oct 18, 2017 9:57 am 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2286
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.


Top
 Profile  
 
PostPosted: Wed Oct 18, 2017 7:52 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 784
How computationally intensive is your average fighting game, excluding graphics decompression?


Top
 Profile  
 
PostPosted: Wed Oct 18, 2017 8:38 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2286
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.


Top
 Profile  
 
PostPosted: Wed Oct 18, 2017 9:17 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 784
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?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 25 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 8 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group