BTW, the guy who commented about bad drivers for ancient slow GPUs is
way out of line. If hardware graphics is slow on that kind of machine
then software graphics will be even slower.
Though personally I’m not entirely opposed to dropping software
rendering in 1.3, I can certainly understand the desire for the
software rendering fallback.
It’s not necessarily a question of speed. It’s often a question of
working properly at all.
There are plenty of developers who would like to have a fallback
option if the hardware drivers are broken or even just not installed.
Granted, often it makes more sense to just bail, but, for some
applications like educational applications, analytic visualization and
even casual games, it is perfectly viable to fall back to software
rendering.
It might be necessary to also limit the quality of the rendering in
that case, of course.
All that being said, if SDL keeps to a sufficiently simple set of
operations, it’s likely that the vast majority of applications will be
able to run successfully even on GMA-950 (the current primary
candidate for bottom of the barrel status).
Some of your other ideas sound interesting, though I tend to swing
toward the opposite end of the spectrum - rather than have SDL hide
everything from me, I think I’d rather have it expose everything to
me, so I can decide what to use, and what features to avoid, and how
best to optimize for a given platform.
A layer could be built on top of SDL to give the behavior you’re espousing.
It’s really just a difference of opinion on what the “Simple” in SDL
should mean. Conservation of Complexity dictates that there will be
complexity somewhere in the system, it’s just a matter of where we
put it.
The API’s implementation can be simple, but then the layers above will
likely need to do more work. That has the advantage of enabling an
intermediate layer that does most or all of that work to expose an
even simpler model to the application, whist retaining both simplicity
in the SDL layer (to ease porting) and giving more flexibility to the
apps built on top of SDL.
The alternative is to do as you suggest, and push the complexity down
into SDL itself. That would remove a layer in the case where an
application doesn’t need the simplicity, but would make things more
complex (or impossible) in the cases where the application needs more
flexibility.
I submit that the former style more closely fits with the design of
SDL up to this point. SDL itself is simple, but limited and/or low
level. Then there are libraries such as SDL_mixer, SDL_image, SDL_ttf,
etc., to extend and/or simplify specific tasks. One could imagine the
addition of SDL_render or some such, that exposes an simplified model
in the way you describe.On Mon, Jan 31, 2011 at 19:08, Bob Pendleton wrote:
Ok, back to your question about the rendering API. There is a need
conceptually simple graphics API that can be used be used and
understood by everyone. If the rendering API was expanded to included
3D then it would be loved by all. The best thing about the rendering
API is that it is always there and will should use whatever hardware
support is available, whether that is OpenGL or DirectX, or whatever
the rendering API can be a high performance, limited, simple, graphics
API that just works with OpenGL.
If I were doing it I would have a nice part of SDL analyze the
hardware and pick the “best” or at least “good enough” depth for the
screen buffers, textures, and images. Provide functions to convert to
and from images to the default format and then hide what is really
there as much as possible. The default would be an rgba buffer on all
platforms, it might be an 8888 format, or a 2222 format or whatever
but it would be RGBA. (OK, it could be ARGB but we would hide that so
the programmer doesn’t care!) ?You could ask for a depth buffer, a
stencil buffer, and all the other buffers. You might not get them, but
if you do they will ?be like the image buffers, the best or at least
good enough, that you can get on the hardware you have. There would be
no hardware pixel formats visible to the at any time.
Yeah, a lot of folks will hate that idea, but it actually works and
allows for a doable cross platform implementation.
Ok, I have a lot of opinions on this subject, but my wife just said
that dinner is ready!
Bob Pendleton
On Fri, Jan 21, 2011 at 3:34 AM, Sam Lantinga wrote:
I’m curious, would people rather see the rendering API go away?
Does it increase the complexity of the API without bringing enough
functionality to be useful?
On Fri, Jan 21, 2011 at 12:39 AM, Sam Lantinga wrote:
I’ve thought a lot about this, and here’s my thoughts…
SDL serves three types of video API users:
- People who just want a framebuffer and use SDL 1.2 blit and direct
pixel access to do the job.
- People who just want an OpenGL context, and use OpenGL or OpenGL ES to
do the job.
- People who want a hardware accelerated 2D API
For #1 and #2, the functionality was available in SDL 1.2 and the feature
set is well understood.
For #3, this is a new area that SDL 1.3 is supporting, and it’s really
easy to lose the “Simple” in “Simple DirectMedia Layer”
So I think here is a good time to remember that the goal of the SDL
rendering API is simply to hardware accelerate operations that were
typically done with the SDL 1.2 API.
This is tricky, since people did lots of interesting things with direct
framebuffer access, but let me break it down into a feature set:
copying images
filling rectangles
drawing single pixel lines
drawing single pixel points
SDL 1.2 provided colorkey, alpha channels, and per-surface alpha, as well
as nearest pixel scaling.
Again, to break that down into a feature set:
blending for all operations
single vertex alpha for all operations
single vertex color for all operations
scaling for image copy operations
It’s tempting to add functionality here, but that road lies madness.
Right now SDL provides renderers with varying levels of functionality, and
the API user has to query renderers and capabilities and so forth.
Again, in the interest of simplicity, I will be pulling out the partially
functional renderers, and requiring all renderers to be fully functional.
This leaves the following renderers, availability depending on platform:
- software (always available, blasting pixels through the 1.2 interfaces)
- Direct3D
- OpenGL
- OpenGL ES
See ya!
On Thu, Jan 20, 2011 at 2:41 PM, Mason Wheeler wrote:
After some discussion on the “Again Rotozoom” thread, I figure I may as
well
formally raise this proposal:
Because all platforms that SDL supports have hardware-accelerated video
available as a standard feature, and because this has been true for over
a
decade, (7+ Moore cycles,) and because of the difficulty of implementing
several
advanced features in a performant manner in software, I propose that SDL
1.3
should drop support for non-accelerated backends such as GDI and X11 and
focus
on modern, hardware-accelerated APIs such as OpenGl, GLES and Direct3D.
Seb Da Rocha brought up an interesting point: the SDL software renderer
is
generic and implemented entirely within SDL instead of relying on an API
backend
to crunch the pixels. ?As such, it could be retained as a reference
implementation (“this is what correct rendering is supposed to look
like”) for
people implementing SDL on new platforms, but it should be made clear
that it’s
only for use as a reference implementation and not supposed to be used to
actually build games with.
Can everyone agree on this?
Mason
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
? ? -Sam Lantinga, Founder and President, Galaxy Gameworks LLC
–
? ? -Sam Lantinga, Founder and President, Galaxy Gameworks LLC
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
–
Do what you can, where you are, with what you have. - T. Roosevelt
