I can’t believe I’m making a thread with that subject, but I just
noticed some quirk. Writing code for a new engine from scratch, wrote
some preliminar video init code that just called
SDL_InitSubSystem(SDL_INIT_VIDEO) and I was expecting it to fail since
SDL_Init() wasn’t called yet… and it worked. Then I decide to take a
look at SDL_Init() to see what was going on:
int
SDL_Init(Uint32 flags)
{
return SDL_InitSubSystem(flags);
}
…huh, is SDL_Init ever expected in the future to do anything else
besides just calling SDL_InitSubSystem as-is? The wiki seems to imply
it may (“If you want to initialize subsystems separately you would
call SDL_Init(0) followed by SDL_InitSubSystem() with the desired
subsystem flag.”), but as it stands, it seems pointless.
At first I thought it handled initialization of system-specific stuff,
but now that I think about it that stuff is most likely being done in
SDL’s own entry point instead. If SDL_Init should be required to be
called first then I imagine it would be nice to make SDL_InitSubSystem
explicitly fail to enforce this (even if it would otherwise work just
fine).
Technically, any deviation from the API specified in the wiki will provoke
undefined behavior, and just because SDL uses this shortcut now doesn’t
mean it will be relied on in the future.
That said, I for one would like the api simplified to conform to actual
practice.On Mon, Aug 31, 2015 at 5:23 AM, Sik the hedgehog < sik.the.hedgehog at gmail.com> wrote:
I can’t believe I’m making a thread with that subject, but I just
noticed some quirk. Writing code for a new engine from scratch, wrote
some preliminar video init code that just called
SDL_InitSubSystem(SDL_INIT_VIDEO) and I was expecting it to fail since
SDL_Init() wasn’t called yet… and it worked. Then I decide to take a
look at SDL_Init() to see what was going on:
int
SDL_Init(Uint32 flags)
{
return SDL_InitSubSystem(flags);
}
…huh, is SDL_Init ever expected in the future to do anything else
besides just calling SDL_InitSubSystem as-is? The wiki seems to imply
it may (“If you want to initialize subsystems separately you would
call SDL_Init(0) followed by SDL_InitSubSystem() with the desired
subsystem flag.”), but as it stands, it seems pointless.
At first I thought it handled initialization of system-specific stuff,
but now that I think about it that stuff is most likely being done in
SDL’s own entry point instead. If SDL_Init should be required to be
called first then I imagine it would be nice to make SDL_InitSubSystem
explicitly fail to enforce this (even if it would otherwise work just
fine).
If I recall, these two entry points used to have different uses, and we
found out right around 2.0.0 shipping that they literally did the same
thing by that point, so it collapsed into what you see there. We didn’t
want to remove one of them outright at that late point in the game,
because it would confuse existing programs (and programmers).
I think for 2.1, we’ll probably remove one of them, though. I don’t
think there’s any intention to make them behave differently in the future.
–ryan.On 08/31/2015 01:24 PM, Raymond Jennings wrote:
Technically, any deviation from the API specified in the wiki will
provoke undefined behavior, and just because SDL uses this shortcut now
doesn’t mean it will be relied on in the future.
That said, I for one would like the api simplified to conform to actual
practice.
So wait, will SDL_InitSubSystem keep working without SDL_Init in the
future or not?
2015-09-02 3:56 GMT-03:00, Ryan C. Gordon :> On 08/31/2015 01:24 PM, Raymond Jennings wrote:
Technically, any deviation from the API specified in the wiki will
provoke undefined behavior, and just because SDL uses this shortcut now
doesn’t mean it will be relied on in the future.
That said, I for one would like the api simplified to conform to actual
practice.
If I recall, these two entry points used to have different uses, and we
found out right around 2.0.0 shipping that they literally did the same
thing by that point, so it collapsed into what you see there. We didn’t
want to remove one of them outright at that late point in the game,
because it would confuse existing programs (and programmers).
I think for 2.1, we’ll probably remove one of them, though. I don’t
think there’s any intention to make them behave differently in the future.
So wait, will SDL_InitSubSystem keep working without SDL_Init in the
future or not? Because in the case where subsystems are initialized
separately anyway it may be better (in my particular case, it would
mean avoiding SDL_Init(0) in a piece of code that’s otherwise devoid
of SDL).
2015-09-02 3:56 GMT-03:00, Ryan C. Gordon :> On 08/31/2015 01:24 PM, Raymond Jennings wrote:
Technically, any deviation from the API specified in the wiki will
provoke undefined behavior, and just because SDL uses this shortcut now
doesn’t mean it will be relied on in the future.
That said, I for one would like the api simplified to conform to actual
practice.
If I recall, these two entry points used to have different uses, and we
found out right around 2.0.0 shipping that they literally did the same
thing by that point, so it collapsed into what you see there. We didn’t
want to remove one of them outright at that late point in the game,
because it would confuse existing programs (and programmers).
I think for 2.1, we’ll probably remove one of them, though. I don’t
think there’s any intention to make them behave differently in the future.
My suggestion would be to remove SDL_Init or downgrade it to a legacy
function call preserved for backward compatibility.
Removing InitSubsystem would remove the ability to boot up SDL subsystems
separately.On Tue, Sep 1, 2015 at 11:56 PM, Ryan C. Gordon wrote:
On 08/31/2015 01:24 PM, Raymond Jennings wrote:
Technically, any deviation from the API specified in the wiki will
provoke undefined behavior, and just because SDL uses this shortcut now
doesn’t mean it will be relied on in the future.
That said, I for one would like the api simplified to conform to actual
practice.
If I recall, these two entry points used to have different uses, and we
found out right around 2.0.0 shipping that they literally did the same
thing by that point, so it collapsed into what you see there. We didn’t
want to remove one of them outright at that late point in the game, because
it would confuse existing programs (and programmers).
I think for 2.1, we’ll probably remove one of them, though. I don’t think
there’s any intention to make them behave differently in the future.
Removing InitSubsystem would remove the ability to boot up SDL subsystems
separately.
Except because SDL_Init already allows that (it’s literally running
the same code), so if the intention is indeed to keep it like this,
the only thing left disagreeing would be the wiki. Hm.
I’d rather deprecate (not remove) SDL_InitSubSystem because it has the
longer name and as such it’s more annoying Although that’d leave
SDL_QuitSubSystem alone (SDL_Quit does indeed behave different). In
that sense, probably the biggest issue here is consistency.
Maybe the best option is to just document SDL_InitSubSystem as being a
working alternative to SDL_Init (and if this ever changes um, make it
impliticly call SDL_Init(0) if needed).
But if SDL_InitSubsystem is removed, can you still run SDL_Init multiple
times for each separate subsystem?On Wed, Sep 2, 2015 at 10:55 AM, Sik the hedgehog < sik.the.hedgehog at gmail.com> wrote:
2015-09-02 14:12 GMT-03:00, Raymond Jennings <@Raymond_Jennings>:
Removing InitSubsystem would remove the ability to boot up SDL subsystems
separately.
Except because SDL_Init already allows that (it’s literally running
the same code), so if the intention is indeed to keep it like this,
the only thing left disagreeing would be the wiki. Hm.
I’d rather deprecate (not remove) SDL_InitSubSystem because it has the
longer name and as such it’s more annoying Although that’d leave
SDL_QuitSubSystem alone (SDL_Quit does indeed behave different). In
that sense, probably the biggest issue here is consistency.
Maybe the best option is to just document SDL_InitSubSystem as being a
working alternative to SDL_Init (and if this ever changes um, make it
impliticly call SDL_Init(0) if needed).
Well…I will say that being able to conditionally enable or disable a
subsystem at runtime, AND do so dynamically as the program’s needs change,
is a feature that we currently have and which I can even see being useful.
At present, you can use InitSubsystem and QuitSubsystem in any arbitrary
sequence to play musical subsystems, and you should be able to do so in the
future.
So if we ditch anything it should be SDL_Init, so that we can still play
subsystem pattycake.
Removing that ability would kinda be a regression of ability, plus I can
foresee toggling a subsystem at runtime even after program initialization
is done. Say, if you load a service module that needs the sound subsystem,
and then quitting the subsystem once the module’s done but the main program
is sitll running.On Wed, Sep 2, 2015 at 2:24 PM, Sik the hedgehog <sik.the.hedgehog at gmail.com wrote:
2015-09-02 17:56 GMT-03:00, Raymond Jennings <@Raymond_Jennings>:
But if SDL_InitSubsystem is removed, can you still run SDL_Init multiple
times for each separate subsystem?
In its current state, yes (since it literally behaves exactly the same
as SDL_InitSubSystem). The question is more whether it should be
allowed to.
Although that’d leave