Re: [Chicken-users] 3D games in Chicken

[Shawn Rutledge]

On 2/10/06, Peter Keller <address@hidden> wrote:
> Because what happened was that I did the bigloo opengl port (my god was
> it *sexy*) and then Mr. Serrano changed the FFI a version later causing
> my work to crumble and I didn't want to repeat it so it died.

That's terrible!

> 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?  To
display images you map them as textures onto rectangles, and the
OpenGL implementation takes care of the rest, right?

What do you have to do to get text via OpenGL?  Would you need an
interface to freetype or something like that?  And if so, would the
output from freetype have to be a bitmap?  Or is it too terribly
expensive to translate glyphs into sequences of OpenGL drawing
commands for each line segment?

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.

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?

My prioritized concerns are first, to get the best 2D performance on
every device; 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.

When a file containing a model is saved, if you are saving a Scheme
data structure in ASCII form, then you cannot necessarily tell whether
a number with a decimal point in it (like say 167.25) is fixed or
floating point (except when it's obvious that the number can't be
exactly expressed in fixed-point).  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
floating point?  For many uses of flonums (for middle-sized values at
least), an approximate implementation would be available on the
fixed-point version, which is better than just not having flonums at
all.  And the OpenGL API would appear identical - it takes flonum
coordinates, and only the implementation is different.  The PDA
version could be linked with klimt and the PC version to Mesa, or
whatever.  And 3D models would be portable across the two; just that
they might not render the same, depending on the scale of the numbers
that are being used.  As fp implementations get faster and more
pervasive the fixed-point implementation would fade out of use anyway.

Well sorry if this seems like a half-baked idea, but I'm curious what
you all think of it anyway.