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

[Shawn Rutledge]

> 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

OK that makes sense.

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

I imagine you're just referring to game menus and such?  Whereas most
non-game apps will involve much more text, so one needs text rendering
to be as fast as possible, and also to support scalable fonts etc. 
And I think soon there will be a lot more attention paid to aesthetics
of the text too - evolving towards the kind of quality on-screen that
you get out of TeX on paper.

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

Can you point me to some examples?

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

Well that's what I figured.

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

So do you agree that Scheme ought to have portable flonums even when
the hardware doesn't support floating-point, by substituting
fixed-point instead?

What I'm proposing is to do that, and then use OpenGL ES or something
like it on small devices, and regular OpenGL on large devices, and
keep the API the same so that the Scheme OpenGL programs will run
unchanged on either one.