On 15-Dec-05, at 8:23 PM, Theodore H. Smith wrote:
Also, OpenGl doesn't offer you everything you need. You'll still
some other code for things like space culling (Where objects that
can't be seen don't get drawn). And then there's collision
detection. OpenGL gives you no ability for collision detection...
So you need to write a simple and extensible, yet fast framework
for collision detection.
Unless you are an OpenGL and game master I wouldn't really bother
making an OpenGL plugin.
It's clear you've misunderstood the intent and target audience of
Marco's plugin. The plugin provides a convenient way to access the
OpenGL API in RB, and is meant for current OpenGL programers or
people wanting/willing to learn. If Marco called it
"UberGameEnginePlugin" then your arguments would have merit, but
as I see it, he's delivering a product as advertised.
Well...
It'll be good for people making demos or very simple games.
OpenGL just does what you tell it to do - simple stuff is, well,
simple ;) but in the right hands it can do million-polygon-per-pixel-
everything. I don't see how this plugin limits you to the latter, it
just exposes the API and includes some convenience functions.
Anyone smart enough to make a good game or sophisticated 3d app,
would probably be smart enough to write their own plugin in the
first place though.
Well sure, but if something already exists that can save you the time
and grief then I don't see a problem using it. Many AAA commercial
games (the majority in fact) are made on the backs of other people's
work.
I thought Quake3 used vertex arrays and did most of the
transformations in the CPU, but I could be wrong.
Vertex arrays are a prerequisite if you want decent performance -
there are several ways to batch geometry nowadays, and the original
vanilla vertex array API is generally at the bottom of the list
(though still useful). I haven't really dug through the Quake 3
source but I'm certain it uses hardware transforms for (at least) the
final vertex transformations. If it's anything like GLQuake1/2 it'll
maintain its own transformation matrices and hand them off to OpenGL
along with model space vertex data. GL will then try to offload the
world space projection transforms to the GPU.
But, I'm still not sure why this matters in respect to this plugin.
You can always run vertexes through your own transforms on the CPU if
you really want to. OpenGL neither helps nor prevents that, and
neither will this plugin.
I can remember writing a simple 3d (4x4x4) tic tac toe game. It
actually ran slower than quake3 did! Despite being much simpler in
terms of graphics and game engine. Well, it wasn't always slower.
But those circles really slowed things down. You know tic tac toe
uses circles and crosses. Enough circles and the display slowed to
a crawl.
Well, that's not too surprising if you did the typically newbie
things and drew it all in immediate mode, with way-overkill
tessellation on the circles. Also keep in mind that GL lighting will
slow you down as well, perhaps to a crawl depending on the number of
lights and hardware (Quake 3 does it's own lighting, and it's mostly
pre-computed).
We're going in circles though - take the plugin for what it is (or
don't). I'm defending Marco's work but I admit I don't have a real
need for it right now. 4 months ago may have been a different story...
Frank.
–––––––––––––––––––––––––––––––––
Open Source RB Goodies and Shareware
<http://developer.chaoticbox.com/>
<http://www.chaoticbox.com/>
–––––––––––––––––––––––––––––––––
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
|