Re: OpenGL: a viable game-programming API?

[Bert Peers <rat@larian.com>]

Joel Stanley wrote:

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

Hm.  I don't know if the comparison 100% holds but I get what you mean.
It may all just depend on what you want to do.  Tools by definition want to
be generally applicable, but too general = not the most performance for
one specific situation.  That's why PVSes were stacked on top of the
basic tool called clipping/transforming/rasterizing API OpenGL is.  Now
if enough people use the PVS it's a new tool, but until then you're not
gonna be able to use it if you stick to the tools available.  Or something
like that :)  I mean, it's not because clipping/.. etc is standard now with
rasterizing in hardware, that nothing exciting is happening in the realtime 3D
scene : check out Q3's bezier, messiah's realtime character LOD etc...
These are not "tools" yet, so either you don't use them, or you wanna
learn them, but in that case from nowhere-to-there may be steep.

I'd say, if you want to do fairly low complexity games (shoot'm'ups,
low-FPS-is-okay adventure like things, or TAnnihilation stuff) or just
the supporting back-end editors/tools, the interiors aren't a worry.
If you wanna be the next Carmack.. well... :)

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

Well I for one discovered a few interesting points in reading Hecker's
rasterization articles, even though that's essentially a dead topic.  There's
a few things in there that I didn't know, but you learn anyway.
 I think that's the core issue : the algorithms as they stand fade away, but
the underlying principles still hold.  That's also how I'd define the need
for implementation : if the principles are clear enough from the algo it's
allright, but sometimes just doing it helps even more (that would be the
case for instance for Hecker's sub-pixel accuracy thing, you're not
gonna think of that just by looking at yer basic 1/Z lerp scheme.  at least
I didn't <g>)  Eg, even with hwared 3D rasterizing the Bresenham is worth
a look imho, if only to see the simplest possible case of forward differencing;
if you got the idea, you can apply it to splines etc...

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

Yeah, exactly.  It may seem silly to study Doom for it's 3D caps if you
have source for Descent, but as a stepstone to Quake's full blown 3D
BSP, it's 2D BSP may help.. Etc etc etc  :)

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

Yeah, that's where it's getting fuzzy again :)  Me I'd say "no, don't do that
stuff anymore", but you can easily rephrase the question to be about
elementary 3D clipping to the view frustrum.. then I wouldn't know anymore :)

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

I think so.  Like I mentioned, if you *don't* optimize your game is never gonna
look so good as from the guys who do bother.  If you do Quake without optimizing,
and I do optimize, my level designers just gonna be able to pump out more polys.
So optimization ain't dead.  On the highest levels it amounts to studying the
latest siggraphs and understanding advanced stuff such as lumigraphs,
wavelets (-> messiah), realtime polygon reduction etc.  On the lowest level
assembly apparently ain't dead either.  The pipeline stages get deeper every
year, and now with out of order execution it's even more fun.  But, again according
to Hecker's articles, compilers apparently aren't able to create highly optimal
code for even the Pentium (I guess CPUs are a too-fast moving target for them
as well), let alone do the "perfect 4/1/1 P2 decoder slice" dance.
We may not need those high-performance assembly lines anymore for
rasterizing, but there's plenty of other gfx stuff to do.  Oh and an A* in good  asm

performs really nice too ;)

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

No idea :)

Bert