nesdev.org

Who knows how to use the direct color the most effectively?

I need to display RGB array on the screen. What can SNES do at the most?
As far I know currently it's about 256 unique tiles having 256 colors + somehow to cover the rest with sprites.
If it's not possible to display a lot of colors it would be ok to display at least some limited number.

Do any other suggestions?

Thanks a lot!

The SNES has a native 2048-color mode (RGB443), but the LSB of each color is shared across each 8x8 pixel region. See fullsnes.

Note that for many images, a good palette choice and dithering will produce pretty acceptable 256-color images. Also, the SNES can address 1024 different tiles (when not in Mode 7), and has enough memory for ≈960 unique tiles.

Thanks a lot for the answer!
Sorry for stupid questions but I have just come for the other world and don't know anything at all about this world.
Can you please tell me: how much image data I may reload each frame thus what's the highest FPS may be achieved?

On NTSC with 224 lines, the limit without forced blanking is in the neighborhood of 6K per frame. FPS depends on two things: how much area you need to cover (less means less data) and how many scanlines you are willing to force-blank (more means more time to copy in pixels).

And unless the image is smaller than about 30K, you will get tearing as you show a half-completed frame.

If you're mostly looking for FMV, there is a way to use a 2-pixel mosaic to make it larger at the cost of graininess by interleaving four tiles into each tile and having each one flipped a different way.

Clear! Very interesting! Thank you!

I definitely will need the forced blanking. Does it work OK on SNES without any negative surprises? Just turn the screen at some scan line and you get full speed (about 166 bytes per scan line) DMA. Right?

So there is no space for at least half-screen buffering?
Maybe the buffer using interlace can be used? However I suppose it will produce the same amount of flickering (as in my world Sega MD/G).

I am looking for something like FMV. But not FMV.
So actually the method you are talking about will just scale for example 128x96 to 256x192? Right?

If you're mostly looking for FMV, there is a way to use a 2-pixel mosaic to make it larger at the cost of graininess by interleaving four tiles into each tile and having each one flipped a different way.

If you only need one bg layer, you could use Mode-7 for that.

psycopathicteen you mean to use mode7 and scale x2 to fill all the screen to achive the same effect?

tepples wrote:And unless the image is smaller than about 30K, you will get tearing as you show a half-completed frame.

This isn't quite true. Since the memory isn't actually overwritten during active display, you can use fractional buffering, where the new data goes into free space first, and then after the final frame before the switch you overwrite part of the old data. The idea is essentially to double buffer only what you can't update in one shot. The gain over normal double buffering isn't massive, but it can help.

The game I'm working on uses forced blank to get enough bandwidth for half a playfield worth of Super FX graphics (half of 144x192 at 4bpp = 6912 KB) plus OAM and OBJ table updates and stuff like that. I only need a little over 20 KB of VRAM for the blitted layer instead of 27 KB, since being able to transfer half the data in one (extended) VBlank means I can use 3/2 buffering.

So there is no space for at least half-screen buffering?

There's 64 KB of VRAM, same as the Mega Drive. It's just that 8bpp chews through it twice as fast. According to my calculations, on an NTSC SNES you can do resolutions like 256x144x8bpp at 30 fps, or 216x176x8bpp at 20 fps, if you really push it. At 4bpp you can double buffer a full screen, but your frame rate will be down around 12 fps because VBlank is so short (again, this is on an NTSC machine - PAL is obviously a different story). Unlike Mega Drive, there is no FIFO; if you try to send data to the PPU while it's busy, the data will be lost.

By "half-screen buffering", do you mean what I've called 3/2 buffering above?

Maybe the buffer using interlace can be used?

I'm not sure what you mean by this.

In Mode 5 or 6, setting interlace mode makes the PPU render tiles as half-height, so you're just doubling the amount of data needed to fill an area of the screen (which is already doubled by the fact that Modes 5 and 6 are 512 pixels wide, but neither mode can do 8bpp so you can't get really crazy). In any other mode, yes, you can flip between two tilemaps every frame to get a 448i image (well, you can't move the tilemap in Mode 7, but you can move the camera), but I'm not clear on how that would improve the double-buffering situation.

greatkreator wrote:psycopathicteen you mean to use mode7 and scale x2 to fill all the screen to achive the same effect?

Wolfenstein 3D did exactly that. 8bpp software raycasting at 15 fps with no special chips, because the Mode 7 format is bytemap rather than bitplane; one byte equals one pixel, so it's easy to render into. Also because they were able to draw at 112x80 and just expand it to 224x160 with no CPU overhead...

They didn't exactly push the bandwidth, though - with the screen size they used, they could easily have done 60 fps (with an arbitrarily powerful rendering processor)...

I need to display RGB array on the screen. What can SNES do at the most?

This: https://www.youtube.com/watch?v=sV1w_H8WxUI

Thanks a lot for the first actual numbers!
Is this "256x144x8bpp at 30 fps" using the forced vblank?

Yes I meant 3/2 buffering.

Nevermind! The interlaced graphics is not an option. Too much flickering.

Isn't possible somehow using two layers to enhance scaled image made of 2x2 pixel blocks? Or such scaling available only using single layer?

Concerning 32768 colors:
(: it's not serious. For example I can show about 1500 colors on Sega MD/G but it's absolutely not practical.
Clarification: I meant an RGB array with random values.
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.

93143 wrote:Since the memory isn't actually overwritten during active display, you can use fractional buffering, where the new data goes into free space first, and then after the final frame before the switch you overwrite part of the old data.

With fractional buffering, don't you also have to rewrite the nametable to reflect the offset into the fractional buffer? Or does that fit easily into the time allowed for the last update?

greatkreator wrote:Isn't possible somehow using two layers to enhance scaled image made of 2x2 pixel blocks? Or such scaling available only using single layer?

If you're willing to use mode 7, you can use the one layer that mode 7 gives you. If you need the additional 16-color layer that mode 3 provides, you can interleave pixels into a tile in the 256-color layer in such a way that the mosaic feature can decode them into four distinct tiles. Here's one way to do it:

1. One 4x4 pixel tile at (0, 0), (2, 0), (4, 0), (6, 0), (0, 2), (2, 2), ..., (6, 6), not flipped
2. A second 4x4 pixel tile at (7, 0), (5, 0), (3, 0), (1, 0), (7, 2), (5, 2), ..., (1, 6), flipped horizontally
3. A third 4x4 pixel tile at (0, 7), (2, 7), (4, 7), (6, 7), (0, 5), (2, 5), ..., (6, 1), flipped vertically
4. A fourth 4x4 pixel tile at (7, 7), (5, 7), (3, 7), (1, 7), (7, 5), (5, 5), ..., (1, 1), flipped horizontally and vertically

Mosaic selects only one of the 4x4 pixel tiles, and flipping allows addressing one of the four.

Interleaving for mosaic decoding without flipping is possible if you divide the screen into four horizontal strips, such as four 40-pixel-tall strips of a 160-pixel-tall visible area, and use an HDMA channel to change the layer's horizontal and vertical scrolling.

1. A 4x4 pixel tile in the first strip at (0, 0), (2, 0), (4, 0), (6, 0), (0, 2), (2, 2), ..., (6, 6)
2. A 4x4 pixel tile in the second strip at (1, 0), (3, 0), (5, 0), (7, 0), (1, 2), (3, 2), ..., (7, 6)
3. A 4x4 pixel tile in the third strip at (0, 1), (2, 1), (4, 1), (6, 1), (0, 3), (2, 3), ..., (6, 7)
4. A 4x4 pixel tile in the fourth strip at (1, 1), (3, 1), (5, 1), (7, 1), (1, 3), (3, 3), ..., (7, 7)

At the start of the first strip, set the scroll position to (0, 0). At the start of the second strip, set the scroll position to (1, 0). A caveat to this method is that you are likely to have to give up fractional buffering.

As you become willing to give up more bus time to changing a layer's scroll position with HDMA, more mappings become possible. There's a mapping for 4x16 pixel tiles that preserves locality, which in turn preserves the ability to use fractional buffering. It is the same as the previous mapping, with "first strip", "second strip", "third strip", and "fourth strip" reinterpreted as consecutive rows of 8 scanlines. Or if you're willing to change a layer's scroll position every second scanline, you can use a different mapping that may be more conducive to software rendering:

• y=0: (0, 0), (2, 0), (4, 0), (6, 0), with scroll (0, 0)
• y=1: (1, 0), (3, 0), (5, 0), (7, 0), with scroll (1, -2)
• y=2: (0, 1), (2, 1), (4, 1), (6, 1), with scroll (0, -3)
• y=3: (1, 1), (3, 1), (5, 1), (7, 1), with scroll (1, -5)
• y=4: (0, 2), (2, 2), (4, 2), (6, 2), with scroll (0, -6)
• y=15: (1, 7), (3, 7), (5, 7), (7, 7), with scroll (1, -22)

The horizontal scroll for each 2 pixels is (virtual_y % 2), and the vertical scroll for each scanline is (virtual_y - physical_y). Scroll values in this example are UNTESTED. Do you need me to make you a test for this when I get home from work?

I suspect an XY problem. What were you planning on using the two layers for?

My only purpose is to display random RGB array having for example about 100 colors and with 30 FPS.
As far I see currently I can do it for 256x144 view.

I don't know anything about SNES programming I just started to read tutorial/manuals.

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".

How can you have several hundred colors onscreen on the Sega Genesis?

You can change all palettes per line if you really want, cost is losing some or all the sprites on that line, depending on how many colors you want to load.

greatkreator: Why does it need to be 30fps?

How can you have several hundred colors onscreen on the Sega Genesis?

I guess you've missed out on all excitement about the DMA color trick.

What's the limitation of that mode, though? 64 color per scanline?

psycopathicteen wrote:How can you have several hundred colors onscreen on the Sega Genesis?

Like this, I presume. Apparently you get 160 pixels per scanline, and it keeps the CPU busy 100% of the time, but with the Sega CD you get another CPU that you can use for running the game.