I mean for a fast paced game like this, I think we should accept that the sprites will flick, like the famicon version:
1 chunk per line ? do your characters have arms, hands and attachments ? Don't forget the shoryuken fire and other special FX's. also when blanka electrifies it could be very bad for the chunk technique.
I counted 1.5 chunks per line on the standard pose.
In diagonal pose pics, cpu will say "thank you" about all those transparent pixels to skip.
Do you have a pic of being eletrified? Make it a solid cloud, 1 chunk per line
@norakomi:
page 0: displayed
page 1: draw overlapping sprites on clean buffer
page 2: blitter cleanup
rotate these 3 every frame.
page 3: clean backup image
page 0-255 ROM: as much pics as your ROM can hold
With the outd instruction, there is lurking a horizontal mirror feature
like this one:
Please can one make those sparcles go horizontal :P
I got another one:
blitter transparent draw with cpu cleanup:
1.33 x faster than normal blitter method AND pics fed from rom.
In the time of 3x slower transparent blit, cpu does
1x provide pic from rom
1x read vram
1x write vram (cpu cleanup)
hmm...
why don't use Carchano's ADVRAM in this game for MSX?
well... i don't know if any emulators actually emulate this feature.
anyway, remember Street Fighter Zero/Alpha 2 in the super famicom,
it loads everytime before and after every fight.
this could be the first game to use ADVRAM as a bed test and other
games could follow it.
if framerates be a problem, try first to do a Pocket Fighter clone for MSX first.
or even.... puzzle fighter 2 turbo. =\
please, use Covox or mp3 cart to do the voices ok?
hadouken!!
I actually did some tests way back in the day with very large software sprites, and this is certainly possible to do. You won't hit 60fps for sure, but please remember that a game like this is just as enjoyable when running at 20/25fps. Depending on the actual sprite size, with larger sprites you probably want to go tile-based. While it's true that using small copies is slower than using large ones, it does offer the potential advantage of not having to restore most of the background cells. With some clever mapping you can get away with having to restore at most 50% of the background cells each 'frame', and can use HMMM copies for about half of your sprite, only needing transparent copies for the edges. It also saves a bunch of VRAM for the sprite storage, since you're not storing any duplicate parts of the sprites or any empty spaces. You can store the background in RAM, and if you do this linearly you can use larger commands for adjacent cells when possible, which offers a slight speed gain. Definitely very doable. You won't hit 60fps, but you can create a very nice, 'un-MSX' game for sure...
Note: I also tried executing RAM - VRAM transfers while doing blitter commands at the same time, but ended up with corruption of the commands. I don't know if this was poor coding on my part or a VDP limitation, but if you run into this issue (I got white pixels and whatnot) you may be dealing with a VDP issue (it only appeared on hardware, not on emulators at the time).
@norakomi:
page 0: displayed
page 1: draw overlapping sprites on clean buffer
page 2: blitter cleanup
rotate these 3 every frame.doh
the 'streetfighter' game between Fray and Pixie (in tower of cabin) uses fairly large charcyers, is actually quite impressive and certainly playable. might be interesting to check out how good old MicroCabin got away with it?
I didn't read the entire thing, but estimating performance is not really that difficult.
Since you have large sprites that won't copy within an interrupt. You need double buffering. To increase speed, you want to avoid having to backup the original graphics, so you would use one extra page as an empty background.
Page 0: display buffer 1
Page 1: display buffer 2
Page 2: background buffer
Page 3: player gfx
Assuming 2 player sprites with approximately 96x96 area.
At these sizes, restoring a sprite is about one interrupt. Transparant copying takes about three times as much. Which means that two players take 8 interrupts to update => max framerate 60 / 8 = 7.5 fps.
If page 3 is not enough space, then you'd have two options. Copy into vram with port $98. This will at its fastest (outi) 3.3kB/s. A rectangular area will be slower, so you're looking at 2 ints per sprite => 60 / 12 = 5 fps.
The second option is to use the VDP command to upload directly into a rectangle. However, this requires a status register check for every write, which basically brings the whole thing down even further and you end up with a slideslow. Not recommended.
So the question really is, is 7.5 fps or 5 fps enough for a game like this?