Just started evaluating SDL.
After porting one of my GLUT apps over to SDL here are my reactions.
My main goal is to find something besides the decrepit old GLUT to base my
apps and demos on, which has the same simplicity and low profile as GLUT.
I develop exclusively on Win32, but I like to keep my code portable.
Overall SDL seems pretty good. I like the ability to control my own event
loop. And the API is reasonably clean. Support for mouse wheel events,
yea!
Build support for MSVC.Net was excellent. Binaries were available for most
of the libs without me having to build anything. Having links to the all
the SDL-related binaries aggregated on one page would be nice, though.
Instead of one page for SDL, one for SDL-mixer, one for SDL_ttf, etc. It
would be nice if I could tell people - you need SDL, download THIS ONE link
and unzip it to the app folder or WINDOWS/system32 folder.
Downsides:
-
I can’t believe it’s not possible to decide where to place my windows.
Apparently there’s some sort of environment variable hack, but that’s just
unacceptable. Setting the window position is at most two lines of code in
windowing systems that support it, and in those that don’t it can be a no-op
just like setting the window caption currently is. -
OpenGL contexts getting invalidated on window resize. No other toolkit
I’ve tried has this problem. FLTK, FOX, wxWidgets,GLUT, you name it.
Invalidating the context because of a window resize is just rude and
unnecessarily complicates the developer’s life. Not sure if this will help
or not, but here’s a snippet from FOX of how it creates a context on Win32
if it helps (i couldn’t find anything special in the code going on on resize
events, so I’m guessing the mojo is in the context creation?) Maybe it’s
just a matter of setting the context to be shared?:// Conceptually, the bitplane organization should be enough to create
a context;
// but on Windows, there is no concept like a visual, and hence we
need to make
// a dummy window, set its pixel format, and then create the GL
context;
// afterwards, the window is no longer needed and will be deleted.
// Yes, I’m painfully aware that this sucks, but we intend to keep the
// logical model clean come hell or high water…
HWND
wnd=CreateWindow(“FXPopup”,NULL,WS_CHILD|WS_VISIBLE|WS_CLIPSIBLINGS|WS_CLIPCHILDREN|WS_POPUP,0,0,2,2,GetDesktopWindow(),0,(HINSTANCE)(getApp()->display),this);
if(!wnd){ fxerror(“FXGLContext::create(): CreateWindow() failed.\n”);
}
// Get the window's device context
HDC hdc=GetDC((HWND)wnd);
// Set the pixel format
if(!SetPixelFormat(hdc,visual->pixelformat,(PIXELFORMATDESCRIPTOR*)visual->info)){
fxerror(“FXGLContext::create(): SetPixelFormat() failed.\n”);
}
// Make the GL context
ctx=(void*)wglCreateContext(hdc);
if(!ctx){ fxerror("FXGLContext::create(): wglCreateContext()
failed.\n"); }
// I hope I didn't get this backward; the new context obviously has no
// display lists yet, but the old one may have, as it has already been
around
// for a while. If you see this fail and can’t explain why, then that
might
// be what’s going on. Report this to jeroen at fox-toolkit.org
if(sharedctx && !wglShareLists((HGLRC)sharedctx,(HGLRC)ctx)){
fxerror(“FXGLContext::create(): wglShareLists() failed.\n”); }
// Release window's device context
ReleaseDC(wnd,hdc);
// Destroy the temporary window
DestroyWindow(wnd);
xid=(void*)1;
-
No redraw of the OpenGL while resizing. GLUT doesn’t do this, but FOX and
maybe others do. It’s a nice touch. Here’s a snippet from FOX that creates
the Win32 OpenGL windows class which may or may not help:
// OpenGL window class
wndclass.cbSize=sizeof(WNDCLASSEX);
wndclass.style=CS_HREDRAW|CS_VREDRAW|CS_OWNDC; // Redraw all when
resized, OWNER DC for speed
wndclass.lpfnWndProc=(WNDPROC) FXApp::wndproc;
wndclass.cbClsExtra=0;
wndclass.cbWndExtra=sizeof(FXWindow*);
wndclass.hInstance=(HINSTANCE)display;
wndclass.hIcon=NULL;
wndclass.hIconSm=NULL;
wndclass.hCursor=LoadCursor(NULL,IDC_ARROW);
wndclass.hbrBackground=NULL;
wndclass.lpszMenuName=NULL;
wndclass.lpszClassName=“FXGLCanvas”;
RegisterClassEx(&wndclass); -
One build issue. Why are the debug versions of SDL libs set to link
against MSVCRT.DLL rather than MSVCRTD.DLL. This is kind of nonstandard.
It makes things harder to debug, too, because asserts() don’t trigger a
break in the debugger, your program just quietly dies when you use
MSVCRT.DLL. Because of the way MSVC works, which is admittedly annoying,
you’re asking for trouble if you link with two libraries that use different
versions of the run-time libraries (for instance, I was getting crashes on
exit because of it – incompatible versions of atexit probably. See the
GLUT header for one ugly workaround). -
I’m not sure about this one, but am I right in thinking SDL only supports
a single window per app? If so that’s also a pretty severe limitiation.
I’m hoping it’s just a limitation in the demo programs I’ve seen.
So I was clearly hoping that SDL would have more functionality across the
board than GLUT, but it seems that while it has much more functionality in
some areas, there are a few significant annoyances that are going to keep me
from moving over whole-heartedly to SDL. I know this is OpenSource etc etc,
and I know you folks have worked hard to get SDL where it is, and I
definitely applaud your efforts. Just consider this my 2 cents on where a
little bit of resource allocation could have a big payoff. With just a
small effort you could have
something that supercedes GLUT in every way that anyone really cares about,
and ensure SDL’s place as THE low-level cross-platform GL substrate of
choice.
Regards,–
William V. Baxter III, Ph.D.
OLM Digital
Kono Dens Building Rm 302
1-8-8 Wakabayashi Setagaya-ku
Tokyo, Japan 154-0023
+81 (3) 3422-3380