Porting the SDL ?

vbt

Staff member
Why not porting the SDL to increase more easily the number of games for the Saturn ? Also maybe there are more developer who know this lib and so more support 🙂 .
 
SDL is built around the concept of compositing to a "master" framebuffer, which I don't think Saturn really supports in the same sense that PC or Dreamcast does. Unless everything is done in software I don't think it's possible to make a 100% compatible implementation, but I think this would mostly only be a problem for programs that try to lock a composited surface to do pixel-blasting on it (e.g. for transition effects). This is mostly speculation though since I've never done any SDL coding.
 
The Saturn doesn't have a "master" framebuffer? It's got a framebuffer just like everything else, doesn't it?
 
Ha, yes, funny.

When you have a master framebuffer, you can overdraw directly without any redraw needed (i learnt something today).

I had the same problem when i used the 32x (seems similar to saturn):

You can only write/read to one FB at once while the other one is displayed/unreadable. When you need to do a overdraw, you must draw all twice (thats frustrating).

But maybe the saturn has a function to copy a framebuffer to the other one wery quickly while displaying (the 32x can't).
 
The Saturn doesn't have a "master" framebuffer? It's got a framebuffer just like everything else, doesn't it?

Actually, Saturn has several buffers that interact differently depending on the graphics mode. As far as I can remember from the docs, there's a pair of 256KB buffers for the VDP1 to draw into (front and back buffer). The VDP2 composites this with its own output (which can be a buffer located in VDP2 VRAM, if bitmap display modes are used) on-the-fly to produce the final video signal. Thus there's no single framebuffer that directly reflects the final image unless you only use one of the two processors. I'm also not sure whether or not the CPU can actually read/write the VDP1 framebuffer; it may only be accessible to the VDP1 and VDP2...
 
Originally posted by ExCyber@Oct 23, 2004 @ 11:48 PM

Thus there's no single framebuffer that directly reflects the final image unless you only use one of the two processors.

You can't capture any of the VDP2 effects either.

I'm also not sure whether or not the CPU can actually read/write the VDP1 framebuffer; it may only be accessible to the VDP1 and VDP2...

You can access the back buffer, but not the front buffer.
 
Isn't the DC SDL *already* software-only? I supposed it rendered everything to a custom buffer in system RAM and just uploaded the result into the PowerVR as a texture.

I don't recall how much RAM there is outside the VDPs in the Saturn... maybe it should be possible to have a custom buffer, render to it, and upload it to the VDP2 as character/tile data.

I recall that a few Saturn games used custom renderers, namely Hexen (Doom-ish renderer for the levels, and used VDP1 sprites layered on top of it) and Amok (it uses a voxel terrain and everything but the hud is done in software - even the 3D ships).

Also, Sonic R and Burning Rangers had SW renderers for specific effects. BR rendered the level at a lower resolution with everything black but the explosions, glass and other things that should be additive-blended into a scaled VDP2 window layer set to blend additively against the VDP1 buffer. Sonic R uses a custom render for the envronment-mapping effects in logo and loading screen, so it surely is possible. But the real question is how hard it is...
 
Back
Top