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

[Drew Sebastino]

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.

If that is possible, then wouldn't you be able to DMA twice as much graphics?

[tepples]

Even if forced blanking during horizontal blanking is possible, this would mean no sprites.

[Drew Sebastino]

Even if forced blanking during horizontal blanking is possible, this would mean no sprites.

I don't plan on halving any sprites, because I want to put everything on BG1 and I would not even have enough vram for a full 8bpp screen and sprites. Just thinking, couldn't you actually update the whole screen in one frame with DMA and several HDMA channels? If I am correct, I am guessing you would load as much of the graphics on the top of the screen with DMA, and also at the top of the screen, you would have several HDMA channels loading graphics at the rest of the screen that DMA does not cover. For every 8 rows of pixels, you could update 1 row using HDMA because each row of pixels in 8bpp mode is 32 bytes, and in HDMA, you can transfer 4 bytes in every row, so 32/4 = 8. Every new HDMA channel would then decrease the amount of rows of HDMA for every row of graphics written. (Sorry for my poorly worded and generally confusing post, I just had trouble writing what I wanted to say.)

[93143]

Not enough bandwidth. You've only got 224 scanlines; with all 8 HDMA channels firing on every line, that's 7,168 bytes. Add that to the 6 kB or so from VBlank, and you're still well short of what would be necessary to update the whole screen in one frame. And since the data is still too big to page, you'll still get tearing.

This is all assuming you can actually do this stunt with force blank and HDMA at all...

Your best bet, if you insist on a flat-rendered 8bpp display, is to make it smaller. This simultaneously increases the DMA bandwidth and reduces the amount of data you need to transfer with it. Getting 60 frames per second would require an unreasonably small display, but you can probably use an adequate amount of the screen at 20 frames per second without the HDMA trick, or 30 with it.

...

NB: Everything I've said thus far assumes an NTSC system. The numbers will be different for PAL; somewhat better, though the same general conclusions should hold.

[Drew Sebastino]

Oh, I was being an Idiot... I was thinking that every pixel was 1 bit, not 1 byte.

And since the data is still too big to page, you'll still get tearing

What do you mean by paging and tearing?

[tepples]

Paging means using half the VRAM for the frame being displayed and half for the next frame as it is being loaded into video memory, then switching the VRAM bank once the frame is completely loaded. At least Elite and Tank Demo use a form of paging.

Tearing means showing a picture on the screen that is only partially updated. Tetris for NES has some visible tearing when updating the matrix after a line clear. And during some particularly fast maneuvers, I've even got Zoop for Super NES to visibly tear.

[koitsu]

Yeah, even with general DMA and HDMA combined there isn't enough time in a single frame to do this. You'd have to settle for actual 30fps. This is how and why arcade games with dedicated hardware for massive sprite or BG overlays and/or lots of ROM space were made. Why does this whole thing make me think of Metal Slug? *cringe* :P

Edit: hey, if every pixel was 1 bit (meaning black-and-white quite literally), you could pull it off. Bad Apple demo for SNES. (I'm certain Tepples will latch on to this, LOL)

[Sik]

NB: Everything I've said thus far assumes an NTSC system. The numbers will be different for PAL; somewhat better, though the same general conclusions should hold.

Vblank time in PAL is gigantic compared to vblank time in NTSC, it's not just somewhat better, it's a lot better. The obvious downside is the lower framerate =P (to put it simple: if you were to trim 16 pixels from the top and the bottom, you'd be nearly doubling blanking time in NTSC without it really being noticeable on the screen size - it's that bad)

Also on top of all this: how much processing time is left to render to such a bitmap in the first place? I guess this would resort to a coprocessor because otherwise I see no way how one could want such a high framerate.