in addition to my previous post, I have a few less code-specific comments.
First of all, I’m glad that SDL 1.3 supports creating and managing several
windows and several OpenGL contexts, and that I do no longer have to call
wglGetProcAddress, wglMakeCurrent and wglSwapBuffers directly.
I’m particularly interested in having a separate “rendering thread” for OpenGL
(I mean for any GL commands including 3D graphics, not only SDL’s GL-based
renderer). MS Windows supports rendering outside the main thread. It worked for
me to deactivate an SDL_GLContext in the main thread (where it was created along
with a window) and activate it in a different thread. It would be nice if SDL
would officially support this (or similar) functionality on appropriate platforms.
One problem I see here is the need to call SDL_GL_SwapWindow in the rendering
thread, which indirectly calls SDL_GetWindowFromID, reading some global,
“unprotected” data. Creating a window at the same time in a different thread may
cause SDL_GetWindowFromID to malfunction. So the caller must make sure these
function calls will not overlap, by using a mutex, for example.
I think this issue might be worth noting in SDL documentation.
Changing SDL’s interface to use the pointers (SDL_Window *) directly instead of
SDL_WindowID might relax some restrictions on multi-threading. What is the
motivation behind SDL_WindowID?
BTW, could you let SDL_GL_GetProcAddress return a pointer-to-function rather
than a pointer-to-object? While C does not care, C++ disallows casting between
those kinds of pointers. When I tried, MinGW GCC 3.4.5 complained about such a
cast when it was a reinterpret_cast, but accepted it in C-style notation (still
compiling C++). I guess this is a GCC compatibility feature, not strictly
compliant with the standard.