[SDL] free( ptr ) causes SDL Parachute Deployed?

Martell, Jeremiah jmarte01 at bellarmine.edu
Fri Jan 31 23:38:00 PST 2003


> On Fri, Jan 17, 2003 at 04:29:31AM -0500, Patrick McFarland wrote:
>
> 1. the zip contains a file called "world", which causes all sorts of
>    problems because it's followed by a directory called "world".  My
>    primitive OS can't deal with a file and a directory attempting to
>    posess the same name simultaneously,  thus extracting the archive
>    was in itself a minor challenge.

It's not your OS, it's me messing up by zipping into an already-existing zip 
file that contained an uncleaned copy of the tree, complete with bogus 
binaries.  A new zipfile, including updated makefile and SetVideo error 
check, is at:

   http://people.nl.linux.org/~phillips/world/world.zip

It's less than 1/3 the size, much more reasonable.

> 2. once extracted, the "world/" directory didn't compile,  since the
>    pthread library wasn't included.   Strangely enough, the Makefile
>    in the parent directory did include -lpthread.

My code doesn't use pthread, and the pthread library is not required in order 
to compile on my (Debian) system.  I'd like to know where this dependency 
comes from before I change the makefile.  Can you double-check it's actually 
needed, please?  Perhaps it's needed only for some configurations of libsdl.

>    -> You should be using sdl-config --cflags  and sdl-config --libs
>       to get the neccessary flags, if you can't be bothered with the
>       autoconf thing.

<soapbox>A configure script plus all the usual tool-generated boilerplate 
would be several times longer than my entire demo, and I do not want to be 
part of that bloat problem.  Perhaps for a full project, but for a demo.  
Personally, I tend to appreciate a demo that comes with a minimal makefile, 
or none at all, a lot more than one full of files that aren't actually 
needed, which the author didn't write, and do not help me improve my 
understanding of the interesting parts.</soapbox>

I added the sdl-config --cflags, even though I don't see that its doing 
anything useful.  (Maybe it will some time in the future.)  I'm always deeply 
suspicious about flags that begin with _, and -D_REENTRANT is no exception.  
Who/what acts on this flag?  Since my demo is single-threaded, I doubt I need 
it.  Is it needed for, say, Windows?

>    The return -2 check seems a bit strange;  shouldn't it be testing
>    if surface isn't NULL?

Yes, thanks.  I inherited that wrong code from a demo and corrected it some 
time ago.

>    ...run it again and get:
>
> mike at satan:/tmp/z$ ./world
> ./world: can't set video mode... Couldn't find matching GLX visual
>
> At this point I decided there's something wrong with my setup anyway,
> and gave up. :-)

Have you ever run an SDL+OpenGL demo?  I also have a machine here that won't 
run the demo, but does run various SDL games and the non-SDL OpenGL 
xscreensaver-gl demos.  I'd like to get to the bottom of this weirdness.

> If anyone's read this far,  I'd appreciate any ideas of things to try
> to get accelerated OpenGL working properly.

I haven't actually run it on an accelerated machine myself, just software 
Mesa, which explains the low polygon counts.  Please do keep trying things, 
for example, try compiling the original version of the waves demo, which uses 
SDL+OpenGL:

  http://home.in.tum.de/~thomsen/Computer/Programs/WaveGL.html

> Currently, it sometimes
> works.  GLTron for example, seems to be accelerated.  GL screensavers
> from xscreensavers fail fullscreen (with the message "Couldn't create
> GL context for visual 0x21"), but work when windowed.

My demo starts in a window.  Could it have something to do with the requested 
OpenGL attributes?  i.e.,

	SDL_GL_SetAttribute(SDL_GL_DEPTH_SIZE, 32);
	SDL_GL_SetAttribute(SDL_GL_RED_SIZE, 5);
	SDL_GL_SetAttribute(SDL_GL_GREEN_SIZE, 5);
	SDL_GL_SetAttribute(SDL_GL_BLUE_SIZE, 5);
	SDL_GL_SetAttribute(SDL_GL_ALPHA_SIZE, 3);

But I don't see anything odd there.  Need more data...

> GeForce4 MX, evil nVidia binary drivers v4191, stock 2.4.21-pre2 with
> rml's preemptible kernel patches  (same behaviour on earlier versions
> of the drivers and different kernel, too).

Good luck.

Daniel




More information about the SDL mailing list