SDL2 Graphics API, was Re: compiling with SDL_NO_COMPAT

SDL Development
21

Remember guys, any idea that gets implemented comes with an opportunity cost. All the bells and whistles being added to SDL 1.3 is holding up a stable release with OpenGL 3+ functionality. Currently I’m using freeGLUT for OpenGL 3. freeGLUT.

I study work flow management and I found the GTD (http://www.amazon.com/Getting-Things-Done-Stress-Free-Productivity/dp/0142000280) method to be one of the more effective methods. Programmers tend to like it because it essentially boils down business to a recursive algorithm. :smiley:

According to the GTD Method: the steps to successful planning are:
-Defining Purpose
-Defining what success looks like
-Brainstorming
-Organizing
-Identifying what needs to get done

Here’s my two cents regarding SDL 2.0:

-Defining Purpose

Simple DirectMedia Layer is a cross-platform multimedia library designed to provide low level access to audio, keyboard, mouse, joystick, 3D hardware via OpenGL, and 2D video framebuffer.

I think SDL’s goal moving forward is to be the go to library when you want to do multiplatform games and simulations development. When companies like EA or Activision want to make multiple ports, SDL should be the clear choice

-Outcome envisioning
How would SDL 2.0 achieve what’s mentioned above?
-The APIs should do one thing really well as opposed to doing many things poorly. This Unix philosophy has served me well.
-Let’s not reinvent the wheel, only make it multiplatform.
-A new focus on being multiplatform as opposed to cross platform. Code once compile anywhere is great, but what if I want to support iOS achievements for the iPad version of my game? SDL 2.0 should allow us to take advantage of our platform’s native features
-OpenGL users have always wanted a DirectX the same way Direct3D users have. SDL being the ultimate OGL support library will ensure it’s relevance in the future.

-Brainstorming
Key to brainstorming is go for quantity not quality. Many “stupid” ideas have turned out to be great (“A free encyclopedia that’s maintained by people that aren’t paid? No way that’ll do better than Encarta”). So let’s see what we have on the table (plus a few of my own):

-OGL/D3D wrapper
-Primitive geometry
-Abolishing software rendering
-Depth buffer

-OpenGL features
I’m currently doing some major OGL development and it’s a pain having to lug around 8 different libraries. Having an SDL_OGL extension library to facilitate OpenGL development that does what D3DX does and more will make SDL of the more influential open source libraries. Some feature I would like to see for SDL_OGL
-A GLEW like functionality that will grab all of the OpenGL function pointers in one call
-SDL_image augmentations to allow for easier texture generation. This will mean not having to add DevIL to my project. (Nice library, but I would like few dlls)
-SDL_TTF augmentations to allow for easier bitmap font textures IE

Code:
TTF_GetFloorPlanTexture( font, pixels, clipRects, &clipRectCount )

This’ll save me having to touch TrueType directly
-Built in model parsers for popular formats like obj and collada
-Built in functionality to load text file shaders
-Some stock GLSL/HLSL shaders to get up an running fast

-Filesystem access
For a previous game a I made, I had each user have their own their own directory save files. I had to use boost to traverse and create/delete directories. Having this integrated into SDL would have made things much nicer.

-Matrix/vector library
If we’re going to have primitives, having a matrix library to transform the geometry is a must have for games and physics simulations. This’ll also save me having to link glmatrix.

-Installation library
A set of functions that will make installing applications easier IE getting the program/my documents path.

-Organizing
This the part where we take all of the ideas and evaluate them to see what we can do with them

-Identifying what needs to get done
From here we can create a todo list and execute

You’ll have to excuse me from coming out of nowhere and appointing myself scrum master. I just wanted to share a management strategy that always helped with my projects and to throw in some of my ideas for what I would like in my SDL apps.

22

Also, is there any way to change the release schedule for SDL? All the features planned for SDL don’t have to be implemented all at once.

We could have:
SDL 1.3: OpenGL 3+ support, hardware rendering, multi window support, Context controls, force feedback, touch
SDL 1.4: Audio recording, features abc
SDL 1.5: Features xyz
SDL 1.6: etc

I just think that having these features stable and in the hands of the SDL users would be a better return on investment that to release them all at once.

23

Sam, I think this discussion is bringing out a basic problem caused by
what people believe SDL IS. That is, if you ask each user WHY SDL
exists, my guess is that you will mostly get one of about 3 different
answers, and of course you will get a bunch of other off the wall
answers :-). The thing is, the developers will, or a least should, all
answer that question one way. And, SDL will develop to meet the way
the developers answer the question.

I, for one, have always seen it as an abstraction layer written by
professionals for professionals. As as result, the focus on providing
the basics and support to access professional level APIs and write
extension libraries makes perfect sense to me.

But, my answer to the question doesn’t really matter, what is your
answer, and what is Ryan’s answer?

Bob PendletonOn Wed, Jan 18, 2012 at 7:00 AM, Sam Lantinga wrote:

SDL already provides a way for the user to use the underlying graphics API.
?The only reason the current code in SDL_render.h couldn’t be pulled out as
a separate library now is that SDL_video.c calls it to support
SDL_CreateWindowSurface() ?:slight_smile:

Cheers!

On Wed, Jan 18, 2012 at 5:21 AM, Pallav Nawani wrote:

SDL2 = SDL1.3 ?+ Code for Rotation & stretch blit simultaneously
Or
SDL provides a way for the user to get hold of the underlying graphics API
(DirectX/OpenGL) to allow me to implement the above code in my game without
touching SDL itself.
:slight_smile:

On 18-01-2012 10:42, Bob Pendleton wrote:

On Sun, Jan 8, 2012 at 2:00 AM, Sam Lantinga ?wrote:

Bob, I don’t think we’re quite ready to talk about this, unless you’re
talking about something you’d like to write and maintain separately from
SDL. :slight_smile:

I waited a long time to reply because I wanted to “stir the pot” and
see what people had to say. I really do want to start a long term
project based on SDL2. But, mostly I wanted to see what people really
want.

Bob Pendleton

On Sun, Jan 8, 2012 at 1:28 AM, Bob Pendleton<@Bob_Pendleton> ?wrote:

If we are going to start talking about what features should be in the
graphics API for SDL2 I think we should start a new thread.

Since this is a 3D API based running on top of modern hardware I’m
going to suggest that it should include layers. We have a Z-Buffer,
even though we are just doing 2D doesn’t mean we shouldn’t use it. It
makes doing so many things so much easier.

Also, I’ve heard a lot of people talking about render to texture as a
requirement, and I’m very much in favor of that, so the minimum
version of OpenGL/DirectX that can be supported is the first version
that supports that functionality.

While is is possible to build up all the graphic primitives, such as
lines, circles, and so on, from a simple scan line fill operation, it
is also pretty trivial to provide a set of solid fill and textured
primitives based on the underlying libraries. They do not have to
complex. It is possible to do textured primitives without ever
specifying a texture coordinate.

And, lets not forget fonts. People need fonts.

A critical problem is the coordinate system to be used. Using Pixels
is rather natural. But, then the library needs to be able to scale
everything for when the window changes size.

Bob Pendleton

To make a modern 2D system anyone want to talk about doing it based
on SVG instead of pixels?

Bob Pendleton

On Fri, Jan 6, 2012 at 9:53 PM, bala_48225<bala_48225 at yahoo.com> ?wrote:

So far I haven’t used SDL 1.3, but as far as the proposed
split-from-base 2D
rendering API
is concerned, perhaps its features could be limited, basic and modern:

  1. Allow the user to flip, rotate and scale images; 2) Provide
    multiple
    alpha blend modes for
    images, including multiply alpha, and 3) Provide something akin to SDL
    1.2’s
    SDL_FillRect,
    perhaps with blending modes as well.

The last feature could put the burden for simpler functions such as
lines
and circles on the user,
and the possibility of having a bloated fixed-function pipeline could
thus
be evaded. The only
other thing I can think is, maybe the rendering API could support less
platforms than the rest of SDL
does, thus decreasing its development overhead. For my part I don’t
see
why
any DirectX prior to 8 or
later than 9 would be necessary to support for a 2D API, and OpenGL
should
be supported from 1.0.
Those three features I suggested should update SDL to the 2010s while
keeping it low-level from the
user’s perspective.

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

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

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

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

–
Pallav Nawani
Game Designer/Writer/CEO
http://www.ironcode.com
Twitter: http://twitter.com/Ironcode_Gaming
Facebook: http://www.facebook.com/Ironcode.Gaming
Mobile: 9997478768

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

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

24

Bob wrote:

I, for one, have always seen it as an abstraction layer written by
professionals for professionals. As as result, the focus on providing
the basics and support to access professional level APIs and write
extension libraries makes perfect sense to me.

I’m not Sam or Ryan but I’ll give my two cents, and it’s the same as
yours. It’s an abstraction layer for OSes. It gives you the ability to
write cross platform code for the nasty OS interactions bit; events,
screen resolution, sound, etc.

Example: dim3 IS a development environment. You make games in it. dim3
uses SDL to be cross platform, it runs on OS X, windows, linux, and iOS
all with the same data. Scruffy3D (no, I’m not advertising, using as an
example) is written in dim3, which uses SDL.

Scruffy3D -> dim3 -> SDL

Each thing is in it’s proper layer and can be developed separately
without interfering with releases or anything else.

I know a lot of people really have a horse in this race, but you
shouldn’t have a horse because it makes things easier on you, you should
have a horse because it makes the product your using better.

Nobody likes having multiple libraries. I hate it. But I think if
there is a 2D drawing layer, it should be outside of SDL, especially as
it can be decoupled and developed faster without each other holding it up.

I’m actually more strict about this than anybody would be; I don’t even
think networking or image loading should be in SDL (they might be
separate libraries, I don’t use them.) Sockets are 99.9% cross-platform
and libPNG is, too. Drawing? OpenGL.

My bottom line is this: SDL should allow you to forget what OS you are
on. If there is a cross-platform way to do it, it might not be
something for SDL proper, but a good candidate for another library.

(Note: This will all have to be a completely new SDL, obviously, as it
wouldn’t be backwards compatible in some areas.)

(Side Note: Sam, I gave Ryan a free copy of Scruffy3D (OS X), if you’d
like a free app store code, drop me an email!)

[>] Brian

25

Not too hard, you just have to find replacements for:
CreateWindowFramebuffer()
UpdateWindowFramebuffer()
DestroyWindowFramebuffer()

in SDL_video.cOn Wed, Jan 18, 2012 at 1:46 PM, RodrigoCard wrote:

**
Is it too hard to change this and make SDL_render a separate API?

Sam Lantinga wrote:

SDL already provides a way for the user to use the underlying graphics
API. The only reason the current code in SDL_render.h couldn’t be pulled
out as a separate library now is that SDL_video.c calls it to support
SDL_CreateWindowSurface() [image: Smile]

Cheers!

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

26

Bob wrote:

I, for one, have always seen it as an abstraction layer written by
professionals for professionals. As as result, the focus on providing
the basics and support to access professional level APIs and write
extension libraries makes perfect sense to me.

I’m not Sam or Ryan but I’ll give my two cents, and it’s the same as yours.
?It’s an abstraction layer for OSes. ?It gives you the ability to write
cross platform code for the nasty OS interactions bit; events, screen
resolution, sound, etc.

Example: dim3 IS a development environment. ?You make games in it. ?dim3
uses SDL to be cross platform, it runs on OS X, windows, linux, and iOS all
with the same data. ?Scruffy3D (no, I’m not advertising, using as an
example) is written in dim3, which uses SDL.

Scruffy3D -> dim3 -> SDL

Each thing is in it’s proper layer and can be developed separately without
interfering with releases or anything else.

I know a lot of people really have a horse in this race, but you shouldn’t
have a horse because it makes things easier on you, you should have a horse
because it makes the product your using better.

Nobody likes having multiple libraries. ?I hate it. ?But I think if there is
a 2D drawing layer, it should be outside of SDL, especially as it can be
decoupled and developed faster without each other holding it up.

I’m actually more strict about this than anybody would be; I don’t even
think networking or image loading should be in SDL (they might be separate
libraries, I don’t use them.) ?Sockets are 99.9% cross-platform and libPNG
is, too. ?Drawing? ?OpenGL.

My bottom line is this: ?SDL should allow you to forget what OS you are on.
?If there is a cross-platform way to do it, it might not be something for
SDL proper, but a good candidate for another library.

(Note: This will all have to be a completely new SDL, obviously, as it
wouldn’t be backwards compatible in some areas.)

(Side Note: Sam, I gave Ryan a free copy of Scruffy3D (OS X), if you’d like
a free app store code, drop me an email!)

Very interesting work! I appreciate the offer of a free copy, but I
can’t afford the the Mac needed to take advantage of it :slight_smile:

Bob PendletonOn Wed, Jan 18, 2012 at 3:04 PM, Brian Barnes wrote:

[>] Brian

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

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

27

Mason, I’ve said it over and over… If you’re OpenGL specific, be OpenGL
specific! :slight_smile:
You should bite the bullet and write the 1000 lines of code or so it takes
to do texture management and simple drawing.

For that matter, if you want to create an OpenGL-specific library that
otherwise emulates the SDL_render API, you’re more than welcome to do that
too! :slight_smile:

If you’re going pure OpenGL and there’s something in SDL that’s blocking
you from doing that effectively then it should definitely be fixed.

See ya!On Wed, Jan 18, 2012 at 2:12 PM, Mason Wheeler wrote:

What do you mean? SDL does not already provide a way for the user to use
the underlying graphics API, at least not in any meaningful way, since
there is no way to obtain the native API handle of textures created through
SDL, and nothing useful that a user of the library can do without that.

From: Sam Lantinga <@slouken>
To: SDL Development List
Sent: Wednesday, January 18, 2012 5:00 AM

Subject: Re: [SDL] SDL2 Graphics API, was Re: compiling with
SDL_NO_COMPAT

SDL already provides a way for the user to use the underlying graphics
API. The only reason the current code in SDL_render.h couldn’t be pulled
out as a separate library now is that SDL_video.c calls it to support
SDL_CreateWindowSurface() :slight_smile:

Cheers!

On Wed, Jan 18, 2012 at 5:21 AM, Pallav Nawani wrote:

SDL2 = SDL1.3 + Code for Rotation & stretch blit simultaneously
Or
SDL provides a way for the user to get hold of the underlying graphics API
(DirectX/OpenGL) to allow me to implement the above code in my game without
touching SDL itself.
:slight_smile:

On 18-01-2012 10:42, Bob Pendleton wrote:

On Sun, Jan 8, 2012 at 2:00 AM, Sam Lantinga<@slouken> wrote:

Bob, I don’t think we’re quite ready to talk about this, unless you’re
talking about something you’d like to write and maintain separately from
SDL. :slight_smile:

I waited a long time to reply because I wanted to “stir the pot” and
see what people had to say. I really do want to start a long term
project based on SDL2. But, mostly I wanted to see what people really
want.

Bob Pendleton

On Sun, Jan 8, 2012 at 1:28 AM, Bob Pendleton wrote:

If we are going to start talking about what features should be in the
graphics API for SDL2 I think we should start a new thread.

Since this is a 3D API based running on top of modern hardware I’m
going to suggest that it should include layers. We have a Z-Buffer,
even though we are just doing 2D doesn’t mean we shouldn’t use it. It
makes doing so many things so much easier.

Also, I’ve heard a lot of people talking about render to texture as a
requirement, and I’m very much in favor of that, so the minimum
version of OpenGL/DirectX that can be supported is the first version
that supports that functionality.

While is is possible to build up all the graphic primitives, such as
lines, circles, and so on, from a simple scan line fill operation, it
is also pretty trivial to provide a set of solid fill and textured
primitives based on the underlying libraries. They do not have to
complex. It is possible to do textured primitives without ever
specifying a texture coordinate.

And, lets not forget fonts. People need fonts.

A critical problem is the coordinate system to be used. Using Pixels
is rather natural. But, then the library needs to be able to scale
everything for when the window changes size.

Bob Pendleton

To make a modern 2D system anyone want to talk about doing it based
on SVG instead of pixels?

Bob Pendleton

On Fri, Jan 6, 2012 at 9:53 PM, bala_48225<bala_48225 at yahoo.**com<bala_48225 at yahoo.com>> wrote:

So far I haven’t used SDL 1.3, but as far as the proposed
split-from-base 2D
rendering API
is concerned, perhaps its features could be limited, basic and modern:

  1. Allow the user to flip, rotate and scale images; 2) Provide multiple
    alpha blend modes for
    images, including multiply alpha, and 3) Provide something akin to SDL
    1.2’s
    SDL_FillRect,
    perhaps with blending modes as well.

The last feature could put the burden for simpler functions such as
lines
and circles on the user,
and the possibility of having a bloated fixed-function pipeline could
thus
be evaded. The only
other thing I can think is, maybe the rendering API could support less
platforms than the rest of SDL
does, thus decreasing its development overhead. For my part I don’t see
why
any DirectX prior to 8 or
later than 9 would be necessary to support for a 2D API, and OpenGL
should
be supported from 1.0.
Those three features I suggested should update SDL to the 2010s while
keeping it low-level from the
user’s perspective.

_____________**
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.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
Pallav Nawani
Game Designer/Writer/CEO
http://www.ironcode.com
Twitter: http://twitter.com/Ironcode_**Gaminghttp://twitter.com/Ironcode_Gaming
Facebook: http://www.facebook.com/**Ironcode.Gaminghttp://www.facebook.com/Ironcode.Gaming
Mobile: 9997478768

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

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

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

28

SDL was never designed as a beginner game programmers’ tool. I’m frankly
astonished and pleased that so many young people learned with it and made
so many amazing things with it, but it was always designed as a porting
layer for games and the base for cross-platform engines.

Both Ryan and I have families and more than full time jobs. Any time we
spend on SDL is either selfish, getting our games on multiple platforms, or
out of love for the community and the project.

There’s a reason the code is under the zlib license and listed on the
website as community supported. There’s no way we can give everybody
everything they want in our free time. This code isn’t ours, it’s yours!
Make it your own, contribute to it, improve it! If there’s some way it
doesn’t meet your needs, improve it if it makes sense, or find a tool that
does!

In that vein, lots of people have asked for OpenGL 3.X support. It’s
something I would love to see in SDL 1.3, but I don’t have time or
expertise to implement it. If you do, speak up! Do it! You have
tremendous power if you simply reach for it. :slight_smile:

Cheers,On Wed, Jan 18, 2012 at 10:34 AM, Brian Barrett <brian.ripoff at gmail.com>wrote:

Hi,

What I have seen, in my copious time spent helping people on on
www.gamedev.net, is a large scale migration from SDL for many tasks.
Where once users were actively pushing beginner game programmers
towards SDL and pygame, they now are pushing SFML and various OpenGL
based Python libraries (even when the beginner has already chosen an
API!). When challenged, their usual reason for this is performance
related. There is also a perception that SDL is unmaintained and out
of date.

To a non-member of this list, SDL is in danger of appearing
irrelevant, unless you want to support niche platforms. I believe this
trend is a threat to the size and sustainability of the SDL community,
and thus to SDL itself in the long run.

The people want hardware acceleration by default, and they do not wish
to drop into OpenGL to scale or rotate sprites.

My own opinion is that I’d like it if the latter two could be
separated from the core SDL library, into a more advanced library
(like SDL_gfx, but expanded and hardware accelerated). SDL’s built in
routines could then focus on axis aligned fast blitting and rectangle
filling, which can be implemented on pretty much any graphics
hardware.

Regards,
– Brian

On 18 January 2012 05:55, Bob Pendleton wrote:

So, what do you want in a 2D API?

Bob Pendleton

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

29

Yes, you’ve said it over and over, and it sounds ridiculous every time you say it.? Which I’ve pointed out over and over.

But since we’re apparently rehashing this again, here’s what that sounds like from my end:

“If SDL’s rendering API provides 95% of what you need, but there’s one feature that you absolutely do need, that SDL doesn’t provide, then the appropriate solution is to throw out the entirety of what SDL’s rendering API can already do for you, and all of the man-decades of experience and accumulated bugfixes that it represents, and re-implement the whole thing from scratch yourself, just so you can gain access to the one feature you need.”

Seriously, Sam, do you have any idea how insane that sounds?!?? I’m sorry, but I can’t think of any other word that describes it.

Mason________________________________
From: Sam Lantinga
To: Mason Wheeler <@Mason_Wheeler>; SDL Development List
Sent: Wednesday, January 18, 2012 6:52 PM
Subject: Re: [SDL] SDL2 Graphics API, was Re: compiling with SDL_NO_COMPAT

Mason, I’ve said it over and over… If you’re OpenGL specific, be OpenGL specific! :slight_smile:
You should bite the bullet and write the 1000 lines of code or so it takes to do texture management and simple drawing.

For that matter, if you want to create an OpenGL-specific library that otherwise emulates the SDL_render API, you’re more than welcome to do that too! :slight_smile:

If you’re going pure OpenGL and there’s something in SDL that’s blocking you from doing that effectively then it should definitely be fixed.

See ya!

On Wed, Jan 18, 2012 at 2:12 PM, Mason Wheeler <@Mason_Wheeler> wrote:

What do you mean? SDL does not already provide a way for the user to use the underlying graphics API, at least not in any meaningful way, since there is no way to obtain the native API handle of textures created through SDL, and nothing useful that a user of the library can do without that.

From: Sam Lantinga
To: SDL Development List
Sent: Wednesday, January 18, 2012 5:00 AM

Subject: Re: [SDL] SDL2 Graphics API, was Re: compiling with SDL_NO_COMPAT

SDL already provides a way for the user to use the underlying graphics API. ?The only reason the current code in SDL_render.h couldn’t be pulled out as a separate library now is that SDL_video.c calls it to support SDL_CreateWindowSurface() ?:slight_smile:

Cheers!

On Wed, Jan 18, 2012 at 5:21 AM, Pallav Nawani wrote:

SDL2 = SDL1.3 ?+ Code for Rotation & stretch blit simultaneously
Or
SDL provides a way for the user to get hold of the underlying graphics API (DirectX/OpenGL) to allow me to implement the above code in my game without touching SDL itself.
:slight_smile:

On 18-01-2012 10:42, Bob Pendleton wrote:

On Sun, Jan 8, 2012 at 2:00 AM, Sam Lantinga ?wrote:

Bob, I don’t think we’re quite ready to talk about this, unless you’re

talking about something you’d like to write and maintain separately from
SDL. :slight_smile:

I waited a long time to reply because I wanted to “stir the pot” and

see what people had to say. I really do want to start a long term
project based on SDL2. But, mostly I wanted to see what people really
want.

Bob Pendleton

On Sun, Jan 8, 2012 at 1:28 AM, Bob Pendleton ?wrote:

If we are going to start talking about what features should be in the

graphics API for SDL2 I think we should start a new thread.

Since this is a 3D API based running on top of modern hardware I’m
going to suggest that it should include layers. We have a Z-Buffer,
even though we are just doing 2D doesn’t mean we shouldn’t use it. It
makes doing so many things so much easier.

Also, I’ve heard a lot of people talking about render to texture as a
requirement, and I’m very much in favor of that, so the minimum
version of OpenGL/DirectX that can be supported is the first version
that supports that functionality.

While is is possible to build up all the graphic primitives, such as
lines, circles, and so on, from a simple scan line fill operation, it
is also pretty trivial to provide a set of solid fill and textured
primitives based on the underlying libraries. They do not have to
complex. It is possible to do textured primitives without ever
specifying a texture coordinate.

And, lets not forget fonts. People need fonts.

A critical problem is the coordinate system to be used. Using Pixels
is rather natural. But, then the library needs to be able to scale
everything for when the window changes size.

Bob Pendleton

To make a modern 2D system anyone want to talk about doing it based
on SVG instead of pixels?

Bob Pendleton

On Fri, Jan 6, 2012 at 9:53 PM, bala_48225<bala_48225 at yahoo.com> ?wrote:

So far I haven’t used SDL 1.3, but as far as the proposed

split-from-base 2D
rendering API
is concerned, perhaps its features could be limited, basic and modern:

  1. Allow the user to flip, rotate and scale images; 2) Provide multiple
    alpha blend modes for
    images, including multiply alpha, and 3) Provide something akin to SDL
    1.2’s
    SDL_FillRect,
    perhaps with blending modes as well.

The last feature could put the burden for simpler functions such as
lines
and circles on the user,
and the possibility of having a bloated fixed-function pipeline could
thus
be evaded. The only
other thing I can think is, maybe the rendering API could support less
platforms than the rest of SDL
does, thus decreasing its development overhead. For my part I don’t see
why
any DirectX prior to 8 or
later than 9 would be necessary to support for a 2D API, and OpenGL
should
be supported from 1.0.
Those three features I suggested should update SDL to the 2010s while
keeping it low-level from the
user’s perspective.

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

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

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

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

–
Pallav Nawani
Game Designer/Writer/CEO
http://www.ironcode.com
Twitter: http://twitter.com/Ironcode_Gaming
Facebook: http://www.facebook.com/Ironcode.Gaming
Mobile: 9997478768

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

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

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

30

Well, since I wrote it and it didn’t take me very long, and I’m not a
skilled a 3D guy, I figured it wouldn’t take you long either. It does
sound silly when you say it that way though. :slight_smile:

In any case, I would be much more open to adding rotation, etc. to
SDL_render if it’s pulled out of SDL13 proper where it’s not constrained by
code size and timeframe. I want to add render to texture support before
the code gets moved, but if pulling it out to a separate library is
something you’re interested in doing and maintaining, I’ll definitely help
coordinate it with you.On Wed, Jan 18, 2012 at 10:10 PM, Mason Wheeler wrote:

Yes, you’ve said it over and over, and it sounds ridiculous every time you
say it. Which I’ve pointed out over and over.

But since we’re apparently rehashing this again, here’s what that sounds
like from my end:

“If SDL’s rendering API provides 95% of what you need, but there’s one
feature that you absolutely do need, that SDL doesn’t provide, then the
appropriate solution is to throw out the entirety of what SDL’s rendering
API can already do for you, and all of the man-decades of experience and
accumulated bugfixes that it represents, and re-implement the whole thing
from scratch yourself, just so you can gain access to the one feature you
need.”

Seriously, Sam, do you have any idea how insane that sounds?!? I’m
sorry, but I can’t think of any other word that describes it.

Mason

From: Sam Lantinga <@slouken>
To: Mason Wheeler ; SDL Development List <
sdl at lists.libsdl.org>
Sent: Wednesday, January 18, 2012 6:52 PM

Subject: Re: [SDL] SDL2 Graphics API, was Re: compiling with
SDL_NO_COMPAT

Mason, I’ve said it over and over… If you’re OpenGL specific, be OpenGL
specific! :slight_smile:
You should bite the bullet and write the 1000 lines of code or so it takes
to do texture management and simple drawing.

For that matter, if you want to create an OpenGL-specific library that
otherwise emulates the SDL_render API, you’re more than welcome to do that
too! :slight_smile:

If you’re going pure OpenGL and there’s something in SDL that’s blocking
you from doing that effectively then it should definitely be fixed.

See ya!

On Wed, Jan 18, 2012 at 2:12 PM, Mason Wheeler wrote:

What do you mean? SDL does not already provide a way for the user to use
the underlying graphics API, at least not in any meaningful way, since
there is no way to obtain the native API handle of textures created through
SDL, and nothing useful that a user of the library can do without that.

From: Sam Lantinga <@slouken>
To: SDL Development List
Sent: Wednesday, January 18, 2012 5:00 AM

Subject: Re: [SDL] SDL2 Graphics API, was Re: compiling with
SDL_NO_COMPAT

SDL already provides a way for the user to use the underlying graphics
API. The only reason the current code in SDL_render.h couldn’t be pulled
out as a separate library now is that SDL_video.c calls it to support
SDL_CreateWindowSurface() :slight_smile:

Cheers!

On Wed, Jan 18, 2012 at 5:21 AM, Pallav Nawani wrote:

SDL2 = SDL1.3 + Code for Rotation & stretch blit simultaneously
Or
SDL provides a way for the user to get hold of the underlying graphics API
(DirectX/OpenGL) to allow me to implement the above code in my game without
touching SDL itself.
:slight_smile:

On 18-01-2012 10:42, Bob Pendleton wrote:

On Sun, Jan 8, 2012 at 2:00 AM, Sam Lantinga<@slouken> wrote:

Bob, I don’t think we’re quite ready to talk about this, unless you’re
talking about something you’d like to write and maintain separately from
SDL. :slight_smile:

I waited a long time to reply because I wanted to “stir the pot” and
see what people had to say. I really do want to start a long term
project based on SDL2. But, mostly I wanted to see what people really
want.

Bob Pendleton

On Sun, Jan 8, 2012 at 1:28 AM, Bob Pendleton wrote:

If we are going to start talking about what features should be in the
graphics API for SDL2 I think we should start a new thread.

Since this is a 3D API based running on top of modern hardware I’m
going to suggest that it should include layers. We have a Z-Buffer,
even though we are just doing 2D doesn’t mean we shouldn’t use it. It
makes doing so many things so much easier.

Also, I’ve heard a lot of people talking about render to texture as a
requirement, and I’m very much in favor of that, so the minimum
version of OpenGL/DirectX that can be supported is the first version
that supports that functionality.

While is is possible to build up all the graphic primitives, such as
lines, circles, and so on, from a simple scan line fill operation, it
is also pretty trivial to provide a set of solid fill and textured
primitives based on the underlying libraries. They do not have to
complex. It is possible to do textured primitives without ever
specifying a texture coordinate.

And, lets not forget fonts. People need fonts.

A critical problem is the coordinate system to be used. Using Pixels
is rather natural. But, then the library needs to be able to scale
everything for when the window changes size.

Bob Pendleton

To make a modern 2D system anyone want to talk about doing it based
on SVG instead of pixels?

Bob Pendleton

On Fri, Jan 6, 2012 at 9:53 PM, bala_48225<bala_48225 at yahoo.**com<bala_48225 at yahoo.com>> wrote:

So far I haven’t used SDL 1.3, but as far as the proposed
split-from-base 2D
rendering API
is concerned, perhaps its features could be limited, basic and modern:

  1. Allow the user to flip, rotate and scale images; 2) Provide multiple
    alpha blend modes for
    images, including multiply alpha, and 3) Provide something akin to SDL
    1.2’s
    SDL_FillRect,
    perhaps with blending modes as well.

The last feature could put the burden for simpler functions such as
lines
and circles on the user,
and the possibility of having a bloated fixed-function pipeline could
thus
be evaded. The only
other thing I can think is, maybe the rendering API could support less
platforms than the rest of SDL
does, thus decreasing its development overhead. For my part I don’t see
why
any DirectX prior to 8 or
later than 9 would be necessary to support for a 2D API, and OpenGL
should
be supported from 1.0.
Those three features I suggested should update SDL to the 2010s while
keeping it low-level from the
user’s perspective.

_____________**
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.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
Pallav Nawani
Game Designer/Writer/CEO
http://www.ironcode.com
Twitter: http://twitter.com/Ironcode_**Gaminghttp://twitter.com/Ironcode_Gaming
Facebook: http://www.facebook.com/**Ironcode.Gaminghttp://www.facebook.com/Ironcode.Gaming
Mobile: 9997478768

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

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

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

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

31

Actually, I’ve never seen the point of pulling functionality out into its own libraries, especially core functionality that every game is likely to end up needing.? If I was the one building it, there would be no “SDL_Image” or “SDL_Mixer” or “SDL_TTF”.? All that basic stuff would be part of SDL.dll.? Keeps the DLL hell problem down that way.________________________________
From: Sam Lantinga
To: Mason Wheeler <@Mason_Wheeler>; SDL Development List
Sent: Wednesday, January 18, 2012 7:16 PM
Subject: Re: [SDL] SDL2 Graphics API, was Re: compiling with SDL_NO_COMPAT

Well, since I wrote it and it didn’t take me very long, and I’m not that skilled a 3D guy, I figured it wouldn’t take you long either. ?It does sound silly when you say it that way though. :slight_smile:

In any case, I would be much more open to adding rotation, etc. to SDL_render if it’s pulled out of SDL13 proper where it’s not constrained by code size and other constraints. ?I want to add render to texture support before the code gets moved, but if pulling it out to a separate library is something you’re interested in, you’re more than welcome to!

On Wed, Jan 18, 2012 at 10:10 PM, Mason Wheeler <@Mason_Wheeler> wrote:

Yes, you’ve said it over and over, and it sounds ridiculous every time you say it.? Which I’ve pointed out over and over.

But since we’re apparently rehashing this again, here’s what that sounds like from my end:

“If SDL’s rendering API provides 95% of what you need, but there’s one feature that you absolutely do need, that SDL doesn’t provide, then the appropriate solution is to throw out the entirety of what SDL’s rendering API can already do for you, and all of the man-decades of experience and accumulated bugfixes that it represents, and re-implement the whole thing from scratch yourself, just so you can gain access to the one feature you need.”

Seriously, Sam, do you have any idea how insane that sounds?!?? I’m sorry, but I can’t think of any other word that describes it.

Mason

From: Sam Lantinga
To: Mason Wheeler <@Mason_Wheeler>; SDL Development List
Sent: Wednesday, January 18, 2012 6:52 PM

Subject: Re: [SDL] SDL2 Graphics API, was Re: compiling with SDL_NO_COMPAT

Mason, I’ve said it over and over… If you’re OpenGL specific, be OpenGL specific! :slight_smile:
You should bite the bullet and write the 1000 lines of code or so it takes to do texture management and simple drawing.

For that matter, if you want to create an OpenGL-specific library that otherwise emulates the SDL_render API, you’re more than welcome to do that too! :slight_smile:

If you’re going pure OpenGL and there’s something in SDL that’s blocking you from doing that effectively then it should definitely be fixed.

See ya!

On Wed, Jan 18, 2012 at 2:12 PM, Mason Wheeler <@Mason_Wheeler> wrote:

What do you mean? SDL does not already provide a way for the user to use the underlying graphics API, at least not in any meaningful way, since there is no way to obtain the native API handle of textures created through SDL, and nothing useful that a user of the library can do without that.

From: Sam Lantinga
To: SDL Development List
Sent: Wednesday, January 18, 2012 5:00 AM

Subject: Re: [SDL] SDL2 Graphics API, was Re: compiling with SDL_NO_COMPAT

SDL already provides a way for the user to use the underlying graphics API. ?The only reason the current code in SDL_render.h couldn’t be pulled out as a separate library now is that SDL_video.c calls it to support SDL_CreateWindowSurface() ?:slight_smile:

Cheers!

On Wed, Jan 18, 2012 at 5:21 AM, Pallav Nawani wrote:

SDL2 = SDL1.3 ?+ Code for Rotation & stretch blit simultaneously
Or
SDL provides a way for the user to get hold of the underlying graphics API (DirectX/OpenGL) to allow me to implement the above code in my game without touching SDL itself.
:slight_smile:

On 18-01-2012 10:42, Bob Pendleton wrote:

On Sun, Jan 8, 2012 at 2:00 AM, Sam Lantinga ?wrote:

Bob, I don’t think we’re quite ready to talk about this, unless you’re

talking about something you’d like to write and maintain separately from
SDL. :slight_smile:

I waited a long time to reply because I wanted to “stir the pot” and

see what people had to say. I really do want to start a long term
project based on SDL2. But, mostly I wanted to see what people really
want.

Bob Pendleton

On Sun, Jan 8, 2012 at 1:28 AM, Bob Pendleton ?wrote:

If we are going to start talking about what features should be in the

graphics API for SDL2 I think we should start a new thread.

Since this is a 3D API based running on top of modern hardware I’m
going to suggest that it should include layers. We have a Z-Buffer,
even though we are just doing 2D doesn’t mean we shouldn’t use it. It
makes doing so many things so much easier.

Also, I’ve heard a lot of people talking about render to texture as a
requirement, and I’m very much in favor of that, so the minimum
version of OpenGL/DirectX that can be supported is the first version
that supports that functionality.

While is is possible to build up all the graphic primitives, such as
lines, circles, and so on, from a simple scan line fill operation, it
is also pretty trivial to provide a set of solid fill and textured
primitives based on the underlying libraries. They do not have to
complex. It is possible to do textured primitives without ever
specifying a texture coordinate.

And, lets not forget fonts. People need fonts.

A critical problem is the coordinate system to be used. Using Pixels
is rather natural. But, then the library needs to be able to scale
everything for when the window changes size.

Bob Pendleton

To make a modern 2D system anyone want to talk about doing it based
on SVG instead of pixels?

Bob Pendleton

On Fri, Jan 6, 2012 at 9:53 PM, bala_48225<bala_48225 at yahoo.com> ?wrote:

So far I haven’t used SDL 1.3, but as far as the proposed

split-from-base 2D
rendering API
is concerned, perhaps its features could be limited, basic and modern:

  1. Allow the user to flip, rotate and scale images; 2) Provide multiple
    alpha blend modes for
    images, including multiply alpha, and 3) Provide something akin to SDL
    1.2’s
    SDL_FillRect,
    perhaps with blending modes as well.

The last feature could put the burden for simpler functions such as
lines
and circles on the user,
and the possibility of having a bloated fixed-function pipeline could
thus
be evaded. The only
other thing I can think is, maybe the rendering API could support less
platforms than the rest of SDL
does, thus decreasing its development overhead. For my part I don’t see
why
any DirectX prior to 8 or
later than 9 would be necessary to support for a 2D API, and OpenGL
should
be supported from 1.0.
Those three features I suggested should update SDL to the 2010s while
keeping it low-level from the
user’s perspective.

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

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

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

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

–
Pallav Nawani
Game Designer/Writer/CEO
http://www.ironcode.com
Twitter: http://twitter.com/Ironcode_Gaming
Facebook: http://www.facebook.com/Ironcode.Gaming
Mobile: 9997478768

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

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

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

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

32

IIRC “DLL hell” only arises if the library installation is poorly
managed - I don’t think that is a problem for this case. (Maybe you
have evidence to the contrary?) These libraries can conceivably be
used individually, such as for an image conversion program, or a
separate sound mixing program. In other words, you can link more to
SDL than just a full-fledged game!

And given the license and Sam’s recent sentiments, there’s no reason
you can’t be the one building it, and distributing a megaSDL.dll that
includes everything for people who find that useful. Shouldn’t be too
hard to automate :slight_smile:

-MikeOn Wed, Jan 18, 2012 at 10:27 PM, Mason Wheeler wrote:

Actually, I’ve never seen the point of pulling functionality out into its
own libraries, especially core functionality that every game is likely to
end up needing.? If I was the one building it, there would be no "SDL_Image"
or “SDL_Mixer” or “SDL_TTF”.? All that basic stuff would be part of
SDL.dll.? Keeps the DLL hell problem down that way.

33

(Side Note: Sam, I gave Ryan a free copy of Scruffy3D (OS X), if you’d
like

a free app store code, drop me an email!)

Very interesting work! I appreciate the offer of a free copy, but I
can’t afford the the Mac needed to take advantage of it :slight_smile:

Heh, I think this was directed at Sam. :wink:

34
SDL_NO_COMPAT Message-ID: Content-Type: text/plain; charset="iso-8859-1"

As it shouldn’t. What’s the point of crossplatform if you want to get at
the API details. DX5 or SW or GL renderer? Who cares, if it works. Either
the API should do that for you, or it shouldn’t, but leaking implementation
details is a terrible plan.

Short answer: It makes extension libraries (let’s say a theoretical
OpenGL5_on_SDL2 library: yes, I know there isn’t an OpenGL5 yet)
actually POSSIBLE.

However, as far as leaking those details to the average program,
certainly not. They should be accessed by using specific header files
and the code those files make availible. For most programmers, such
details should simply be a credible rumor that they’ve never bothered
with (and will probably never have to, since most probably won’t write
an extension library).> Date: Wed, 18 Jan 2012 13:20:07 -0600

From: Patrick Baggett <baggett.patrick at gmail.com>
To: Mason Wheeler , SDL Development List
Subject: Re: [SDL] SDL2 Graphics API, was Re: compiling with

Date: Wed, 18 Jan 2012 12:11:48 -0800
From: “Lazy Foo’”
To: sdl at lists.libsdl.org
Subject: [SDL] SDL2 Graphics API, was Re: compiling with SDL_NO_COMPAT
Message-ID: <1326917508.m2f.31533 at forums.libsdl.org>
Content-Type: text/plain; charset=“iso-8859-1”

-Abolishing software rendering

On general principles I prefer that the software renderer remain in
place, but I’d be fine with an extension library version too.

-Depth buffer

I don’t see a lot of need for this, but as said before, I’ve written
things like this before (specifically, a system that was intended to
implement REALLY GENERIC windowing on other graphics apis), so I’m
willing to implement it (approximately, since I don’t recall details
being suggested) as Bob’s layering idea.

-Built in model parsers for popular formats like obj and collada

This really sounds like something for a SDL_3Dformat library.

-Filesystem access
For a previous game a I made, I had each user have their own their own
directory save files. I had to use boost to traverse and create/delete
directories. Having this integrated into SDL would have made things much
nicer.

This would definitely be nice, I can’t immediately recall any standard
library functions for C/C++ that do this (Noone recommend Boost, I
hate the documetation, and consider it bloatware).

-Matrix/vector library
If we’re going to have primitives, having a matrix library to transform the
geometry is a must have for games and physics simulations. This’ll also save
me having to link glmatrix.

I technically started one, but I quickly decided “It would be so much
smarter for them to use someone else’s math library” so I stopped
pretty quick.

-Installation library
A set of functions that will make installing applications easier IE getting
the program/my documents path.

I’ve been thinking about writing a basic program to launch other
programs and accept commands from them (e.g. “wait 1 second, run
updater, wait for updater to exit, relaunch me”, though not in that
particular format). Not quite the same thing, but certainly related. A
SDL version of the common pipe() function (starts a program, making
the standard input and output of the program being launched availible
to the program calling pipe) would be a good support function. Can you
think of any others? I think it might be worth writing a support
library.

You’ll have to excuse me from coming out of nowhere and appointing myself
scrum master. I just wanted to share a management strategy that always
helped with my projects and to throw in some of my ideas for what I would
like in my SDL apps.

If you’re scrumm master, then that means you have to play
editor/minion-master to us lemmings :wink:
After all, from what I understand, the successful ‘bazaar’ projects
are mostly those with good organization.

Date: Wed, 18 Jan 2012 19:27:32 -0800 (PST)
From: Mason Wheeler
To: sdl
Subject: Re: [SDL] SDL2 Graphics API, was Re: compiling with
SDL_NO_COMPAT
Message-ID:
<1326943652.41346.YahooMailNeo at web161204.mail.bf1.yahoo.com>
Content-Type: text/plain; charset=“iso-8859-1”

Actually, I’ve never seen the point of pulling functionality out into its
own libraries, especially core functionality that every game is likely to
end up needing.

Pulling functionality into different libraries forces those various
pieces to be more self-contained (not entirely, just more). This makes
maintinence easier, because you’re less likely to accidentally clobber
something else, AND it’s easier to understand the system, because the
system is smaller.

For an example of this NOT being done, look at Windows: Before WinXP,
everything was so interrelated that it was essentially impossible to
run the ‘true windows kernel’ on an embedded device, Windows CE was
apparently a completely different system that was written to provide a
strongly similar interface. Why? Because the ‘true windows kernel’ was
essentially almost EVERYTHING on the Windows CD, it couldn’t really
run without ALL of those features. With Windows XP, Microsoft began a
program of trimming down the kernel; I understand that they’ve now
gotten it small enough that the minimal kernel is acceptably small for
smartphones (Windows XP itself apparently mostly just involved cleanup
so that this could happen, rather than benefiting from it directly).

If I was the one building it, there would be no "SDL_Image"
or “SDL_Mixer” or “SDL_TTF”. All that basic stuff would be part of
SDL.dll. Keeps the DLL hell problem down that way.

Now this, I have a slightly different perspective on: specifically, I
like David Olofson’s suggestion (link:
http://lists.libsdl.org/pipermail/sdl-libsdl.org/2012-January/083383.html)
of linking SEVERAL libraries into one dll. However, I’m not certain
how easy this would be. Would this play nicely with the build
frameworks? I’ve never tried to look into SDL’s build systems (and I
don’t do Mac developement), how well would this work? Is this a
seriously credible idea? How would it interact with custom-compiled
versions, would replacing a trimmed-down version with the official
version work?

35

Sam Lantinga wrote:

Both Ryan and I have families and more than full time jobs. ?Any time we spend on SDL is either selfish, getting our games on multiple platforms, or out of love for the community and the project.

…Sam you just gave me one hell of an idea.

I’m CS major, but I have a background in marketing (I plan on getting an MBA in the future). Would you be willing to spend some time in recruiting new SDL developers that actually have the free time to develop?

I have experience kickstarting unpaid projects due to the fact that the developers don’t have time. That’s my job as Publicity Chair for my student ACM chapter.

36

For what it’s worth I’d really love to have a way to get hold of D3D9, D3D10, and D3D11 contexts from SDL, right now I only support these APIs in my native (non-SDL) version of my game engine which is
a shame, considering all the other functionality that SDL nicely provides.

I know it is possible to use SDL_CreateWindowFrom or something of that nature to do this and get most of the SDL functionality back, but that still has the burden in the wrong place, SDL has taken up
the task of creating the window and it does a fine job, I’d just like more choices of graphics API when I create the window, where I am planning to directly use said graphics API.On 01/18/2012 02:21 AM, Pallav Nawani wrote:

SDL2 = SDL1.3 + Code for Rotation & stretch blit simultaneously
Or
SDL provides a way for the user to get hold of the underlying graphics API (DirectX/OpenGL) to allow me to implement the above code in my game without touching SDL itself.
:slight_smile:

On 18-01-2012 10:42, Bob Pendleton wrote:

On Sun, Jan 8, 2012 at 2:00 AM, Sam Lantinga wrote:

Bob, I don’t think we’re quite ready to talk about this, unless you’re
talking about something you’d like to write and maintain separately from
SDL. :slight_smile:
I waited a long time to reply because I wanted to “stir the pot” and
see what people had to say. I really do want to start a long term
project based on SDL2. But, mostly I wanted to see what people really
want.

Bob Pendleton

On Sun, Jan 8, 2012 at 1:28 AM, Bob Pendleton wrote:

If we are going to start talking about what features should be in the
graphics API for SDL2 I think we should start a new thread.

Since this is a 3D API based running on top of modern hardware I’m
going to suggest that it should include layers. We have a Z-Buffer,
even though we are just doing 2D doesn’t mean we shouldn’t use it. It
makes doing so many things so much easier.

Also, I’ve heard a lot of people talking about render to texture as a
requirement, and I’m very much in favor of that, so the minimum
version of OpenGL/DirectX that can be supported is the first version
that supports that functionality.

While is is possible to build up all the graphic primitives, such as
lines, circles, and so on, from a simple scan line fill operation, it
is also pretty trivial to provide a set of solid fill and textured
primitives based on the underlying libraries. They do not have to
complex. It is possible to do textured primitives without ever
specifying a texture coordinate.

And, lets not forget fonts. People need fonts.

A critical problem is the coordinate system to be used. Using Pixels
is rather natural. But, then the library needs to be able to scale
everything for when the window changes size.

Bob Pendleton

To make a modern 2D system anyone want to talk about doing it based
on SVG instead of pixels?

Bob Pendleton

On Fri, Jan 6, 2012 at 9:53 PM, bala_48225<bala_48225 at yahoo.com> wrote:

So far I haven’t used SDL 1.3, but as far as the proposed
split-from-base 2D
rendering API
is concerned, perhaps its features could be limited, basic and modern:

  1. Allow the user to flip, rotate and scale images; 2) Provide multiple
    alpha blend modes for
    images, including multiply alpha, and 3) Provide something akin to SDL
    1.2’s
    SDL_FillRect,
    perhaps with blending modes as well.

The last feature could put the burden for simpler functions such as
lines
and circles on the user,
and the possibility of having a bloated fixed-function pipeline could
thus
be evaded. The only
other thing I can think is, maybe the rendering API could support less
platforms than the rest of SDL
does, thus decreasing its development overhead. For my part I don’t see
why
any DirectX prior to 8 or
later than 9 would be necessary to support for a 2D API, and OpenGL
should
be supported from 1.0.
Those three features I suggested should update SDL to the 2010s while
keeping it low-level from the
user’s perspective.

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

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

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

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

–
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

37

Tear out the rendering API! It is important to have access to the
renderer-specific handles so that SDL supports instead of restricts. SDL
has so many use-cases, that flexibility is important. DLL hell is the
price to pay for dynamic modularity. This shouldn’t even be a concern when
considering what SDL should do. Modularity is a Good Thing!

Jonny D

38

There’s nothing special in SDL_render_d3d.c that you can’t do from your own
code. It’s a great example of using D3D with SDL.On Thu, Jan 19, 2012 at 6:13 AM, Forest Hale wrote:

For what it’s worth I’d really love to have a way to get hold of D3D9,
D3D10, and D3D11 contexts from SDL, right now I only support these APIs in
my native (non-SDL) version of my game engine which is
a shame, considering all the other functionality that SDL nicely provides.

I know it is possible to use SDL_CreateWindowFrom or something of that
nature to do this and get most of the SDL functionality back, but that
still has the burden in the wrong place, SDL has taken up
the task of creating the window and it does a fine job, I’d just like more
choices of graphics API when I create the window, where I am planning to
directly use said graphics API.

On 01/18/2012 02:21 AM, Pallav Nawani wrote:

SDL2 = SDL1.3 + Code for Rotation & stretch blit simultaneously
Or
SDL provides a way for the user to get hold of the underlying graphics
API (DirectX/OpenGL) to allow me to implement the above code in my game
without touching SDL itself.
:slight_smile:

On 18-01-2012 10:42, Bob Pendleton wrote:

On Sun, Jan 8, 2012 at 2:00 AM, Sam Lantinga<@slouken> wrote:

Bob, I don’t think we’re quite ready to talk about this, unless you’re
talking about something you’d like to write and maintain separately
from

SDL. :slight_smile:
I waited a long time to reply because I wanted to “stir the pot” and
see what people had to say. I really do want to start a long term
project based on SDL2. But, mostly I wanted to see what people really
want.

Bob Pendleton

On Sun, Jan 8, 2012 at 1:28 AM, Bob Pendleton wrote:

If we are going to start talking about what features should be in the
graphics API for SDL2 I think we should start a new thread.

Since this is a 3D API based running on top of modern hardware I’m
going to suggest that it should include layers. We have a Z-Buffer,
even though we are just doing 2D doesn’t mean we shouldn’t use it. It
makes doing so many things so much easier.

Also, I’ve heard a lot of people talking about render to texture as a
requirement, and I’m very much in favor of that, so the minimum
version of OpenGL/DirectX that can be supported is the first version
that supports that functionality.

While is is possible to build up all the graphic primitives, such as
lines, circles, and so on, from a simple scan line fill operation, it
is also pretty trivial to provide a set of solid fill and textured
primitives based on the underlying libraries. They do not have to
complex. It is possible to do textured primitives without ever
specifying a texture coordinate.

And, lets not forget fonts. People need fonts.

A critical problem is the coordinate system to be used. Using Pixels
is rather natural. But, then the library needs to be able to scale
everything for when the window changes size.

Bob Pendleton

To make a modern 2D system anyone want to talk about doing it based
on SVG instead of pixels?

Bob Pendleton

On Fri, Jan 6, 2012 at 9:53 PM, bala_48225<bala_48225 at yahoo.com> wrote:

So far I haven’t used SDL 1.3, but as far as the proposed
split-from-base 2D
rendering API
is concerned, perhaps its features could be limited, basic and
modern:

  1. Allow the user to flip, rotate and scale images; 2) Provide
    multiple

alpha blend modes for
images, including multiply alpha, and 3) Provide something akin to
SDL

1.2’s
SDL_FillRect,
perhaps with blending modes as well.

The last feature could put the burden for simpler functions such as
lines
and circles on the user,
and the possibility of having a bloated fixed-function pipeline could
thus
be evaded. The only
other thing I can think is, maybe the rendering API could support
less

platforms than the rest of SDL
does, thus decreasing its development overhead. For my part I don’t
see

why
any DirectX prior to 8 or
later than 9 would be necessary to support for a 2D API, and OpenGL
should
be supported from 1.0.
Those three features I suggested should update SDL to the 2010s while
keeping it low-level from the
user’s perspective.

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

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

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

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

–
LordHavoc
Author of DarkPlaces Quake1 engine -
http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged
demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

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

39

Agreed with Sam. Also, someone mentioned it would be easier to implement a
future-OpenGL5 by having a separate renderer library, but OpenGL is all
extension based, and it’s just as easy to use glew to load up whichever
version of OpenGL you need.
-OzOn Thu, Jan 19, 2012 at 8:27 PM, Sam Lantinga wrote:

There’s nothing special in SDL_render_d3d.c that you can’t do from your
own code. It’s a great example of using D3D with SDL.

On Thu, Jan 19, 2012 at 6:13 AM, Forest Hale wrote:

For what it’s worth I’d really love to have a way to get hold of D3D9,
D3D10, and D3D11 contexts from SDL, right now I only support these APIs in
my native (non-SDL) version of my game engine which is
a shame, considering all the other functionality that SDL nicely provides.

I know it is possible to use SDL_CreateWindowFrom or something of that
nature to do this and get most of the SDL functionality back, but that
still has the burden in the wrong place, SDL has taken up
the task of creating the window and it does a fine job, I’d just like
more choices of graphics API when I create the window, where I am planning
to directly use said graphics API.

On 01/18/2012 02:21 AM, Pallav Nawani wrote:

SDL2 = SDL1.3 + Code for Rotation & stretch blit simultaneously
Or
SDL provides a way for the user to get hold of the underlying graphics
API (DirectX/OpenGL) to allow me to implement the above code in my game
without touching SDL itself.
:slight_smile:

On 18-01-2012 10:42, Bob Pendleton wrote:

On Sun, Jan 8, 2012 at 2:00 AM, Sam Lantinga wrote:

Bob, I don’t think we’re quite ready to talk about this, unless you’re
talking about something you’d like to write and maintain separately
from

SDL. :slight_smile:
I waited a long time to reply because I wanted to “stir the pot” and
see what people had to say. I really do want to start a long term
project based on SDL2. But, mostly I wanted to see what people really
want.

Bob Pendleton

On Sun, Jan 8, 2012 at 1:28 AM, Bob Pendleton wrote:

If we are going to start talking about what features should be in the
graphics API for SDL2 I think we should start a new thread.

Since this is a 3D API based running on top of modern hardware I’m
going to suggest that it should include layers. We have a Z-Buffer,
even though we are just doing 2D doesn’t mean we shouldn’t use it. It
makes doing so many things so much easier.

Also, I’ve heard a lot of people talking about render to texture as a
requirement, and I’m very much in favor of that, so the minimum
version of OpenGL/DirectX that can be supported is the first version
that supports that functionality.

While is is possible to build up all the graphic primitives, such as
lines, circles, and so on, from a simple scan line fill operation, it
is also pretty trivial to provide a set of solid fill and textured
primitives based on the underlying libraries. They do not have to
complex. It is possible to do textured primitives without ever
specifying a texture coordinate.

And, lets not forget fonts. People need fonts.

A critical problem is the coordinate system to be used. Using Pixels
is rather natural. But, then the library needs to be able to scale
everything for when the window changes size.

Bob Pendleton

To make a modern 2D system anyone want to talk about doing it based
on SVG instead of pixels?

Bob Pendleton

On Fri, Jan 6, 2012 at 9:53 PM, bala_48225<bala_48225 at yahoo.com> wrote:

So far I haven’t used SDL 1.3, but as far as the proposed
split-from-base 2D
rendering API
is concerned, perhaps its features could be limited, basic and
modern:

  1. Allow the user to flip, rotate and scale images; 2) Provide
    multiple

alpha blend modes for
images, including multiply alpha, and 3) Provide something akin to
SDL

1.2’s
SDL_FillRect,
perhaps with blending modes as well.

The last feature could put the burden for simpler functions such as
lines
and circles on the user,
and the possibility of having a bloated fixed-function pipeline
could

thus
be evaded. The only
other thing I can think is, maybe the rendering API could support
less

platforms than the rest of SDL
does, thus decreasing its development overhead. For my part I don’t
see

why
any DirectX prior to 8 or
later than 9 would be necessary to support for a 2D API, and OpenGL
should
be supported from 1.0.
Those three features I suggested should update SDL to the 2010s
while

keeping it low-level from the
user’s perspective.

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

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

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

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

–
LordHavoc
Author of DarkPlaces Quake1 engine -
http://icculus.org/twilight/darkplaces
Co-designer http://icculus.org/twilight/darkplacesCo-designer of
Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged
demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

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

40

Hi!

I love SDL, but the complicated feature-creep roadmap debated in this thread makes no sense! Please send help!

Doing too much is bad. Case and point: Allegro 5. It’s a library that used to do everything (everything 2D games needed back in the day), but I don’t know anyone that wants to touch that anymore.

Complaining about DLL hell is silly, so 1990’s. Relics of bad design. If plentiful DLLs really bother you, then start an SDL_Complete project, that statically links them all in to one big DLL or one big LIB. If you’re still angry, investigate what’s needed to make SDL in to a “drop in as source” library. In practice, nobody takes advantage of “upgrading a library by replacing the DLL”. To a developer, being able to click over to a file inside a piece of middleware you’re using, to trace a bug and fix it is huge workflow improvement over Library files any day.

As far as Graphics go, Graphics context creation, and that’s it please. If someone wants to write a cross platform game, they’ll use OpenGL. If they want to appease Microsoft, they’ll use Direct3D. Please keep any mega library that supports multiple renderers out of core SDL. The key point here is layers, and SDL should be the bottom layer. A “Simple DirectMedia Layer”.

SDL is a staple of many gamedevs. It’s how many of us can get away with Mac and Linux ports. We’re never going to get an API consensus out of Microsoft, Apple, and the Linux Foundation.------------------------
| Mike Kasprzak | Sykhronics Entertainment (http://www.sykhronics.com) | Blog (http://www.toonormal.com) | Twitter (http://www.twitter.com/mikekasprzak) |