My 2 cents is simply that we should have something that works and is featureful, at present the compatibility mode is not binary compatible which is what distributions would require to replace SDL
1.2 in a meaningful way, we either need real binary compatibility across the board or we need to use a separate base name (Linux distributions version their .so filenames but the includes remain
conflicted among other things, and other platforms do not share this versioned name system).
To summarize that, two options for the way forward:
- SDL2 / SDL2_mixer / SDL2_image / etc (or SDL_mixer2 / SDL_image2 if we prefer that naming scheme)
- direct replacement for existing libs with binary and source compatibility.
There aren’t other meaningful options from what I can see.
Both solutions are absolutely fine with me, I don’t personally see any problems with the existing SDL 1.2 API from a developer perspective, nor do I see a problem with the SDL 1.3 API from a developer
perspective (although at times it is a touch overblown - most apps will never need multiple windows at once and the existing SDL_SetVideoMode is all they ever dreamed of).
There are many little debates we can have over semantics, methodologies, theories and practical solutions, but this particular problem is a simple one with only those two solutions as I see it.On 12/28/2011 03:01 AM, Sam Lantinga wrote:
I’ll be discussing this with Ryan. Originally the idea was for SDL 1.3 to replace SDL 1.2, which means the compatibility layer was extremely useful to minimize the pain with the transition.
At this point they serve two different audiences though, so it may make sense to make a clean break.
At the moment SDL is almost entirely community supported, so I’d love to hear from you guys which you’d prefer and (even better), why?
As an aside, the real reason SDL 1.3 hasn’t been pushed harder for release is the distribution problem of how do you release system libraries of SDL_image, SDL_mixer, etc. for both SDL 1.2 and SDL
1.3? Distributing SDL 1.2 and 1.3 separately is fairly easy to do. Maybe the solution is just to make “2.0” versions of all the satellite libraries and make a clean break there as well.
the other hand, I’ve been able to run some really old games on my computer that didn’t work, simply by replacing the SDL library with a more recent one that supports the system better.
I’m awake because I’m sick atm, so apologies if that didn’t come across very well.
On Thu, Nov 24, 2011 at 3:27 AM, Vittorio Giovara <vittorio.giovara at gmail.com <mailto:vittorio.giovara at gmail.com>> wrote:
+1 of course :)
On Wed, Nov 23, 2011 at 6:57 PM, Ryan C. Gordon <icculus at icculus.org <mailto:icculus at icculus.org>> wrote:
> On 11/23/2011 10:02 AM, Vittorio Giovara wrote:
>> It is perfectly fine to use SDL_NO_COMPAT in my project only, what i
>> mean is that right now the project will fail without the patch i attached.
> Fwiw, I'm considering just ripping out the compat layer (you can always just
> use 1.2 itself, and we can fix the problems that prevent them from
> SDL mailing list
> SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
SDL mailing list
SDL at lists.libsdl.org
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