Nice little plug for your precious glSDL, eh? hehe, i joke.
Well, glSDL is a result of a need and my position, rather than the
other way around.
I partially agree, but I just dont like when people seem to forget
about 2D graphics. And so, in retaliation, I say things like I did
in hopes of rallying the troops to save enthusiasm for 2D graphics.
I think that explained things…
I agree that forgetting 2D is a bad thing, but then I tend to think of
it in terms of “2D projection”. The underlying technique has been
changing for as long as I’ve been playing around with computers (some
18 years), and it’s still changing.
It started with very primitive “enhanced text modes” and the like.
Then came the real hardware sprites, to make up for the fact that
CPUs were way too slow to animate anything on the pixel level.
Eventually, some platforms started using specially designed hardware
blitters in combination with, or instead of sprites. Eventually, CPUs
became so fast that they made both solutions obsolete through
performance and flexibility. Then real time 3D graphics boomed, and
with it came blending effects, image scaling, antialiasing and
texturing - and CPUs were again too slow. The age of 3D accelerators
This is where we are now, and the way it looks now, I think it will be
quite some time before we’re back with some form of s/w rendering.
(The closest to that available to “normal” users is the Wildcat VP,
which is based on arrays of very simple “CPU” cores in a network.
This isn’t exactly your average processor, but it is pretty much
Anyway, whether you’re doing 2D or 3D games is secondary to what
hardware you’re using. There were various kinds of 3D games based on
vector displays (before the array based displays we use these days),
(pre)scaled sprites, s/w or h/w rendered wireframe into array based
displays and whatnot. We’re still using textured polygons, which are
just another approximation, strongly rooted in traditional 2D
But you are correct the matters of 2D over 3D, which is ironic
since its displayed in 2D in the end anyway.
Exactly. It’s only the API and the way some of the hardware is used
that makes it 3D oriented in any way. OpenGL just happens to have 4x4
matrices and 4D coordinates, because that works nicely with anything
up to 3D. Then it (and GLU) has some rather 3D specific features, but
that doesn’t make OpenGL less suitable for 2D in any way.
But, does this mean
completely forgetting the true 2D surfaces we use in light of
Well, what do you want with it? The scaling and filtering is built
into the hardware, so it doesn’t impact performance if you use it.
That doesn’t mean you have to use it.
The issue also lies in the realm of KISS (keep it simple,
stupid.) Are we needlessly complicating things? I believe so.
However, I can’t be sure which way is the more complicated set up.
2D gets pretty complicated as well, if you want to do anything
interesting at all. Big deal if there are Z coordinates and other
features you never use… Lots of people want 3D, so there’s a big
industry around it. If we only want to use part of what the resulting
drivers and hardware can do, fine. It’s not our problem that the
subsystems are overkill for what we want to do. (If they are, that
is. I don’t think they will be in future “2D” games, whether their
projections are fully 2D or not.)
There is another issue I’ll bring up just because it popped into my
head… There are real reasons for keeping the true 2D structures
we use today, such as non game uses.
Really? Where do you draw the line between which transformations are
legal in a 2D API, and which ones are not?
Even most 2D games need 3D
acceleration for rotating, scaling, alpha, etc. Now, I do believe
those things should be supported in 2D, but eh what to do?
Use OpenGL or Direct3D.
If you design a 2D API that does everything advanced 2D apps need,
it’s going to be very similar to a 3D API. I mean, the step from
texturing 2D quads (where you can move the vertices around as you
like) to 3D is very small. On the rendering level, it’s just a matter
of perspective correct texture mapping… The rest is just matrix
operations, and those are pretty generic things both or video cards
and in CPUs (SIMD) these days.
course, we should also all realize that OpenGL is not a 3D only
API. It was designed with 2D graphics in mind and that is something
we should never forget. One of the big differences is coordinate
systems, going full 3D hardware actually ommits caring about screen
size. you just draw relatively. That is a plus in many ways.
Yeah, this is one of the big advantages, but it also has some
someday to see systems where you never need to care about
I don’t think that’s possible, except maybe if every display has a
few times higher resolution than any human eye, or if we ditch fixed
pixel clocks and horizontal scan lines for some other system.
Scaling means interpolation, and that means you get to face Nyqvist,
aliasing and other stuff, just like in audio - only here, we get it
all in (at least) two dimensions. Any rendition of a vector "scene"
is an approximation. If you scale bitmap graphics, the result will
always be inaccurate.
Even in 2048x1536, it matters how antialiasing and scaling is done,
and that’s about the highest resolution this $$,$$$ monitor can
handle. Not even the fastest accelerators around are quite fast
enough to get good frame rates with any recent game in that
resolution, so it’s not just about monitors. I think it will be quite
a few years until display resolution is something you just set and
For 18 years, I’ve heard over and over that “Optimization is a waste
of time! Next year, comupters will be fast enough.”
Damn long year, if you ask me…
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Saturday 08 March 2003 22.26, Calvin Spealman wrote: