Streetfighter 2 conversion for MSX

I suggest this:

- do both fighters as sprites
- use the VDP to copy from VRAM to the SPT the data of each frame

this allows two 32x64 fighters on the screen and you can store in VRAM as many frames you like

A single sprite frame 32x64 with 3 colors per line takes 8*32 +16*8 (colors) = 256 +128 bytes in vram
Thus, you can store about 170 frames in two pages ;-)this is not a bad idea, however I dont like the limitation of fighters being 32 pixels maximum in width. If you look at the chun-li sprite sheets you will see this is just not good enough.

however you did give me a good idea.
It might be smart to make both fighters as sprites, and then when the sprite is wider than 32 pixels (when a fighter kicks or punches) then the additional graphic data can be copied as a software sprite.
So basically players are hardware sprites AND they will be added with software sprites if needed....
Very good idea, thanx !

About storing the frames in vram, that's a good suggestion, although i dont mind updating the spritedata from ram to vram each frame, since there will be enough time anyway (i'm thinking that 30fps is doable)

Using the VDP for moving the sprite data is a very good method for using efficiently the VRAM
All you need is :
- two SATs for double buffering colors
- a single SPT used for double buffering (positition 0-31 and 32-63 used as two pages)

Differently you have to spend z80 time and you cannot exploit the VRAM efficiently for storing data

Thanks to the "compressed" nature of the data for HW sprites, you will have sufficient VDP time to copy also bitmap "details" to integrate HW sprites when the frames become larger than 32x64

Just use page 0 and 1 that to double buffer the bitmap animations

Consider also that data for HW sprites can safely fit aven under the borders of page 0 and 1 that you will use to double buffer the bitmap animations

... however I dont like the limitation of fighters being 32 pixels maximum in width. If you look at the chun-li sprite sheets you will see this is just not good enough.

this is because we tend to think that sprites layers must be exacly overlapped.
sometimes layers can be X shifted, gaining more width. Of course, you will pay in color freedom.... but look at the main ship in konami nemesis, it's 24 pixels wide and is using two colors blue and white.
Normally 3/4 sprites should be required, but konami used only 2

take a look at this image, is on 16 colours SC5, all the background and the characters
That's screen 5? Incredible!!!

Thanks JohnHassink, the PC tools are far the best tools to develop for any plattform

yes
the command is LMMC (look page 75)
http://www.ccas.ru/brychkov/MSX/V9938_programmers_guide.pdf
it lock the z80 so it is not a good idea

The best thing I can think to is this mixed approach:

1) when the animation frame is composed by sprites + bitmap
send a HMMM command (High speed move VRAM to VRAM) for the bitmap part (LMMM if you need logical operations) and, while the command is being executed, copy RAM to VRAM the sprite definitions using standard VRAM access.
In this was the VDP engine and z80 work in parallel and you get the max video bandwidth
(This is the sole case when the msx video section has an acceptable performance )

2) when, instead, the frame is a pure sprite, just use a HMMM command for moving VRAM to VRAM the sprite definitions.
The z80 will be free of other duties while the vdp engine works

The contra is that you have to keep the sprite definitions both in VRAM and in RAM and that you need two different routines for updating players