Re: OpenGL: a viable game-programming API?

[Joel Stanley <jstanley@up.edu>]

On Thu, 25 Feb 1999, Bert Peers wrote:

>   Yeah, that's a tricky one.  I myself did most of the algo's (been there in
> the
> days of write-your-own-rasterizers demo-scene things) but you never
> know everything, and with these APIs moving on to ever increasing
> highlevel stuff, I have basically the same question, but on a different level
> :
> is it still worthwile to study Inverse kinematics, NURBS etc if these come
> prepacked with the API ?
>   I don't know.  Lotsof things play here.  There are probably 3D people
> out there who don't even know what a dotproduct is let alone what it's
> used for, but using the D3D Retained mode (or whatever) they build nice
> tools etc.  But personally I think it's gonna be a lot easier if you make sure

This is pretty much the heart of the matter as far as I'm concerned. If
the tools exist to do what you want to do, how far must one must go to
truly understand what _is_ going on underneath the hood? I mean, the whole
point of OOP and data abstraction/method hiding/etc is that I can take
this neat group of tools, learn how to use them, and not even *care* what
they're doing with the hardware.

Games are _almost_ getting to the point where some form of hardware
acceleration is expected, even if that hardware acceleration is only in
the form of a $50 3dfx (vooodo 1 chipset) card...so why not take advantage
of that? In a way, the days of extremely low-level optimization (the demo
scene, early 3D games, etc) are close to being over...but does learning
those optimization techniques still have merit? If one learns all of the
low-level fancy schmancy algorithms for all of the drawing stuff, and
learns how to do them _well_, that knowledge could certainly apply to
pushing the limitations of the current (acclerated) hardware...thoughts?
:)

> you have at least the basics layed out.  That'd mean studying the algo's
> but not go as far as to implement them (which as we probably all know
> suddenly makes a whole lot of special cases and didn't-think-of-thats

Where's the line drawn between understanding an algorithm and implementing
it? I mean, I understand the line-drawing algos I've seen and the
circle/ellipse drawing algos I've seen, but I'd have to have a lot of 
overhead (setting display modes, getting used to SVGALib, etc, etc) if I
were to actually implement -- more stuff I'm not familiar with...the
question is do I _need_ to be familiar with it? >:)

> appear).  What also matters is that if something becomes a standard, then
> it's just that : standard stuff.  Everyone using it will then subsequently be
> doing "nice" work but nothing cutting edge.  Like, hware is so powerful
> today that you can use OpenGL to implement something like Doom
> without ever turning your head to educated data structures; just load
> the level and throw all the poly's at the screen.  Obviously, the people
> who do bother to check out the underlying technology, and then try
> to improve on it, are the ones that bring Quake -- on the same hardware.

Exactly...but when trying to learn this stuff is it important to
understand the inner workings? Or could I simply screw around in OpenGL
and pick up on low-level stuff if and when I needed it later? ;) I have
yet to become an optimization freak except when cutting O(n^2)+ algorithms
into logarithmic or linear runtime if and when I can.  Quite frankly, on
modern processors and hardware, are all of the optimization techniques
available (like the volumes of optimization tips written in Abrash's Black Book) 
even worth anything? If I were to write a Quake clone with accelerator
hardware, would I even need all of the optimizations? :)

>   It's probably like the language/compiler thingy : you don't have to write
> a compiler to understand what goes on under the hood, but knowing
> how function calling, C++ object members etc are implemented is
> probably help you improve code efficiency.  Replace efficiency with
> "visual ooh and aah" and language/compiler with 3D tech/API and
> you're there... somehow :)

On a side note...how is OpenGL as a 2D API? If I wanted to make a
nostalgic platform romp...:)

-joel

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