[SDL] SDL 1.3 status ?
masonwheeler at yahoo.com
Thu Jul 28 07:36:29 PDT 2011
>From: Tim Angus <tim at ngus.net>
>Subject: Re: SDL 1.3 status ?
>On 28/07/2011 14:54, Mason Wheeler wrote:
>> It's not my argument; it's the one that the people arguing *against*
>> my argument used last time this came up.
>Regardless of whose argument it is, it's a poor one.
Fair enough. One less reason to let it influence decisions about the
future of SDL, then. :)
>> I think it's silly to go and throw out the simplifying abstractions
>> that serve me so well in the 90% case (which would basically require
>> me to reimplement all of SDL, most likely with plenty of new bugs)
>> just to get the 10% case working. That's crazy talk.
>I think you're rather over-estimating how complicated OpenGL is to use.
>You certainly don't need to "reimplement all of SDL" to make use of it.
If I can't use SDL textures for sprites, I need something else. If I'm not
using SDL video, I can't use SDL events, because the two are very tightly
coupled. I also can't use SDL_Image, for obvious reasons. Without
SDL video and SDL events, I have no need for the library at all, except
the subset that SDL_Mixer is dependent on.
>> Just out of curiosity, have you ever looked at the implementation of
>> GL_CreateTexture in sdl_render_gl.c?
>I hadn't since I don't use the SDL rendering API and don't really have
>any interest in it. I've looked just now since you've effectively asked
>me to. It looks fine to me? I'm not sure what your point is?
My point is, it's ~150 lines of code and requires 10 local variables, 10
if statements, 5 returns and 4 ifdefs. That's a whole lot of complexity
required to correctly set up a texture, which I'm really glad to not have
to deal with or reimplement.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the SDL