nesdev.org

I thought he meant arbitrary colors.

I meant arbitary colors but not "absolutely" arbitary. Arbitary for human eye. If you cannot distinguish - then it's fine for me.
I need it not from theoretical view but practical usage.

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.

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.

You mean, close enough that you don't notice anything missing?

With 4bpp, you can have 128 onscreen colors, and it's fast enough to do 224x192 at 30fps and still has enough time to update palette attributes and palettes. I think you can exchange up to 16 colors per scanline, but I'm not sure.

Cool! If it's true.
For me "(224x192) x 128 colors x 30 fps" is already acceptable.
It would be perfect to reach one-tile-wide borders instead two-tile-wide of 224 but it's ok.
It's very good! Thanks for the hope!


93143
cool "hcolor"!
what "fps" does it have?
Is that real 256x224 resolution or a scaled smaller one but enhanced to look like 256x224?

greatkreator wrote:cool "hcolor"!
what "fps" does it have?
Is that real 256x224 resolution or a scaled smaller one but enhanced to look like 256x224?

That's real 256x224. hcolor2 gets 417 colours out of 8 bits per pixel using the HDMA method. The game I'm working on gets 548 on the title screen background image; sprite overlays and translucency push it past 800. It may be possible to improve my HDMA scheduling algorithm...

Frame rate is pants (6-7 fps) and you'd get tearing as there simply isn't enough VRAM to buffer it. It is fullscreen after all; neither the SNES nor the Mega Drive was designed to refresh a full screen of graphics at a decent speed, and that goes double for 8bpp...

However, the HDMA technique works fine on vertically trimmed images, such as the 256x144 example I mentioned above. And since HDMA tables can be used in-place anywhere in the ROM, there's no extra DMA load - just the overhead of reassigning a DMA channel twice if you're using all 8 channels for HDMA, which shouldn't hurt the framerate unless you're really pushing the limits... Using an H-IRQ is more involved and consumes more CPU time, but it only needs at most two DMA channels - one for the address, one for the colours - so there should be no extra VBlank overhead at all. EDIT: Not sure where my head was at; the H-IRQ is only really good for changing out a single 4bpp palette (or maybe a larger swath with extended HBlank), assuming it can be timed well enough to overwrite the whole palette in one shot. If you want random access into CGRAM like the hcolor technique uses, HDMA is better.

greatkreator wrote:For me "(224x192) x 128 colors x 30 fps" is already acceptable.

I believe that'd be 121 colours, not 128, since you can't use CGRAM indices that are a nonzero multiple of 16 without using 8bpp (colour #0 in each palette is transparent; global colour #0 is used as the main screen backdrop colour, and there's a whole other register for the subscreen backdrop but I'll ignore that). And of course you're limited to 16 colours (15 plus backdrop) in each 8x8 tile. But since the underlying tile data is only 4bpp, you can do 256x224 at 12 frames per second (cartoon speed)...

Method for compressing high-colour images into 4bpp with multiple palettes: viewtopic.php?f=12&t=12343&p=144374#p144936
Application: viewtopic.php?f=12&t=12738
Code: https://github.com/KhazWolf/SNESTools

Note that it seems to have some trouble with artifacting in areas of nearly constant colour. I've noticed a similar effect in a Mode 7 pixel packing technique I developed along similar lines. This may be fixable.

Note also that it would be possible to expand the method to use sprites as well as BG tiles, so as to use 241 colours instead of 121. This comes with a small bandwidth penalty, since you need to update OAM and the bottom byte of each tilemap entry; unfortunately this means 224x192 no longer works at 30 fps, but 248x184 does. Coupling this with the HDMA technique could produce some impressive high-colour video, but as both methods require extensive preprocessing, this could take a very long time to generate, and actually having the SNES hardware or even an expansion device render into such a format in real time is probably impossible.

To anyone who read the above message soon after I posted it, and concluded therefrom that I was full of $#!+: please be advised that I made a number of critical edits several hours afterward; so far as I can determine, it no longer misrepresents the facts.