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

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

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

Guys,
I would suggest structuring it something similar to Qt's QGraphicsView/QGraphicsScene API. It is quite powerful, fairly simple to understand, and a joy to use. Practically if not everything Bob has mentioned is there. I dont use SDL for graphics anymore simply because getting HW-accelerated graphics using SDL just simply isn't "Simple". I've found the new Haptic API to be quite enjoyable, and I still use the Joystick and SDL_mixer stuff, but the one thing that really excited me about SDL2 that I was looking forward to was the HW Graphics API.

I'm probably reinventing the wheel (particularly wrt SDL2 renderers), but I started writing a "simple" 2D abstraction lib for OpenGL and Direct3D.  I'm not going to link to it, since I think my last email with a link got lost in moderation (we'll probably see it in the next mailing burp).  Tentatively called SDL_gpu, you can find it on Google Code.  I'd love help with it in both design and implementation.  However it works out, a library on top of the core SDL is the way to go.  I'm working off of SDL 1.2 right now and it should be very easy to port to SDL2.

Any takers?


Jonny D


On Sun, Jan 8, 2012 at 4:15 AM, Jonathan Greig wrote:

In my opinion, SDL2 should have enough graphics functions to do basic
rendering (load textures to video card from memory, NOT from files; display
textures on screen), an API for extension libraries (where I would put things
like line-drawing, AND render-to-texture), and that's it for the
ACTUAL graphics. Everything else should be implemented in an extension
library, and if it can't be, then that indicates the SDL2 api doesn't
properly support extensions.

Whether rotation etc. belongs in SDL2 or in such an extension library
I'm not inclined to speak on. I will say that if it isn't implemented
for the software renderer, then it shouldn't be in the SDL core.

Regardless, I think it should always be possible to implement simple
graphical SDL programs with ONLY SDL, regardless of whether it's SDL
1.2, SDL2, etc.





I think that some exposure of the underlying system will probably be
necessary, for the sake of library interoperability. Hopefully a
handful of functions, enums, and structures, all declared in an
optional header file. Maybe call it "extension_api.h" or something.


I personally would prefer render-to-texture to be in an official
extension library, but I have a smart-phone that doesn't support it,
so I'm biased on this subject.




Fair enough.


Doesn't really strike me as sufficiently simple, but I've written
enough image-layering stuff that I'm willing to look at the current
software renderer, and attempt to add support, if Sam & the team
decide to go with it. It isn't like it's THAT complex if you aren't
using MMX & co. (which would be enough for the reference/emergency
backup implementation that the software renderer *optimistically* is).

That having been said, an api that supported it would need to be
defined for, e.g., clearing a single layer.


I'm in favor of using an *official* extension library (ala SDL_mixer)
for that, but see my note above .


My perspective on primitives is that the core graphics api should
provide textured triangles or rectangles and nothing else. With a good
extension interface you can do a low-level implementation of other
standards (lines, circles, etc.), and without it you can use the
textured triangle/rectangle function to implement them.


I'd say that should be kept separate, much as SDL_TTF currently is.
More prominent placement and mention of the 'standard support
libraries' (preferably mentioned and downloadable right beside the
core library) would be nice though.


For the core Windowing/Graphics api, pixels make the most sense for
every platform where that's the 'native way'. For a richer Grahics api
that sits on top of SDL, instead of just extending it, I think the
field should be considered wide-open.


I don't know SVG, but from a quick glance at what appeared to be the
relevant info, I'd suggest the following for a library that USES SDL2:
1) The 'drawable area' is always considered '1.0' wide, and tall. If a
3d library, then it also has a depth of '1.0'. Drawing & etc.
functions always use this particular floating-point coordinate system.
Resizing the drawable area does not modify this coordinate scheme: no
matter what the size of the drawable area is, it's dimensions are
always 1.0*1.0(*1.0). After all, a viewport will ALWAYS be exactly 1
viewport in width, and 1 viewport in height. From what I read, this is
not what SVG does; the other two suggestions are:
2) The drawable area can be queried for it's dimensions in pixels (or
voxels if a 3d library). This coordinate system is not used by
graphics functions, it is only provided for informational purposes
(e.g. to choose texture resolutions).
3) The drawable area can be asked for it's real-world dimensions
(inches, centimeters, etc.) but is not required to provide them. This
coordinate system is provided for the same purpose as the pixel
coordinate system.

But, again, this wouldn't be for SDL2 itself, just for a graphics
library sitting on top of it.
_______________________________________________
SDL mailing list

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

*blink* OK, this is getting ridiculous. What is with your obsession with putting all
possible functionality in extension libraries? It's like you've never heard the term
DLL Hell before!


It's bad enough as it is. Every bit of external code I use requires yet another DLL
in my deployment package. The worst offender (in my game engine at least) is
Firebird. There's no good reason it should take 7 different DLLs just to support a
simple embedded database, but it does! But second on the list is SDL. I need
two different DLLs just to open a ubiquitous file format such as PNG or JPEG
and draw it on the screen, plus an external library for each file format I want
to support, plus other dependencies for those libraries (zlib for libpng, etc.)
And heaven help me if I want to include music-playing capabilities! And now
you want to make it even worse?!?



Give me one good reason why fundamental functionality that every game
is going to need, such as loading images, rendering, playing audio and displaying
text should *not* be included as part of the basic package in a multimedia library
whose name proclaims that its goal is to make multimedia programming "simple"!

Sure, plugin support is a good idea, but let's be realistic and save it for stuff that
really is only optional, not for core functionality that everyone is realistically
likely to need!


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



In my opinion, SDL2 should have enough graphics functions to do basic
rendering (load textures to video card from memory, NOT from files; display
textures on screen), an API for extension libraries (where I would put things
like line-drawing, AND render-to-texture), and that's it for the
ACTUAL graphics. Everything else should be implemented in an extension
library, and if it can't be, then that indicates the SDL2 api doesn't
properly support extensions.

Whether rotation etc. belongs in SDL2 or in such an extension library
I'm not inclined to speak on. I will say that if it isn't implemented
for the software renderer, then it shouldn't be in the SDL core.

Regardless, I think it should always be possible to implement simple
graphical SDL programs with ONLY SDL, regardless of whether it's SDL
1.2, SDL2, etc.





I think that some exposure of the underlying system will probably be
necessary, for the sake of library interoperability. Hopefully a
handful of functions, enums, and structures, all declared in an
optional header file. Maybe call it "extension_api.h" or something.


I personally would prefer render-to-texture to be in an official
extension library, but I have a smart-phone that doesn't support it,
so I'm biased on this subject.




Fair enough.


Doesn't really strike me as sufficiently simple, but I've written
enough image-layering stuff that I'm willing to look at the current
software renderer, and attempt to add support, if Sam & the team
decide to go with it. It isn't like it's THAT complex if you aren't
using MMX & co. (which would be enough for the reference/emergency
backup implementation that the software renderer *optimistically* is).

That having been said, an api that supported it would need to be
defined for, e.g., clearing a single layer.


I'm in favor of using an *official* extension library (ala SDL_mixer)
for that, but see my note above .


My perspective on primitives is that the core graphics api should
provide textured triangles or rectangles and nothing else. With a good
extension interface you can do a low-level implementation of other
standards (lines, circles, etc.), and without it you can use the
textured triangle/rectangle function to implement them.


I'd say that should be kept separate, much as SDL_TTF currently is.
More prominent placement and mention of the 'standard support
libraries' (preferably mentioned and downloadable right beside the
core library) would be nice though.


For the core Windowing/Graphics api, pixels make the most sense for
every platform where that's the 'native way'. For a richer Grahics api
that sits on top of SDL, instead of just extending it, I think the
field should be considered wide-open.


I don't know SVG, but from a quick glance at what appeared to be the
relevant info, I'd suggest the following for a library that USES SDL2:
1) The 'drawable area' is always considered '1.0' wide, and tall. If a
3d library, then it also has a depth of '1.0'. Drawing & etc.
functions always use this particular floating-point coordinate system.
Resizing the drawable area does not modify this coordinate scheme: no
matter what the size of the drawable area is, it's dimensions are
always 1.0*1.0(*1.0). After all, a viewport will ALWAYS be exactly 1
viewport in width, and 1 viewport in height. From what I read, this is
not what SVG does; the other two suggestions are:
2) The drawable area can be queried for it's dimensions in pixels (or
voxels if a 3d library). This coordinate system is not used by
graphics functions, it is only provided for informational purposes
(e.g. to choose texture resolutions).
3) The drawable area can be asked for it's real-world dimensions
(inches, centimeters, etc.) but is not required to provide them. This
coordinate system is provided for the same purpose as the pixel
coordinate system.

But, again, this wouldn't be for SDL2 itself, just for a graphics
library sitting on top of it.
_______________________________________________
SDL mailing list

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

I can see the motivation for making it all modular from a library development
POV - but that doesn't mean it has to literally build as separate
libs/modules.

Linux kernel module style solution; allow optional extensions to be compiled
in, built as external libs, or not built at all?

Pre-built SDL would normally come with everything compiled in. If you want to
save every last byte (which seems kind of ridiculous unless you're aiming for
90% structured/procedural media - like me and like, five other gamedevs on the
planet), you either pick a modular build and drop in only the libs you need,
or you build your own single file version.

Not the most trivial solution, but one size does not fit all, obviously...


On Thursday 12 January 2012, at 14.16.19, Mason Wheeler
wrote:

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

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

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

Mason, what about licensing that allows static linking?

Jonny D


On Thu, Jan 12, 2012 at 8:47 AM, David Olofson wrote:

What about it? The current licensing does allow static linking, and I might actually end
up going that route. Ideally, I'd like to be able to compile everything into the EXE. Less
clutter to deal with, plus that way the smartlinker can analyze stuff and trim out unused
functions to help keep the download size down. Never gonna happen, of course, but a
guy can dream, right?



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

Mason, what about licensing that allows static linking?

Jonny D


On Thu, Jan 12, 2012 at 8:47 AM, David Olofson wrote:





_______________________________________________
SDL mailing list

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

On Thursday 12 January 2012, at 16.17.53, Mason Wheeler
wrote:

...and it'll actually work without dirty tricks on Linux, where you normally
cannot just drop libs in the directory along with the executable.

OTOH, that would actually still work if the libs were loaded run-time, as one
normally does with OpenGL etc. So, either static or run-time - "normal" shared
libs is where the problems are.



Well, there is static linking + object files...


[...]


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

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

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

On 2012-01-12 14:16, Mason Wheeler wrote:

I don't use the SDL extension libraries. I don't need the SDL extension
libraries. I don't want the functionality from the SDL extension
libraries in the SDL core.

The problem with including it all in the core is that this actually
increases DLL hell. If the SDL core included the functionality of
SDL_image, then the SDL core would inherit all of the dependenies of
SDL_image, for example. Why should I need to ship a libpng DLL if my
program doesn't load PNG files?


--
Rainer Deyke

_______________________________________________
SDL mailing list

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

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

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




--
+-----------------------------------------------------------
+ Bob Pendleton: writer and programmer
+ email:
+ web: www.TheGrumpyProgrammer.com
_______________________________________________
SDL mailing list

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

On Thu, Jan 12, 2012 at 7:16 AM, Mason Wheeler wrote:

I think that SDL is rather like the elephant in the story of the blind
men and the elephant. Each of us sees something different depending on
how we approach the elephant. I've seen a number of arguments on the
list over whether the Simple in SDL means that the library it self is
simple, as in small, or simple to use, or simple to understand, or....
May I propose that the Simple in SDL may mean that it makes it Simple
to write cross platform extension libraries? :-)

I have come to see SDL as an abstraction layer for interacting with
the human interface hardware and the multimedia hardware available on
modern computer based devices. Basically, Apple, Google, MS, et al. do
there best to provide incompatible APIs and SDL make them all
compatible.

Seriously, I understand your point of view. Can a single library ever
contain everything that every end user needs? More realistically, can
a single library, provide 80% of what everyone needs and 100% of what
they need to implement the rest? You can hope to get 80%, but never
100%.

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

Bob Pendleton




--
+-----------------------------------------------------------
+ Bob Pendleton: writer and programmer
+ email:
+ web: www.TheGrumpyProgrammer.com
_______________________________________________
SDL mailing list

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

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


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

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

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

+1 for either ideas;
++1 for both ideas together


On Wed, Jan 18, 2012 at 11:21 AM, Pallav Nawani wrote:
_______________________________________________
SDL mailing list

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

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

Cheers!

On Wed, Jan 18, 2012 at 5:21 AM, Pallav Nawani 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:
_______________________________________________
SDL mailing list

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

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

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

Cheers!

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





_______________________________________________
SDL mailing list

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

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.

Patrick


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

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 method to be one of the more effective methods. Programmers tend to like it because it essentially boils down business to a recursive algorithm. :D

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

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

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.

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.

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 Pendleton

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



--
+-----------------------------------------------------------
+ Bob Pendleton: writer and programmer
+ email:
+ web: www.TheGrumpyProgrammer.com
_______________________________________________
SDL mailing list

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

Bob wrote:


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

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

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


in SDL_video.c

On Wed, Jan 18, 2012 at 1:46 PM, RodrigoCard wrote:

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

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

Bob Pendleton




--
+-----------------------------------------------------------
+ Bob Pendleton: writer and programmer
+ email:
+ web: www.TheGrumpyProgrammer.com
_______________________________________________
SDL mailing list

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

Mason, I've said it over and over.. If you're OpenGL specific, be OpenGL specific! :)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! :)


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:

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


Cheers,

On Wed, Jan 18, 2012 at 10:34 AM, Brian Barrett 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; 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! :)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! :)


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:

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.

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:

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

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

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

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

-Mike
_______________________________________________
SDL mailing list

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

Heh, I think this was directed at Sam.

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





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


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.


This really sounds like something for a SDL_3Dformat library.


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


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.


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.


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




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


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

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

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

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:


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

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

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

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: