Shawn Rutledge wrote:
You don't. I've avoided learning SDL because I'm not convinced it's a
value add if you're going to require OpenGL anyways. SDL began life as
a 2D portability layer. I don't have a sense of how OpenGL oriented it
is nowadays. I'm kinda jaded. I'm thinking, gee there's probably a
lot of code in the way of the OpenGL stuff, because of SDL's long and
And, if you wanted the most bang for your buck, then the SDL_* API should
Forgive my naivety but why do you still need SDL in that case?
There's a bunch of stuff at www.opengl.org about this.
What do you have to do to get text via OpenGL?
Man this is so early 90s. Back when we all wrote our own 3D APIs from
scratch! Look into OpenGL ES and what devices support it. ES is
supposed to be the stripped down version of OpenGL for such gizmos.
Another reason I was starting my own 2D graphics library (and
procrastinating dealing with 3D) is that I see OpenGL uses
floating-point arguments to most functions. For now that is not a
good idea on small devices (even the ones that are powerful enough to
do some 3D rendering). But klimt claims to have a fixed-point
implementation. So I think it would be ideal to keep the numeric
types swappable somehow.
I stared long and hard at the problem, and concluded that doing 2D via
3D HW is the correct way to do things. You're going to need image
rotation and scaling operations and so forth. There's a reason the
rest of the industry went "3D for 2D." I wouldn't waste time
reinventing last decade's thought processes on the matter.
For my 2D library I planned to use 24.8 bit fixed point for screen
coordinates, with the units being millimeters, and on most devices
(where exact dimensions are not important) to fudge it by assuming
there are 4 pixels per mm (101.6 dpi is pretty close to typical
resolution of today's monitors). So you'd end up with 6 bits of
sub-pixel resolution. A simple implementation would just round to the
nearest pixel; an integer antialiasing implementation would use the
subpixels to be more accurate; and if OpenGL acceleration is
available, the 2D drawing commands could be translated into OpenGL
calls, and the fixed-point numbers would get translated into
floating-point. But, this approach assumes that the majority of the
work is 2D, because OpenGL is just being used as an implementation.
Wouldn't it be nice to get away from needing completely separate 2D
and 3D methodologies?
Unless this is going to get you big $$$$$$, this is a complete waste of
My prioritized concerns are first, to get the best 2D performance on
Yeah, so, 2 years from now nobody will care. You'll waste all this
time trying to optimize for obsolescent technology. Reminds me when I
was going to port Free3D from i486 to Pentium. Glad I got lazy,
because in hindsight, it would have been for nothing. The HW changes
too fast. Plan for the future, not the past.
second, to be forward-compatible with 3D hardware;
third, to make the 3D functionality on such hardware available fully
via a "nice" clean API which very closely resembles the 2D API (and
last but not least, slow 3D should even be available on slower
machines, using the same API). Apparently Cairo achieves at least the
first two goals (it can do software 2D rendering, or you can use the
"glitz" backend to render to OpenGL calls) but it's kindof
heavyweight, and also uses floating-point extensively.
Blow off the device that has poor market share. You know, I wasted my
early career on trying to make 3D APIs portable to everything,
everywhere. I ended up with a really spiffy portable 2D rasterization
layer, and my 3D API barely drew a polygon. I was also an Autoconf and
IMake guru. It's better to pick one platform that's worth *money* and
do a decent job on it.
So what if there was a version of
Chicken for devices without math coprocessors in which flonums are
really fixed-point 24.8 format, and another version in which they are
I think I've been there, done that. I know everyone has to reinvent
the world anew for themselves, but I hope you heed the warnings of
Well sorry if this seems like a half-baked idea, but I'm curious what
you all think of it anyway.
Brandon Van Every