Adding features to SDL vs creating a satellite library

Hi Ladies and Gents,

A few of you may know that when people start a thread of ‘can we add
feature X to SDL’, sometimes I’ll jump on the conversation just to mention
building said feature into a satellite library instead, and it’s often met
with some opposition, and I’m not the only one to make this a frequent
suggestion.

With this in mind, I think we need to discuss two things as a community:

  1. What makes feature x better as part of libSDL vs a separate library?

This brings on many questions, like what sort of data should SDL be
exposing, should we provide callback hooks for some internal functions with
OS-specific data, etc.

  1. Is there a better way to handle the distinction between core SDL
    functionality vs satellite?

I’m more keen on this question, personally, because I think I have a
possible solution (maybe for 2.2, since it could be a larger update).

So, what if, as a community, we built a framework wrapper for SDL satellite
libraries that could easily be compiled inside SDL? The basic idea is that
it provides a number of callbacks that could be implemented in a Satellite
library so that we get a standard way for libraries to interact with SDL,
plus a way that would could add a satellite directly into SDL without much
extra effort.

It would be easy for anyone to have a custom built SDL with whatever
satellite libraries they need (hopefully this would mean smaller downloads,
in both quantity of files and file sizes in general), and it would be easy
for those satellite libraries to have contributors since there would be a
standard approach.

It would be easy for Sam, Ryan and other main library devs to test and
potentially include new features into SDL without a pile of hassle.

Unfortunately, it would be a huge overhaul of how SDL internally works, and
may cause some serious performance issues if not implemented well.

I’m mostly just thinking out loud, and I think it is at least a good
community discussion.

-Alex

2014-12-31 0:48 GMT-03:00, Jeffrey Carpenter :

  1. SDL Logging

Another awesome feature that I sometimes feel like could be in its own
library. For the same reasons that I prefaced in #1 ? where I use SDL as the
underlying glue in an engine.

This one can’t be split away. It’s exposed publicly in case a program
could benefit from a logging system, but its main purpose is to allow
SDL itself to log errors (e.g. if initializing something goes wrong,
SDL can log the exact cause that prevented it from working). If you
split it away either 1) SDL becomes unable to do any logging or 2) SDL
becomes dependent on that new library (defeating the whole point).

Sik,

Doh, good point! I remember now dealing with similar sort of dependency problems specific to my engine when I began splitting it up into separate libraries!

Cheers,
Jeffrey Carpenter <@Jeffrey_Carpenter>

-------------- next part --------------
A non-text attachment was scrubbed…
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1572 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20141231/02bc3b08/attachment-0001.bin

Hi,

Interesting topic! I?d like to try and help jumpstart the discussion with a few specific examples of areas where this discussion could possibly benefit from. They are probably not particularly great examples (I?m biting my tongue here as I write this), but alas? I?m also thinking out loud here! :slight_smile: It would be even more awesome if these issues were not actually issues, and something I was just overlooking! :stuck_out_tongue:

  1. SDL_Assert.

I really appreciate the work that has been put into this feature ? thanks Ryan and whomever else I might be leaving out! ? and absolutely love using it everywhere. The (admittedly, minor) problem that I?ve found when using it is that it enforces that I link to SDL explicitly (along with the header files).

If you do as I have, and use SDL as the underlying glue of a game engine (library called from the game), and so happen to go the route of wrapping things into functions and methods that are then called from the game ? you run into this minor nuisance, where you need to link to SDL within the game solely for the use of this feature. For me, the solution is obvious: I?d much rather link to SDL and package it with the game to get this feature than to go without it. (I?ve speculated that I could very well just copy the macro and its dependencies into my own project, but I?d much prefer not to).

This is a particularly tricky issue, though, because the assertion, like all the other implementations I?ve seen, rely on a macro. In this case, the macro is basically a special function loop. A very special function it is ? you can read up on the blog post Ryan made in regards to this that you can find in the header comments as to what it helps achieve. Anyhow, point being, if there was a way of better implementing this feature (wrapping it into a function that could be wrapped by another library) ? I?d be all for it. I?m at a loss of knowing if there even is another way, though, due to the ? rather unique constraints here of needing to evaluate any expression. Nor am I sure it is worth the trouble, if there even is another way.

  1. SDL Logging

Another awesome feature that I sometimes feel like could be in its own library. For the same reasons that I prefaced in #1 ? where I use SDL as the underlying glue in an engine.

  1. SDL_RenderCopy & floating-point math (perhaps the only sane example I might have :-P)

I recently came across an instance where having the ability to pass floating-point values to the destination rectangle of SDL_RenderCopy could simplify some of the mathematics involved in running animation loops ? where you inevitably run into fractional values during certain key frame intervals, etc. such as translating positions and scaling textures. (Internally, the integers you pass to SDL_RenderCopy are ultimately expressed as floating-point values for input to OpenGL ? not sure about DirectX, but presumably the same occurs?)

Anyhow, onwards to my point ? I quickly came to realize that I could very easily provide my own function prototypes that mimic SDL_RenderCopy by doing the internal work of GL_RenderCopy, all while maintaining compatibility with SDL Textures ? by using the public SDL_GL_Texture API. The only problem was that access to the SDL_Texture and SDL_Renderer structs are prohibited, and thus I lose the ability to use the internal error and callback fields specified therein. Perhaps not a big deal in the end (I might be able to provide my own facilities without much additional work?), but I don?t know, I abandoned the idea because of the internal refactoring work that it could involve on my engine, since everything is expressed as integers.

In closing, I?m not sure how sane it would be for the APIs of any of these examples to be refactored to allow for any of the things I?ve attempted to do while using SDL. But I still feel relatively new to all of this ? :stuck_out_tongue: I also hope that my reply doesn?t derail things too much?.. it was not my intention at all.

Cheers,
Jeffrey Carpenter <@Jeffrey_Carpenter>

-------------- next part --------------
A non-text attachment was scrubbed…
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1572 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20141230/31bc3131/attachment-0001.bin

Hi Ladies and Gents,

A few of you may know that when people start a thread of ‘can we add
feature X to SDL’, sometimes I’ll jump on the conversation just to mention
building said feature into a satellite library instead, and it’s often met
with some opposition, and I’m not the only one to make this a frequent
suggestion.

With this in mind, I think we need to discuss two things as a community:

I started writing a reply basically on this topic in another post
(along with my personal wishlist for SDL 2.1/future developments and
how it fits into this somewhat.) As I was doing it over ssh and
timed out and lost the message, I’ll put it here where it belongs.

  1. What makes feature x better as part of libSDL vs a separate library?

This brings on many questions, like what sort of data should SDL be
exposing, should we provide callback hooks for some internal functions with
OS-specific data, etc.

If it exposes access to hardware, it belongs in SDL, obviously.

If it isn’t, I have to ask a few questions:

  1. Is it something often done incorrectly?
  2. Is it something that hooks into SDL’s innards?
  3. Is it something that really CAN be an extension lib?
  4. Is it something that SDL-using devs should always have access to?
  5. Is it something that end users benefit from having in SDL?

I would argue that as a general rule, SDL-using software should NOT
have platform-specific ifdefs and whatnot all over the code. That
may not be true of SDL extension libraries, however. SDL_image has
the ability to access Apple’s native image handling which gets you the
most common sorts of images without bloat. But that requires
SDL_image to build differently on a Mac or iOS than on Linux. And
it’s getting the same for Windows. I’d argue for similar for Haiku
if it’s logical to do it that way on that platform. It’s good for
end users. (It makes debugging a little more complex for devs.)

Some of the things in SDL today probably shouldn’t be there. The
GameController API is literally a helper library for the joystick
system, baked right in to SDL. Turns out that it kind of makes sense
for it to be done that way because it’s good for devs and for users
to have that particular wheel not reinvented squarely on a regular
basis. Managing a controller database probably does not belong in
SDL, but reading from one externally supplied probably does.

The 2D renderer is also kind of bolted on top of the software and 3D
functions. It too is something that could have (and in its current
incarnation should have been) a helper lib. But there were some
promises for the API that were not delivered in 2.0.x that would have
justified it.

  1. Is there a better way to handle the distinction between core SDL
    functionality vs satellite?

Possibly. At the moment, there are a few things that you cannot
necessarily depend on SDL providing and a few components that are
ripe for extension that cannot be extended without adding bloat to
SDL. Here’s my wishlist for 2.1/future development of SDL:

  1. I want to see SDL’s renderer have its scope changed a bit. At
    present, you either create a context for 3D or for the renderer.
    It’s POSSIBLE to mix the two (and easy unless you’re using fixed
    pipeline OpenGL), but you’re not meant to do it.

If I got my way, the idea that renderer “hides” the underlying
context would go away. It should be possible to have more than one
renderer to a given window context too, though there might be some
rules regarding threads, draw order, and (for GL contexts without
shaders) pipeline state preconditions.

This delivers on the promise that the SDL renderer would allow helper
libs like the old 1.2 SDL_console to be used by any program that
wants to. In fact, you could port Windows’ mintty to draw using the
SDL renderer and (given a little 3D work), paste a fully-functioning
UNIX terminal on any quadrilateral in 3D space. SDL’s got MOST of
the pieces necessary to do this already.

  1. Also for the renderer, I’d expose a little more renderer
    internals. Possibly that might have to be renderer-specific, but
    where that’s done all of the 3D renderers (or at least the GL-based
    ones) should do it in the same way. I proposed adding some basic
    primitives that 2D games used to be able to do easily like circles,
    but are harder in 3D. Well, specifically, they’re easier than ever
    if you’ve got shaders, and “impossible” if you don’t.

The arguments against it were many, but they boiled down to three
major ones: Either people didn’t know how to do it and argued that it
was therefore far too difficult to be done, or that so few things
actually use the SDL renderer that it isn’t worth making it larger.
The third argument was that further things belong in a helper lib,
but when it was pointed out that you CANNOT extend the renderer from
the outside, the response was back to don’t use the renderer and get
SDL_gfx instead (which doesn’t support D3D I notice.)

Like with the first change of making a renderer just another way to
draw things into a window, this has the result of making the renderer
more useful in general, and it can become then an answer to the
people who say that the renderer is just extra cruft to the 3D games
that SDL is mainly used to write.

  1. Seemingly going the opposite direction, I’d likely fold
    SDL_GameController into SDL_Joystick. We basically have people
    trying to map anything that resembles a stick and buttons (analog and
    digital, with or without other things) into the GameController model.
    Might as well extend it to cover the things that AREN’T those things
    (wanted anyway) and make it How Things Are Done. Need to expose
    unmapped controls in the raw somehow, as well as provide a means to
    define a few things that aren’t presently in the standard profile
    like accelerometers and the like.

This one’s a little premature in my head, admittedly. That it makes
sense to do so was something that started swirling in my head when I
looked at libretro/RetroArch for a project for my GF^H^Hfiancee(!!
Yup, you read it here first folks, not that it is even remotely
topical other than as an excuse for why I haven’t written the
MSYS2/MingW stuff yet!))

  1. Event subsystem becomes no longer optional but recommended. Like
    HALF of SDL’s targets now absolutely require your app to listen for
    and respond to events. And on every other platform SDL can be used,
    it’s good practice to do so. But you can still shut it off because
    some old, no longer even supported by SDL2, low-horsepower targets
    were better off without it.

  2. Sound recording, very basic, pretty much supporting the headset
    plugged into your controller if you’ve got one.

That’s my wishlist.

I’m more keen on this question, personally, because I think I have a
possible solution (maybe for 2.2, since it could be a larger update).

So, what if, as a community, we built a framework wrapper for SDL satellite
libraries that could easily be compiled inside SDL? The basic idea is that
it provides a number of callbacks that could be implemented in a Satellite
library so that we get a standard way for libraries to interact with SDL,
plus a way that would could add a satellite directly into SDL without much
extra effort.

There’s some promise to this idea, and I’m very much in favor of
modularity in SDL as it is. For example I mentioned libretro before
in passing. In a lot of ways, libretro provides the hardware
abstraction that porters look for SDL to provide, but things written
FOR SDL use a it as a framework to provide a lot of things. Threads,
timing, networking via SDL_net, filesystem abstractions, image
handling via SDL_image, sound and music via SDL_mixer or similar,
etc.

The closer to minimalism in SDL you get, the easier it would be to
port SDL-using code into a libretro or to pare down SDL compile it
FOR libretro. The bigger SDL itself becomes, the harder it is to do
either of those things. It’s a balancing act.

It would be easy for anyone to have a custom built SDL with whatever
satellite libraries they need (hopefully this would mean smaller downloads,
in both quantity of files and file sizes in general), and it would be easy
for those satellite libraries to have contributors since there would be a
standard approach.

It would be easy for Sam, Ryan and other main library devs to test and
potentially include new features into SDL without a pile of hassle.

The issue there is that there needs to be a standard SDL for things
like Linux distributions and an easy way for things to use either an
extension/helper lib or having it baked in to SDL, as needed.

The default needs to be the separate libs with the option to bake in
things for specialized targets. The ability to access more SDL
internals is all that’s really necessary IMO.

Unfortunately, it would be a huge overhaul of how SDL internally works, and
may cause some serious performance issues if not implemented well.

I’m mostly just thinking out loud, and I think it is at least a good
community discussion.

Some things are best implemented as callbacks. Others are good to do
by registering an implementation. I considered once implementing a
"joystick" driver for the iCade. If you’re familiar, the iCade is a
bluetooth keyboard device that sends make/break for a key when a
button is pressed and for another key when a button is released. It
would not be a joystick in the traditional sense, but it would look
like one. If I could do it more cleanly, it’d be pretty trivial to
write the thing.

JosephOn Tue, Dec 30, 2014 at 05:08:13PM -0500, Alex Barry wrote:

Are you suggesting that certain SDL features be able to be cut out of
SDL (or build on their own?) That’s an interesting idea. I think
some things like joysticks have dependency on a window because the
possibility is you’re getting your joysticks from X11 and the like.

But a little effort regarding chunks of SDL and what they need to
work could allow SDL to be a lot more modular, which would make the
extensions that replace bits of SDL a lot easier to write. Very
interesting idea there. Hard to do well, but certainly it can be
done.

JosephOn Tue, Dec 30, 2014 at 09:48:48PM -0600, Jeffrey Carpenter wrote:

Hi,

Interesting topic! I?d like to try and help jumpstart the discussion with a few specific examples of areas where this discussion could possibly benefit from. They are probably not particularly great examples (I?m biting my tongue here as I write this), but alas? I?m also thinking out loud here! :slight_smile: It would be even more awesome if these issues were not actually issues, and something I was just overlooking! :stuck_out_tongue:

  1. SDL_Assert.

I really appreciate the work that has been put into this feature ? thanks Ryan and whomever else I might be leaving out! ? and absolutely love using it everywhere. The (admittedly, minor) problem that I?ve found when using it is that it enforces that I link to SDL explicitly (along with the header files).

If you do as I have, and use SDL as the underlying glue of a game engine (library called from the game), and so happen to go the route of wrapping things into functions and methods that are then called from the game ? you run into this minor nuisance, where you need to link to SDL within the game solely for the use of this feature. For me, the solution is obvious: I?d much rather link to SDL and package it with the game to get this feature than to go without it. (I?ve speculated that I could very well just copy the macro and its dependencies into my own project, but I?d much prefer not to).

This is a particularly tricky issue, though, because the assertion, like all the other implementations I?ve seen, rely on a macro. In this case, the macro is basically a special function loop. A very special function it is ? you can read up on the blog post Ryan made in regards to this that you can find in the header comments as to what it helps achieve. Anyhow, point being, if there was a way of better implementing this feature (wrapping it into a function that could be wrapped by another library) ? I?d be all for it. I?m at a loss of knowing if there even is another way, though, due to the ? rather unique constraints here of needing to evaluate any expression. Nor am I sure it is worth the trouble, if there even is another way.

  1. SDL Logging

Another awesome feature that I sometimes feel like could be in its own library. For the same reasons that I prefaced in #1 ? where I use SDL as the underlying glue in an engine.

  1. SDL_RenderCopy & floating-point math (perhaps the only sane example I might have :-P)

I recently came across an instance where having the ability to pass floating-point values to the destination rectangle of SDL_RenderCopy could simplify some of the mathematics involved in running animation loops ? where you inevitably run into fractional values during certain key frame intervals, etc. such as translating positions and scaling textures. (Internally, the integers you pass to SDL_RenderCopy are ultimately expressed as floating-point values for input to OpenGL ? not sure about DirectX, but presumably the same occurs?)

Anyhow, onwards to my point ? I quickly came to realize that I could very easily provide my own function prototypes that mimic SDL_RenderCopy by doing the internal work of GL_RenderCopy, all while maintaining compatibility with SDL Textures ? by using the public SDL_GL_Texture API. The only problem was that access to the SDL_Texture and SDL_Renderer structs are prohibited, and thus I lose the ability to use the internal error and callback fields specified therein. Perhaps not a big deal in the end (I might be able to provide my own facilities without much additional work?), but I don?t know, I abandoned the idea because of the internal refactoring work that it could involve on my engine, since everything is expressed as integers.

In closing, I?m not sure how sane it would be for the APIs of any of these examples to be refactored to allow for any of the things I?ve attempted to do while using SDL. But I still feel relatively new to all of this ? :stuck_out_tongue: I also hope that my reply doesn?t derail things too much?.. it was not my intention at all.

Cheers,
Jeffrey Carpenter


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Well, I think the internals of SDL should remain inside of SDL - there is
no reason to try and pull them out and allow them to optionally be compiled
in.

What I am suggesting is that new features or satellite libraries could be
compiled in and bundled with SDL in a standard way. This also means that
satellite libraries could be standardized so new developers could jump into
SDL projects more easily.

This is especially good for projects that want to distribute custom builds
of SDL - projects similar to GameMaker and the likes. They would have use
for things like libSDL bundles with SDL_gpu and SDL_net, among other
popular options. Makes distribution and dependency handling a little
easier.

Again, there would be no reason to rip out things like SDL_log, SDL_assert,
etc.

What would be neat is compiling in a satellite library and initializing it
through SDL_init, ie:

SDL_Init( SDL_VIDEO | SDL_NET | SDL_GPU );

So satellite libraries become proper sub-systems, and the framework would
have to be written in a way that the above can also be expressed as:

SDL_Init( SDL_VIDEO );
SDLNet_Init();
GPU_Init();

SDL_Init( SDL_VIDEO );
SDL_InitSubSystem( SDL_NET );
SDL_InitSubSystem( SDL_GPU );

I also want to make clear that this shouldn’t be a wish-list thread, or
about how SDL should expose x/y/z to end-developers. This is about what
actually belongs inside or outside of SDL.

-AlexOn Fri, Jan 2, 2015 at 3:29 AM, T. Joseph Carter < tjcarter at spiritsubstance.com> wrote:

Are you suggesting that certain SDL features be able to be cut out of SDL
(or build on their own?) That’s an interesting idea. I think some things
like joysticks have dependency on a window because the possibility is
you’re getting your joysticks from X11 and the like.

But a little effort regarding chunks of SDL and what they need to work
could allow SDL to be a lot more modular, which would make the extensions
that replace bits of SDL a lot easier to write. Very interesting idea
there. Hard to do well, but certainly it can be done.

Joseph

On Tue, Dec 30, 2014 at 09:48:48PM -0600, Jeffrey Carpenter wrote:

Hi,

Interesting topic! I?d like to try and help jumpstart the discussion with
a few specific examples of areas where this discussion could possibly
benefit from. They are probably not particularly great examples (I?m biting
my tongue here as I write this), but alas? I?m also thinking out loud here!
:slight_smile: It would be even more awesome if these issues were not actually issues,
and something I was just overlooking! :stuck_out_tongue:

  1. SDL_Assert.

I really appreciate the work that has been put into this feature ? thanks
Ryan and whomever else I might be leaving out! ? and absolutely love using
it everywhere. The (admittedly, minor) problem that I?ve found when using
it is that it enforces that I link to SDL explicitly (along with the header
files).

If you do as I have, and use SDL as the underlying glue of a game engine
(library called from the game), and so happen to go the route of wrapping
things into functions and methods that are then called from the game ? you
run into this minor nuisance, where you need to link to SDL within the game
solely for the use of this feature. For me, the solution is obvious: I?d
much rather link to SDL and package it with the game to get this feature
than to go without it. (I?ve speculated that I could very well just copy
the macro and its dependencies into my own project, but I?d much prefer not
to).

This is a particularly tricky issue, though, because the assertion, like
all the other implementations I?ve seen, rely on a macro. In this case, the
macro is basically a special function loop. A very special function it is ?
you can read up on the blog post Ryan made in regards to this that you can
find in the header comments as to what it helps achieve. Anyhow, point
being, if there was a way of better implementing this feature (wrapping
it into a function that could be wrapped by another library) ? I?d be all
for it. I?m at a loss of knowing if there even is another way, though, due
to the ? rather unique constraints here of needing to evaluate any
expression. Nor am I sure it is worth the trouble, if there even is another
way.

  1. SDL Logging

Another awesome feature that I sometimes feel like could be in its own
library. For the same reasons that I prefaced in #1 ? where I use SDL as
the underlying glue in an engine.

  1. SDL_RenderCopy & floating-point math (perhaps the only sane example I
    might have :-P)

I recently came across an instance where having the ability to pass
floating-point values to the destination rectangle of SDL_RenderCopy could
simplify some of the mathematics involved in running animation loops ?
where you inevitably run into fractional values during certain key frame
intervals, etc. such as translating positions and scaling textures.
(Internally, the integers you pass to SDL_RenderCopy are ultimately
expressed as floating-point values for input to OpenGL ? not sure about
DirectX, but presumably the same occurs?)

Anyhow, onwards to my point ? I quickly came to realize that I could very
easily provide my own function prototypes that mimic SDL_RenderCopy by
doing the internal work of GL_RenderCopy, all while maintaining
compatibility with SDL Textures ? by using the public SDL_GL_Texture API.
The only problem was that access to the SDL_Texture and SDL_Renderer
structs are prohibited, and thus I lose the ability to use the internal
error and callback fields specified therein. Perhaps not a big deal in the
end (I might be able to provide my own facilities without much additional
work?), but I don?t know, I abandoned the idea because of the internal
refactoring work that it could involve on my engine, since everything is
expressed as integers.

In closing, I?m not sure how sane it would be for the APIs of any of
these examples to be refactored to allow for any of the things I?ve
attempted to do while using SDL. But I still feel relatively new to all of
this ? :stuck_out_tongue: I also hope that my reply doesn?t derail things too much?.. it
was not my intention at all.

Cheers,
Jeffrey Carpenter


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

    library

Message-ID:
<CAJSO58M1=2NAVt4irvPt__yOaL1UNmjBfiDTBma5p9QEdtsB9g at mail.gmail.com>
Content-Type: text/plain; charset=“utf-8”

No time for a proper reply, so I’ll make it quick.

What would be neat is compiling in a satellite library and initializing it
through SDL_init, ie:

SDL_Init( SDL_VIDEO | SDL_NET | SDL_GPU );

This is a bad idea. You’ll get different groups trying to use the same
value, thereby making satellite libraries incompatible with each
other.

So satellite libraries become proper sub-systems, and the framework would
have to be written in a way that the above can also be expressed as:

SDL_Init( SDL_VIDEO );
SDLNet_Init();
GPU_Init();

This is much better, albeit identical to how it’s currently done.

If you really want to initialize satellite libraries through a
conventional SDL function then add something like this:
int SDL_StringInit( char* );
It would take a string naming the sub-system, and return a result,
just like the other init functions. This completely avoids the
problem.> Date: Fri, 2 Jan 2015 19:34:52 -0500

From: Alex Barry <alex.barry at gmail.com>
To: SDL Development List
Subject: Re: [SDL] Adding features to SDL vs creating a satellite

I’m surprised nobody has yet mentioned to do just the Allegro 5
approach: every subsystem is a completely separate library, period.
The core library is only used as a completely minimalist kernel to
load the other ones. The problem is that it turned into DLL hell,
since every program has to include the DLL for every subsystem it
wants.

Also the problem with a customizable DLL is that somebody may decide
to take it and put it into another program to update the SDL version.
If that newer DLL doesn’t have all the subsystems that other program
wants, it won’t work, and the user will be rightly confused about the
issue. Basically you’re completely breaking ABI compatibility.

2015-01-02 5:08 GMT-03:00, T. Joseph Carter :

Like with the first change of making a renderer just another way to
draw things into a window, this has the result of making the renderer
more useful in general, and it can become then an answer to the
people who say that the renderer is just extra cruft to the 3D games
that SDL is mainly used to write.

If you’re making a 3D game then you shouldn’t use neither the renderer
nor SDL_gpu, your code is already complex enough to probably be able
to cope with 2D on its own (and you’ll want to, to make sure it
doesn’t clash with how it handles 3D), and if it doesn’t then you
should really consider if what you have is good enough.

2015-01-02 5:08 GMT-03:00, T. Joseph Carter :

  1. Event subsystem becomes no longer optional but recommended. Like
    HALF of SDL’s targets now absolutely require your app to listen for
    and respond to events. And on every other platform SDL can be used,
    it’s good practice to do so. But you can still shut it off because
    some old, no longer even supported by SDL2, low-horsepower targets
    were better off without it.

Isn’t the event subsystem a requirement already? SDL won’t poll system
events unless the program polls SDL events, and if system events are
not handled then the operating system will think the program has hung
up (and in some cases it won’t just warn the user, it will outright
terminate the program immediately).

Had to salvage the first quote from another reply.

I’m more keen on this question, personally, because I think I have a
possible solution (maybe for 2.2, since it could be a larger update).

So, what if, as a community, we built a framework wrapper for SDL satellite
libraries that could easily be compiled inside SDL? The basic idea is that
it provides a number of callbacks that could be implemented in a Satellite
library so that we get a standard way for libraries to interact with SDL,
plus a way that would could add a satellite directly into SDL without much
extra effort.

It would be easy for anyone to have a custom built SDL with whatever
satellite libraries they need (hopefully this would mean smaller downloads,
in both quantity of files and file sizes in general), and it would be easy
for those satellite libraries to have contributors since there would be a
standard approach.

It would be easy for Sam, Ryan and other main library devs to test and
potentially include new features into SDL without a pile of hassle.

As Joseph Carter and Sik pointed out, this can break things when your
users attempt to replacve the SDL2 dynamic library with a new one.
Still, the basics of the idea have some merit. Maybe provide a way to
specify extension libraries to SDL via both environment variable (so
that users can choose a set of standard extensions for their personal
machine), and a function that CAN BE (but doesn’t have to be) called
before SDL_Init() and friends.

This doesn’t provide the full functionality of your suggestion, but it
should make it fairly easy to implement the rest, and won’t break your
program if a user does what they’re supposed to be able to.On Tue, Dec 30, 2014 at 05:08:13PM -0500, Alex Barry wrote:

Date: Fri, 2 Jan 2015 00:08:49 -0800
From: “T. Joseph Carter”
To: SDL Development List
Subject: Re: [SDL] Adding features to SDL vs creating a satellite
library
Message-ID: <20150102080849.GJ36326 at amaya.spiritsubstance.com>
Content-Type: text/plain; charset=utf-8; format=flowed

On Tue, Dec 30, 2014 at 05:08:13PM -0500, Alex Barry wrote:

  1. Sound recording, very basic, pretty much supporting the headset
    plugged into your controller if you’ve got one.

I remember seeing something like that in the Mercurial repo, so I
currently assume that at least limited support will make it into the
next release.

Date: Fri, 2 Jan 2015 19:34:52 -0500
From: Alex Barry <alex.barry at gmail.com>
To: SDL Development List
Subject: Re: [SDL] Adding features to SDL vs creating a satellite
library
Message-ID:
<CAJSO58M1=2NAVt4irvPt__yOaL1UNmjBfiDTBma5p9QEdtsB9g at mail.gmail.com>
Content-Type: text/plain; charset=“utf-8”

Well, I think the internals of SDL should remain inside of SDL - there is
no reason to try and pull them out and allow them to optionally be compiled
in.

Assuming that I’m correct about what post you’re refering to, I think
the intention was actually the opposite: take a few components that
SDL relies upon, and make them OPTIONALLY available without the full
library. Maybe as a header library or something, whatever works.

What I am suggesting is that new features or satellite libraries could be
compiled in and bundled with SDL in a standard way. This also means that
satellite libraries could be standardized so new developers could jump into
SDL projects more easily.

I personally think that the big problems with starting SDL2
development right now are:

  1. Incomplete / out-of-date documentation,
  2. No listing of satellite libraries and where to find them.
    Standardizing the libraries doesn’t help if those who need to know
    never find out about them.

Simply put, SDL’s renderer as written cannot reasonably do several
things that are trivial for 2D games, at least one of which I
intended to port to SDL2 at one point only to discover that it
couldn’t handle it. The issues in question were circles, lines, and
flat and filled polygons. (Original used turtle-style graphics(!),
so a port would involve a thin state machine?)

When I proposed adding stuff to SDL’s renderer that’d do
this?something I could do for software, trivially with a shader for
GL/GLES 2+, and with a little effort for GL/GLES 1.x, but would need
someone who knows the API a little better to help me translate to D3D
people absolutely SCREAMED their opposition. The API is frozen! I
never intended to change it, only add. You can’t do curves in GL
1.x! Yes, you can, if you know a little math. It’s not possible to
add any features to the renderer because it’s just TOO HARD to
maintain them and NOBODY EVER can produce results for all the
different renderer targets!!! Um, nobody necessarily has to know
every single API, provided that somebody who knows each one is
prepared to contribute that bit. Oh and finally, THE RENDERER IS
OBSOLETE CRUFT!!! YOU CAN’T BLOAT THE LIBRARY ANY MORE!!!

Which is about the point I threw up my hands in disgust, and
consequently where I kind of stopped working on SDL stuff very
actively. What’s the use in working on a project that isn’t allowed
to change because a bunch of whiny n00b C++ weenies don’t understand
the basics of how to draw a polygon or a circle unless they have a
pre-functioning API call to do it anymore. In 2D no less! Take a
first year undergrad course on geometry with trig, folks! Hell, the
math needed was covered in Math 112 in my local state university.

If you can’t figure out how to draw a filled polygon on any 3D
renderer API given the free help that’s out there for new devs, you
have no business developing 3D games. Unfilled polygons? Well,
that’s a little harder since 3D accelerator hardware is made for
wireframes to be fast, but with just about any hardware we’re going
to see supporting DirectX 9+ and OpenGL 1.4+, you can replace all of
your lines with really skinny rectangles and get faster performance
than you would using legacy OpenGL with GL_LINES.

Circles and arcs? Trivial on modern GL?it’s a pretty basic shader.
On old GL you need to spit out a bunch of triangles?enough to look
circley enough. D3D 9 hardware can cope, I promise you.

And what about software rendering?! Shock, horror! Yeah, the
algorithms for that are older than the majority of the people
freaking out about it. They’re optimized, produce excellent results,
and they just work well.

Either SDL’s renderer needs to be fixed to be useful (including use
alongside native 3D) as was promised when the API was proposed, or
the code needs to be removed entirely. Because this half-useful
thing nobody is allowed to improve for all the above reasons, extend
because its internals are ? internal, or even touch because so many
would-be “game coders” couldn’t render a triangle in a pixel buffer
if their lives depended on it, is actually kind of ridiculous.

JosephOn Fri, Jan 02, 2015 at 07:34:52PM -0500, Alex Barry wrote:

Well, I think the internals of SDL should remain inside of SDL - there is
no reason to try and pull them out and allow them to optionally be compiled
in.

What I am suggesting is that new features or satellite libraries could be
compiled in and bundled with SDL in a standard way. This also means that
satellite libraries could be standardized so new developers could jump into
SDL projects more easily.

This is especially good for projects that want to distribute custom builds
of SDL - projects similar to GameMaker and the likes. They would have use
for things like libSDL bundles with SDL_gpu and SDL_net, among other
popular options. Makes distribution and dependency handling a little
easier.

Again, there would be no reason to rip out things like SDL_log, SDL_assert,
etc.

What would be neat is compiling in a satellite library and initializing it
through SDL_init, ie:

SDL_Init( SDL_VIDEO | SDL_NET | SDL_GPU );

So satellite libraries become proper sub-systems, and the framework would
have to be written in a way that the above can also be expressed as:

SDL_Init( SDL_VIDEO );
SDLNet_Init();
GPU_Init();

SDL_Init( SDL_VIDEO );
SDL_InitSubSystem( SDL_NET );
SDL_InitSubSystem( SDL_GPU );

I also want to make clear that this shouldn’t be a wish-list thread, or
about how SDL should expose x/y/z to end-developers. This is about what
actually belongs inside or outside of SDL.

-Alex

On Fri, Jan 2, 2015 at 3:29 AM, T. Joseph Carter < @T_Joseph_Carter> wrote:

Are you suggesting that certain SDL features be able to be cut out of SDL
(or build on their own?) That’s an interesting idea. I think some things
like joysticks have dependency on a window because the possibility is
you’re getting your joysticks from X11 and the like.

But a little effort regarding chunks of SDL and what they need to work
could allow SDL to be a lot more modular, which would make the extensions
that replace bits of SDL a lot easier to write. Very interesting idea
there. Hard to do well, but certainly it can be done.

Joseph

On Tue, Dec 30, 2014 at 09:48:48PM -0600, Jeffrey Carpenter wrote:

Hi,

Interesting topic! I?d like to try and help jumpstart the discussion with
a few specific examples of areas where this discussion could possibly
benefit from. They are probably not particularly great examples (I?m biting
my tongue here as I write this), but alas? I?m also thinking out loud here!
:slight_smile: It would be even more awesome if these issues were not actually issues,
and something I was just overlooking! :stuck_out_tongue:

  1. SDL_Assert.

I really appreciate the work that has been put into this feature ? thanks
Ryan and whomever else I might be leaving out! ? and absolutely love using
it everywhere. The (admittedly, minor) problem that I?ve found when using
it is that it enforces that I link to SDL explicitly (along with the header
files).

If you do as I have, and use SDL as the underlying glue of a game engine
(library called from the game), and so happen to go the route of wrapping
things into functions and methods that are then called from the game ? you
run into this minor nuisance, where you need to link to SDL within the game
solely for the use of this feature. For me, the solution is obvious: I?d
much rather link to SDL and package it with the game to get this feature
than to go without it. (I?ve speculated that I could very well just copy
the macro and its dependencies into my own project, but I?d much prefer not
to).

This is a particularly tricky issue, though, because the assertion, like
all the other implementations I?ve seen, rely on a macro. In this case, the
macro is basically a special function loop. A very special function it is ?
you can read up on the blog post Ryan made in regards to this that you can
find in the header comments as to what it helps achieve. Anyhow, point
being, if there was a way of better implementing this feature (wrapping
it into a function that could be wrapped by another library) ? I?d be all
for it. I?m at a loss of knowing if there even is another way, though, due
to the ? rather unique constraints here of needing to evaluate any
expression. Nor am I sure it is worth the trouble, if there even is another
way.

  1. SDL Logging

Another awesome feature that I sometimes feel like could be in its own
library. For the same reasons that I prefaced in #1 ? where I use SDL as
the underlying glue in an engine.

  1. SDL_RenderCopy & floating-point math (perhaps the only sane example I
    might have :-P)

I recently came across an instance where having the ability to pass
floating-point values to the destination rectangle of SDL_RenderCopy could
simplify some of the mathematics involved in running animation loops ?
where you inevitably run into fractional values during certain key frame
intervals, etc. such as translating positions and scaling textures.
(Internally, the integers you pass to SDL_RenderCopy are ultimately
expressed as floating-point values for input to OpenGL ? not sure about
DirectX, but presumably the same occurs?)

Anyhow, onwards to my point ? I quickly came to realize that I could very
easily provide my own function prototypes that mimic SDL_RenderCopy by
doing the internal work of GL_RenderCopy, all while maintaining
compatibility with SDL Textures ? by using the public SDL_GL_Texture API.
The only problem was that access to the SDL_Texture and SDL_Renderer
structs are prohibited, and thus I lose the ability to use the internal
error and callback fields specified therein. Perhaps not a big deal in the
end (I might be able to provide my own facilities without much additional
work?), but I don?t know, I abandoned the idea because of the internal
refactoring work that it could involve on my engine, since everything is
expressed as integers.

In closing, I?m not sure how sane it would be for the APIs of any of
these examples to be refactored to allow for any of the things I?ve
attempted to do while using SDL. But I still feel relatively new to all of
this ? :stuck_out_tongue: I also hope that my reply doesn?t derail things too much?.. it
was not my intention at all.

Cheers,
Jeffrey Carpenter


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Can we stay on topic, please?

I don’t know how my threads usually go off the rails like this, but I want
to make it clear, I’m not talking about adding features or breaking ABI
stuff.

What I’m suggesting is implementing hooks for libraries that would highly
encourage a consistent and structured way for SDL satellite libraries to be
written, and making it easier for main SDL developers to include new
features if they sprouted from satellite libraries.

OS-level distribution would be no problem, as long as people are getting
SDL from the official website. There are few cases when independent
developers would package their own SDL customisations, just like now, and
they will distribute this version with their software.

Init variables would be addressed in the merging process/code review, and
would not have conflicts unless we have terrible build testing, but it
seems the build bot would catch that in the worst case scenario.

  • AlexOn 4 Jan 2015 16:06, “T. Joseph Carter” wrote:

Simply put, SDL’s renderer as written cannot reasonably do several things
that are trivial for 2D games, at least one of which I intended to port to
SDL2 at one point only to discover that it couldn’t handle it. The issues
in question were circles, lines, and flat and filled polygons. (Original
used turtle-style graphics(!), so a port would involve a thin state
machine?)

When I proposed adding stuff to SDL’s renderer that’d do this?something I
could do for software, trivially with a shader for GL/GLES 2+, and with a
little effort for GL/GLES 1.x, but would need someone who knows the API a
little better to help me translate to D3D people absolutely SCREAMED their
opposition. The API is frozen! I never intended to change it, only add.
You can’t do curves in GL 1.x! Yes, you can, if you know a little math.
It’s not possible to add any features to the renderer because it’s just TOO
HARD to maintain them and NOBODY EVER can produce results for all the
different renderer targets!!! Um, nobody necessarily has to know every
single API, provided that somebody who knows each one is prepared to
contribute that bit. Oh and finally, THE RENDERER IS OBSOLETE CRUFT!!!
YOU CAN’T BLOAT THE LIBRARY ANY MORE!!!

Which is about the point I threw up my hands in disgust, and consequently
where I kind of stopped working on SDL stuff very actively. What’s the use
in working on a project that isn’t allowed to change because a bunch of
whiny n00b C++ weenies don’t understand the basics of how to draw a polygon
or a circle unless they have a pre-functioning API call to do it anymore.
In 2D no less! Take a first year undergrad course on geometry with trig,
folks! Hell, the math needed was covered in Math 112 in my local state
university.

If you can’t figure out how to draw a filled polygon on any 3D renderer
API given the free help that’s out there for new devs, you have no business
developing 3D games. Unfilled polygons? Well, that’s a little harder
since 3D accelerator hardware is made for wireframes to be fast, but with
just about any hardware we’re going to see supporting DirectX 9+ and OpenGL
1.4+, you can replace all of your lines with really skinny rectangles and
get faster performance than you would using legacy OpenGL with GL_LINES.

Circles and arcs? Trivial on modern GL?it’s a pretty basic shader. On
old GL you need to spit out a bunch of triangles?enough to look circley
enough. D3D 9 hardware can cope, I promise you.

And what about software rendering?! Shock, horror! Yeah, the algorithms
for that are older than the majority of the people freaking out about it.
They’re optimized, produce excellent results, and they just work well.

Either SDL’s renderer needs to be fixed to be useful (including use
alongside native 3D) as was promised when the API was proposed, or the code
needs to be removed entirely. Because this half-useful thing nobody is
allowed to improve for all the above reasons, extend because its internals
are ? internal, or even touch because so many would-be "game coders"
couldn’t render a triangle in a pixel buffer if their lives depended on it,
is actually kind of ridiculous.

Joseph

On Fri, Jan 02, 2015 at 07:34:52PM -0500, Alex Barry wrote:

Well, I think the internals of SDL should remain inside of SDL - there is
no reason to try and pull them out and allow them to optionally be
compiled
in.

What I am suggesting is that new features or satellite libraries could be
compiled in and bundled with SDL in a standard way. This also means that
satellite libraries could be standardized so new developers could jump
into
SDL projects more easily.

This is especially good for projects that want to distribute custom builds
of SDL - projects similar to GameMaker and the likes. They would have use
for things like libSDL bundles with SDL_gpu and SDL_net, among other
popular options. Makes distribution and dependency handling a little
easier.

Again, there would be no reason to rip out things like SDL_log,
SDL_assert,
etc.

What would be neat is compiling in a satellite library and initializing it
through SDL_init, ie:

SDL_Init( SDL_VIDEO | SDL_NET | SDL_GPU );

So satellite libraries become proper sub-systems, and the framework would
have to be written in a way that the above can also be expressed as:

SDL_Init( SDL_VIDEO );
SDLNet_Init();
GPU_Init();

SDL_Init( SDL_VIDEO );
SDL_InitSubSystem( SDL_NET );
SDL_InitSubSystem( SDL_GPU );

I also want to make clear that this shouldn’t be a wish-list thread, or
about how SDL should expose x/y/z to end-developers. This is about what
actually belongs inside or outside of SDL.

-Alex

On Fri, Jan 2, 2015 at 3:29 AM, T. Joseph Carter < tjcarter at spiritsubstance.com> wrote:

Are you suggesting that certain SDL features be able to be cut out of SDL

(or build on their own?) That’s an interesting idea. I think some
things
like joysticks have dependency on a window because the possibility is
you’re getting your joysticks from X11 and the like.

But a little effort regarding chunks of SDL and what they need to work
could allow SDL to be a lot more modular, which would make the extensions
that replace bits of SDL a lot easier to write. Very interesting idea
there. Hard to do well, but certainly it can be done.

Joseph

On Tue, Dec 30, 2014 at 09:48:48PM -0600, Jeffrey Carpenter wrote:

Hi,

Interesting topic! I?d like to try and help jumpstart the discussion
with
a few specific examples of areas where this discussion could possibly
benefit from. They are probably not particularly great examples (I?m
biting
my tongue here as I write this), but alas? I?m also thinking out loud
here!
:slight_smile: It would be even more awesome if these issues were not actually
issues,
and something I was just overlooking! :stuck_out_tongue:

  1. SDL_Assert.

I really appreciate the work that has been put into this feature ?
thanks
Ryan and whomever else I might be leaving out! ? and absolutely love
using
it everywhere. The (admittedly, minor) problem that I?ve found when
using
it is that it enforces that I link to SDL explicitly (along with the
header
files).

If you do as I have, and use SDL as the underlying glue of a game engine
(library called from the game), and so happen to go the route of
wrapping
things into functions and methods that are then called from the game ?
you
run into this minor nuisance, where you need to link to SDL within the
game
solely for the use of this feature. For me, the solution is obvious: I?d
much rather link to SDL and package it with the game to get this feature
than to go without it. (I?ve speculated that I could very well just copy
the macro and its dependencies into my own project, but I?d much prefer
not
to).

This is a particularly tricky issue, though, because the assertion, like
all the other implementations I?ve seen, rely on a macro. In this case,
the
macro is basically a special function loop. A very special function it
is ?
you can read up on the blog post Ryan made in regards to this that you
can
find in the header comments as to what it helps achieve. Anyhow, point
being, if there was a way of better implementing this feature
(wrapping
it into a function that could be wrapped by another library) ? I?d be
all
for it. I?m at a loss of knowing if there even is another way, though,
due
to the ? rather unique constraints here of needing to evaluate any
expression. Nor am I sure it is worth the trouble, if there even is
another
way.

  1. SDL Logging

Another awesome feature that I sometimes feel like could be in its own
library. For the same reasons that I prefaced in #1 ? where I use SDL as
the underlying glue in an engine.

  1. SDL_RenderCopy & floating-point math (perhaps the only sane example I
    might have :-P)

I recently came across an instance where having the ability to pass
floating-point values to the destination rectangle of SDL_RenderCopy
could
simplify some of the mathematics involved in running animation loops ?
where you inevitably run into fractional values during certain key frame
intervals, etc. such as translating positions and scaling textures.
(Internally, the integers you pass to SDL_RenderCopy are ultimately
expressed as floating-point values for input to OpenGL ? not sure about
DirectX, but presumably the same occurs?)

Anyhow, onwards to my point ? I quickly came to realize that I could
very
easily provide my own function prototypes that mimic SDL_RenderCopy by
doing the internal work of GL_RenderCopy, all while maintaining
compatibility with SDL Textures ? by using the public SDL_GL_Texture
API.
The only problem was that access to the SDL_Texture and SDL_Renderer
structs are prohibited, and thus I lose the ability to use the internal
error and callback fields specified therein. Perhaps not a big deal in
the
end (I might be able to provide my own facilities without much
additional
work?), but I don?t know, I abandoned the idea because of the internal
refactoring work that it could involve on my engine, since everything is
expressed as integers.

In closing, I?m not sure how sane it would be for the APIs of any of
these examples to be refactored to allow for any of the things I?ve
attempted to do while using SDL. But I still feel relatively new to all
of
this ? :stuck_out_tongue: I also hope that my reply doesn?t derail things too much?..
it
was not my intention at all.

Cheers,
Jeffrey Carpenter


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

No time for a proper reply, so I’ll make it quick.

What would be neat is compiling in a satellite library and initializing it
through SDL_init, ie:

SDL_Init( SDL_VIDEO | SDL_NET | SDL_GPU );

This is a bad idea. You’ll get different groups trying to use the same
value, thereby making satellite libraries incompatible with each
other.

I’m going to just agree with that one. I know it makes for longer
source code to _InitVideo, _InitNet, _InitGPU, etc. (and actually, my
preference would always be SDL_VideoInit), it’s better to have the
ability to break them out like that and throw them in a try block in
languages with exceptions so if something doesn’t start properly, you
can more easily figure out what, where, and why.

Hey, just because I constantly mock C++ and hate the language (more
accurately its backward-incompatible revisioning) doesn’t mean I fail
to recognize when Bjarne did something useful even by accident. :smiley:

In fact, if I could get pass by reference, exceptions, and thin
support for object types in the base C language, that’d be kind of
neat if they didn’t screw it up. My suggestion would be to look at
things that already implement objects in pure C and examine the stuff
that requires ugly #define macros to accomplish, and start there.
But that’s getting off topic fast. :wink:

So satellite libraries become proper sub-systems, and the framework would
have to be written in a way that the above can also be expressed as:

SDL_Init( SDL_VIDEO );
SDLNet_Init();
GPU_Init();

This is much better, albeit identical to how it’s currently done.

You could actually use the SDL_ namespace if you were going for SDL
extensions, which is not how it’s done presently. So you could have
SDL_NetInit() as noted above. There’s still some question of where
SDL_NetInit might come from?whose _Net subsystem, if there wound up
being more than one? That’s a less major problem than it could
become if the current habit of naming libraries that extend SDL
continues.

Or you could kind of keep it as-is described above, in which case
this idea of baking extensions into SDL becomes more about some build
system consideration to allow libraries to be built as standalone
(the Linux distribution probably preferred way of doing it, though
I’d advise doing it that way generally by default) and perhaps some
sort of hook in library and SDL to allow you to build them as one.

But is that really necessary, aside from maybe making how SDL-using
extension libraries get built somehow “standard” and theoretically
able to be built as many different ways as SDL itself can be? Even
that seems kind of crazy-making, because SDL itself supports a lot of
random build systems. Multiple MSVC versions, a couple of XCode
versions, autoconf with God only knows what vaguely standard UNIX
build environment, CMake theoretically like 2.8 or so(?), premake,
and possibly more not coming to mind just now.

Is that desired for every single random library, by the people
producing those libraries I mean? I don’t have ANY version of MSVC,
and frankly I don’t really want it either. I could dig up an old OS
X 10.7 or even 10.6 to shove in a VM for those versions of XCode, but
should I? And while I like the concept of CMake, its execution I
find woefully inadequate. I haven’t got the first clue about premake
but it doesn’t really interest me.

My preference is simply to use autoconf/automake. Not because I LIKE
either one, nor because I think either one is terribly efficient or
even necessarily good at what they do. But because I can set up a
basic build tree to start a new project in about a minute thanks to a
handy over-glorified shell script built for the job, and it works on
every desktop OS I might ever build for including Windows. Mobile
dev I’ve not really gotten into yet.

Plus, as ugly as it is, judicious use of the poorly utilized ability
to modularize your configure.ac file and some planning of your build
tree makes configure.ac and Makefile.am into essentially what CMake
promised regarding a readable, maintainable build description. Sadly
it’s not possible to match CMake’s promise of a self-contained one
simple thing that works everywhere (and even CMake has failed to
deliver the “, and works well” that should follow?), but nobody else
has done any better.

The result is that if you NEED something else (XCode for iOS maybe),
you only need to read through a relatively short/sweet list of things
to be checked for in configure.ac so that you can set up your build
system accordingly and produce the requisite config.h, and then look
at Makefile.am for a list of what source files to build. You could
almost automake the latter if other build systems followed any kind
of documented standard and remained backward compatible from version
to version.

If you really want to initialize satellite libraries through a
conventional SDL function then add something like this:
int SDL_StringInit( char* );
It would take a string naming the sub-system, and return a result,
just like the other init functions. This completely avoids the
problem.

Again, I’ll note my preference is for this to be how it’s done, if
anything. But again if it’s just a matter of namespace, it’s purely
an aesthetics discussion. If it’s about building together, then I
don’t know why you must compile two libraries into one pretty much
ever. If it’s about extensions having deeper access to the core of
SDL so that say, SDL_gpu could extend the razzin-frazzin render API
rather than an alternative of limited usefulness, then maybe the REAL
issue is that it should be possible to do that somehow with the
system as it is designed today?

Continuing with the renderer discussion for just a moment, say you
were to create one using Apple’s Metal API for iOS. It’s not ready
to go in to SDL proper yet. So do you maintain a fork of SDL, or
could you maybe just call a function to tell SDL that hey, here’s a
new renderer for you!

Actually, if I could access enough SDL innards to do it, I’d make a
driver for the iCade controllers as an SDL extension library. It
would need to register a new system-level joystick driver (which is
not currently possible, but easily fixed). If it detects (if it can
detect) a connected iCade, it’d register a new joystick device (and a
digital-only GameController mapping). Then when key commands from
the iCade “keyboard” came in, the library would eat them before your
app gets them and spit out the joystick events/state needed.

Could put that into SDL, but it’s a tremendous hack (which happens to
have been widely used) which is technically now obsolete. You’re
supposed to use Apple controllers from now on. Except a lot of
people still have iCades and kind of prefer them to the first couple
of generations of MFi controllers. Oh, and it’s a simple enough
device to support, so why not support it too?

Because anywhere but iOS and maybe Android, it’s probably silly to
bother, though technically there’s no reason why you couldn’t use
them on any desktop OS. And because it’s kind of obsolete hardware,
shoving into mainline SDL probably doesn’t make a whole lot of sense
anymore. Except again that a lot of people still have the things and
a lot of games still work with them on mobile devices. And it’s
currently not possible to support it in a transparent way without
extending SDL in some fashion.

I could give you my little shim to add to your SDL program that does
approximately the same thing as the above without actually using any
internals. Your system keyboard is an iCade controller at that point
and you’ve gotta ignore events yourself, and you have an illegal fake
joystick (fake instance ID that theoretically could but won’t
actually exist on a real system) which cannot be queried (fake) but
does send press/release events. If I ever had a real iCade to test
it with, I’d have posted it to the list with the big disclaimer on it
that it does something that should be considered a big no-no, but
happens to work if you don’t get it wet, don’t feed it after
midnight, etc.

Joseph

It’s not just the renderer API though, it’s the entire SDL that’s
like that. Every time anybody ever suggests the possibility of adding
something nearly everybody will scream to not add it to SDL and to
maybe put it into its own separate library (often ignoring the
existing ones as well, ironically). It’s like people want SDL to be
frozen forever and the only development to be bugfixes.

I think this is pretty much the purpose of this whole thread, to see
how we move forwards, because as it stands, if it was up to the
mailing list SDL should be completely frozen. Normally Sam or Ryan
would get in and take a decision settling the whole matter, but lately
they don’t seem to be around here (vacation?).

PS: actually I’d like to have those improvements you mentioned for the
renderer API. Actually, something like Allegro (pre-version 5) would
be nice (OK, maybe drop ancient stuff like palettes, but should be a
good guideline).

2015-01-04 18:06 GMT-03:00, T. Joseph Carter :> Simply put, SDL’s renderer as written cannot reasonably do several

things that are trivial for 2D games, at least one of which I
intended to port to SDL2 at one point only to discover that it
couldn’t handle it. The issues in question were circles, lines, and
flat and filled polygons. (Original used turtle-style graphics(!),
so a port would involve a thin state machine?)

When I proposed adding stuff to SDL’s renderer that’d do
this?something I could do for software, trivially with a shader for
GL/GLES 2+, and with a little effort for GL/GLES 1.x, but would need
someone who knows the API a little better to help me translate to D3D
people absolutely SCREAMED their opposition. The API is frozen! I
never intended to change it, only add. You can’t do curves in GL
1.x! Yes, you can, if you know a little math. It’s not possible to
add any features to the renderer because it’s just TOO HARD to
maintain them and NOBODY EVER can produce results for all the
different renderer targets!!! Um, nobody necessarily has to know
every single API, provided that somebody who knows each one is
prepared to contribute that bit. Oh and finally, THE RENDERER IS
OBSOLETE CRUFT!!! YOU CAN’T BLOAT THE LIBRARY ANY MORE!!!

Which is about the point I threw up my hands in disgust, and
consequently where I kind of stopped working on SDL stuff very
actively. What’s the use in working on a project that isn’t allowed
to change because a bunch of whiny n00b C++ weenies don’t understand
the basics of how to draw a polygon or a circle unless they have a
pre-functioning API call to do it anymore. In 2D no less! Take a
first year undergrad course on geometry with trig, folks! Hell, the
math needed was covered in Math 112 in my local state university.

If you can’t figure out how to draw a filled polygon on any 3D
renderer API given the free help that’s out there for new devs, you
have no business developing 3D games. Unfilled polygons? Well,
that’s a little harder since 3D accelerator hardware is made for
wireframes to be fast, but with just about any hardware we’re going
to see supporting DirectX 9+ and OpenGL 1.4+, you can replace all of
your lines with really skinny rectangles and get faster performance
than you would using legacy OpenGL with GL_LINES.

Circles and arcs? Trivial on modern GL?it’s a pretty basic shader.
On old GL you need to spit out a bunch of triangles?enough to look
circley enough. D3D 9 hardware can cope, I promise you.

And what about software rendering?! Shock, horror! Yeah, the
algorithms for that are older than the majority of the people
freaking out about it. They’re optimized, produce excellent results,
and they just work well.

Either SDL’s renderer needs to be fixed to be useful (including use
alongside native 3D) as was promised when the API was proposed, or
the code needs to be removed entirely. Because this half-useful
thing nobody is allowed to improve for all the above reasons, extend
because its internals are ? internal, or even touch because so many
would-be “game coders” couldn’t render a triangle in a pixel buffer
if their lives depended on it, is actually kind of ridiculous.

Joseph

On Fri, Jan 02, 2015 at 07:34:52PM -0500, Alex Barry wrote:

Well, I think the internals of SDL should remain inside of SDL - there is
no reason to try and pull them out and allow them to optionally be compiled
in.

What I am suggesting is that new features or satellite libraries could be
compiled in and bundled with SDL in a standard way. This also means that
satellite libraries could be standardized so new developers could jump into
SDL projects more easily.

This is especially good for projects that want to distribute custom builds
of SDL - projects similar to GameMaker and the likes. They would have use
for things like libSDL bundles with SDL_gpu and SDL_net, among other
popular options. Makes distribution and dependency handling a little
easier.

Again, there would be no reason to rip out things like SDL_log, SDL_assert,
etc.

What would be neat is compiling in a satellite library and initializing it
through SDL_init, ie:

SDL_Init( SDL_VIDEO | SDL_NET | SDL_GPU );

So satellite libraries become proper sub-systems, and the framework would
have to be written in a way that the above can also be expressed as:

SDL_Init( SDL_VIDEO );
SDLNet_Init();
GPU_Init();

SDL_Init( SDL_VIDEO );
SDL_InitSubSystem( SDL_NET );
SDL_InitSubSystem( SDL_GPU );

I also want to make clear that this shouldn’t be a wish-list thread, or
about how SDL should expose x/y/z to end-developers. This is about what
actually belongs inside or outside of SDL.

-Alex

On Fri, Jan 2, 2015 at 3:29 AM, T. Joseph Carter < tjcarter at spiritsubstance.com> wrote:

Are you suggesting that certain SDL features be able to be cut out of SDL
(or build on their own?) That’s an interesting idea. I think some
things
like joysticks have dependency on a window because the possibility is
you’re getting your joysticks from X11 and the like.

But a little effort regarding chunks of SDL and what they need to work
could allow SDL to be a lot more modular, which would make the extensions
that replace bits of SDL a lot easier to write. Very interesting idea
there. Hard to do well, but certainly it can be done.

Joseph

On Tue, Dec 30, 2014 at 09:48:48PM -0600, Jeffrey Carpenter wrote:

Hi,

Interesting topic! I?d like to try and help jumpstart the discussion
with
a few specific examples of areas where this discussion could possibly
benefit from. They are probably not particularly great examples (I?m
biting
my tongue here as I write this), but alas? I?m also thinking out loud
here!
:slight_smile: It would be even more awesome if these issues were not actually
issues,
and something I was just overlooking! :stuck_out_tongue:

  1. SDL_Assert.

I really appreciate the work that has been put into this feature ?
thanks
Ryan and whomever else I might be leaving out! ? and absolutely love
using
it everywhere. The (admittedly, minor) problem that I?ve found when
using
it is that it enforces that I link to SDL explicitly (along with the
header
files).

If you do as I have, and use SDL as the underlying glue of a game engine
(library called from the game), and so happen to go the route of
wrapping
things into functions and methods that are then called from the game ?
you
run into this minor nuisance, where you need to link to SDL within the
game
solely for the use of this feature. For me, the solution is obvious: I?d
much rather link to SDL and package it with the game to get this feature
than to go without it. (I?ve speculated that I could very well just copy
the macro and its dependencies into my own project, but I?d much prefer
not
to).

This is a particularly tricky issue, though, because the assertion, like
all the other implementations I?ve seen, rely on a macro. In this case,
the
macro is basically a special function loop. A very special function it
is ?
you can read up on the blog post Ryan made in regards to this that you
can
find in the header comments as to what it helps achieve. Anyhow, point
being, if there was a way of better implementing this feature
(wrapping
it into a function that could be wrapped by another library) ? I?d be
all
for it. I?m at a loss of knowing if there even is another way, though,
due
to the ? rather unique constraints here of needing to evaluate any
expression. Nor am I sure it is worth the trouble, if there even is
another
way.

  1. SDL Logging

Another awesome feature that I sometimes feel like could be in its own
library. For the same reasons that I prefaced in #1 ? where I use SDL as
the underlying glue in an engine.

  1. SDL_RenderCopy & floating-point math (perhaps the only sane example I
    might have :-P)

I recently came across an instance where having the ability to pass
floating-point values to the destination rectangle of SDL_RenderCopy
could
simplify some of the mathematics involved in running animation loops ?
where you inevitably run into fractional values during certain key frame
intervals, etc. such as translating positions and scaling textures.
(Internally, the integers you pass to SDL_RenderCopy are ultimately
expressed as floating-point values for input to OpenGL ? not sure about
DirectX, but presumably the same occurs?)

Anyhow, onwards to my point ? I quickly came to realize that I could
very
easily provide my own function prototypes that mimic SDL_RenderCopy by
doing the internal work of GL_RenderCopy, all while maintaining
compatibility with SDL Textures ? by using the public SDL_GL_Texture
API.
The only problem was that access to the SDL_Texture and SDL_Renderer
structs are prohibited, and thus I lose the ability to use the internal
error and callback fields specified therein. Perhaps not a big deal in
the
end (I might be able to provide my own facilities without much
additional
work?), but I don?t know, I abandoned the idea because of the internal
refactoring work that it could involve on my engine, since everything is
expressed as integers.

In closing, I?m not sure how sane it would be for the APIs of any of
these examples to be refactored to allow for any of the things I?ve
attempted to do while using SDL. But I still feel relatively new to all
of
this ? :stuck_out_tongue: I also hope that my reply doesn?t derail things too much?..
it
was not my intention at all.

Cheers,
Jeffrey Carpenter


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

One of the promises in the early SDL 1.3 daze was the renderer. At
the time, a popular helper lib for SDL 1.2 was SDL_console, a
quake-style console for 2D SDL games. It was textually simplistic, a
subset of ASCII using pre-rendered pixmap fonts rather than TTF and
Unicode and whatnot. But it managed the basics of text ring buffer
that could be scrolled, a functioning line editor, etc. You could
easily have extended it today to use SDL_ttf and Unicode text.

But it drew using 2D. So it would draw using the SDL renderer in
SDL2, if it ever had been ported.

If you want a drop-in console, maybe because you are mostly just
using it for debugging purposes rather than necessarily for the
purpose to which FPS games tend to put it, or just to make it so you
don’t have to reinvent that particular wheel, the ability to stick
SDL’s renderer on top of an OpenGL screen might be useful. And in
those 1.3 days, that was supposed to be possible with SDL. The claim
was that any of those 2D libraries would be useful no matter whether
you were working in 2D or 3D. Sure, you might be able to pump out
the triangles a little faster if you rewrote SDL2_console’s 2D draw
functions to spit out native OpenGL, but any game I could play with
the hardware I owned at the time (a GF4(!)) wouldn’t have appreciably
impacted the frame rate with the console open.

That promise was never delivered, and SDL_console never got ported or
expanded. And I still see people asking how to reinvent that wheel
for their games, sometimes getting bad advice on how to do it
"properly" (wasting and/or leaking mem all over the place), but with
nice efficient 3D rendering. If the result would’ve been worthwhile,
I’d have ported SDL_console to SDL2’s renderer myself. I’d leave the
TTF and Unicode to someone else because debugging in ASCII is all I’d
ever use myself, but there’s no point if I couldn’t use the result in
OpenGL-based stuff. I’ll just either reinvent the wheel myself?it’s
not like I haven’t invented this particular wheel a time or two
myself already over the years.

So much for code reusability. sigh :slight_smile:

Actually, here’s one I happen to own full rights to, and it uses a
Quake3 conchars font. Meh, OpenGL 1.4 target, calling abstracted
vertex array functions that could cope with falling back to not
having them. Yeah, I can rewrite that easily enough. So that solves
MY problem the next time I need one. Totally different API than
SDL_console used, but I am familiar with this API because it’s mine.
Commands set something that looks like Quake CVars, but are kind of
uglier in code. Ugly yes, but fast because the “CVar” is typed and
the console structure gets a pointer to the variable in the subsystem
in question. So I can quickly twiddle renderer internals without
slowing down the renderer in the slightest to convert anything to a
"native" type.

See, I don’t actually HAVE TO work on anything for the community,
especially if the community doesn’t actually want my contributions.
I’m quite capable of producing the stuff I need. But a generic
version of the above without ugly CVar-type debugging setting stuff
was once deemed useful, and a moder modern version could be useful
again. But I’m only going to port it once. Probably to desktop
OpenGL, because that’s what I use. If SDL’s renderer did what it was
supposed to have been able to do, I’d target that instead and release
it so that someone else could maybe extend it for the stuff I don’t
care about too much. But I’m not going to bother writing support for
GLES, D3D, SDL2’s renderer, and whatever sort of arbitrary pixel
buffer you might wanna scribble text on top of.

JosephOn Sat, Jan 03, 2015 at 03:37:40AM -0300, Sik the hedgehog wrote:

Like with the first change of making a renderer just another way to
draw things into a window, this has the result of making the renderer
more useful in general, and it can become then an answer to the
people who say that the renderer is just extra cruft to the 3D games
that SDL is mainly used to write.

If you’re making a 3D game then you shouldn’t use neither the renderer
nor SDL_gpu, your code is already complex enough to probably be able
to cope with 2D on its own (and you’ll want to, to make sure it
doesn’t clash with how it handles 3D), and if it doesn’t then you
should really consider if what you have is good enough.

To be fair the problem with the renderer is that we can’t tell what is
its internal state, nor what API is it using. I suppose that if you
could override the renderer functions that would help - sounds like
defeating the whole point at first, until you realize that it makes
sense when you start adding third-party libraries that make use of the
renderer.

While exposing the internals of all of SDL could potentially end up
being a mess, being able to specify your own renderer could be useful
I suppose.

Alternately, it could be written to use SDL surfaces, in which case you
could use it with all three rendering methods that SDL supports: upload
it as an OpenGL texture, upload it as an SDL texture with
SDL_CreateTextureFromSurface, or blit it directly to SDL_GetWindowSurface().On 05.01.2015 00:00, T. Joseph Carter wrote:

One of the promises in the early SDL 1.3 daze was the renderer. At the
time, a popular helper lib for SDL 1.2 was SDL_console, a quake-style
console for 2D SDL games. It was textually simplistic, a subset of
ASCII using pre-rendered pixmap fonts rather than TTF and Unicode and
whatnot. But it managed the basics of text ring buffer that could be
scrolled, a functioning line editor, etc. You could easily have
extended it today to use SDL_ttf and Unicode text.

But it drew using 2D. So it would draw using the SDL renderer in SDL2,
if it ever had been ported.

–
Rainer Deyke (rainerd at eldwood.com)

    library

Message-ID: <20150104210604.GC20976 at amaya.spiritsubstance.com>
Content-Type: text/plain; charset=utf-8; format=flowed

Simply put, SDL’s renderer as written cannot reasonably do several
things that are trivial for 2D games, at least one of which I
intended to port to SDL2 at one point only to discover that it
couldn’t handle it. The issues in question were circles, lines, and
flat and filled polygons. (Original used turtle-style graphics(!),
so a port would involve a thin state machine?)

When I proposed adding stuff to SDL’s renderer that’d do
this?something I could do for software, trivially with a shader for
GL/GLES 2+, and with a little effort for GL/GLES 1.x, but would need
someone who knows the API a little better to help me translate to D3D
people absolutely SCREAMED their opposition. The API is frozen! I
never intended to change it, only add. You can’t do curves in GL
1.x! Yes, you can, if you know a little math. It’s not possible to
add any features to the renderer because it’s just TOO HARD to
maintain them and NOBODY EVER can produce results for all the
different renderer targets!!! Um, nobody necessarily has to know
every single API, provided that somebody who knows each one is
prepared to contribute that bit. Oh and finally, THE RENDERER IS
OBSOLETE CRUFT!!! YOU CAN’T BLOAT THE LIBRARY ANY MORE!!!

Tell me about it. I stopped working on a software-renderer
textured-triangle implementation because I was under the impression
that Gabrielo (I might have misspelled that) was going to get one in
(about a year ago, or maybe even two), and I can’t find any sign of
any version in the current Mercurial source.

Though admittedly, I might have opposed circles on the basis of “too
easy” or something. Or maybe used “the height of 1980’s rendering
technology” to support textured triangles. I forget which.

And what about software rendering?! Shock, horror! Yeah, the
algorithms for that are older than the majority of the people
freaking out about it. They’re optimized, produce excellent results,
and they just work well.

Shoot, who cares about optimized? Software’s a fall-back, so I say
that we should hold no fear of 15-FPS (or maybe even 2-FPS) algorithms
for the software renderer. I scratched out my textured triangle
algorithm on the basis of barycentric coordinates, and as I recall
didn’t find anything that directly talked about the subject (it worked
too, except that I apparently can’t render to a pixel buffer to save
my life; Handmade Hero has made me suspect that I was AT LEAST writing
color channels to the wrong destinations, which would explain some of
the color artifacts…), the only bits that I recall being incomplete
were corner cases (specifically related to color blending: I did not
take the fast route).> Date: Sun, 4 Jan 2015 13:06:04 -0800

From: “T. Joseph Carter”
To: SDL Development List
Subject: Re: [SDL] Adding features to SDL vs creating a satellite

Date: Sun, 4 Jan 2015 14:20:25 -0800
From: “T. Joseph Carter”
To: SDL Development List
Subject: Re: [SDL] Adding features to SDL vs creating a satellite
library
Message-ID: <20150104222025.GD20976 at amaya.spiritsubstance.com>
Content-Type: text/plain; charset=utf-8; format=flowed

No time for a proper reply, so I’ll make it quick.

What would be neat is compiling in a satellite library and initializing it
through SDL_init, ie:

SDL_Init( SDL_VIDEO | SDL_NET | SDL_GPU );

This is a bad idea. You’ll get different groups trying to use the same
value, thereby making satellite libraries incompatible with each
other.

I’m going to just agree with that one.

Or you could kind of keep it as-is described above, in which case
this idea of baking extensions into SDL becomes more about some build
system consideration to allow libraries to be built as standalone
(the Linux distribution probably preferred way of doing it, though
I’d advise doing it that way generally by default) and perhaps some
sort of hook in library and SDL to allow you to build them as one.

My biggest problem with the whole idea, admittedly, is that my concept
of how this SHOULD work in order to preserve SDL’s dll-swapability
jive with yours, but I DON’T see how it’s supposed to get along with
the impression that SDL_Init( SDL_NET ) gives me.

If you really want to initialize satellite libraries through a
conventional SDL function then add something like this:
int SDL_StringInit( char* );
It would take a string naming the sub-system, and return a result,
just like the other init functions. This completely avoids the
problem.

Again, I’ll note my preference is for this to be how it’s done, if
anything. But again if it’s just a matter of namespace, it’s purely
an aesthetics discussion. If it’s about building together, then I
don’t know why you must compile two libraries into one pretty much
ever.

I agree, but I also worry that it might be done in a poorly-conceived
fashion. Hence the suggestion.

If it’s about extensions having deeper access to the core of
SDL so that say, SDL_gpu could extend the razzin-frazzin render API
rather than an alternative of limited usefulness, then maybe the REAL
issue is that it should be possible to do that somehow with the
system as it is designed today?

Continuing with the renderer discussion for just a moment, say you
were to create one using Apple’s Metal API for iOS. It’s not ready
to go in to SDL proper yet. So do you maintain a fork of SDL, or
could you maybe just call a function to tell SDL that hey, here’s a
new renderer for you!

I’ve talked on the list about this sort of thing before. I think that
you’d ultimately want to slightly modify (at least some of) the
existing structures, but basically only so that you can include a
"version" field at the very start. After all, internals are
implementation details, so they should basically be EXPECTED to
change.

A render plugin that I think it would be useful to support is
basically anything network-centric. There are, for example, XServer
systems for Windows, but since they aren’t standard SDL doesn’t
support them… and probably SHOULDN’T. However, I personally think it
would be at least convenient to be able to use an extension library to
add such a backend (or even better, a "duplicate to network"
extension: perfect for both stores and competitions). With the current
setup, all that you can do is provide a custom dynamic library.

Another nice one would, of course, be something to allow you to adapt
the standard renderers to YOUR specifications. I don’t know exactly
how that would work, but I assume a conceptual inspiration from
DOS-era TSRs (no, I wasn’t programming at the time, I just found an
old book and read it a decade or more ago).

Hey, just because I constantly mock C++ and hate the language (more
accurately its backward-incompatible revisioning) doesn’t mean I fail
to recognize when Bjarne did something useful even by accident. :smiley:

I personally believe that there’s only a few things (all inherited
from C) wrong with C++ that couldn’t be fixed by taking the list of
features and redesigning the language from scratch… including
swapping out those template angle brackets with parentheses WRAPPING
angle brackets (how many years of parser errors could that simple fix
have avoided? And goodness knows there’s no sensible way to parse a
meaning out of such a construct in C, so it wouldn’t step on any valid
toes… -_- ).

Fixing C++ while keeping it as C++ though… yeah, I don’t think
that’s sensible.

But is that really necessary, aside from maybe making how SDL-using
extension libraries get built somehow “standard” and theoretically
able to be built as many different ways as SDL itself can be? Even
that seems kind of crazy-making, because SDL itself supports a lot of
random build systems. Multiple MSVC versions, a couple of XCode
versions, autoconf with God only knows what vaguely standard UNIX
build environment, CMake theoretically like 2.8 or so(?), premake,
and possibly more not coming to mind just now.

Is that desired for every single random library, by the people
producing those libraries I mean? I don’t have ANY version of MSVC,
and frankly I don’t really want it either. I could dig up an old OS
X 10.7 or even 10.6 to shove in a VM for those versions of XCode, but
should I? And while I like the concept of CMake, its execution I
find woefully inadequate. I haven’t got the first clue about premake
but it doesn’t really interest me.

I can see the possible value of providing a quasi-imake so that
programmers can get fairly reliable support for conditionals in
makefiles (Microsoft, BSD, and GNU all do it, and they all do it
DIFFERENTLY), and maybe a simple scripting-tool to read a file and run
the quasi-imake on a list of targets described within it. Both a C
preprocessor and a Make variant can trivially be found for most (maybe
all?) platforms (even Microsoft ships one with MSVC: apparently they
use it to build Windows). What I suggest would be limited (no looping,
for one), but it provides intermediate to advanced makefile use in a
simple way.

My preference is simply to use autoconf/automake. Not because I LIKE
either one, nor because I think either one is terribly efficient or
even necessarily good at what they do. But because I can set up a
basic build tree to start a new project in about a minute thanks to a
handy over-glorified shell script built for the job, and it works on
every desktop OS I might ever build for including Windows. Mobile
dev I’ve not really gotten into yet.

Plus, as ugly as it is, judicious use of the poorly utilized ability
to modularize your configure.ac file and some planning of your build
tree makes configure.ac and Makefile.am into essentially what CMake
promised regarding a readable, maintainable build description. Sadly
it’s not possible to match CMake’s promise of a self-contained one
simple thing that works everywhere (and even CMake has failed to
deliver the “, and works well” that should follow?), but nobody else
has done any better.

The result is that if you NEED something else (XCode for iOS maybe),
you only need to read through a relatively short/sweet list of things
to be checked for in configure.ac so that you can set up your build
system accordingly and produce the requisite config.h, and then look
at Makefile.am for a list of what source files to build. You could
almost automake the latter if other build systems followed any kind
of documented standard and remained backward compatible from version
to version.

What I would personally like is a build AND package-manager system (I
consider the two categories to strongly overlap) inspired by the
autotools system, but implemented as an
Actor-Oriented-Programming/LPMud-Object system in the form of a C
library (it’s C, so if someone doesn’t like the language they can just
implement a wrapper). That would be too big a project to shoehorn into
SDL, though.

In fact, if I could get pass by reference, exceptions, and thin
support for object types in the base C language, that’d be kind of
neat if they didn’t screw it up. My suggestion would be to look at
things that already implement objects in pure C and examine the stuff
that requires ugly #define macros to accomplish, and start there.
But that’s getting off topic fast. :wink:

And in my eyes passing arrays by value instead of by pointer, but you
quickly get into magic hidden variables, so better to leave that to
something else. Ah well, back to the topic.

Date: Sun, 4 Jan 2015 16:26:34 -0500
From: Alex Barry <alex.barry at gmail.com>
To: SDL Mailing List
Subject: Re: [SDL] Adding features to SDL vs creating a satellite
library
Message-ID:
<CAJSO58NcW9p+HoNY_L3HB-J10pp+fa2aVYEWhQuyCubJbon3rA at mail.gmail.com>
Content-Type: text/plain; charset=“utf-8”

Can we stay on topic, please?

I don’t know how my threads usually go off the rails like this, but I want
to make it clear, I’m not talking about adding features or breaking ABI
stuff.

What I’m suggesting is implementing hooks for libraries that would highly
encourage a consistent and structured way for SDL satellite libraries to be
written, and making it easier for main SDL developers to include new
features if they sprouted from satellite libraries.

Actually, that IS adding a feature: SDL isn’t designed to do that
right now. Also, the email that you quoted provided a point in favor
of the “Add” side of the equation, thus it is on topic.

In case it wasn’t clear, several of us consider SDL to be SMALLER than
it should be at the moment, NOT larger, and have been discussing these
additions because we consider their omission HIGHLY ill-advised.

Init variables would be addressed in the merging process/code review, and
would not have conflicts unless we have terrible build testing, but it
seems the build bot would catch that in the worst case scenario.

  • Alex

I consider this to be inherently wrong, for the simple reason that it
requires SDL admins to be involved with external code. A system to
make it easier for satellite libraries to augment SDL should be fine,
but anything that requires direct involvement from SDL developers
should be considered a no-go (among other things, a well-designed
system may be highly useful for customizing SDL to individual
machines… but such customized versions should NOT be expected to be
shared projects).

Date: Sun, 4 Jan 2015 19:28:16 -0300
From: Sik the hedgehog <sik.the.hedgehog at gmail.com>
To: SDL Development List
Subject: Re: [SDL] Adding features to SDL vs creating a satellite
library
Message-ID:
<CAEyBR+VbooCRDMfg+Vfdjj6kuyo_HSc4nNxMU8Bs5OOf8jY1nQ at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

It’s not just the renderer API though, it’s the entire SDL that’s
like that. Every time anybody ever suggests the possibility of adding
something nearly everybody will scream to not add it to SDL and to
maybe put it into its own separate library (often ignoring the
existing ones as well, ironically). It’s like people want SDL to be
frozen forever and the only development to be bugfixes.

Actually, I remember it just being a vocal few: Alex for example, as
demonstrated by this very thread. More common were cries that someone
should implement the neglected versions first (which is why I was
working on software-renderer textured-triangles for a while: the
software renderer was the neglected platform for those).

I think this is pretty much the purpose of this whole thread, to see
how we move forwards, because as it stands, if it was up to the
mailing list SDL should be completely frozen. Normally Sam or Ryan
would get in and take a decision settling the whole matter, but lately
they don’t seem to be around here (vacation?).

Maybe, but just as likely other job duties. I don’t know if I even
heard where Ryan works, but I assume that Valve did NOT hire Sam to
only work on SDL.

Date: Mon, 5 Jan 2015 04:26:14 -0300
From: Sik the hedgehog <sik.the.hedgehog at gmail.com>
To: SDL Development List
Subject: Re: [SDL] Adding features to SDL vs creating a satellite
library
Message-ID:
<CAEyBR+U3cskUYQPXU836u9jNwiz_c8rFLhvaqcT9cugFVFGb4A at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

To be fair the problem with the renderer is that we can’t tell what is
its internal state, nor what API is it using. I suppose that if you
could override the renderer functions that would help - sounds like
defeating the whole point at first, until you realize that it makes
sense when you start adding third-party libraries that make use of the
renderer.

While exposing the internals of all of SDL could potentially end up
being a mess, being able to specify your own renderer could be useful
I suppose.

You’re basically talking about a version id number, and some functions
in a separate header file (because you probably only care about this
stuff if you’re writing an extension library, if you’re just using one
then an init or pre-init function + whatever functions the library
exposes for IT’S functionality should be enough).

It’s not there for you. It’s there either for 3rd party libs (except
that doesn’t work) or for porting 2D games more easily (which mostly
works most of the time?) Both are fixable with ABI and even API
compatibility, but you’ve gotta be able to do it without people
screaming that it should not be done because too hard or useless or
unmaintainable.

JosephOn Mon, Jan 05, 2015 at 04:39:33PM +0100, Rainer Deyke wrote:

But it drew using 2D. So it would draw using the SDL renderer in SDL2,
if it ever had been ported.

Alternately, it could be written to use SDL surfaces, in which case
you could use it with all three rendering methods that SDL supports:
upload it as an OpenGL texture, upload it as an SDL texture with
SDL_CreateTextureFromSurface, or blit it directly to
SDL_GetWindowSurface().

Kind of defeats the purpose of even having a renderer doesn’t it?

I already consider the SDL renderer useless, so no argument from me there.

2015-01-05 21:54 GMT-03:00, Jared Maddox :

Tell me about it. I stopped working on a software-renderer
textured-triangle implementation because I was under the impression
that Gabrielo (I might have misspelled that) was going to get one in
(about a year ago, or maybe even two), and I can’t find any sign of
any version in the current Mercurial source.

Honestly I’d say go for it, I don’t think I’ve seen him around for a
while. You may want to make a flat triangle function first, though
(for the sake of completeness).

Shoot, who cares about optimized? Software’s a fall-back, so I say
that we should hold no fear of 15-FPS (or maybe even 2-FPS) algorithms
for the software renderer.

I do care, don’t pull off something like Allegro 5 did (where the
software renderer just calls a “GPU simulator” that has the equivalent
of a mega pixel shader running for every pixel… THAT is slow for no
reason). I don’t mean microoptimize like hell but don’t go around with
crappy algorithms. Also, I’d argue that not being 100% perfect would
be acceptable (e.g. the occasional pixel being off is fine, or even
stuff like never doing texture filtering regardless of the quality
hint).

As for why you’d want to use the software renderer: IIRC the original
reason for it staying (when long ago people wanted it gone) was
because it turned out that it made things much easier to deal with
format conversions due to how surfaces work (e.g. when using YUV).
Also, I know some magnifiers have trouble with GPU-rendered images,
and then on Linux you have some people with rather broken drivers
where OpenGL doesn’t work (it makes sense to lock them out of heavy
stuff, but if the CPU could have easily handled it on its own…).

You’re basically talking about a version id number, and some functions
in a separate header file (because you probably only care about this
stuff if you’re writing an extension library, if you’re just using one
then an init or pre-init function + whatever functions the library
exposes for IT’S functionality should be enough).

You also care if you’re writing your own graphics code directly in
your program (i.e. not in a library).

Huh no, it’s the other way. The idea was just to provide callbacks
that replace the renderer functions (this is how SDL already
implements its backends, so this is not really that out of place, it’d
be like a custom backend). Then anything else that uses that renderer
instance would end up using your callbacks instead - very useful for
extension libraries (like SDL_Console that was mentioned before, or
potentially something like a GUI library) to hook into your own
graphics code :smiley:

The bigger issue I imagine would be renderer functions that don’t have
callbacks implemented (this would happen if you update the SDL2
version without also updating the program). As long as other code
doesn’t use those functions it’s fine, but if not it will lead to bugs
(although granted, you probably should just update everything as a
whole and not just part of it).

Silly question: should we maybe start another thread to just discuss
what to do with the renderer in particular? (especially get back onto
just adding those functions that everybody wants but are missing)