[SDL] SDL 1.3 status ?
havoc at ghdigital.com
Thu Jul 28 00:54:04 PDT 2011
I think that discussion of software OpenGL is off-topic to this discussion as this discussion centers mostly on the reality that FEW people lack hardware acceleration, and those that do, are often a
matter of misconfigured drivers.
I will remark however on the performance of software rasterizers in general.
Anyone not interested in software rasterizer performance on x86 + SSE2 need read no further, but there are some interesting hardware anecdotes here:
Software rasterizers are CPU hogs like nothing else, in my darkplaces engine the DPSOFTRAST code (written as a collaboration between me and Lee Salzman of sauerbraten fame) can max out 6 threads and
find itself severely memory bound, and still only struggle to reach 30fps at 1080P with modest geometry and shaders for optimal fillrate, and Mesa (with the softrast implementation or with llvmpipe)
is sometimes "playable" performance but worse than the custom code in DPSOFTRAST, and far from adequate.
An even worse problem arose however - there is no GOOD way to get system memory pixels to the video card framebuffer, even if you can fill them fast enough.
On X11 there's a way with asynchronous DMA transfers using the XShm shared memory extensions to get the highest performance observed so far, but still not what I would call good.
Other platforms tend to be a bit more mediocre at this, limiting framerate further (to be clear, Windows GDI does not suck at this task, but isn't quite as good as XShm DMA transfers), usually with
So basically... filling pixels on the CPU sucks, blitting them to video memory sucks even more.
Rendering entirely in video memory (D3D/GL/GLES/etc) is win for this reason alone.
On 07/28/2011 12:42 AM, Alberto Luaces wrote:
> Nicholas Vining writes:
>> We added an OpenGL "renderer" in patch 1.0.3 to support the Steam
>> overlay, because Steam's overlay will only work with OpenGL or
>> Direct3D code. Instead of creating an SDL surface for our screen, we
>> run using SDL_OPENGL, create a texture, and then upload a software
>> surface to it per frame using glTexSubImage2D(). We then draw a
>> textured triangle and flip it. We get about five issues being
>> reported, per day, from the userbase. This is the *simplest* possible
>> OpenGL program you could make. It's basically the textured polygon
>> example in the Red Book. And yet, we get support requests from people
>> who use it and can't make it work, or whose machine it just doesn't
>> work on.
>> So, no. It is incorrect to assume that "everybody has OpenGL" on
>> Windows, or even "nearly anybody." I expect a major flare-up in issues
>> *with GDI* once we hit the next few portals, which will be more casual
>> in nature. Heck, not everybody has a version of DirectDraw that works!
>> That's from... what, 1992? Based on what we want to do for the next
>> game, I'm going to end up writing an actual OpenGL renderer, and
>> that's going to be a support nightmare. Them's the breaks, I suppose.
> The use of Mesa 3D graphics library could help for those `GL challenged
> environments'. Mesa 3D can implement OpenGL calls in software — on
> windows, there is a GDI backend.
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier
More information about the SDL