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 reasonit should take 7 differentDLLs just to support a
simple embedded database, butit 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
Date: Wed, 4 Jan 2012 17:17:10 -0600
From: Bob Pendleton
Subject: Re: [SDL] compiling with SDL_NO_COMPAT
Does SDL2 need any graphics support in it? It needs to be able to load
images, it needs to be able to do the kinds of image manipulation that
a graphics program needs to do to prepare images for use by a graphics
program, and it would be nice if it had helper functions to hand off
images to the OpenGL and DirectX and whatever other high level
graphics API you are using.
In my opinion, SDL2 should have functions to load and save images and
hand them off to OpenGL, DirectX, and what ever other high level
graphics APIs may be in use.
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.
Date: Wed, 4 Jan 2012 19:58:23 -0500
From: Sam Lantinga
Subject: Re: [SDL] compiling with SDL_NO_COMPAT
Mason is absolutely right that the current API doesn’t expose the things he
needs to extend the underlying rendering system.? To some extent this is
intentional as the API user isn’t supposed to have to worry about whether
the underlying rendering system is OpenGL, Direct3D or software.
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.
My feeling is that there are still one or two things that the API can use
to be really useful, such as render to texture, but I have drawn the line
at things that would expose 3D math - once you go there you’re better off
using a real 3D engine or going directly to OpenGL/Direct3D.
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.
Date: Sun, 8 Jan 2012 00:28:21 -0600
From: Bob Pendleton
To: sdl at lists.libsdl.org
Subject: [SDL] SDL2 Graphics API, was Re:? compiling with
??? SDL_NO_COMPAT
Message-ID:
??? <CAKabUS5zgoAeMixVjaie5841HSugn-42SPzcAW-hUGyL=TOFiA at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
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.
Fair enough.
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.
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.
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.
I’m in favor of using an official extension library (ala SDL_mixer)
for that, but see my note above .
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.
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.
And, lets not forget fonts. People need fonts.
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.
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.
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.
To make a modern 2D system anyone want to talk about doing it based
on SVG instead of pixels?
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:
- 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:
- 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).
- 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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org