The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.


SDL Forum Index
SDL
Simple Directmedia Layer Forums
Adding features to SDL vs creating a satellite library
MrOzBarry


Joined: 26 Jun 2010
Posts: 620
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.


2. 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
Adding features to SDL vs creating a satellite library
i8degrees


Joined: 22 Nov 2014
Posts: 39
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! :-) It would be even more awesome if these issues were not actually issues, and something I was just overlooking! Razz

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.

2. 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.

3. SDL_RenderCopy & floating-point math (perhaps the only sane example I might have Razz)

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 … Razz I also hope that my reply doesn’t derail things too much….. it was not my intention at all.
Cheers,
Jeffrey Carpenter
Adding features to SDL vs creating a satellite library
Sik


Joined: 26 Nov 2011
Posts: 905
2014-12-31 0:48 GMT-03:00, Jeffrey Carpenter:
Quote:
2. 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).
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
i8degrees


Joined: 22 Nov 2014
Posts: 39
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


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
Joseph Carter


Joined: 20 Sep 2013
Posts: 279
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:
Quote:
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! :-) It would be even more awesome if these issues were not actually issues, and something I was just overlooking! :-P

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.

2. 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.

3. SDL_RenderCopy & floating-point math (perhaps the only sane example I might have Razz)

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 … Razz I also hope that my reply doesn’t derail things too much….. it was not my intention at all.

Cheers,
Jeffrey Carpenter




Quote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
Joseph Carter


Joined: 20 Sep 2013
Posts: 279
On Tue, Dec 30, 2014 at 05:08:13PM -0500, Alex Barry wrote:
Quote:
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.


Quote:
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.


Quote:
2. 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.

2. 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.

3. 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!))

4. 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.

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


That's my wishlist.


Quote:
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.


Quote:
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.


Quote:
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.

Joseph

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
MrOzBarry


Joined: 26 Jun 2010
Posts: 620
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 wrote:
Quote:
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:
Quote:
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! :-) It would be even more awesome if these issues were not actually issues, and something I was just overlooking! Razz

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.

2. 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.

3. SDL_RenderCopy & floating-point math (perhaps the only sane example I might have Razz)

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 … Razz I also hope that my reply doesn’t derail things too much….. it was not my intention at all.

Cheers,
Jeffrey Carpenter






Quote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Adding features to SDL vs creating a satellite library
Jared Maddox
Guest

Quote:
Date: Fri, 2 Jan 2015 19:34:52 -0500
From: Alex Barry
To: SDL Development List
Subject: Re: [SDL] Adding features to SDL vs creating a satellite
library
Message-ID:
<CAJSO58M1=
Content-Type: text/plain; charset="utf-8"


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

Quote:
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.


Quote:
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.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
Sik


Joined: 26 Nov 2011
Posts: 905
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:
Quote:
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:
Quote:
4. 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).
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
Jared Maddox
Guest

Had to salvage the first quote from another reply.



On Tue, Dec 30, 2014 at 05:08:13PM -0500, Alex Barry wrote:
Quote:
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.



Quote:
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:
Content-Type: text/plain; charset=utf-8; format=flowed

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


Quote:
5. 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.



Quote:
Date: Fri, 2 Jan 2015 19:34:52 -0500
From: Alex Barry
To: SDL Development List
Subject: Re: [SDL] Adding features to SDL vs creating a satellite
library
Message-ID:
<CAJSO58M1=
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.


Quote:
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.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
Joseph Carter


Joined: 20 Sep 2013
Posts: 279
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:
Quote:
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 <
wrote:

Quote:
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:

Quote:
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!
:-) It would be even more awesome if these issues were not actually issues,
and something I was just overlooking! :-P

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.

2. 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.

3. SDL_RenderCopy & floating-point math (perhaps the only sane example I
might have Razz)

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 … Razz 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

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Quote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
MrOzBarry


Joined: 26 Jun 2010
Posts: 620
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.
- Alex On 4 Jan 2015 16:06, "T. Joseph Carter" wrote:
Quote:
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:
Quote:
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 <
wrote:

Quote:
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:

Quote:
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!
:-) It would be even more awesome if these issues were not actually issues,
and something I was just overlooking! Razz

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.

2. 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.

3. SDL_RenderCopy & floating-point math (perhaps the only sane example I
might have Razz)

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 … Razz 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

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
Joseph Carter


Joined: 20 Sep 2013
Posts: 279
Quote:
No time for a proper reply, so I'll make it quick.

Quote:
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. :D

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. ;)

Quote:
Quote:
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.


Quote:
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

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
Joseph Carter


Joined: 20 Sep 2013
Posts: 279
On Sat, Jan 03, 2015 at 03:37:40AM -0300, Sik the hedgehog wrote:
Quote:
Quote:
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.

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* :)

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.

Joseph

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
Sik


Joined: 26 Nov 2011
Posts: 905
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:
Quote:
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:
Quote:
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 <
wrote:

Quote:
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:

Quote:
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!
:-) It would be even more awesome if these issues were not actually
issues,
and something I was just overlooking! :-P

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.

2. 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.

3. SDL_RenderCopy & floating-point math (perhaps the only sane example I
might have Razz)

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 … Razz 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

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Quote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
Sik


Joined: 26 Nov 2011
Posts: 905
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.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
Rainer Deyke
Guest

On 05.01.2015 00:00, T. Joseph Carter wrote:
Quote:
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.

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().


--
Rainer Deyke

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
Joseph Carter


Joined: 20 Sep 2013
Posts: 279
On Mon, Jan 05, 2015 at 10:50:35AM +0100, Rainer Deyke wrote:
Quote:
Quote:
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?

Joseph

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
Joseph Carter


Joined: 20 Sep 2013
Posts: 279
On Mon, Jan 05, 2015 at 04:26:14AM -0300, Sik the hedgehog wrote:
Quote:
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.

I think that a few bits of renderer internals COULD safely be
exposed, if the renderer were modularized a little more so that it
could coexist with drawing not done by it. And even the software
renderer maintains a state machine for things like current blend
color which could be queried if an accessor were written and not shot
down as bloat before the patch was even finished uploading to the bug
tracker. Razz

Joseph

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
Rainer Deyke
Guest

On 05.01.2015 13:54, T. Joseph Carter wrote:
Quote:
On Mon, Jan 05, 2015 at 10:50:35AM +0100, Rainer Deyke wrote:
Quote:
Quote:
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.


--
Rainer Deyke

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
Joseph Carter


Joined: 20 Sep 2013
Posts: 279
On Mon, Jan 05, 2015 at 04:39:33PM +0100, Rainer Deyke wrote:
Quote:
Quote:
Quote:
Quote:
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.

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.

Joseph

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
Jared Maddox
Guest

Quote:
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
library
Message-ID:
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.


Quote:
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).



Quote:
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:
Content-Type: text/plain; charset=utf-8; format=flowed

Quote:
No time for a proper reply, so I'll make it quick.

Quote:
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.

Quote:
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.


Quote:
Quote:
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.


Quote:
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).


Quote:
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. Very Happy


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.


Quote:
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.


Quote:
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.


Quote:
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.



Quote:
Date: Sun, 4 Jan 2015 16:26:34 -0500
From: Alex Barry
To: SDL Mailing List
Subject: Re: [SDL] Adding features to SDL vs creating a satellite
library
Message-ID:

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.


Quote:
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).



Quote:
Date: Sun, 4 Jan 2015 19:28:16 -0300
From: Sik the hedgehog
To: SDL Development List
Subject: Re: [SDL] Adding features to SDL vs creating a satellite
library
Message-ID:

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).


Quote:
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.



Quote:
Date: Mon, 5 Jan 2015 04:26:14 -0300
From: Sik the hedgehog
To: SDL Development List
Subject: Re: [SDL] Adding features to SDL vs creating a satellite
library
Message-ID:

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).
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
Sik


Joined: 26 Nov 2011
Posts: 905
2015-01-05 21:54 GMT-03:00, Jared Maddox:
Quote:
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).

Quote:
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...).

Quote:
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 Very Happy

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)
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
gabomdq


Joined: 28 Jul 2011
Posts: 495
Location: Argentina
2015-01-06 6:48 GMT-03:00 Sik the hedgehog:
Quote:
2015-01-05 21:54 GMT-03:00, Jared Maddox:
Quote:
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).


I'm here, I usually don't get involved in these discussions because what little time I have to put into SDL I'd rather put it into fixing bugs or helping in the issue tracker, and not writing walls of text about philosophical issues and political intrigue...but to each its own I guess!


Like it or not, the best way to steer SDL is to first *make* a patch (not talk about it, actually sit down and code it, and test it across all platforms, and, you know...hard work), then annoy/con/extort/beg/etc some of the core contributors into accepting it. The more radical the change, the higher you'll have to go in the chain, but that's basically the only way that works, I've done it myself.


Finally, the patch contributed by Jared is in the pipeline as do so many others. I contributed a sizable patch for SDL_RenderGeometry myself [bug #1734] , lack of support for all platforms is all that's missing from it for inclusion (as of the last time we spoke about it). If anyone want to take precious minutes from their spare time and complete that, you are more than welcome and I'm happy to help!







--
Gabriel.
Adding features to SDL vs creating a satellite library
Rainer Deyke
Guest

On 06.01.2015 04:17, T. Joseph Carter wrote:
Quote:
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.

The thing is, every 2D game requires a different feature set. I
consider the following features indispensable:
- Lighting: render lights to an off-screen texture, the modulate all
pixels drawn to the screen with that texture.
- Full color-matrix operations.
- Pixel-perfect flipping and rotation by increments of 90°.
- Scaling that is pixel perfect at integer increments, and gap-less
at non-integer values.
Other people and other projects consider other features indispensable.
I don't care about lines and circles, but other people do. A 2D
rendering library that is all things to all people would be no less
complex than OpenGL.


--
Rainer Deyke

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
Joseph Carter


Joined: 20 Sep 2013
Posts: 279
But 2D games—those that target software targets—are generally not
that complex. They are either written for tiling engines (most
consoles prior to 3D hardware) or use blits to get graphics on screen
and other simple algorithms to draw lines, polygons, and curves
(generally flat shaded) in screen memory. And they use a lot of
palette twiddling.

Some of that SDL does with its 2D renderer, and some of it the
renderer just can't do yet.

But let's say you were going to "remaster" such a game. I kind of
see SDL's render API as not unlike GLU (assuming for a moment that
GLU is still used by anyone for anything, I've not used it pretty
much in about 14 years!) You don't need GLU to do things in OpenGL,
and everything GLU does, you can do yourself. It's a shortcut to get
something working quickly. But you could easily implement your own
versions of these functions and sometimes you'd be better off doing
so. If you don't use it heavily, it'd be worth doing it just to cut
down on library usage.

The thing is, most of these old 2D games ran in at most likely
640x480 and … well I dunno about you, but my resolution is 2560x1440.
By the time my CPU scales each pixel by 3.0 to draw 1920x1440, it's
using a fair bit of CPU and a lot more of PCI bus bandwidth to do it.
The same with a game that ran in 320x200, except you have the added
"cost" of trying to scale horizontally by 6.0 and vertically by 7.2
if you want to maintain aspect. Which brings up the issue of those
fractional pixels, what kind of mag filter to use, etc. And all in
software. The game's gonna run slower on my Core i5 at scaled to
native resolution than it would on a 486 with a resolution change.

Obviously that kind of thing is why we have 3D hardware. But the
game isn't written for that, and the goal is to get it running and at
acceptable performance as quickly as possible. Enter SDL's renderer
(a "renderer" in the thinnest sense really…) That's what the code is
for.

But what if you want to then remaster the game, add some 3D effects,
basically port it to OpenGL? You've gotta start from scratch with
the draw code presently because SDL's renderer is a dead-end API.
You would have been better off porting to old skool NeHe OpenGL 1.x
because at least from there you could transition your code to modern
standards and practices, culminating in no longer asking OpenGL for a
legacy fixed pipeline you no longer need.

I argue the same should be possible with SDL's renderer. And it
won't be until I code it to be, I guess—Gabriel is probably 100%
correct about that. Side effect of what I have in mind is that other
things the renderer was promised to allow (coming back to SDL_console
as an example) would be doable.

Of course I've got an ABI not to break, so my approach must be
different than it would be if I could change some stuff, but I
understand that if Sam and Ryan waited for everything they wanted
SDL2 to have, we'd still be using SDL 1.2.35 or so and talking about
how one day we'd have hot-pluggable joysticks, multiple windows, and
support for new platforms like iOS, Android, NaCL, and emscripten.
It'll happen one of these days I tell you!

Given the two possibilities, I'd say releasing SDL2 without it was
the right call. But it's still a wanted feature.

Joseph


On Wed, Jan 07, 2015 at 09:44:53AM +0100, Rainer Deyke wrote:
Quote:
On 06.01.2015 04:17, T. Joseph Carter wrote:
Quote:
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.

The thing is, every 2D game requires a different feature set. I
consider the following features indispensable:
- Lighting: render lights to an off-screen texture, the modulate all
pixels drawn to the screen with that texture.
- Full color-matrix operations.
- Pixel-perfect flipping and rotation by increments of 90°.
- Scaling that is pixel perfect at integer increments, and gap-less
at non-integer values.
Other people and other projects consider other features indispensable.
I don't care about lines and circles, but other people do. A 2D
rendering library that is all things to all people would be no less
complex than OpenGL.


--
Rainer Deyke

_______________________________________________
SDL mailing list

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

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
Sik


Joined: 26 Nov 2011
Posts: 905
Those old 2D games most likely were written using SDL1 and not the
renderer so they really would have to be completely rewritten either
way, making which API has to be used a moot point.

This said, I think I may have a solution for this, so I'll just make a
separate thread for that.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
Joseph Carter


Joined: 20 Sep 2013
Posts: 279
On Thu, Jan 08, 2015 at 11:06:35AM -0300, Sik the hedgehog wrote:
Quote:
Those old 2D games most likely were written using SDL1 and not the
renderer so they really would have to be completely rewritten either
way, making which API has to be used a moot point.

This said, I think I may have a solution for this, so I'll just make a
separate thread for that.

Actually I had assumed the games were written for direct video RAM
access under DOS or whatnot. A few of those are still being found,
released, and ported. Though not many anymore.

Joseph

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
Rainer Deyke
Guest

On 08.01.2015 06:50, T. Joseph Carter wrote:
Quote:
But 2D games—those that target software targets—are generally not that
complex. They are either written for tiling engines (most consoles
prior to 3D hardware) or use blits to get graphics on screen and other
simple algorithms to draw lines, polygons, and curves (generally flat
shaded) in screen memory. And they use a lot of palette twiddling.

Different games had different features, but having some kind of special
effect that is hard to duplicate in 3D were fairly common. Cosmo's
Cosmic Adventure had a transparency effect (in 16 colors!) that looked
completely unlike alpha blending. Commander Keen episode 2 had light
switches that darkened the room (also in 16 colors!) in a way that looks
completely unlike modern darkening techniques. Quake, admittedly not a
2D game, had a 2D water effect in software rendering that was lost when
the game was ported to OpenGL. Duke Nukem, the original 16 color 2D
game, had a very nice reflection effect. 2D SNES games often used mode
7, the SNES's pseudo-3D mode.

Quote:
Some of that SDL does with its 2D renderer, and some of it the renderer
just can't do yet.

But let's say you were going to "remaster" such a game. I kind of see
SDL's render API as not unlike GLU (assuming for a moment that GLU is
still used by anyone for anything, I've not used it pretty much in about
14 years!) You don't need GLU to do things in OpenGL, and everything
GLU does, you can do yourself. It's a shortcut to get something working
quickly. But you could easily implement your own versions of these
functions and sometimes you'd be better off doing so. If you don't use
it heavily, it'd be worth doing it just to cut down on library usage.

The SDL renderer and GLU could hardly be more different, IMO:
- GLU is tied to OpenGL. The SDL renderer has many back-ends.
- GLU is stateless. The SDL renderer requires internal state by design.
- GLU is a separate add-on for OpenGL. The SDL renderer is
integrated into SDL.
- You can freely mix GLU calls with OpenGL calls. You can't mix SDL
renderer calls with anything.
Some of these could be "fixed", but that would change the fundamental
design of the SDL renderer. Writing a new satellite library that is
more like GLU would probably be easier than "fixing" the SDL renderder.

Quote:
The thing is, most of these old 2D games ran in at most likely 640x480
and … well I dunno about you, but my resolution is 2560x1440. By the
time my CPU scales each pixel by 3.0 to draw 1920x1440, it's using a
fair bit of CPU and a lot more of PCI bus bandwidth to do it. The same
with a game that ran in 320x200, except you have the added "cost" of
trying to scale horizontally by 6.0 and vertically by 7.2 if you want to
maintain aspect. Which brings up the issue of those fractional pixels,
what kind of mag filter to use, etc. And all in software. The game's
gonna run slower on my Core i5 at scaled to native resolution than it
would on a 486 with a resolution change.

The cheap and easy way to port these games is to software-render to a
640x480 back buffer, then upload the result to the GPU and let the GPU
handle the scaling - something that SDL admittedly doesn't make as easy
as it should, but that's another issue. This approach has numerous
advantages over using the SDL renderer:

- It's less work for the programmer, which also means less
opportunity to introduce new bugs.
- It can easily cope with any and all special effects that the
original game used.
- It could actually be faster than using the SDL renderer. The
actual rendering code would be the same as the original, and should
therefore run just as fast, multiplied by the speed improvement of the CPU.
- It doesn't require massive changes to SDL. You can do it right now.

To be honest, I'm far more interested in new 2D games than in porting
old games. Porting old games is a solved issue, as far as I'm concerned.

Quote:
I argue the same should be possible with SDL's renderer. And it won't
be until I code it to be, I guess—Gabriel is probably 100% correct about
that. Side effect of what I have in mind is that other things the
renderer was promised to allow (coming back to SDL_console as an
example) would be doable.

As someone who has had a patch with an obvious bug fix sitting in the
queue for over a month now, I can only say: good luck.


--
Rainer Deyke

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
Joseph Carter


Joined: 20 Sep 2013
Posts: 279
I'm REALLY growing tired of the "you can't fix SDL" mentality.

Even if YOU think it's useless, the code exists and it's not going
away. If it can be made more useful, then insisting that everybody
constantly reinvent the wheel is far more bloat than actually fixing
the damned code to be useful.

Joseph

On Fri, Jan 09, 2015 at 09:03:24AM +0100, Rainer Deyke wrote:
Quote:
On 08.01.2015 06:50, T. Joseph Carter wrote:
Quote:
But 2D games—those that target software targets—are generally not that
complex. They are either written for tiling engines (most consoles
prior to 3D hardware) or use blits to get graphics on screen and other
simple algorithms to draw lines, polygons, and curves (generally flat
shaded) in screen memory. And they use a lot of palette twiddling.

Different games had different features, but having some kind of
special effect that is hard to duplicate in 3D were fairly common.
Cosmo's Cosmic Adventure had a transparency effect (in 16 colors!)
that looked completely unlike alpha blending. Commander Keen episode
2 had light switches that darkened the room (also in 16 colors!) in a
way that looks completely unlike modern darkening techniques. Quake,
admittedly not a 2D game, had a 2D water effect in software rendering
that was lost when the game was ported to OpenGL. Duke Nukem, the
original 16 color 2D game, had a very nice reflection effect. 2D SNES
games often used mode 7, the SNES's pseudo-3D mode.

Quote:
Some of that SDL does with its 2D renderer, and some of it the renderer
just can't do yet.

But let's say you were going to "remaster" such a game. I kind of see
SDL's render API as not unlike GLU (assuming for a moment that GLU is
still used by anyone for anything, I've not used it pretty much in about
14 years!) You don't need GLU to do things in OpenGL, and everything
GLU does, you can do yourself. It's a shortcut to get something working
quickly. But you could easily implement your own versions of these
functions and sometimes you'd be better off doing so. If you don't use
it heavily, it'd be worth doing it just to cut down on library usage.

The SDL renderer and GLU could hardly be more different, IMO:
- GLU is tied to OpenGL. The SDL renderer has many back-ends.
- GLU is stateless. The SDL renderer requires internal state by design.
- GLU is a separate add-on for OpenGL. The SDL renderer is
integrated into SDL.
- You can freely mix GLU calls with OpenGL calls. You can't mix SDL
renderer calls with anything.
Some of these could be "fixed", but that would change the fundamental
design of the SDL renderer. Writing a new satellite library that is
more like GLU would probably be easier than "fixing" the SDL
renderder.

Quote:
The thing is, most of these old 2D games ran in at most likely 640x480
and … well I dunno about you, but my resolution is 2560x1440. By the
time my CPU scales each pixel by 3.0 to draw 1920x1440, it's using a
fair bit of CPU and a lot more of PCI bus bandwidth to do it. The same
with a game that ran in 320x200, except you have the added "cost" of
trying to scale horizontally by 6.0 and vertically by 7.2 if you want to
maintain aspect. Which brings up the issue of those fractional pixels,
what kind of mag filter to use, etc. And all in software. The game's
gonna run slower on my Core i5 at scaled to native resolution than it
would on a 486 with a resolution change.

The cheap and easy way to port these games is to software-render to a
640x480 back buffer, then upload the result to the GPU and let the GPU
handle the scaling - something that SDL admittedly doesn't make as
easy as it should, but that's another issue. This approach has
numerous advantages over using the SDL renderer:

- It's less work for the programmer, which also means less
opportunity to introduce new bugs.
- It can easily cope with any and all special effects that the
original game used.
- It could actually be faster than using the SDL renderer. The
actual rendering code would be the same as the original, and should
therefore run just as fast, multiplied by the speed improvement of the
CPU.
- It doesn't require massive changes to SDL. You can do it right now.

To be honest, I'm far more interested in new 2D games than in porting
old games. Porting old games is a solved issue, as far as I'm
concerned.

Quote:
I argue the same should be possible with SDL's renderer. And it won't
be until I code it to be, I guess—Gabriel is probably 100% correct about
that. Side effect of what I have in mind is that other things the
renderer was promised to allow (coming back to SDL_console as an
example) would be doable.

As someone who has had a patch with an obvious bug fix sitting in the
queue for over a month now, I can only say: good luck.


--
Rainer Deyke

_______________________________________________
SDL mailing list

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

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
Sik


Joined: 26 Nov 2011
Posts: 905
2015-01-09 5:36 GMT-03:00, T. Joseph Carter:
Quote:
I'm REALLY growing tired of the "you can't fix SDL" mentality.

I think in this case it was more referring to the fact that you'd need
so many changes to do what's suggested that ABI (even API)
compatibility would need to be thrown away, which is a no-no in SDL.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
Jared Maddox
Guest

Quote:
Date: Tue, 6 Jan 2015 06:48:59 -0300
From: Sik the hedgehog
To: SDL Development List
Subject: Re: [SDL] Adding features to SDL vs creating a satellite
library
Message-ID:
<CAEyBR+UZmx8FtQ6eiumX02Q=aMQ0N9av5pC=
Content-Type: text/plain; charset=UTF-8

2015-01-05 21:54 GMT-03:00, Jared Maddox:
Quote:
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).

Quote:
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).

Ah, yeah, that is sorta nutty. I sort-of recall wanting to write an
additional version that could be programmed, but that would have come
afterwards (and might have been done as a satellite library).


Quote:
Quote:
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).

Quote:
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).

My thinking was to provide your own renderer-initializer, and hook
into the system THAT way (so that your rendering system gets reported
through the same mechanisms as EVERY other system).


Quote:
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).


Another point in favor of my version: the "registration" function(s)
can add any necessary "always fail" functions.



Quote:
Date: Tue, 6 Jan 2015 10:54:26 -0300
From: Gabriel Jacobo
To: SDL Development List
Subject: Re: [SDL] Adding features to SDL vs creating a satellite
library
Message-ID:
<CAKDfesm63sVYAdX2GCKEK-PNwpQmT_qg=
Content-Type: text/plain; charset="utf-8"

2015-01-06 6:48 GMT-03:00 Sik the hedgehog:

Quote:
2015-01-05 21:54 GMT-03:00, Jared Maddox:
Quote:
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).



Quote:
Finally, the patch contributed by Jared is in the pipeline

Huh? Is it supposed to be in the bug tracker, or just with Sam & Ryan?
I'd been assuming that your version would provide all of that
functionality, so I haven't touched it in a while.

I guess I'll go dig it back up again.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
Sam Lantinga


Joined: 10 Sep 2009
Posts: 1765
BTW, we're starting to toss around ideas for what should go into 2.1, so if somebody wants a revamped renderer that sings and dances, I say go for it!

As for where Ryan and I are... we're still here, but have work and families and so forth. Smile


On Wed, Jan 7, 2015 at 9:50 PM, T. Joseph Carter wrote:
Quote:
But 2D games—those that target software targets—are generally not that complex.  They are either written for tiling engines (most consoles prior to 3D hardware) or use blits to get graphics on screen and other simple algorithms to draw lines, polygons, and curves (generally flat shaded) in screen memory.  And they use a lot of palette twiddling.

Some of that SDL does with its 2D renderer, and some of it the renderer just can't do yet.

But let's say you were going to "remaster" such a game.  I kind of see SDL's render API as not unlike GLU (assuming for a moment that GLU is still used by anyone for anything, I've not used it pretty much in about 14 years!)  You don't need GLU to do things in OpenGL, and everything GLU does, you can do yourself.  It's a shortcut to get something working quickly.  But you could easily implement your own versions of these functions and sometimes you'd be better off doing so.  If you don't use it heavily, it'd be worth doing it just to cut down on library usage.

The thing is, most of these old 2D games ran in at most likely 640x480 and … well I dunno about you, but my resolution is 2560x1440.  By the time my CPU scales each pixel by 3.0 to draw 1920x1440, it's using a fair bit of CPU and a lot more of PCI bus bandwidth to do it.  The same with a game that ran in 320x200, except you have the added "cost" of trying to scale horizontally by 6.0 and vertically by 7.2 if you want to maintain aspect.  Which brings up the issue of those fractional pixels, what kind of mag filter to use, etc.  And all in software.  The game's gonna run slower on my Core i5 at scaled to native resolution than it would on a 486 with a resolution change.

Obviously that kind of thing is why we have 3D hardware.  But the game isn't written for that, and the goal is to get it running and at acceptable performance as quickly as possible.  Enter SDL's renderer (a "renderer" in the thinnest sense really…)  That's what the code is for.

But what if you want to then remaster the game, add some 3D effects, basically port it to OpenGL?  You've gotta start from scratch with the draw code presently because SDL's renderer is a dead-end API.  You would have been better off porting to old skool NeHe OpenGL 1.x because at least from there you could transition your code to modern standards and practices, culminating in no longer asking OpenGL for a legacy fixed pipeline you no longer need.

I argue the same should be possible with SDL's renderer.  And it won't be until I code it to be, I guess—Gabriel is probably 100% correct about that.  Side effect of what I have in mind is that other things the renderer was promised to allow (coming back to SDL_console as an example) would be doable.

Of course I've got an ABI not to break, so my approach must be different than it would be if I could change some stuff, but I understand that if Sam and Ryan waited for everything they wanted SDL2 to have, we'd still be using SDL 1.2.35 or so and talking about how one day we'd have hot-pluggable joysticks, multiple windows, and support for new platforms like iOS, Android, NaCL, and emscripten.  It'll happen one of these days I tell you!

Given the two possibilities, I'd say releasing SDL2 without it was the right call.  But it's still a wanted feature.

Joseph


On Wed, Jan 07, 2015 at 09:44:53AM +0100, Rainer Deyke wrote:
Quote:
On 06.01.2015 04:17, T. Joseph Carter wrote:
Quote:
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.

The thing is, every 2D game requires a different feature set.  I consider the following features indispensable:
 - Lighting: render lights to an off-screen texture, the modulate all pixels drawn to the screen with that texture.
 - Full color-matrix operations.
 - Pixel-perfect flipping and rotation by increments of 90°.
 - Scaling that is pixel perfect at integer increments, and gap-less at non-integer values.
Other people and other projects consider other features indispensable. I don't care about lines and circles, but other people do.  A 2D rendering library that is all things to all people would be no less complex than OpenGL.


--
Rainer Deyke

_______________________________________________
SDL mailing list

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

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Adding features to SDL vs creating a satellite library
Joseph Carter


Joined: 20 Sep 2013
Posts: 279
That's dangerous to say, Sam… Muahahaha!


At the moment my "wish list" for SDL looks like:


- The ability to request D3D contexts the same way you do OpenGL today. (Mostly for the next item.)
- The ability to mix native 3D with SDL's renderer. My current notion of the BEST way to do this is to be able to create a renderer for a 3D context in addition to a window. This can fail if your OpenGL context cannot render to texture, but … anything DX9-class or higher can, which is anything standard for any version of Windows not firmly in maintenance mode at this point. Of course you can fall back on a streaming texture if you really want to, which is the absolute easiest to implement since it'd be basically the software renderer we already have.
- I have some pretty major pipe dreams in mind for the Joystick/GameController API. I'd like to be able to describe non-joypad XInput devices like guitars and whatnot, but also describe other common things like player indicators, accelerometers, pointing devices, and references to which sound, keypad, etc device is "part of" this controller. And the list of unmapped controls for you to be able to support stuff that SDL may not yet like analog buttons on a MFi controller.
- I'd like to see a thin backend to target libretro. Since libretro already abstracts hardware a lot, SDL built with only libretro support would be very small, making it very easy to turn SDL games and emulators, engines, and apps into libretro "cores".


The only one of these that couldn't be done in 2.0 is the joystick stuff, and that may be pie in the sky thinking anyway.

JosephSent via mobile


On Jan 15, 2015, at 14:05, Sam Lantinga wrote:


Quote:
BTW, we're starting to toss around ideas for what should go into 2.1, so if somebody wants a revamped renderer that sings and dances, I say go for it!

As for where Ryan and I are... we're still here, but have work and families and so forth. Smile


On Wed, Jan 7, 2015 at 9:50 PM, T. Joseph Carter wrote:
Quote:
But 2D games—those that target software targets—are generally not that complex. They are either written for tiling engines (most consoles prior to 3D hardware) or use blits to get graphics on screen and other simple algorithms to draw lines, polygons, and curves (generally flat shaded) in screen memory. And they use a lot of palette twiddling.

Some of that SDL does with its 2D renderer, and some of it the renderer just can't do yet.

But let's say you were going to "remaster" such a game. I kind of see SDL's render API as not unlike GLU (assuming for a moment that GLU is still used by anyone for anything, I've not used it pretty much in about 14 years!) You don't need GLU to do things in OpenGL, and everything GLU does, you can do yourself. It's a shortcut to get something working quickly. But you could easily implement your own versions of these functions and sometimes you'd be better off doing so. If you don't use it heavily, it'd be worth doing it just to cut down on library usage.

The thing is, most of these old 2D games ran in at most likely 640x480 and … well I dunno about you, but my resolution is 2560x1440. By the time my CPU scales each pixel by 3.0 to draw 1920x1440, it's using a fair bit of CPU and a lot more of PCI bus bandwidth to do it. The same with a game that ran in 320x200, except you have the added "cost" of trying to scale horizontally by 6.0 and vertically by 7.2 if you want to maintain aspect. Which brings up the issue of those fractional pixels, what kind of mag filter to use, etc. And all in software. The game's gonna run slower on my Core i5 at scaled to native resolution than it would on a 486 with a resolution change.

Obviously that kind of thing is why we have 3D hardware. But the game isn't written for that, and the goal is to get it running and at acceptable performance as quickly as possible. Enter SDL's renderer (a "renderer" in the thinnest sense really…) That's what the code is for.

But what if you want to then remaster the game, add some 3D effects, basically port it to OpenGL? You've gotta start from scratch with the draw code presently because SDL's renderer is a dead-end API. You would have been better off porting to old skool NeHe OpenGL 1.x because at least from there you could transition your code to modern standards and practices, culminating in no longer asking OpenGL for a legacy fixed pipeline you no longer need.

I argue the same should be possible with SDL's renderer. And it won't be until I code it to be, I guess—Gabriel is probably 100% correct about that. Side effect of what I have in mind is that other things the renderer was promised to allow (coming back to SDL_console as an example) would be doable.

Of course I've got an ABI not to break, so my approach must be different than it would be if I could change some stuff, but I understand that if Sam and Ryan waited for everything they wanted SDL2 to have, we'd still be using SDL 1.2.35 or so and talking about how one day we'd have hot-pluggable joysticks, multiple windows, and support for new platforms like iOS, Android, NaCL, and emscripten. It'll happen one of these days I tell you!

Given the two possibilities, I'd say releasing SDL2 without it was the right call. But it's still a wanted feature.

Joseph


On Wed, Jan 07, 2015 at 09:44:53AM +0100, Rainer Deyke wrote:
Quote:
On 06.01.2015 04:17, T. Joseph Carter wrote:
Quote:
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.

The thing is, every 2D game requires a different feature set. I consider the following features indispensable:
- Lighting: render lights to an off-screen texture, the modulate all pixels drawn to the screen with that texture.
- Full color-matrix operations.
- Pixel-perfect flipping and rotation by increments of 90°.
- Scaling that is pixel perfect at integer increments, and gap-less at non-integer values.
Other people and other projects consider other features indispensable. I don't care about lines and circles, but other people do. A 2D rendering library that is all things to all people would be no less complex than OpenGL.


--
Rainer Deyke

_______________________________________________
SDL mailing list

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

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org






_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Adding features to SDL vs creating a satellite library
Sik


Joined: 26 Nov 2011
Posts: 905
2015-01-15 19:05 GMT-03:00, Sam Lantinga:
Quote:
BTW, we're starting to toss around ideas for what should go into 2.1, so if
somebody wants a revamped renderer that sings and dances, I say go for it!

Can we have screen reader support?

Although the way you phrased it sounds like 2.1 won't be even remotely
compatible with 2.0 programs (much like the jump from 1.2 to 2.0), so
I guess that won't help me much as I'd be required to rewrite all the
subsystems in my game to get anything working (granted that doesn't
mean much in my case, but ouch rewriting the input code).
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
Jared Maddox
Guest

Quote:
Date: Sun, 18 Jan 2015 17:57:19 -0800
From: "T. Joseph Carter"
To: SDL Development List
Subject: Re: [SDL] Adding features to SDL vs creating a satellite
library
Message-ID:
Content-Type: text/plain; charset="utf-8"

That's dangerous to say, Sam? Muahahaha!

At the moment my "wish list" for SDL looks like:

- The ability to request D3D contexts the same way you do OpenGL today.
(Mostly for the next item.)

It might be wise to also include a way to get the surface that the
software renderer uses, though the ability to simply pass your own for
the renderer to be built around does make this unimportant for
anything except scripting languages.


Quote:
- The ability to mix native 3D with SDL's renderer. My current notion of the
BEST way to do this is to be able to create a renderer for a 3D context in
addition to a window. This can fail if your OpenGL context cannot render
to texture, but ? anything DX9-class or higher can, which is anything
standard for any version of Windows not firmly in maintenance mode at this
point. Of course you can fall back on a streaming texture if you really
want to, which is the absolute easiest to implement since it'd be
basically the software renderer we already have.

On a related note, how about a function to change the Z-depth that
SDL's renderers render to? I'm assuming isometric (?) projection
instead of perspective (?) projection, so it shouldn't matter too
much, but it might be useful for reducing or eliminating clipping
errors.


Quote:
- I have some pretty major pipe dreams in mind for the
Joystick/GameController API. I'd like to be able to describe non-joypad
XInput devices like guitars and whatnot, but also describe other common
things like player indicators, accelerometers, pointing devices, and
references to which sound, keypad, etc device is "part of" this
controller. And the list of unmapped controls for you to be able to
support stuff that SDL may not yet like analog buttons on a MFi
controller.

I think I suggested a "unified I/O" system before: a single system to
represent mice, joysticks, tablets, keyboards, and whatever else (some
of the gaming mice from Razor have a lot of buttons that seemingly map
as keyboard buttons, and there's always those new mice with the
touch-pad where your fingers rest). That would probably be the ideal
way to do the "unmapped" bit that you're describing. Player
indicators, if I'm getting your meaning correctly, would require an
expansion of the inputs to also accept output: not a big thing, but
might as well put some thought into "how", so that more output stuff
can be shoehorned into that later.

As for "part of this controller", you're talking about stuff like
microphone & earphone jacks on joypads & such, right? I think that
proper support would require the ability for some sort of external
program to provide the information in some way (I'm thinking of those
people that build massive flight-sim rigs at home when I say this...),
but in the (presumed, on my part) absence of such do you think that
providing "descriptive text strings" via some API would be enough to
future-proof things?
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
Sik


Joined: 26 Nov 2011
Posts: 905
2015-01-19 20:26 GMT-03:00, Jared Maddox:
Quote:
It might be wise to also include a way to get the surface that the
software renderer uses, though the ability to simply pass your own for
the renderer to be built around does make this unimportant for
anything except scripting languages.

The software renderer uses the window's own surface if you create it
the usual way (yeah, I just checked). I guess that such a function
would still be useful so you don't have to keep track of which surface
it's using, though.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
Bob


Joined: 19 Sep 2009
Posts: 185
LOL, I rarely post any more, too much to do on other subjects. (I just reached the level of being a webcomic after all :-) but I just have to jump in here for just a minute....


This subject comes up every couple of years. It comes up in a really big way, like now, about every five years. This subject almost always involves the renderer and the idea of adding hooks to make it easier to write add on libraries.

Based on experience I am going to go out on a limb and say that there will never be a case where everyone likes the renderer as it currently is. It would really help if people made a list of use cases for the renderer and listed where the existing one works for them and where it fails. You need real data to make decisions. Maybe this time we can get an all-singing all-dancing renderer that a larger percentage of people will like. You can not make all the people happy all the time.


The idea of hooks to support add ons is, in my arrogant opinion is not a good idea. The new hooks become part of the SDL API and get used for whatever, not just for add on libraries. That always happens. I have come to live by the rule that if it can be written entirely in terms of the existing SDL API then it is best implemented as a separate library. If implementing it requires changing internal data structures or internal code in SDL then it must be implemented as a new feature.


Add on libraries are you own personal projects and can be done at you own pace and implement anything you want. Adding new features to SDL takes dedication. You have to convince people that it is actually needed. It helps to write a version of it your self. Even if you do that do not expect the final version to look anything like your initial version. Expect to be the person who has to explain it and maintain it FOREVER. When I say dedication I mean dedication. Plus, of course, you do have to convince Sam and Ryan that it actually should be a feature of SDL.


Back to lurking,


Bob Pendleton

TheGrumpyProgrammer.com






On Mon, Jan 19, 2015 at 7:23 PM, Sik the hedgehog wrote:
Quote:
2015-01-19 20:26 GMT-03:00, Jared Maddox:
Quote:
It might be wise to also include a way to get the surface that the
software renderer uses, though the ability to simply pass your own for
the renderer to be built around does make this unimportant for
anything except scripting languages.

The software renderer uses the window's own surface if you create it
the usual way (yeah, I just checked). I guess that such a function
would still be useful so you don't have to keep track of which surface
it's using, though.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org





--
+-----------------------------------------------------------
+ Bob Pendleton: writer and programmer
+ email:
+ mailing list: GameProgrammer.com        
+ blog: www.TheGrumpyProgrammer.com
pyroary


Joined: 18 Mar 2014
Posts: 7
As someone who's released 3 games using SDL- one using 1.2's software renderer, one using SDL 1.2 + OpenGL, and one using the SDL2 renderer, there is nothing higher on my wishlist than SDL_RenderGeometry (Bug 1734).

With this feature, I would be able to add skeletal animation support directly into my engine. I use Spine for my games but right now I have to export individual frames and combine them into bigger images, which makes it really unwieldy as even 128px tall characters end up having spritesheets the size of 4000x4000 once you have walk, stand, attack animations in 4 directions at 60 fps. With skeletal animation, I can do all sorts of stuff like flying cloth banners, light shafts, you name it (I know I can still do this stuff, just that RenderGeometry will make it waaay easier from both an artist's and programmer's POV).

This feature is *the* most important feature from my perspective. I would seriously be perfectly happy if only this feature were added to SDL2.1, and nothing else.

Arvind
Pyrodactyl Games
Adding features to SDL vs creating a satellite library
MrOzBarry


Joined: 26 Jun 2010
Posts: 620
Bob, thanks for your input; I thought you fell off the face of the earth!
On Tue, 20 Jan 2015 6:19 pm Bob Pendleton wrote:
Quote:
LOL, I rarely post any more, too much to do on other subjects. (I just reached the level of being a webcomic after all :-) but I just have to jump in here for just a minute....


This subject comes up every couple of years. It comes up in a really big way, like now, about every five years. This subject almost always involves the renderer and the idea of adding hooks to make it easier to write add on libraries.

Based on experience I am going to go out on a limb and say that there will never be a case where everyone likes the renderer as it currently is. It would really help if people made a list of use cases for the renderer and listed where the existing one works for them and where it fails. You need real data to make decisions. Maybe this time we can get an all-singing all-dancing renderer that a larger percentage of people will like. You can not make all the people happy all the time.


The idea of hooks to support add ons is, in my arrogant opinion is not a good idea. The new hooks become part of the SDL API and get used for whatever, not just for add on libraries. That always happens. I have come to live by the rule that if it can be written entirely in terms of the existing SDL API then it is best implemented as a separate library. If implementing it requires changing internal data structures or internal code in SDL then it must be implemented as a new feature.


Add on libraries are you own personal projects and can be done at you own pace and implement anything you want. Adding new features to SDL takes dedication. You have to convince people that it is actually needed. It helps to write a version of it your self. Even if you do that do not expect the final version to look anything like your initial version. Expect to be the person who has to explain it and maintain it FOREVER. When I say dedication I mean dedication. Plus, of course, you do have to convince Sam and Ryan that it actually should be a feature of SDL.


Back to lurking,


Bob Pendleton

TheGrumpyProgrammer.com







On Mon, Jan 19, 2015 at 7:23 PM, Sik the hedgehog wrote:
Quote:
2015-01-19 20:26 GMT-03:00, Jared Maddox:
Quote:
It might be wise to also include a way to get the surface that the
software renderer uses, though the ability to simply pass your own for
the renderer to be built around does make this unimportant for
anything except scripting languages.

The software renderer uses the window's own surface if you create it
the usual way (yeah, I just checked). I guess that such a function
would still be useful so you don't have to keep track of which surface
it's using, though.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org






--
+-----------------------------------------------------------
+ Bob Pendleton: writer and programmer
+ email:
+ mailing list: GameProgrammer.com        
+ blog: www.TheGrumpyProgrammer.com

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
Jared Maddox
Guest

Quote:
Date: Mon, 19 Jan 2015 22:23:53 -0300
From: Sik the hedgehog
To: SDL Development List
Subject: Re: [SDL] Adding features to SDL vs creating a satellite
library
Message-ID:

Content-Type: text/plain; charset=UTF-8

2015-01-19 20:26 GMT-03:00, Jared Maddox:
Quote:
It might be wise to also include a way to get the surface that the
software renderer uses, though the ability to simply pass your own for
the renderer to be built around does make this unimportant for
anything except scripting languages.

The software renderer uses the window's own surface if you create it
the usual way (yeah, I just checked). I guess that such a function
would still be useful so you don't have to keep track of which surface
it's using, though.


To be honest, even when I was typing it the suggestion came across as
pedantic, the only reason I sent it is that some scripting system
might be setup in such a way that it needs the basic model provided
for OpenGL (and now suggested for DirectX).
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
Sik


Joined: 26 Nov 2011
Posts: 905
2015-01-20 20:01 GMT-03:00, Bob Pendleton:
Quote:
The idea of hooks to support add ons is, in my arrogant opinion is not a
good idea. The new hooks become part of the SDL API and get used for
whatever, not just for add on libraries. That always happens. I have come
to live by the rule that if it can be written entirely in terms of the
existing SDL API then it is best implemented as a separate library. If
implementing it requires changing internal data structures or internal code
in SDL then it must be implemented as a new feature.

I think the problem here is that you have people who want both things
at the same time. On one hand, people want to do 3D using the GPU
directly, something that can't be done with the renderer because its
state is unpredictable and how it works can change between versions
(and that's assuming you can even predict which backend it'll use!).
On the other hand, people don't want having to write whole new GPU
code from scratch or having to include extra libraries just to blit a
couple of bitmaps on screen (this is where the renderer comes in).

If you understand that you shouldn't mix both things then this isn't
an issue (and if you're injecting your own 3D code then doing your own
2D code should be trivial in comparison). The problem is that a lot of
people *constantly* fail to understand this, so you'll always end up
with some newbie asking why it breaks when they try to do it. So
either we make it work, or we somehow find out a way to make people
stop misunderstanding this issue.

Now, that the renderer is underfeatured (i.e. missing primitives and
such), that's another issue, but that can be fixed without throwing
away the existing stuff.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
Sik


Joined: 26 Nov 2011
Posts: 905
2015-01-20 20:01 GMT-03:00, Bob Pendleton:
Quote:
The idea of hooks to support add ons is, in my arrogant opinion is not a
good idea. The new hooks become part of the SDL API and get used for
whatever, not just for add on libraries. That always happens. I have come
to live by the rule that if it can be written entirely in terms of the
existing SDL API then it is best implemented as a separate library. If
implementing it requires changing internal data structures or internal code
in SDL then it must be implemented as a new feature.

I think the problem here is that you have people who want both things
at the same time. On one hand, people want to do 3D using the GPU
directly, something that can't be done with the renderer because its
state is unpredictable and how it works can change between versions
(and that's assuming you can even predict which backend it'll use!).
On the other hand, people don't want having to write whole new GPU
code from scratch or having to include extra libraries just to blit a
couple of bitmaps on screen (this is where the renderer comes in).

If you understand that you shouldn't mix both things then this isn't
an issue (and if you're injecting your own 3D code then doing your own
2D code should be trivial in comparison). The problem is that a lot of
people *constantly* fail to understand this, so you'll always end up
with some newbie asking why it breaks when they try to do it. So
either we make it work, or we somehow find out a way to make people
stop misunderstanding this issue.

Now, that the renderer is underfeatured (i.e. missing primitives and
such), that's another issue, but that can be fixed without throwing
away the existing stuff.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
Jonny D


Joined: 12 Sep 2009
Posts: 932
I'm in agreement with Bob Lurkerton.  We can evolve SDL_Renderer to fulfill most use-cases and from there we just have to live with it.  Adding on to SDL is the more personal/flexible way to achieve features that you want.


What I really want to avoid is another big break like the 1.2 -> 2.0 renderer migration.  When SDL 2.1 comes out, the SDL_gpu API will still work for all of the versions of SDL (zero migration cost, backward and forward compatibility).  A rendering system built into SDL cannot do that.  Not to mention that results are results and you can have working add-on code in an afternoon.  Wiring things into the non-public interface within SDL is not a simple job.


I'm personally invested in SDL_gpu, so it might be no surprise that it feels awkward talking about so many features it already has.  For me, these are all solved problems that can be used for apps now, but getting them worked into SDL_Renderer is still a big challenge on several fronts.  And the result may be off the mark for some because, as Ryan noted recently, the rendering system represents some serious binary bloat (particularly the software renderer).


So I think I've said it before...  Either we get some features in that reasonable people expect to have in a modern rendering system (without breaking compatibility hopefully?), or we more clearly tag SDL_Renderer as a limited (some say "toy", but that's not accurate) rendering API and recommend add-ons to replace it.


Jonny D
Adding features to SDL vs creating a satellite library
Joseph Carter


Joined: 20 Sep 2013
Posts: 279
My specific weird use case that requires extending the capabilities
of SDL's renderer:

I have a couple old DOS games that use Borland's ancient turtle
graphics library(!) There actually used to be a fairly clever
library that emulated this environment for SDL 1.2, but these have
not been ported to SDL2 and would require SDL_gfx anyway. The
originals were written on an IBM PS/2 286, but would've run just fine
on older machines if you had a reasonably modern gaming video card!

Something as obscure as turtle graphics do NOT belong in SDL
obviously, but the games actually both basically used it because it's
what was there because the author was a n00b. So there's a lot of
"moveto() then draw" sort of construction. Still, it drew filled
polygons, line arcs, and the odd filled circle, and SDL2's renderer
neither has the ability to do this, nor the facility to let me sanely
accomplish the same outside of SDL with an arbitrary renderer.

Yet I could implement that in all but the DX9/DX11 renderers today,
and for those I'd just have to look up some API functions and port
the GLSL version to HLSL with an automated tool. Gimme another day
or so to look up how it's done and test the result.

But I can't do that because nobody's allowed to add anything to the
SDL renderer, nor can the SDL renderer be extended by a library. The
standard claptrap is that if your code needs something not in the
renderer, then don't use the renderer. Which makes it the single
most useless waste of code in SDL.


What I'd do with SDL's renderer does not break ABI compatibility, but
it may require a little refactoring of internal code. First, I'd
add SDL_CreateGLRenderer and equivalents. At least on OpenGL 1.x
(and perhaps OpenGL ES v1, I'd have to check) this can fail due to
the context not supporting render to texture.

This covers every usage case of mixing 2D and 3D I can think of from
extension libraries like a SDL_console port to wanting to add 3D
effects to a 2D game, etc. It would even allow me to bind OpenGL the
way SDL does and make my old DOS games draw their arcs and circles
using OpenGL if possible or twiddle pixels on a surface if not.

And it can be done with or without consideration to support D3D
(though it would seem rude to not add support for that given the
Windows Store…)


Separately from that, I'd like to engage in some diff reduction
amongst the various GL render targets. I don't think I want to do
any code refactoring, but I might port the crufty desktop GL to use
vertex arrays (for code parity with GLESv1 rather than "performance")
and basically just make it easy to see how these renderers differ
from one another to help dispel the "maze of twisty little renderers,
all totally different" argument against doing anything to them ever.

Ideally I'd like to do the same to the two D3D renderers, but I'd
need a hand with that or at least some quality time spent with the
MSDN website. They'll obviously be totally different from the OpenGL
renderers, but they appear to be less different from each other than
a casual diff suggests.

PSP is on its own. I'm pretty sure the PSP target doesn't even
compile at the moment. Is someone actually maintaining it still? :)

From there I'd consider the problem carefully to determine how
feasible it is to allow something outside SDL to query some renderer
state details in a way that'd allow something like SDL_gfx to plug
into it and play nice. It's possible certainly, but it might break
too many rules.

That solves all of my use cases, and all of the cases I can actually
imagine. Moreover, it can be done within the current ABI. It can
probably be improved upon when the ABI is unfrozen, but I'll take
something that works over something theoretical in the future any day
of the week.


And for the C++ weenie l33t g4m3 c0d0rz who insist that you can't do
curves in OpenGL without a shader to do it, there is math and a
visual explanation at http://en.wikipedia.org/wiki/Bézier_curve (not
that I think it'll do much good…)

Joseph

On Tue, Jan 20, 2015 at 05:01:56PM -0600, Bob Pendleton wrote:
Quote:
LOL, I rarely post any more, too much to do on other subjects. (I just
reached the level of being a webcomic after all :-) but I just have to jump
in here for just a minute....

This subject comes up every couple of years. It comes up in a really big
way, like now, about every five years. This subject almost always involves
the renderer and the idea of adding hooks to make it easier to write add on
libraries.

Based on experience I am going to go out on a limb and say that there will
never be a case where everyone likes the renderer as it currently is. It
would really help if people made a list of use cases for the renderer and
listed where the existing one works for them and where it fails. You need
real data to make decisions. Maybe this time we can get an all-singing
all-dancing renderer that a larger percentage of people will like. You can
not make all the people happy all the time.

The idea of hooks to support add ons is, in my arrogant opinion is not a
good idea. The new hooks become part of the SDL API and get used for
whatever, not just for add on libraries. That always happens. I have come
to live by the rule that if it can be written entirely in terms of the
existing SDL API then it is best implemented as a separate library. If
implementing it requires changing internal data structures or internal code
in SDL then it must be implemented as a new feature.

Add on libraries are you own personal projects and can be done at you own
pace and implement anything you want. Adding new features to SDL takes
dedication. You have to convince people that it is actually needed. It
helps to write a version of it your self. Even if you do that do not expect
the final version to look anything like your initial version. Expect to be
the person who has to explain it and maintain it FOREVER. When I say
dedication I mean dedication. Plus, of course, you do have to convince Sam
and Ryan that it actually should be a feature of SDL.

Back to lurking,

Bob Pendleton
TheGrumpyProgrammer.com


On Mon, Jan 19, 2015 at 7:23 PM, Sik the hedgehog <
wrote:

Quote:
2015-01-19 20:26 GMT-03:00, Jared Maddox:
Quote:
It might be wise to also include a way to get the surface that the
software renderer uses, though the ability to simply pass your own for
the renderer to be built around does make this unimportant for
anything except scripting languages.

The software renderer uses the window's own surface if you create it
the usual way (yeah, I just checked). I guess that such a function
would still be useful so you don't have to keep track of which surface
it's using, though.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org




--
+-----------------------------------------------------------
+ Bob Pendleton: writer and programmer
+ email:
+ mailing list: GameProgrammer.com
+ blog: www.TheGrumpyProgrammer.com

Quote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
Bob


Joined: 19 Sep 2009
Posts: 185
Reading these replies I see what is called "target fixation". Pilots get so fixated on a specific target that they get shot down by the guy on their six or they fly into the ground or into the side of a mountain. In the case of turtle graphics I think you are so fixated on doing it in the renderer that you are missing the easy solution. It is not hard to implement turtle graphics on top of OpenGL directly. Really it isn't I've implemented turtle graphics on top of several different graphics libraries and it is not hard to do and it is kind of fun.


OTOH, if the code has a bunch of moveto(x,y) type calls in it it is not turtle graphics. In turtle graphics you see things like forward(distance), left(angle), but never moveto(x,y). It you are talking about the old Borland graphics libraries, which I used for a long time because it was the best thing available, those libraries were based on the kind of graphic libraries seen on the old flat bed plotters (think a robot with a pen) and the old storage scope displays. Those libraries were based on vector graphics, not on turtle graphics.


Sik's point is valid but the problem is that you can not educate people not to misuse and API. If the API exists people will use it. The only way to prevent misuse is to not give people the API. The other problem is that once you open up some parts of the system people will ask for more parts to be open. That leads to an end less progression of additions. In the end you wind up with something that can not be maintained because any change leads to a change in the semantics of an existing API.


People to not understand that API design is not just a technical problem. It is at least as much a social problem as technical. Sometimes you just have to say no. One of the key people problems is that no mater how much experience you have with something, you are likely to hate a new system for doing that thing because it was built from a different point of view. If a problem is an elephant and the designers of the new system only see the elephant from the front, and you always look at the elephant from the side it can take a long to understand why they attacked the problem the way they did.


As to the very kind words about where I have been. I did not drop off the face of the earth. The last few years I have gone through the experience of losing the sight in one eye (no cool stereo graphics for ME! At least I got to see Avatar in 3D) and while that was going on I was told I had a incurable, potentially fatal cancer. About a month later I found out that the average time to die from my peculiar cancer was... well they don't know with proper treatment everyone who has it dies of old age before they die of cancer... So, all that knocked me for a serious loop mentally, spiritually, and physically. Took a while to get my head straight. As I have often said before, the only thing worse that getting old is not getting old.


Oh well, it really made me feel good to hear that I was missed.


Bob Pendleton

TheGrumpyProgrammer.com



On Thu, Jan 22, 2015 at 12:43 PM, T. Joseph Carter wrote:
Quote:
My specific weird use case that requires extending the capabilities of SDL's renderer:

I have a couple old DOS games that use Borland's ancient turtle graphics library(!)  There actually used to be a fairly clever library that emulated this environment for SDL 1.2, but these have not been ported to SDL2 and would require SDL_gfx anyway.  The originals were written on an IBM PS/2 286, but would've run just fine on older machines if you had a reasonably modern gaming video card!

Something as obscure as turtle graphics do NOT belong in SDL obviously, but the games actually both basically used it because it's what was there because the author was a n00b.  So there's a lot of "moveto() then draw" sort of construction.  Still, it drew filled polygons, line arcs, and the odd filled circle, and SDL2's renderer neither has the ability to do this, nor the facility to let me sanely accomplish the same outside of SDL with an arbitrary renderer.

Yet I could implement that in all but the DX9/DX11 renderers today, and for those I'd just have to look up some API functions and port the GLSL version to HLSL with an automated tool.  Gimme another day or so to look up how it's done and test the result.

But I can't do that because nobody's allowed to add anything to the SDL renderer, nor can the SDL renderer be extended by a library.  The standard claptrap is that if your code needs something not in the renderer, then don't use the renderer.  Which makes it the single most useless waste of code in SDL.


What I'd do with SDL's renderer does not break ABI compatibility, but it may require a little refactoring of internal code.  First, I'd add SDL_CreateGLRenderer and equivalents.  At least on OpenGL 1.x (and perhaps OpenGL ES v1, I'd have to check) this can fail due to the context not supporting render to texture.

This covers every usage case of mixing 2D and 3D I can think of from extension libraries like a SDL_console port to wanting to add 3D effects to a 2D game, etc.  It would even allow me to bind OpenGL the way SDL does and make my old DOS games draw their arcs and circles using OpenGL if possible or twiddle pixels on a surface if not.

And it can be done with or without consideration to support D3D (though it would seem rude to not add support for that given the Windows Store…)


Separately from that, I'd like to engage in some diff reduction amongst the various GL render targets.  I don't think I want to do any code refactoring, but I might port the crufty desktop GL to use vertex arrays (for code parity with GLESv1 rather than "performance") and basically just make it easy to see how these renderers differ from one another to help dispel the "maze of twisty little renderers, all totally different" argument against doing anything to them ever.

Ideally I'd like to do the same to the two D3D renderers, but I'd need a hand with that or at least some quality time spent with the MSDN website.  They'll obviously be totally different from the OpenGL renderers, but they appear to be less different from each other than a casual diff suggests.

PSP is on its own.  I'm pretty sure the PSP target doesn't even compile at the moment.  Is someone actually maintaining it still?  Smile

From there I'd consider the problem carefully to determine how feasible it is to allow something outside SDL to query some renderer state details in a way that'd allow something like SDL_gfx to plug into it and play nice.  It's possible certainly, but it might break too many rules.

That solves all of my use cases, and all of the cases I can actually imagine.  Moreover, it can be done within the current ABI.  It can probably be improved upon when the ABI is unfrozen, but I'll take something that works over something theoretical in the future any day of the week.


And for the C++ weenie l33t g4m3 c0d0rz who insist that you can't do curves in OpenGL without a shader to do it, there is math and a visual explanation at http://en.wikipedia.org/wiki/Bézier_curve (not that I think it'll do much good…)

Joseph

On Tue, Jan 20, 2015 at 05:01:56PM -0600, Bob Pendleton wrote:
Quote:
LOL, I rarely post any more, too much to do on other subjects. (I just
reached the level of being a webcomic after all :-) but I just have to jump
in here for just a minute....

This subject comes up every couple of years. It comes up in a really big
way, like now, about every five years. This subject almost always involves
the renderer and the idea of adding hooks to make it easier to write add on
libraries.

Based on experience I am going to go out on a limb and say that there will
never be a case where everyone likes the renderer as it currently is. It
would really help if people made a list of use cases for the renderer and
listed where the existing one works for them and where it fails. You need
real data to make decisions. Maybe this time we can get an all-singing
all-dancing renderer that a larger percentage of people will like. You can
not make all the people happy all the time.

The idea of hooks to support add ons is, in my arrogant opinion is not a
good idea. The new hooks become part of the SDL API and get used for
whatever, not just for add on libraries. That always happens. I have come
to live by the rule that if it can be written entirely in terms of the
existing SDL API then it is best implemented as a separate library. If
implementing it requires changing internal data structures or internal code
in SDL then it must be implemented as a new feature.

Add on libraries are you own personal projects and can be done at you own
pace and implement anything you want. Adding new features to SDL takes
dedication. You have to convince people that it is actually needed. It
helps to write a version of it your self. Even if you do that do not expect
the final version to look anything like your initial version. Expect to be
the person who has to explain it and maintain it FOREVER. When I say
dedication I mean dedication. Plus, of course, you do have to convince Sam
and Ryan that it actually should be a feature of SDL.

Back to lurking,

Bob Pendleton
TheGrumpyProgrammer.com


On Mon, Jan 19, 2015 at 7:23 PM, Sik the hedgehog <
wrote:

Quote:
2015-01-19 20:26 GMT-03:00, Jared Maddox:
Quote:
It might be wise to also include a way to get the surface that the
software renderer uses, though the ability to simply pass your own for
the renderer to be built around does make this unimportant for
anything except scripting languages.

The software renderer uses the window's own surface if you create it
the usual way (yeah, I just checked). I guess that such a function
would still be useful so you don't have to keep track of which surface
it's using, though.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org




--
+-----------------------------------------------------------
+ Bob Pendleton: writer and programmer
+ email:
+ mailing list: GameProgrammer.com
+ blog: www.TheGrumpyProgrammer.com

Quote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org





--
+-----------------------------------------------------------
+ Bob Pendleton: writer and programmer
+ email:
+ blog: www.TheGrumpyProgrammer.com
Adding features to SDL vs creating a satellite library
Jonny D


Joined: 12 Sep 2009
Posts: 932
You were indeed missed over where I sit, and not only because of your insights.  I hope you can keep your head where you need it to be, even if we try to distract you. Wink


Jonny D
Adding features to SDL vs creating a satellite library
Joseph Carter


Joined: 20 Sep 2013
Posts: 279
The target is a 2D game that is easy to run in software on SDL 1.2,
but cannot be ported to SDL2 without an OpenGL dependency, which kind
of means no WinRT.

It's a 2D game. What is the 2D renderer for if not for 2D games? It
should be possible to implement this using the API designed for
porting 2D games, or the API shouldn't exist because we should all be
using OpenGL anyway.

Yeah, I could do it in OpenGL. But I wanted to take advantage of the
ability to make the game run on Windows (including WinRT) at the same
time and share a couple of games I originally wrote over 20 years
ago.

And we're back to the API that may not ever be changed, cannot be
maintained, and indeed shall not be touched: The all-holy SDL 2D
"renderer". Which rightly ought to be ripped out entirely simply
because nobody can depend on code that is so sacred that it may not
ever be maintained.

Joseph

On Fri, Jan 23, 2015 at 11:27:33AM -0600, Bob Pendleton wrote:
Quote:
Reading these replies I see what is called "target fixation". Pilots get so
fixated on a specific target that they get shot down by the guy on their
six or they fly into the ground or into the side of a mountain. In the case
of turtle graphics I think you are so fixated on doing it in the renderer
that you are missing the easy solution. It is not hard to implement turtle
graphics on top of OpenGL directly. Really it isn't I've implemented turtle
graphics on top of several different graphics libraries and it is not hard
to do and it is kind of fun.

OTOH, if the code has a bunch of moveto(x,y) type calls in it it is not
turtle graphics. In turtle graphics you see things like forward(distance),
left(angle), but never moveto(x,y). It you are talking about the old
Borland graphics libraries, which I used for a long time because it was the
best thing available, those libraries were based on the kind of graphic
libraries seen on the old flat bed plotters (think a robot with a pen) and
the old storage scope displays. Those libraries were based on vector
graphics, not on turtle graphics.

Sik's point is valid but the problem is that you can not educate people not
to misuse and API. If the API exists people will use it. The only way to
prevent misuse is to not give people the API. The other problem is that
once you open up some parts of the system people will ask for more parts to
be open. That leads to an end less progression of additions. In the end you
wind up with something that can not be maintained because any change leads
to a change in the semantics of an existing API.

People to not understand that API design is not just a technical problem.
It is at least as much a social problem as technical. Sometimes you just
have to say no. One of the key people problems is that no mater how much
experience you have with something, you are likely to hate a new system for
doing that thing because it was built from a different point of view. If a
problem is an elephant and the designers of the new system only see the
elephant from the front, and you always look at the elephant from the side
it can take a long to understand why they attacked the problem the way they
did.

As to the very kind words about where I have been. I did not drop off the
face of the earth. The last few years I have gone through the experience of
losing the sight in one eye (no cool stereo graphics for ME! At least I got
to see Avatar in 3D) and while that was going on I was told I had a
incurable, potentially fatal cancer. About a month later I found out that
the average time to die from my peculiar cancer was... well they don't know
with proper treatment everyone who has it dies of old age before they die
of cancer... So, all that knocked me for a serious loop mentally,
spiritually, and physically. Took a while to get my head straight. As I
have often said before, the only thing worse that getting old is not
getting old.

Oh well, it really made me feel good to hear that I was missed.

Bob Pendleton
TheGrumpyProgrammer.com


On Thu, Jan 22, 2015 at 12:43 PM, T. Joseph Carter <
wrote:

Quote:
My specific weird use case that requires extending the capabilities of
SDL's renderer:

I have a couple old DOS games that use Borland's ancient turtle graphics
library(!) There actually used to be a fairly clever library that emulated
this environment for SDL 1.2, but these have not been ported to SDL2 and
would require SDL_gfx anyway. The originals were written on an IBM PS/2
286, but would've run just fine on older machines if you had a reasonably
modern gaming video card!

Something as obscure as turtle graphics do NOT belong in SDL obviously,
but the games actually both basically used it because it's what was there
because the author was a n00b. So there's a lot of "moveto() then draw"
sort of construction. Still, it drew filled polygons, line arcs, and the
odd filled circle, and SDL2's renderer neither has the ability to do this,
nor the facility to let me sanely accomplish the same outside of SDL with
an arbitrary renderer.

Yet I could implement that in all but the DX9/DX11 renderers today, and
for those I'd just have to look up some API functions and port the GLSL
version to HLSL with an automated tool. Gimme another day or so to look up
how it's done and test the result.

But I can't do that because nobody's allowed to add anything to the SDL
renderer, nor can the SDL renderer be extended by a library. The standard
claptrap is that if your code needs something not in the renderer, then
don't use the renderer. Which makes it the single most useless waste of
code in SDL.


What I'd do with SDL's renderer does not break ABI compatibility, but it
may require a little refactoring of internal code. First, I'd add
SDL_CreateGLRenderer and equivalents. At least on OpenGL 1.x (and perhaps
OpenGL ES v1, I'd have to check) this can fail due to the context not
supporting render to texture.

This covers every usage case of mixing 2D and 3D I can think of from
extension libraries like a SDL_console port to wanting to add 3D effects to
a 2D game, etc. It would even allow me to bind OpenGL the way SDL does and
make my old DOS games draw their arcs and circles using OpenGL if possible
or twiddle pixels on a surface if not.

And it can be done with or without consideration to support D3D (though it
would seem rude to not add support for that given the Windows Store…)


Separately from that, I'd like to engage in some diff reduction amongst
the various GL render targets. I don't think I want to do any code
refactoring, but I might port the crufty desktop GL to use vertex arrays
(for code parity with GLESv1 rather than "performance") and basically just
make it easy to see how these renderers differ from one another to help
dispel the "maze of twisty little renderers, all totally different"
argument against doing anything to them ever.

Ideally I'd like to do the same to the two D3D renderers, but I'd need a
hand with that or at least some quality time spent with the MSDN website.
They'll obviously be totally different from the OpenGL renderers, but they
appear to be less different from each other than a casual diff suggests.

PSP is on its own. I'm pretty sure the PSP target doesn't even compile at
the moment. Is someone actually maintaining it still? :)

From there I'd consider the problem carefully to determine how feasible it
is to allow something outside SDL to query some renderer state details in a
way that'd allow something like SDL_gfx to plug into it and play nice.
It's possible certainly, but it might break too many rules.

That solves all of my use cases, and all of the cases I can actually
imagine. Moreover, it can be done within the current ABI. It can probably
be improved upon when the ABI is unfrozen, but I'll take something that
works over something theoretical in the future any day of the week.


And for the C++ weenie l33t g4m3 c0d0rz who insist that you can't do
curves in OpenGL without a shader to do it, there is math and a visual
explanation at http://en.wikipedia.org/wiki/Bézier_curve (not that I
think it'll do much good…)

Joseph

On Tue, Jan 20, 2015 at 05:01:56PM -0600, Bob Pendleton wrote:

Quote:
LOL, I rarely post any more, too much to do on other subjects. (I just
reached the level of being a webcomic after all :-) but I just have to
jump
in here for just a minute....

This subject comes up every couple of years. It comes up in a really big
way, like now, about every five years. This subject almost always involves
the renderer and the idea of adding hooks to make it easier to write add
on
libraries.

Based on experience I am going to go out on a limb and say that there will
never be a case where everyone likes the renderer as it currently is. It
would really help if people made a list of use cases for the renderer and
listed where the existing one works for them and where it fails. You need
real data to make decisions. Maybe this time we can get an all-singing
all-dancing renderer that a larger percentage of people will like. You can
not make all the people happy all the time.

The idea of hooks to support add ons is, in my arrogant opinion is not a
good idea. The new hooks become part of the SDL API and get used for
whatever, not just for add on libraries. That always happens. I have come
to live by the rule that if it can be written entirely in terms of the
existing SDL API then it is best implemented as a separate library. If
implementing it requires changing internal data structures or internal
code
in SDL then it must be implemented as a new feature.

Add on libraries are you own personal projects and can be done at you own
pace and implement anything you want. Adding new features to SDL takes
dedication. You have to convince people that it is actually needed. It
helps to write a version of it your self. Even if you do that do not
expect
the final version to look anything like your initial version. Expect to be
the person who has to explain it and maintain it FOREVER. When I say
dedication I mean dedication. Plus, of course, you do have to convince Sam
and Ryan that it actually should be a feature of SDL.

Back to lurking,

Bob Pendleton
TheGrumpyProgrammer.com


On Mon, Jan 19, 2015 at 7:23 PM, Sik the hedgehog <
wrote:

2015-01-19 20:26 GMT-03:00, Jared Maddox:
Quote:
Quote:
It might be wise to also include a way to get the surface that the
software renderer uses, though the ability to simply pass your own for
the renderer to be built around does make this unimportant for
anything except scripting languages.

The software renderer uses the window's own surface if you create it
the usual way (yeah, I just checked). I guess that such a function
would still be useful so you don't have to keep track of which surface
it's using, though.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org




--
+-----------------------------------------------------------
+ Bob Pendleton: writer and programmer
+ email:
+ mailing list: GameProgrammer.com
+ blog: www.TheGrumpyProgrammer.com


_______________________________________________

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org




--
+-----------------------------------------------------------
+ Bob Pendleton: writer and programmer
+ email:
+ blog: www.TheGrumpyProgrammer.com

Quote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
Alex Szpakowski
Guest

https://github.com/MSOpenTech/angle

On Jan 23, 2015, at 2:46 PM, T. Joseph Carter wrote:

Quote:
OpenGL dependency, which kind of means no WinRT.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
gabomdq


Joined: 28 Jul 2011
Posts: 495
Location: Argentina
Angle should work (it did last time I checked).


https://hg.libsdl.org/SDL/file/tip/docs/README-windows.mdhttps://hg.libsdl.org/SDL/file/tip/docs/README-winrt.md



There's also SDL-gpu.

2015-01-23 15:48 GMT-03:00 Alex Szpakowski:
Quote:
https://github.com/MSOpenTech/angle

On Jan 23, 2015, at 2:46 PM, T. Joseph Carter wrote:

Quote:
OpenGL dependency, which kind of means no WinRT.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org




--
Gabriel.
Re: Adding features to SDL vs creating a satellite library
DLudwig


Joined: 09 Feb 2012
Posts: 179
[quote="Alex Szpakowski"]https://github.com/MSOpenTech/angle

On Jan 23, 2015, at 2:46 PM, T. Joseph Carter wrote:

Quote:
OpenGL dependency, which kind of means no WinRT.


ANGLE should work on WinRT, just note that provides the OpenGL ES 2.x API, and not non-ES/desktop OpenGL. I think there might be some ongoing work on having it also support OpenGL ES 3.x, but I'm not certain of that.

Cheers,
-- David L.
Adding features to SDL vs creating a satellite library
Joseph Carter


Joined: 20 Sep 2013
Posts: 279
Great, more external dependencies! Oh, and in this case the need to
write my code for OpenGL ES which is almost but not quite OpenGL.

I'm beginning to remember all too clearly why I stopped working on
SDL. It isn't worth fighting with people over every single detail
and watching patches go unused because they do something, anything.

Joseph

On Fri, Jan 23, 2015 at 02:48:44PM -0400, Alex Szpakowski wrote:
Quote:
https://github.com/MSOpenTech/angle

On Jan 23, 2015, at 2:46 PM, T. Joseph Carter wrote:

Quote:
OpenGL dependency, which kind of means no WinRT.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
Joseph Carter


Joined: 20 Sep 2013
Posts: 279
If I wanted an OpenGL dependency, I'd have rewritten the code for
OpenGL.

Joseph

On Fri, Jan 23, 2015 at 03:53:02PM -0300, Gabriel Jacobo wrote:
Quote:
Angle should work (it did last time I checked).

https://hg.libsdl.org/SDL/file/tip/docs/README-windows.md
https://hg.libsdl.org/SDL/file/tip/docs/README-winrt.md

There's also SDL-gpu.

2015-01-23 15:48 GMT-03:00 Alex Szpakowski:

Quote:
https://github.com/MSOpenTech/angle

On Jan 23, 2015, at 2:46 PM, T. Joseph Carter <
wrote:

Quote:
OpenGL dependency, which kind of means no WinRT.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org




--
Gabriel.

Quote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
Alex Szpakowski
Guest

Words of wisdom right there. Smile

On Jan 23, 2015, at 1:27 PM, Bob Pendleton wrote:

Quote:
Sik's point is valid but the problem is that you can not educate people not to misuse and API. If the API exists people will use it. The only way to prevent misuse is to not give people the API. The other problem is that once you open up some parts of the system people will ask for more parts to be open. That leads to an end less progression of additions. In the end you wind up with something that can not be maintained because any change leads to a change in the semantics of an existing API.

People to not understand that API design is not just a technical problem. It is at least as much a social problem as technical. Sometimes you just have to say no. One of the key people problems is that no mater how much experience you have with something, you are likely to hate a new system for doing that thing because it was built from a different point of view. If a problem is an elephant and the designers of the new system only see the elephant from the front, and you always look at the elephant from the side it can take a long to understand why they attacked the problem the way they did.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
gabomdq


Joined: 28 Jul 2011
Posts: 495
Location: Argentina
Dude, enough bitching. The SDL_RenderGeometry patch is there for the taking, add software rendering support to it, test it on our main target platforms (or get someone to test it) and it goes in, simple as that. The situation for many users will be better with that "simple" act.

No amount of pouting will change things, at some point the ugly truth is...patches or gtfo.


2015-01-23 15:55 GMT-03:00 T. Joseph Carter:
Quote:
Great, more external dependencies!  Oh, and in this case the need to write my code for OpenGL ES which is almost but not quite OpenGL.

I'm beginning to remember all too clearly why I stopped working on SDL.  It isn't worth fighting with people over every single detail and watching patches go unused because they do something, anything.

Joseph

On Fri, Jan 23, 2015 at 02:48:44PM -0400, Alex Szpakowski wrote:
Quote:
https://github.com/MSOpenTech/angle

On Jan 23, 2015, at 2:46 PM, T. Joseph Carter wrote:

Quote:
OpenGL dependency, which kind of means no WinRT.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org




--
Gabriel.
Adding features to SDL vs creating a satellite library
Joseph Carter


Joined: 20 Sep 2013
Posts: 279
Actually, the last I heard about the SDL_RenderGeometry patch was
that because software rendering of textured polygons was "too slow"
and "just bloat", it was not wanted.

Which is precisely what I'm "bitching" about:

PATCHES ARE _NOT_ WANTED.

Sik is having to fight tooth and nail to get accessibility support to
even be accepted as a concept because "it doesn't belong in SDL",
despite the established fact that it cannot be done anywhere else.
To listen to this mailing list, absolutely NOTHING belongs in SDL,
including some of the stuff that's already there.

So I'll "gtfo" now. Somebody else can fix the joystick mapping thing
I guess, or it will stay unfixed. My solution (for which I have had
code for a year BTW) got caught up in "breaks compatibility". (It
didn't actually, though Steam obviously won't know what to do with
half- or inverted-axis maps until it was updated…)

Joseph

On Fri, Jan 23, 2015 at 04:05:54PM -0300, Gabriel Jacobo wrote:
Quote:
Dude, enough bitching. The SDL_RenderGeometry patch is there for the
taking, add software rendering support to it, test it on our main target
platforms (or get someone to test it) and it goes in, simple as that. The
situation for many users will be better with that "simple" act.

No amount of pouting will change things, at some point the ugly truth
is...patches or gtfo.


2015-01-23 15:55 GMT-03:00 T. Joseph Carter:

Quote:
Great, more external dependencies! Oh, and in this case the need to write
my code for OpenGL ES which is almost but not quite OpenGL.

I'm beginning to remember all too clearly why I stopped working on SDL.
It isn't worth fighting with people over every single detail and watching
patches go unused because they do something, anything.

Joseph

On Fri, Jan 23, 2015 at 02:48:44PM -0400, Alex Szpakowski wrote:

Quote:
https://github.com/MSOpenTech/angle

On Jan 23, 2015, at 2:46 PM, T. Joseph Carter <
wrote:

OpenGL dependency, which kind of means no WinRT.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org




--
Gabriel.

Quote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
David Olofson
Guest

On Fri, Jan 23, 2015 at 7:46 PM, T. Joseph Carter
wrote:
[...]
Quote:
It's a 2D game.
[...]

They're all 2D games. What we're all doing (well, most of us, at
least) is using various hardware and software to render stuff into a
2D array of pixels. What is typically referred to as a "2D API" is
just an arbitrary subset of the graphics rendering capabilities that
are explicitly supported by commonly available platforms.

So, where do we draw the line? If we don't, "2D" becomes irrelevant,
and what we end up with then (as of now) is one of the mainstream 3D
rendering APIs. There is no golden feature set that will cover
everything everyone considers 2D. There will always be another missing
feature.


Anyway, FWIW, I pretty much agree that the one missing feature in the
current API is SDL_RenderGeometry(), mostly because it seems close
enough to what's already in there, while eliminating lots remaining
"must use OpenGL" situations. Going much beyond that (more blending
modes, z-buffering, custom shaders etc) is a slippery slope, leaning
towards Yet Another 3D API That Still Doesn't Please Everyone.

If SDL_RenderGeometry() is not enough, my position is still that you
should use OpenGL. Or Direct3D, directly, or via Angle. There's more
than one 3D API, and there's nothing much we can do about it! Just be
glad that the days of coding umpteen different machines directly to
the metal are over for most of you! Spoiled kids... Wink


--
//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.--- Games, examples, libraries, scripting, sound, music, graphics ---.
| http://consulting.olofson.net http://olofsonarcade.com |
'---------------------------------------------------------------------'
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
gabomdq


Joined: 28 Jul 2011
Posts: 495
Location: Argentina
2015-01-23 16:22 GMT-03:00 T. Joseph Carter:
Quote:
Actually, the last I heard about the SDL_RenderGeometry patch was that because software rendering of textured polygons was "too slow" and "just bloat", it was not wanted.

Which is precisely what I'm "bitching" about:

PATCHES ARE _NOT_ WANTED.


This is not true. I've never met Sam or Ryan in my life, I'm just some random dude from the other side of the world, yet I got a lot of patches accepted, even patches that added to the render API like SDL_RenderCopyEx and SDL_SetRenderTarget. The trick to doing that is simple...start by having the patch, not the idea of a patch or a feature request, then listen to the feedback provided in good faith, and don't lash out against it. Easier said than done, I know.


In turn, I accepted lots of patches from others, many that add functionality.


I campaigned for having some features added to the renderer code where some backends didn't support them (like SDL_RenderGeometry), mostly because I don't care about the software backend. I got turned down on that regard for reasons I don't exactly share but that I can respect...but the fact remains that (and Sam said this before), if that patch can be extended by someone to run on all backends, it will be accepted, simple as that. The software backend will suck speed wise, but it will be there..."for reference", I guess.


-- 


Gabriel.
Adding features to SDL vs creating a satellite library
Luke Groeninger
Guest

Quote:
On Jan 23, 2015, at 12:27 PM, David Olofson wrote:
So, where do we draw the line? If we don't, "2D" becomes irrelevant,and what we end up with then (as of now) is one of the mainstream 3Drendering APIs. There is no golden feature set that will covereverything everyone considers 2D. There will always be another missingfeature.

The problem here isn’t 2D becoming irrelevant - that’s never going to happen.

The problem is that twiddling bits in a buffer with your CPU and blitting them to the screen has been irrelevant for 20 or so years.

SDL_Render is trying to do two orthogonal things: placate the people who just want pixels in a buffer they can muck around with, and placate people who expect it to resemble a modern, hardware-backed drawing API (and supports things like DPI scaling).

Following with Bob’s point from earlier - the API being available means people are going to (ab)use it. For that reason, I think that, at minimum, SDL_render should actually be frozen and moved into a separate extension library. If people don’t want to invest in modernizing their code for accelerated rendering, fine - at least then it won’t be preventing development of the main SDL library. And if you’re smart (or foolish) enough to be mucking around with it, you’re on your own like it’s 1993.

Ideally, something like SDL_gpu would be promoted to being part of the main SDL library. I won’t say SDL needs it, but 2D rendering is a nice feature to have. And people seem to want a modern 2D renderer. So why don’t we invest in actually making a (sane) renderer that can leverage the accelerated graphics API’s available and do things like provide native Hi-DPI support?

Either way - the two things (GPU backed 2D compositing and raw pixel buffer access) are orthogonal, and trying to support both in a single API is a terrible route forward.

-L
Adding features to SDL vs creating a satellite library
Sik


Joined: 26 Nov 2011
Posts: 905
2015-01-23 16:22 GMT-03:00, T. Joseph Carter:
Quote:
Actually, the last I heard about the SDL_RenderGeometry patch was
that because software rendering of textured polygons was "too slow"
and "just bloat", it was not wanted.

It wasn't even that, and it wasn't an issue specific to that function
either, but to just about every proposal for the renderer: in order to
make it to SDL we need an implementation for all the backends. People
are willing to make implementations for the hardware accelerated
backends, but nobody wants to touch the software renderer. In fact I
remember that some years ago there were people demanding to get rid of
it altogether. If I recall correctly, it stayed because it turned out
some developers doing commercial programs needed it since it made
handling YUV formats easier somehow (probably due to the software
renderer internally using surfaces).

(also another good reason to keep the software renderer around: some
magnifiers have trouble with GPU-rendered graphics, so the software
renderer is the only one that works with them - at least let's keep
the option since it's working already!)

But yeah, basically the problem with the renderer API is that we get
stuck until we manage to settle on implementing the new stuff on all
existing backends.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
Jonny D


Joined: 12 Sep 2009
Posts: 932
To go along with what Sik is saying and to add another point...  SDL is, at heart, a platform abstraction layer.  Think about this:  Which platform are we targeting with the software renderer?

And to expand on Luke's: It makes sense to have comparable features supported via both OpenGL and Direct3D, but maybe software rendering should not be used as a fallback.  Maybe it's better to fail than to pretend that hardware accelerated features performed at an unusable speed are worth delaying development progress?

Jonny D







On Fri, Jan 23, 2015 at 4:16 PM, Sik the hedgehog wrote:
Quote:
2015-01-23 16:22 GMT-03:00, T. Joseph Carter:
Quote:
Actually, the last I heard about the SDL_RenderGeometry patch was
that because software rendering of textured polygons was "too slow"
and "just bloat", it was not wanted.

It wasn't even that, and it wasn't an issue specific to that function
either, but to just about every proposal for the renderer: in order to
make it to SDL we need an implementation for all the backends. People
are willing to make implementations for the hardware accelerated
backends, but nobody wants to touch the software renderer. In fact I
remember that some years ago there were people demanding to get rid of
it altogether. If I recall correctly, it stayed because it turned out
some developers doing commercial programs needed it since it made
handling YUV formats easier somehow (probably due to the software
renderer internally using surfaces).

(also another good reason to keep the software renderer around: some
magnifiers have trouble with GPU-rendered graphics, so the software
renderer is the only one that works with them - at least let's keep
the option since it's working already!)

But yeah, basically the problem with the renderer API is that we get
stuck until we manage to settle on implementing the new stuff on all
existing backends.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Adding features to SDL vs creating a satellite library
Luke
Guest

And also consider this - which platforms *don't* have some sort of GPU and hardware accelerated graphics API these days?


-L


On Fri, Jan 23, 2015, at 01:53 PM, Jonathan Dearborn wrote:

Quote:
To go along with what Sik is saying and to add another point... SDL is, at heart, a platform abstraction layer. Think about this: Which platform are we targeting with the software renderer?


And to expand on Luke's: It makes sense to have comparable features supported via both OpenGL and Direct3D, but maybe software rendering should not be used as a fallback. Maybe it's better to fail than to pretend that hardware accelerated features performed at an unusable speed are worth delaying development progress?


Jonny D






On Fri, Jan 23, 2015 at 4:16 PM, Sik the hedgehog wrote:

Quote:
2015-01-23 16:22 GMT-03:00, T. Joseph Carter:

Quote:
Actually, the last I heard about the SDL_RenderGeometry patch was

Quote:
that because software rendering of textured polygons was "too slow"

Quote:
and "just bloat", it was not wanted.


It wasn't even that, and it wasn't an issue specific to that function

either, but to just about every proposal for the renderer: in order to

make it to SDL we need an implementation for all the backends. People

are willing to make implementations for the hardware accelerated

backends, but nobody wants to touch the software renderer. In fact I

remember that some years ago there were people demanding to get rid of

it altogether. If I recall correctly, it stayed because it turned out

some developers doing commercial programs needed it since it made

handling YUV formats easier somehow (probably due to the software

renderer internally using surfaces).


(also another good reason to keep the software renderer around: some

magnifiers have trouble with GPU-rendered graphics, so the software

renderer is the only one that works with them - at least let's keep

the option since it's working already!)


But yeah, basically the problem with the renderer API is that we get

stuck until we manage to settle on implementing the new stuff on all

existing backends.

_______________________________________________

SDL mailing list



http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org





_______________________________________________

SDL mailing list



http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Adding features to SDL vs creating a satellite library
Bob


Joined: 19 Sep 2009
Posts: 185
I understand the frustration at not having patches accepted and not having features accepted. Believe me, I do. For several years I was a committer, I could check in my own patches, and I still had patches rejected. I have had patches rejected for many reasons, but the main one is that I do not have the global view of the project that Sam does. And, you know what, I never will have it. Sam and Ryan have to look at how every patch affects the entire design of the existing system, their ideas for the design of the future system and how the change will affect every person who uses the system right now. Not to mention things like the documentation and the demos.


Small changes can cause huge ripples of trouble for people. How much code has to be debugged and changed to adapt to the change? How many articles and tutorials have to be rewritten to accommodate a change in SDL semantics? How many people will wind up posting here wondering why things changed? The social implications of small changes can be huge. How many people will lose how many minutes of their time if a small change is made? It doesn't have to be very many minutes or very many people before it ads up to one or more complete human lives. Every change has to be balanced against that.


Yes, of course you can use the same arguments to justify adding things. Accessibility may be the perfect counter example. (though you would have to work a lot harder to convince me it was. Consider that I now use several accessibility features to be able to use a web browser but have no trouble playing games.) You also have to consider how much time Sam and Ryan have to spend evaluating things. They have lives that are separate from SDL. I don't know that much about Ryan, but Sam has a family, every minute he spends on SDL is time he could be with his family. I well bet that on his death bed Sam will not say "I wish I had spent more time on SDL and less time with my family".


Bob Pendleton






On Fri, Jan 23, 2015 at 3:04 PM, Luke wrote:
Quote:
And also consider this - which platforms *don't* have some sort of GPU and hardware accelerated graphics API these days?

 
-L 

 
On Fri, Jan 23, 2015, at 01:53 PM, Jonathan Dearborn wrote:

Quote:
To go along with what Sik is saying and to add another point...  SDL is, at heart, a platform abstraction layer.  Think about this:  Which platform are we targeting with the software renderer?

 
And to expand on Luke's: It makes sense to have comparable features supported via both OpenGL and Direct3D, but maybe software rendering should not be used as a fallback.  Maybe it's better to fail than to pretend that hardware accelerated features performed at an unusable speed are worth delaying development progress?

 
Jonny D

 
 


 
On Fri, Jan 23, 2015 at 4:16 PM, Sik the hedgehog wrote:

Quote:
2015-01-23 16:22 GMT-03:00, T. Joseph Carter:

Quote:
Actually, the last I heard about the SDL_RenderGeometry patch was

Quote:
that because software rendering of textured polygons was "too slow"

Quote:
and "just bloat", it was not wanted.

 
It wasn't even that, and it wasn't an issue specific to that function

either, but to just about every proposal for the renderer: in order to

make it to SDL we need an implementation for all the backends. People

are willing to make implementations for the hardware accelerated

backends, but nobody wants to touch the software renderer. In fact I

remember that some years ago there were people demanding to get rid of

it altogether. If I recall correctly, it stayed because it turned out

some developers doing commercial programs needed it since it made

handling YUV formats easier somehow (probably due to the software

renderer internally using surfaces).

 
(also another good reason to keep the software renderer around: some

magnifiers have trouble with GPU-rendered graphics, so the software

renderer is the only one that works with them - at least let's keep

the option since it's working already!)

 
But yeah, basically the problem with the renderer API is that we get

stuck until we manage to settle on implementing the new stuff on all

existing backends.

_______________________________________________

SDL mailing list



http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org



 

_______________________________________________

SDL mailing list



http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

 




_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org




--
+-----------------------------------------------------------
+ Bob Pendleton: writer and programmer
+ email:
+ blog: www.TheGrumpyProgrammer.com
Adding features to SDL vs creating a satellite library
David Olofson
Guest

On Fri, Jan 23, 2015 at 9:06 PM, Luke Groeninger wrote:
[...]
Quote:
The problem here isn’t 2D becoming irrelevant - that’s never going to
happen.

The problem is that twiddling bits in a buffer with your CPU and blitting
them to the screen has been irrelevant for 20 or so years.
[...]

The point I was trying to make is that "2D" is just a vaguely defined
subset of graphics rendering, whether you're doing the bit twiddling
in custom code, a software library, or in hardware.

However...

On Fri, Jan 23, 2015 at 9:53 PM, Jonathan Dearborn wrote:
Quote:
To go along with what Sik is saying and to add another point... SDL is, at
heart, a platform abstraction layer. Think about this: Which platform are
we targeting with the software renderer?

And to expand on Luke's: It makes sense to have comparable features
supported via both OpenGL and Direct3D, but maybe software rendering should
not be used as a fallback. Maybe it's better to fail than to pretend that
hardware accelerated features performed at an unusable speed are worth
delaying development progress?

Tough call, actually... Sometimes, like in GUI code, and load-time
preparation of in-game graphics, performance is not all that critical,
but it's important that it actually works, or you'll have nothing to
feed to the part that actually is hardware accelerated. (Or, "fast
enough," provided you actually find something that isn't hardware
accelerated at all...)

Problem is, even slow software rendering code is a lot of work to
implement, compared to passing parameters on to a rendering API. It's
easy to say that wrapping this or that makes sense because it's in
both OpenGL and Direct3D, but, this software renderer... If you need
it at all, do you want it slow but accurate, or ugly but fast?

If given the choice, I prefer rolling my own software renderer for any
"advanced" stuff I might need (that would probably be something weird
anyway, like ZeeSpace), to having to deal with various variants of
OpenGL and Direct3D on multiple platforms. I'd rather not actually
code and debug my own Direct3D code, as I do all work on GNU/Linux
normally, whereas software rendering code will nicely cross-compile to
any target.

So indeed, maybe it's the platform abstraction layer aspect of SDL
that should have top priority, and anything beyond that should be
dropped if the effort/usefulness ratio is too bad...?


--
//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.--- Games, examples, libraries, scripting, sound, music, graphics ---.
| http://consulting.olofson.net http://olofsonarcade.com |
'---------------------------------------------------------------------'
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
Ryan C. Gordon
Guest

(I've been down with the flu for the past list, so I'm just catching up
on this discussion now.)

Quote:
Which is precisely what I'm "bitching" about:

PATCHES ARE _NOT_ WANTED.

I still think the RenderGeometry patch is worth adding, but it needs
some work. It's not just the software renderer part. I believe the
necessary work will get done eventually, maybe even by me, although not
for 2.0.4. But I _do_ want to see this API make its way into SDL2 sooner
or later.

This is worth noting, though: my experience with open source is that
lots of patches get rejected. Some of them are "this needs more work"
and some are "this isn't something we're interested in,"
and--crucially--some are "this is a serious piece of work and I need to
find time to wrestle with this." Even _perfect_ changes, if large
enough, or making API changes, tend to be overwhelming to maintainers.
Because the one fixing the software texture mapper later is almost never
the person that wrote the patch, it's _me_.

Quote:
Sik is having to fight tooth and nail to get accessibility support to
even be accepted as a concept because "it doesn't belong in SDL",
despite the established fact that it cannot be done anywhere else. To
listen to this mailing list, absolutely NOTHING belongs in SDL,
including some of the stuff that's already there.

Well, the mailing list has as many opinions as it has subscriptions.

That is a blessing and a curse. Since it works like that, I wouldn't
expect you to go out and sell everyone on your idea. In many cases, you
don't have to sell anyone, either.

It's been a crazy year for me for many reasons, and a lot of these sort
of things haven't been on my radar as well as they should be: I honestly
have no idea what the status of Sik's patch is.

Sik: let's correct that. Can you get me up to speed? (even just give me
the bugzilla link? I should know already, but I don't.)

Quote:
Somebody else can fix the joystick mapping thing I guess, or it will
stay unfixed. My solution (for which I have had code for a year BTW)
got caught up in "breaks compatibility".

I didn't realize code was written; last I heard, a long time ago, it was
still a basic proposal. I'm still interested in talking about this if
you still have it. Adding features to the game controller config string
is a TODO list item for me, so I'd like to see where it was left.

--ryan.



_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
Ryan C. Gordon
Guest

Quote:
I don't know that much about Ryan

I have a daughter that turns three on the 31st. Smile

--ryan.


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
Joseph Carter


Joined: 20 Sep 2013
Posts: 279
It was left at "get a consensus about the best way to handle it". One wasn't happening, so I wrote code in the hopes that a working example was more useful than endless blather about what wasn't possible.

I lost a couple of things last October including the diff file and part of the source tree which implemented that (and a couple of other things), but I can extract the appropriate bits from it. The implementation wasn't hard, but it does feel kind of inefficient to me.

Joseph
Sent via mobile

Quote:
On Jan 23, 2015, at 19:25, Ryan C. Gordon wrote:


(I've been down with the flu for the past list, so I'm just catching up on this discussion now.)

Quote:
Which is precisely what I'm "bitching" about:

PATCHES ARE _NOT_ WANTED.

I still think the RenderGeometry patch is worth adding, but it needs some work. It's not just the software renderer part. I believe the necessary work will get done eventually, maybe even by me, although not for 2.0.4. But I _do_ want to see this API make its way into SDL2 sooner or later.

This is worth noting, though: my experience with open source is that lots of patches get rejected. Some of them are "this needs more work" and some are "this isn't something we're interested in," and--crucially--some are "this is a serious piece of work and I need to find time to wrestle with this." Even _perfect_ changes, if large enough, or making API changes, tend to be overwhelming to maintainers. Because the one fixing the software texture mapper later is almost never the person that wrote the patch, it's _me_.

Quote:
Sik is having to fight tooth and nail to get accessibility support to
even be accepted as a concept because "it doesn't belong in SDL",
despite the established fact that it cannot be done anywhere else. To
listen to this mailing list, absolutely NOTHING belongs in SDL,
including some of the stuff that's already there.

Well, the mailing list has as many opinions as it has subscriptions.

That is a blessing and a curse. Since it works like that, I wouldn't expect you to go out and sell everyone on your idea. In many cases, you don't have to sell anyone, either.

It's been a crazy year for me for many reasons, and a lot of these sort of things haven't been on my radar as well as they should be: I honestly have no idea what the status of Sik's patch is.

Sik: let's correct that. Can you get me up to speed? (even just give me the bugzilla link? I should know already, but I don't.)

Quote:
Somebody else can fix the joystick mapping thing I guess, or it will
stay unfixed. My solution (for which I have had code for a year BTW)
got caught up in "breaks compatibility".

I didn't realize code was written; last I heard, a long time ago, it was still a basic proposal. I'm still interested in talking about this if you still have it. Adding features to the game controller config string is a TODO list item for me, so I'd like to see where it was left.

--ryan.



_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
Sik


Joined: 26 Nov 2011
Posts: 905
2015-01-24 0:25 GMT-03:00, Ryan C. Gordon:
Quote:
It's been a crazy year for me for many reasons, and a lot of these sort
of things haven't been on my radar as well as they should be: I honestly
have no idea what the status of Sik's patch is.

Sik: let's correct that. Can you get me up to speed? (even just give me
the bugzilla link? I should know already, but I don't.)

Didn't get time around it yet, I said I was gonna do one a couple of
days ago but I was busy dealing with some HTML problem (incidentally
related). The thread is "Outputting text to accessibility tools" if
you want to look into it, though.

The gist of the thing is this: I was looking around to do screen
reader support and realize it'd be easier to just implement it in SDL,
especially since to do it I need to run code from within the window
procedure (in the case of Windows). So I propose the idea and also ask
for information on what other requirements may be there for other
platforms to take into account. Shortly after the thread devolves into
an argument that it shouldn't be added to SDL and should be made a
separate library (despite what I said about the window procedure
thing), which eventually itself devolved into *this* thread getting
created in response. I think you can guess where it's going...

Now things have calmed down over there so I can proceed to start
writing some code, but I think it shows the issues whenever something
new is proposed for SDL.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
i8degrees


Joined: 22 Nov 2014
Posts: 39
Hi Sik!

Just letting you know that I haven't forgotten, err I'm still planning on spending some time here soon at looking at accessibility options / API on the OS X front. I'm hoping that after a short preliminary peek at the sample code I have stashed away, I could help start considering the real challenge with you; SDL2's side of things with the API internals. I'm excited to delve into it.

I'm more or less at the end of the sub-project I've been working on, and now just adding last-minute polish and house cleaning up now. **mumbles** I was crazy enough to do extensive unit testing on an animation action engine, and it has cost me an enormous amount of time upfront... better now than later, though Razz

Cheers,
Jeffrey Carpenter


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Adding features to SDL vs creating a satellite library
Sik


Joined: 26 Nov 2011
Posts: 905
2015-01-24 21:25 GMT-03:00, Jeffrey Carpenter:
Quote:
Hi Sik!

Just letting you know that I haven't forgotten, err I'm still planning on
spending some time here soon at looking at accessibility options / API on
the OS X front. I'm hoping that after a short preliminary peek at the sample
code I have stashed away, I could help start considering the real challenge
with you; SDL2's side of things with the API internals. I'm excited to delve
into it.

This probably belongs in the other thread ^^;

Yesterday I got some speech-dispatcher code up quickly, although I
think I'm going to rewrite it to account for windows from the get-go.
In any case the code is simpler than what I had in my original
implementation.

My biggest issue will be dealing with the SDL internals since honestly
I have absolutely no idea about it (I have the feeling somebody else
will have to cope with that). There's a reason why I'm making a
"mock-up" rather than a proper patch.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org