Re: OpenGL: a viable game-programming API?

[Joel Stanley <jstanley@up.edu>]

On Thu, 25 Feb 1999, Jeff Read wrote:

> Joel Stanley wrote:

> Abstraction is nice. But this whole idea of "program to the abstraction
> layer and forget about everything else" is IMHO dangerous. In the world
> of Win32, we're seeing fewer and fewer programmers and more and more
> Visual Basic junkies whose only purpose is slapping together chunks of
> Microsoft-authored code. Microsoft itself is really hurting for
> programmers as they only accept people who really know their Win32 and
> those are getting rarer and rarer.

Agreed. The biggest problem I have, however, is not so much being forced
to use someone's existant API, but rather not knowing how to go about
doing what I want to do under Linux. I have a big problem with reading and
understanding other peoples' source code -- let alone when it is for
different hardware/platforms than my own.  I _want_ to code under linux,
not using internal DJGPP macros under win32 to shut off 32-bit protected
memory and then write directly to video memory...

I haven't really had the chance to play around much with assembly language
yet...most of the stuff I've written that's of any significant size is
either C, C++, or Java...how hard would it be to use something like the
GNU assembler under linux to do what is done in some of the graphics books
I have? :) Since it's the same processor, there wouldn't/shouldn't be much
porting involved, correct?

A good place to start is probably straight SVGA using SVGALib and a bit of
raw assembly...there is a wealth of source code available as examples for
16-bit DOS.  Is there anything I need to be aware of if I jump right
in and try to start using this as a starting point for doing hardware
programming under Linux?

> I have a nice book, "The Black Art of 3D Game Programming" that takes
> you through matrices and transformations and Z-buffering and all that
> stuff. It was written for DOS programmers using fixed-point math but it
> translates quite nicely to Linux/svgalib with floating point (gotta love
> those high-speed FPU's in the Pentia :)). I don't think you'll find such

This is pretty much what I need. I have Abrash's black book, which is
_huge_ and probably has more assembly code than I'd be capable of writing
in a few lifetimes. I certainly want to get at the hardware directly and
understand just what the hell is going on -- that is, after all, what it's
all about :) I would prefer to start this way but I'm having a pretty hard
time finding example code or documentation which I can apply to a linux
development environment vs a windows one.  I'm pretty committed to NOT
learning DirectX or any of its relatives.  If I use any pre-established
API, it will be OpenGL if only for its cross-platform features.
 
> I think so. For example, learning the basic matrix transforms allows you
> to optimize them before feeding them to your Voodoo card. :)

I see your point. I don't think I would intent on using the API to do
_all_ of the dirty work (especially not the matrix math), but the level of
optimization required/desired to write a full-blown game using only OpenGL
would be very minimal when compared to the level of optimization
required/desired using hardcore SVGALib and asm code.  But where does one
draw the line? Do I focus on hardware-level graphics programming until
I've done enough at that level to understand exactly what it is that
OpenGL is doing? And how it does it?

Can a prospective game programer only (initially) gain the desired
knowledge via hardware-level (and probably hardware-specific) programming?
I certainly wouldn't mind taking this approach (I always do things the
hard way anyway :), but I just want to hear from some people who had
"been there, done that" that I'd be on the right track if I did so. I'd be
pretty frustrated if I spent significan amounts of time in order to
accumulate vast amounts of knowledge about programming techniques which 
are already considered slightly outdated...

-joel

--
Joel R. Stanley                   *  jstanley@up.edu       
http://rainier.up.edu/~jstanley   *  #include <std_disclaimer.h>