On 16 Dec 2005, at 12:17, Theodore H. Smith wrote:
On 16 Dec 2005, at 06:18, Frank Condello wrote:
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.
I didn't say it limited anyone. I just said it'll be good for
people making demos or very simple games (like the very simple game
I made.)
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...
I probably did some newbie things but somethings I did based upon
reading from other people's suggestions. I had to turn the circles
into triangles eventually :) Well it did form a complete loop
anyhow so it's circle-like. Even the "triangle loop" could bog down
the drawing with enough triangles on screen. I only had a 4x4x4
cube, so there was only a maximum of 64 spaces anyhow. I made heavy
use of transparencies, though. This was because with a 4x4x4 cube,
it was very handy to be able to see "inside" the cube and through
the pieces on the board.
I'd like to see a nice OpenGL plugin that allowed for good games or
other 3D apps (visualisation of biological data perhaps), could
keep it's speed up compared with modern games, had a simple
structure and was extensible so that you could play around with
it's internals even if you eventually found that the default
settings were usually the best to use. Having collision detection,
kinesematics (or whatever it's called it's when one object is moved
relative to another), animated textures, bollards (for the animated
textures), etc etc.
Something like that would really be nice.
Oh yeah now I remember, in addition to all of that some kind of depth
sorting is necessary. Depth sorting is not necessary for opaque
elements, but it is necessary for transparent elements. I had to
write a special depth sorter myself in RB that used a form of
quicksort that wouldn't swap equivalent items. The standard quicksort
algorithm will actually swap equivalent items, making each frame
flicker horribly if two elements have the same depth from the screen.
Really it quickly became so much work to do all this 3d stuff, even a
very simple game like "3d tic tac toe", that I knew it wasn't worth
it unless you have a proper thorough understanding of OpenGL and game/
demo making by an OpenGL master or were willing to become one. Then
write fast and powerful framework that makes coding nice and simple
for the developer. Someone has to make it easy for the rest of us :)
_______________________________________________
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>
|