chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Brandon J. Van Every
Subject: Re: [Chicken-users] 3D games in Chicken
Date: Sat, 11 Feb 2006 05:52:09 -0800
User-agent: Thunderbird 1.5 (Windows/20051201)

Shawn Rutledge wrote:

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?
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 sundry history.

What do you have to do to get text via OpenGL?
There's a bunch of stuff at www.opengl.org about this.


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

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

My prioritized concerns are first, to get the best 2D performance on
every device;
Unless this is going to get you big $$$$$$, this is a complete waste of time.

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

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

Well sorry if this seems like a half-baked idea, but I'm curious what
you all think of it anyway.
  
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 older souls.


Cheers,
Brandon Van Every


reply via email to

[Prev in Thread] Current Thread [Next in Thread]