nesdev.com

Okay, I'm not saying I want to try and make this or anything, but I always enjoyed F-Zero but found its lack of 2 player disappointing. I know how Mario Kart can do it and it seemed like it was purely a design choice, but I realized that the tile map in Mario Kart never appears to get updated, unlike F-Zero. Would this be the reason? I can't really think of a way to have 2 different tile maps given the weird nature of how mode 7 is set up. The only way I can think of it would be to change the data in the tile map mid screen using force blanking, but I don't think you would be able to update it in time without a huge gap between the top and bottom screens. I know that Super Mario Kart has a chip called the DSP-1. What is it for and what does it do? I've heard it helps the game have split screen Mode 7, but this is not very clear. Also, kind of off topic, but do you think that the SNES would be able to expand/shrink about 8 32x32 sprites through software in one frame? I hate the look of the choppy scaling in racing games that use pre rendered scaling sprites.

The tilemap is updated sometimes in Mario Kart. The ice blocks in Vanilla Lake are on the plane.

But were talking about 2 separate tile maps for each screen.

Why did you delete your post? I didn't think like that sounded like that bad of an idea. (Although I have no idea as to how you would implement it.)

You just mean that the map doesn't scroll, so both players can share the same map data at all times.

From your description, I'm presuming F-Zero is very different than this, scrolling the map with wrapping. The wrapping makes it really hard to share, since you always need to keep the scrolling seam behind the player. Since there can only be one scrolling seam on a layer, only one player.

It suddenly started to sound like I hadn't thought it through. The problem is that you don't actually have two tilemaps. They don't wrap at the middle; they wrap at the edges, so it gets difficult to prevent players from driving onto one another's maps. The Mode 7 map is big, but it's not that big...

Regarding sprite scaling, I guess I'll repost that link...

The DSP-1 is doing the 3D point to 2D projection stuff. The pipes in mario circuit, the players, the bananas on the track, the shells.

It's doing polar coordinate stuff to do vector math. (I.e. what angle does the red shell need to travel to hit the nearest player higher in place)

It's at least helping out with that skewing effect that gives the illusion of convergence toward the horizon, although with some precalculated tables F-Zero is able to do it without DSP-1.




You actually bring up a good point. Since there is no way to change the memory offset of the mode-7 bitmap, it always takes up the bottom 32K of VRAM. So you really can't have two independent maps being rotated/scaled, just different views of the same map data.

Exactly. 1024x1024 pixels is a bit small for a full fledged race track. You know, if you think about it, F-Zero was really about 20 years ahead of it's time, seeing that it doesn't allow split screen. I guess the only way to do 2 player (on one console ) would be to have a 64 pixel black bar. About the sprite scaling, is it uncommon to keep switching sprite sizes as the sprite shrinks so you don't run into the sprites per scanline limit? If you were trying to scale a tree in the background that is only 8x16, but its max size is 32x64, you're going to run into problems if there are more than 8. (Which there are going to be because of depth.)


Honestly, I've never understood why they made the setup for mode 7 so different than the other modes when it didn't need to be. (Unless it's some kind of hardware thing I'm not aware of.)

It's totally a hardware thing. If you take a look at the schematics, the two video ram chips are independently addressed. Plus they are Static RAM and they are constantly being read, with no spare cycles to even think about a dram-style refresh. Really this is the best they could come up with at the time and remain affordable.

Oh yeah, has anyone ever made something like a "link cable" for the SNES? (I think I just beat my personal record of how fast I can derail a conversation here. ) (You know, it could almost be like one of those joined arcade cabinets:)




Interesting... Well, it works completely fine the way it is, as long as you are "playing by the rules".

How much graphics DMA is involved here? If you're scaling up to 8 32x32 sprites, that's 4 kB, but you shouldn't need to transfer that every frame. Every two frames, maybe, if not more. OAM shouldn't be full, and CGRAM doesn't change (much?), so there should be nearly 4 kB left for map updates. That's about a frame to rewrite a quarter of the Mode 7 tilemap.

If you could guarantee 4 kB of tilemap DMA every frame, you could just use two submaps of 4 kB each, and completely rewrite each one every other frame, preventing visible seams while also keeping players from crossing between maps. Scroll positions and tilemap position offsets could be tabulated based on angle of view to give maximum valid draw distance without garbage creeping in at the edges of the picture; that way you could maximize resolution without having garbage show up near the horizon...

It'd still probably look a bit blocky compared to the original, but I don't see why it wouldn't work. Split-screen squishes the picture anyway, so you get less detail and maybe a nearer horizon (though caution is advised when doing anything to an F-Zero game that might give players less time to react)...

Wait, how? From what you're describing, it seems like the game would run at 30 fps. Edit: Oh, you mean having two different spaces for each playfield, right? Maybe you could have 2 separate maps and also partially expand the bottom one using force blank. (I guess a 16 pixel black bar wouldn't look too bad? )

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 (alternating between players), to remove the necessity of wrapping. All you have to do is leave enough leeway for scroll changes during the off frame so that you don't get garbage onscreen. You might also be able to back a player's position up towards the edge of his tilemap a bit so as to get more data in view, partially mitigating the effect of the smaller map size and letting the tile resolution be closer to the original.


No, but now that you mention it, that would allow you to double-buffer, if you couldn't manage 4 kB in one frame for some reason.

...this scheme does strike me as a pain to deal with DMA-wise...

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.

Edit: Just look at this:


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.

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.


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.


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:


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?