greatkreator wrote:
Thanks a lot for the first actual numbers!
Is this "256x144x8bpp at 30 fps" using the forced vblank?
Oh yes. I assumed everything outside the 144 lines of the image was forced blank. This gives you (262-144)*(1364-40)/8 = roughly 19 KB of DMA per frame.
If you want to be able to use a different palette for each frame, the final update needs to include a CGRAM refresh; this costs a little over 3 lines of blanking time, so the tile data component can be a maximum of about 18.6 KB. This leaves about 17.4 KB to transfer during the first update, meaning the 3/2 buffering needs to cover around 53.4 KB in total. Two tilemaps of 18 rows each is 2.25 KB, leaving about 8.3 KB for anything else you might want to do.
Alternately, instead of having two tilemaps, you could overwrite the tilemap as well during the final update and limit the data transfer to 17.4 KB, leaving 18.6 KB for the first update and resulting in a 54.6 KB tile data area. But this consumes more DMA bandwidth without saving any VRAM, so I probably wouldn't do it that way.
Quote:
It's not critical to have thousand colors but would be very cool to have at least 100-200 but closer to the fullscreen and as close as possible to at least 30 fps.
Depending on what else you want on screen, that could be possible without having to touch VRAM at all. For instance, you can easily show an array of 256 random colours by changing out CGRAM during VBlank. This is only 512 bytes of DMA, so you don't need forced blank. But the positions of the colour indices on screen will remain the same unless you change either the tilemap or the tile data, so you can't easily do video this way.
You can also boost the colour count by using HDMA, which is capable of changing one CGRAM entry per channel per transfer, meaning you can change 8 colours per line if you don't need HDMA for anything else. I've gotten 8bpp images (not test patterns; real pictures) up near 600 colours this way. You could in principle encode video with this technique, but optimizing the palette and HDMA schedule for an arbitrary image is not a real-time operation even on a modern PC, so generating images in real time on the SNES is probably unfeasible.
Using regular DMA in a carefully timed H-IRQ instead of HDMA might allow a whole 4bpp palette to be changed out every line without compromising any other features (other than hogging the IRQ and burning some CPU time), but I haven't tried it. It's possible that extending HBlank could allow more, but it would probably kill sprites, and you'd have to extend it a lot to quadruple the bandwidth...
Using transparency can boost the number of onscreen colours. An appropriate algorithm might be able to select a pair of colours to blend in order to produce each desired colour, given an evenly-spaced palette. You should be able to do true 12-bit RGB this way, or 15-bit including the per-tile bits in direct colour mode, but it consumes a lot of VRAM...
tepples wrote:
With fractional buffering, don't you also have to rewrite the nametable to reflect the offset into the fractional buffer?
I don't see why. Every case I've looked at has room for two tilemaps if you pack as much data as you can into the final update. Not necessarily full 2 KB tilemaps, but big enough to describe the active area.
Take 5/3 buffering. If you had single-transfer chunks in order, 1-2-3-4-5, your first frame could use chunks 1-3, and your second frame could use chunks 3-5. You'd update 4 and 5 during the first frame, then update 3 and switch tilemaps to display the second frame. Then, during the second frame, you'd update 1 and 2, then update 3 again and switch back to the first tilemap.
Am I missing something? This seems eminently reasonable to me.
greatkreator wrote:
For example my current development for Sega MD/G can produce hundreds of colors with 288x192 and 30 FPS.
I hoped(and still hope) that SNES could do at least the same. Because it has less horizontal resolution at least and capable of displaying much more colors than Sega MD/G "from the box".
I am strongly reminded of
this thread... I have some tricks in mind beyond what was shown or suggested there, but I haven't tried them so I don't know how well they work.