Recently, I was thinking about ways to optimize SNES video rendering... the most notable thing I can see is that the default SNES video format is BGR555, very close to a PC's RGB565. I could just convert the palette entries to this format and do color add/sub a little differently.
The basic method I use now is ppu->bgr555 surface->rgb565 DDraw surface (video or system [optional])->video out. I wanted to cut out the second step, so that it is ppu->rgb565 DDraw surface->video out.
This runs into a few problems. You would have to compensate for RGB888 mode. The only way to do that is to either make two identical copies of your PPU core for each video mode, or add in functions like snes_palette_to_video_palette(), and putpixel(). If you only made one PPU core, you'd only be able to call these functions via pointers to functions or if/switch statements for all possible video modes... not ideal to call a function every time you want to write a pixel to the output buffer... it would be faster to just stick with the 3-stage rendering I had before in that case.
My next idea was that since DDraw can convert a video-memory texture from one format to another, I could create a video memory RGB565 texture and video->video blit to RGB888. For cards that choke when you use video memory surfaces, use system->video buffer->video output instead. The performance seems good, but this method loses the ability to disable the video card's bilinear filtering on the output image, as a system->video blit cannot translate RGB565->RGB888.
Does this idea sound good or bad? And does anyone know how ZSNES handles rendering the screen from the PPU to the DDraw output?
DirectDraw question
Moderator: ZSNES Mods
I assume the same as snes9x, it writes to a buffer first, then tells DirectDraw to draw it.
Anomie can correct me if im wrong, but im pretty sure the buffer is rgb, rather than bgr(ie snes9x has the ppu code write the values to the buffer in the correct order, rather than having to convert it before blitting).
Anomie can correct me if im wrong, but im pretty sure the buffer is rgb, rather than bgr(ie snes9x has the ppu code write the values to the buffer in the correct order, rather than having to convert it before blitting).
Re: DirectDraw question
That's how I implemented 32-bit output for windowed modes.byuusan wrote:My next idea was that since DDraw can convert a video-memory texture from one format to another, I could create a video memory RGB565 texture and video->video blit to RGB888.
MaxSt.