Espozo wrote:
Actually, Unless you have 2 parts of the tilemap being shared, You couldn't just copy all of the graphics for mode 7 because if I'm not mistaken, you cannot change the position of where you look for the information. It always starts at the beginning of vram, and even if you were going to copy the whole thing twice, you would have literally 0 space for anything else because it would take up the whole 64KBs.
Each player's tilemap in my scheme is only 4 kB. One quarter of the Mode 7 tilemap. This might allow it to update in one frame, or perhaps two if there's no quick way to DMA it.
If a player's quarter-tilemap can't be updated in one shot, some method of double-buffering is necessary to avoid visible artifacts. But hey - there are two free quarters; the player can be switched between the quarter he's on and one of the free ones by altering the scroll parameters. So you can update the free one instead of the live one, and move the player when it's done.
Espozo wrote:
Quote:
No, the scroll position and matrix parameters, and sprite positions, would be updated every frame. But each player's tilemap and scroll position would be totally refreshed every other frame
Which one do you mean? I think you could get away with scrolling at 60 fps just fine, as I don't see anything wrong with it.
I mean both.
Each time the player is put on a fresh tilemap, his scroll position is chosen to maximize the viewable area of the tilemap based on his rotation angle, and the tilemap itself is chosen so that this procedure results in the player looking at the right tiles in the right places. But this doesn't happen every frame, so the player's position will move within this tilemap, and so there has to be enough margin in the initially-chosen position that the player won't end up seeing the edges of the tilemap before another refresh can be accomplished a few frames later.
This gives you 60 fps scroll, on top of a slower scroll update corresponding to the tilemap refresh.
In the attached picture, Player 2 (green) has just had his map refreshed and has been placed in an optimal position on it. Player 1 (red) is using an old map and has thus moved somewhat from his original position. The game will now proceed to update Player 1's map and position.
Attachment:
2pmap_fzero_p2update.png [ 505 Bytes | Viewed 5710 times ]
Of course, the calculated optimal scroll position baseline (where the player is initially going to be put) is needed to define the tilemap, so depending on how fast the DMA happens, the result may be a couple of frames old by the time it's used. Adding normal scrolling to it every frame keeps it up to date so the player doesn't see any judder or lag, though it requires extra viewable-area margin because the player can now get farther from the baseline position before the next refresh.
...
Wait a minute; I just thought of something. What if both players got updated at the same time? With double buffering, there's no reason not to:
Attachment:
2pmap_fzero_halfupdate.png [ 520 Bytes | Viewed 5710 times ]
In this pic, both players are on slightly stale maps (one frame old) and have thus both moved a bit from their original positions. New map data for
both players has been properly compiled and interleaved in WRAM (ie: a miracle happens) and can thus be DMAed to VRAM in two big single-channel bursts instead of 128 little ones. The bright area is a single 4 kB DMA that has just happened. Next frame, another one will happen, and the players will be moved down onto the new maps.
...
Am I making any sense here?