[SDL] [DEMO] Minimal world engine in SDL+OpenGL
phillips at arcor.de
Wed Jan 22 11:18:02 PST 2003
On Wednesday 22 January 2003 10:49, Michael Alger wrote:
> Changing -lSDL to `sdl-config --libs` allows it to compile fine, albeit
> with two warnings:
> world.c: In function `do_button':
> world.c:520: warning: implicit declaration of function `memset'
> worlds/wireframe.c: In function `loader':
> worlds/wireframe.c:25: warning: implicit declaration of function `exit'
The "exit(1)" in wireframe.c is bogus and should be replaced by return -1, as
it is not the data loader's responsibility to decide whether to abort an
application, only to report failure. I didn't catch that because gcc 2.95.4
incorrectly fails to report the implicit definition. (Time to change default
compiler, almost...) The memsets are also bogus and should be deleted but
otherwise they'd need #include <string.h>.
I fixed those glitches, added the pthread dependency to the Makefile and
updated the zip at:
> Anyway, once compiled it still refuses to run for the same reason as
Yes, now the real problem...
> > ...Could it have something to do with the
> > requested OpenGL attributes? i.e.,
> > But I don't see anything odd there. Need more data...
> I don't have a clue about OpenGL, but I had a look at the attributes
> the WaveGL demo uses and compared it to what you used, and changed the:
> SDL_GL_SetAttribute(SDL_GL_DEPTH_SIZE, 32);
> SDL_GL_SetAttribute(SDL_GL_DEPTH_SIZE, 16);
> and now it all works. *shrug*
Nice shooting. OK, your card doesn't support a 32 bit depth buffer, or the
driver doesn't. The (pathetic excuse for) specs on NVidia's site say that
your gforce4 supports a 32 bit depth buffer, so we've got a software problem.
It's unlikely such a gross driver problem would slip through, so naturally I
suspect SDL here, being the youngest of the components involved.
Unfortunately, a 16 bit depth buffer is simply inadequate for a walk-around
environment, as you have to clip away the scene annoyingly far from the
observer's nose in order to preserve enough resolution to render accurately
over a reasonable distance. You'll see artifacts in the shadow demo as a
result of this. The demo can be modified to use a bigger separation between
the shadow polygons and the shadowed surface, but this will break as soon as
you step back some distance from the object. Or the visibility algorithm
could be changed to, for example, bsp, a nontrivial amount of work but
perhaps worth doing. Setting the depth buffer to 32 bits is the only
reasonably convenient solution. With the massive amounts of memory on
graphics cards today, who is going to notice a doubling of the depth buffer
size? This one needs to be tracked down.
> Only problem I found was with resizing the window, which results in a
> lot of redraws and takes a very long time. Perhaps if it processed
> all the resize events and then actually resized only once at the end
> it would be faster.
Could you please define "very long time"?
It's fast here. The demo is limited to 15 screen flips per second (I know,
it's too low, it's on my list of things to fix). It redraws exactly once if
you maximize the window and redraws at the expected rate if you drag the
> I think the slowness may be caused by Sawfish as
> jumping to another workspace (so it wasn't displaying the window) and
> back was a /lot/ faster than watching it keep trying to resize.
It smells like a window manager bug all right. You can do a quick test under
KDE without shutting down Gnome by getting to a new virtual console with,
say, Alt-F2 and doing:
xinit /usr/bin/kde2 -- :1
which will give you a kde session on the Alt-F8 virtual console.
You can also change the off(printf("Resize %i to %i, %i\n"... in the
SDL_VIDEORESIZE event handler to "on", and see how many resize events are
being delivered at which sizes, which may shed some light on the problem.
> Aside from that -- the demos look good. Nice work!
Thanks. Did you find the feature in the waves demo that lets you make
splashes with the mouse?
More information about the SDL