Bregalad wrote:If we don't want to store each character two times in the CHRROM, it'd be good to have the one watching in one direction always BG and the one watching in the other direction always a sprite (using horizontal flipping).
This is a very good idea! There is simply no extra ROM cost then.
Also it'd be good to have some way of uploading the BG character in nametable in a single VBlank, maybe 2 if this simplifies things (split top/bottom, but that will introduce some minor artifacts I guess).
With optimized code, it's probably possible to do it in 1 VBlank, since there is not much else going on. The scrolling is just horizontal, and depending on the nature of the background, VRAM updates might not even be necessary. Sprite DMA is required, as are occasional palette updates.
But even if for some reason it has to be done every 2 VBlanks, since there are 2 name tables it's possible to draw the new tiles to the half that is not on screen, and only show it when the fighter is complete. Double buffering, essentially. Note that this wouldn't even make the game any less smooth, because the fighter can still be moved around, only it's animations will be restricted to 30FPS, which is still more than the typical animation.
That way, when a character jumps over another, they imediately switch the direction they're watching (as in SF2) and the BG character and sprite characters immediately get swapped.
Right. and with priority control it's possible to maintain one in front of the other consistently even when they switch sides, so that a person playing the game will have no way to tell what's happening. Most fighting games have the players always facing each other, which is a requirement for this trick to work.