Adding features to SDL vs creating a satellite library

[Gabriel_Jacobo]

2015-01-06 6:48 GMT-03:00 Sik the hedgehog <sik.the.hedgehog at gmail.com>:

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

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

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

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 https://bugzilla.libsdl.org/show_bug.cgi?id=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.

[Rainer_Deyke]

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

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.

–
Rainer Deyke (rainerd at eldwood.com)

[T_Joseph_Carter]

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.

JosephOn Wed, Jan 07, 2015 at 09:44:53AM +0100, Rainer Deyke wrote:

On 06.01.2015 04:17, T. Joseph Carter wrote:

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 (rainerd at eldwood.com)

---

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

[Sik_the_hedgehog]

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.

[T_Joseph_Carter]

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.

JosephOn Thu, Jan 08, 2015 at 11:06:35AM -0300, Sik the hedgehog wrote:

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.

[T_Joseph_Carter]

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.

JosephOn Fri, Jan 09, 2015 at 09:03:24AM +0100, Rainer Deyke wrote:

On 08.01.2015 06:50, T. Joseph Carter wrote:

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.

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.

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.

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 (rainerd at eldwood.com)

---

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

[Sik_the_hedgehog]

2015-01-09 5:36 GMT-03:00, T. Joseph Carter :

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.

[Rainer_Deyke]

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.

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.

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.

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.On 08.01.2015 06:50, T. Joseph Carter wrote:

–
Rainer Deyke (rainerd at eldwood.com)

[slouken]

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. :)On Wed, Jan 7, 2015 at 9:50 PM, T. Joseph Carter < tjcarter at spiritsubstance.com> wrote:

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:

On 06.01.2015 04:17, T. Joseph Carter wrote:

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 (rainerd at eldwood.com)

---

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

---

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

[T_Joseph_Carter]

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

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

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 < sik.the.hedgehog at gmail.com> wrote:

2015-01-19 20:26 GMT-03:00, Jared Maddox :

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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
±----------------------------------------------------------

• Bob Pendleton: writer and programmer
• email: Bob at Pendleton.com
• mailing list: GameProgrammer.com
• blog: www.TheGrumpyProgrammer.com

---

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

[Bob_Pendleton]

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.comOn Thu, Jan 22, 2015 at 12:43 PM, T. Joseph Carter < tjcarter at spiritsubstance.com> wrote:

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:

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 < sik.the.hedgehog at gmail.com> wrote:

2015-01-19 20:26 GMT-03:00, Jared Maddox :

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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
±----------------------------------------------------------

• Bob Pendleton: writer and programmer
• email: Bob at Pendleton.com
• mailing list: GameProgrammer.com
• blog: www.TheGrumpyProgrammer.com

---

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

---

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

–
±----------------------------------------------------------

• Bob Pendleton: writer and programmer
• email: Bob at Pendleton.com
• blog: www.TheGrumpyProgrammer.com

[JonnyD]

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.

Jonny D

[T_Joseph_Carter]

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.

JosephOn Fri, Jan 23, 2015 at 11:27:33AM -0600, Bob Pendleton wrote:

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 < @T_Joseph_Carter> wrote:

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:

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 < sik.the.hedgehog at gmail.com> wrote:

2015-01-19 20:26 GMT-03:00, Jared Maddox :

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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
±----------------------------------------------------------

• Bob Pendleton: writer and programmer
• email: Bob at Pendleton.com
• mailing list: GameProgrammer.com
• blog: www.TheGrumpyProgrammer.com

---

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

---

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

–
±----------------------------------------------------------

• Bob Pendleton: writer and programmer
• email: Bob at Pendleton.com
• blog: www.TheGrumpyProgrammer.com

---

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

[slime]

https://github.com/MSOpenTech/angleOn Jan 23, 2015, at 2:46 PM, T. Joseph Carter wrote:

OpenGL dependency, which kind of means no WinRT.

[Gabriel_Jacobo]

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 :> https://github.com/MSOpenTech/angle

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

OpenGL dependency, which kind of means no WinRT.

---

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

–
Gabriel.

[David_Ludwig]

[quote=“Alex Szpakowski”]https://github.com/MSOpenTech/angleOn Jan 23, 2015, at 2:46 PM, T. Joseph Carter wrote:

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.

[T_Joseph_Carter]

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.

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

https://github.com/MSOpenTech/angle

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

OpenGL dependency, which kind of means no WinRT.

---

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

[T_Joseph_Carter]

If I wanted an OpenGL dependency, I’d have rewritten the code for
OpenGL.

JosephOn Fri, Jan 23, 2015 at 03:53:02PM -0300, Gabriel Jacobo wrote:

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 :

https://github.com/MSOpenTech/angle

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

OpenGL dependency, which kind of means no WinRT.

---

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

–
Gabriel.

---

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

[slime]

Words of wisdom right there. :)On Jan 23, 2015, at 1:27 PM, Bob Pendleton wrote:

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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Gabriel_Jacobo]

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

https://github.com/MSOpenTech/angle

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

OpenGL dependency, which kind of means no WinRT.

---

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

---

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

–
Gabriel.