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

[Peter Keller]

On Sat, Feb 11, 2006 at 12:23:32AM -0700, Shawn Rutledge wrote:
> 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!

Yeah, I was sad, which is why I'll only do it if the FFI is stable for
Chicken. I'd probably build on Felix's Egg, depending how it was done.

> > 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?

While opengl is happy to draw whatever you want into a window, it has no
idea how to acquire that window from the window manager, set it up for
the right color depth, double bufferring, etc, and deal with keyboard,
mouse, window manager events, etc.

That's why you need something like GLUT (which isn't a part of opengl,
but often bundled with it) or SDL. GLUT has it's own internal event
handler loop which you cannot control, and SDL exposes this loop so in
essence you write it. After coding plenty of 3D things in my life, I've
found I very much prefer SDL to GLUT any day. Plus, SDL has an audio
and mixer set to its API which are really nice. There is OpenAL, which
is the opengl equivalent for an audio library, but it had some issues
for a while politically (Loki Games wrote it, went out of business,
released it, it lied fallow for a while, then some people took it over),
I'm not sure on its completness and support at this time.

> 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?

You'll probably have to use freetype or something to deal with the
truetype font. I've never used truetype stuff in anything I've done,
usually I just have some big bitmap of a bunch of antialiased characters
and then I select the subtexture which represents one letter out whenever
I need it. The pipeline takes care of bilenear filtering it and mapping
it onto whatever surface it needs to go on.

> 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.

Yikes! Don't bother doing a raw 2D library anymore. It isn't worth
it. Opengl has the ability to ask for pixel perfect placement on the
window in a 2D setting, even though to coordinates are floating point. Use
that instead.

> Wouldn't it be nice to get away from needing completely separate 2D
> and 3D methodologies?

If your project deals with 2D components specifically, then a small
abstraction layer would be good to represent it, but have the back end
be opengl.

> 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).

Truth be told, use a 3D interface like opengl and do the mathematics
so things end up 2D. That will be the fastest solution across the most
hardware. 

> 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).   [...]

Surprisingly, you have this problem is every other language too. :) The
main way to deal with it is simply not to care about the slop and assume a
"thickness" around everything which is built into your calculations.

-pete