Would it be feasable to put everything on one 8bpp BG layer?

[Drew Sebastino]

How do I put this... Basically, what I am trying to say is if you can load all the data you would normally use for other backgrounds and sprites and make all of them overlap on one layer and update it all every frame. Example:

example 1.png (16.71 KiB) Viewed 4643 times

+

example 2.png (8.5 KiB) Viewed 4644 times

=

example 3.png (20.53 KiB) Viewed 4643 times

The way you would set this all up is to use a large portion of vram to display a 32x28 tile grid of unique 8x8 pixel tiles and a much smaller portion displaying a 32x32 tile map. By the way, are the pictures working, and if not, how do you add pictures?

[tepples]

You can't use [img] to refer to images on your computer's hard drive. Upload them as attachments.

Anyway, yes you can put everything on a big bitmap, but it'll be dog slow if you're updating a significant amount of pixels on the screen.

[Drew Sebastino]

Is that why most 3d games for the Super Nintendo suffer frame rate issues, or is it just because the 3d calculations take a lot of time?

[psycopathicteen]

Both.

[Sik]

Also another problem is that a 32×28 tiles 8bpp bitmap would take up 56KB of VRAM... Do any of the 8bpp modes even allow that? Mode 7 definitely doesn't, even if you switched on the fly mid-screen you'd have 32KB at most, although at least in that case you can use less tiles and stretch it to cover the entire screen =P

[93143]

Also another problem is that a 32×28 tiles 8bpp bitmap would take up 56KB of VRAM... Do any of the 8bpp modes even allow that?

Yes. The tilemap in a normal BG mode (ie: 0-6) is 16-bit, composed of two flip bits, a priority bit, three palette selector bits, and ten bits to denote the actual tile. This means you have up to 1024 tiles, which in 8bpp will completely fill the VRAM.

Mode 7 uses an 8-bit tilemap with no extra features, so you can only have 256 tiles, but since the tilemap is the same size as the tile data (16 kB), the resulting BG layer is huge - which is of course helpful when you're zooming out and viewing it in perspective and such...

...

It's true that a 56 kB background would be impossible to page, though, and the DMA is nowhere near fast enough to update it in one VBlank, so you'd get tearing during updates (on top of a horrible frame rate) unless you were careful to limit the number of tiles changed. Updating the whole screen at 8bpp takes more than 9 frames in the best case, unless you use force blank to get more DMA time.

[Interestingly, Starfox had a small enough playfield (224x190x4bpp) to update at 30fps given the extra VBlank. I wonder if a later-model GSU at 21 MHz might have allowed it to hit that number at times during gameplay, with appropriate programming...?]

[tepples]

The kind of game for which one big 8bpp plane works well is Zoop. Because of the size of its playfield (18x14 cells), it needs to use 12x14 pixels in each cell. It could have used the Puyo Pop (GBA) solution in mode 1 with two 16-color planes scrolled 12 pixels apart and then chop off the bottom row of each 8x8 pixel tile with scroll HDMA, but then that'd leave a single 4-color plane for the playfield backdrop. So instead, it renders in software to a plane that covers most of the screen. But this being an advancing-block puzzle game, most of the field isn't moving at once, except for one advancing row or column of blocks.

[Drew Sebastino]

It's true that a 56 kB background would be impossible to page, though, and the DMA is nowhere near fast enough to update it in one VBlank, so you'd get tearing during updates (on top of a horrible frame rate) unless you were careful to limit the number of tiles changed. Updating the whole screen at 8bpp takes more than 9 frames in the best case, unless you use force blank to get more DMA time.

[Interestingly, Starfox had a small enough playfield (224x190x4bpp) to update at 30fps given the extra VBlank. I wonder if a later-model GSU at 21 MHz might have allowed it to hit that number at times during gameplay, with appropriate programming...?]

I am just thinking about how 93143 said that I would take over 9 frames to update an entire 8bpp screen, but some Super FX games I know , like Doom, are 8bpp and run at a (somewhat) reasonable speed. Does the Super FX chip have anything to do with the fast DMA transfers, or am I crazy and they actually only run at about 10 frames per second?

[3gengames]

SuperFX is replacing the 3Mhz 65816 with a 10Mhz 65816, and later 21Mhz, so that's why games run better and needed it for the complex graphics and 3D math.

[tokumaru]

That helps with the 3D calculations, but what about transferring data to VRAM?

[Sik]

SNES Doom definitely isn't rendering to the entire screen though, I imagine that gets rid of a rather big chunk of the memory needed. Also stupid question, but in what mode does Doom show the graphics? I mean, it isn't full resolution so in theory scaling in mode 7 would work (thereby reducing memory usage even less), but no idea if Doom is doing that.

EDIT: oh, also I suppose mosaic can be used to make the SNES skip every other pixel, so that'd mean even less bandwidth needed if you can make it transfer into every other byte, right?

[93143]

I am just thinking about how 93143 said that I would take over 9 frames to update an entire 8bpp screen, but some Super FX games I know , like Doom, are 8bpp and run at a (somewhat) reasonable speed. Does the Super FX chip have anything to do with the fast DMA transfers, or am I crazy and they actually only run at about 10 frames per second?

My "9 frames" number is for a standard full-screen display, where the active region is 256 dots wide and takes up 224 lines out of 262, giving you about (262-224)*(1364-40)/8 = 6,289 bytes of DMA per frame to transfer 57,344 bytes of graphical data. If you want to refresh the entire screen, that's about six and a half frames per second, with visible tearing because the screen is too big for any paging strategy.

Doom seems to run at 216x176, with a 32-pixel-high status display at the bottom reducing the actual rendered area to 216x144. This means that in principle up to (262-176)*1324/8 = 14,233 bytes of DMA per frame is available to transfer 31,104 bytes of graphical data. That's plenty for 20 frames per second, with ample headroom for OAM and CGRAM updates, so you can use 5/3 buffering regardless of frame rate as long as the Super FX has enough RAM to hold up its end (a 30 kB layer still seems a little big to naïvely double buffer if you want anything else on screen)...

SuperFX is replacing the 3Mhz 65816 with a 10Mhz 65816, and later 21Mhz, so that's why games run better and needed it for the complex graphics and 3D math.

Uh, the Super FX was a custom RISC chip by Argonaut. The SA-1 was a 65816 at 10.74 MHz, but it was never (so far as I know) upgraded to 21 MHz as the Super FX was.

Also, while I believe Super FX games tended to leave the SNES CPU mostly idle, the SA-1 was designed to cooperate with the CPU rather than outright replace it.

in theory scaling in mode 7 would work (thereby reducing memory usage even less), but no idea if Doom is doing that.

I think it's using Mode 3. Actually, I've seen no evidence that the Super FX's PLOT instruction even knows about Mode 7; it seems to be only for bitplanes. You could always render normally in software, I suppose...

I suppose mosaic can be used to make the SNES skip every other pixel, so that'd mean even less bandwidth needed if you can make it transfer into every other byte, right?

That's not how bitplanes work, unfortunately. Each byte contains data for all eight pixels in the row.

As a matter of fact, the VRAM port is two bytes wide, and you can set the word address to increment after writing either the low or high byte. This doesn't really help with the cunning plan I had a while back re: DMAing only the first two bitplanes of a sprite table (if anyone has any great ideas on how to do that without having to reset the DMA every 16 bytes, I'm all ears), but it does mean you can write to either the tilemap or the tiledata in Mode 7 without wasting bandwidth writing to both...

[Sik]

I think it's using Mode 3. Actually, I've seen no evidence that the Super FX's PLOT instruction even knows about Mode 7; it seems to be only for bitplanes. You could always render normally in software, I suppose...

The docs say "256-color mode" without ever mentioning to which mode it's referring to =/ Seriously, Nintendo's documentation is atrocious.

Also PLOT only advances forward horizontally (more specifically, after PLOT is executed the X coordinate advances by 1 while the Y coordinate is untouched), so using PLOT would mean having to substract 1 from R1 and add 1 to R2 after every pixel, so I'd imagine PLOT isn't even used in the first place, it'd be just wasteful.

That's not how bitplanes work, unfortunately. Each byte contains data for all eight pixels in the row.

Ouch, right, for some reason I was under the impression that 8bpp modes were always packed instead of planar (I know that's definitely the case in mode 7).

[psycopathicteen]

Since we had good luck changing bg modes mid scanline, would it be possible to use force blank during H-blank, and use DMA then.

[koitsu]

in theory scaling in mode 7 would work (thereby reducing memory usage even less), but no idea if Doom is doing that.

I think it's using Mode 3.

Correct, Doom for the SNES/SFC uses mode 3. I verified it in SNES9x's debugger. All of Doom's scaling, as I remember it, is purely 100% software; there isn't any "HDMA trickery" or anything else that I know of. Using NO$SNS check out the VRAM, tab "Tiles 8bpp", and watch the window when moving/panning around (even a slight bit) -- all software.