OpenGL: needs more tools for game developers

[Daecho]

I don't know if this has been mentioned already, but I wish that OpenGL would add on more things that are very usefull for people making games. Everyone that makes games using OpenGL still have to deal with making collision detection and such common non-graphical things. Seeing as OpenGL is used mostly for games from what I've learned, it should be enhanced for game developers. Sure you can find all the things out there you need to make a game, but the fewer libraries you have, the easier it gets. Kinda like DirectX - it really sucks, but it has all the elements you need. OpenGL would gain a huge edge if it could adopt more non-graphical tools.

David Eckel
http://www.echogames.com

[john]

But... but... opengl is the open *graphics* library, not the open game library with useful toolkits and dinky utilities to make programmer's life easier. It's meant to be an abstraction over the graphics hardware: nothing more. To a certain extent it's like saying that assembly shold have more high level constructs... It's meant to be a set of mnemonics for the underlying instruction, not some BASIC wrapper for the machine...!

Sure, there are tools to help you make games. But saying that these tools _should be part of the opengl specification_ is defeating the purpose _of_ the opengl specification. I can't see SGI announcing the new IR4 graphics subsystem has inbuilt game utilities just so they can say it meets the OpenGL 2.0 spec.

[Daecho]

Yeah, I kept that in mind, I know what you mean, and I tried to think of a way around that. I know it's a graphics library, but it's used so much for games it would be neat to see opengl expand or be encorporated into a nice game SDK. The non-graphical util's wouldn't have to be incorporated into the gl standard, but be available to those who want it on the side. I see a lot of people new at opengl who are struggling to find and use other game development libraries along with opengl.

Or if that doesn't work at all, why can't the top sound companies get together and build awesome sound libraries or something. OpenGL is cool 'cause it's standards are set by multiple companies, unlike directX, and I believe that's why it's so good. Seeing as how well that worked, I don't see why it needs to be restricted to graphics. It's granted that graphics is the biggest / most important part, but I don't want to have to use awesome openGL with crappy ol' microsoft created DirectInput.

[john]

yep, I appreciate what you're suggesting. What you're after, really, is some kind of opengl *wrapper*, rather than extensions to opengl. (Although there are probably exceptions to this, where core functionality within opengl would find a place with games and not the scientific/business community).
Wrappers already exist: OpenInventor and CrystalSpace, for example.

cheers,
John

[This message has been edited by john (edited 08-20-2000).]

[Bob]

But... What if we DO implement this, what might happen then? If the collision detection algorithm called A was implemented, then quite a few would complain that B was not implemented. And if B was implemented too, then a few would complain C wasn't implemented. So far, only well accepted algorithms/functions has been implemented (like gouraud shading, lightning, texturemapping and stuff like that), because there is (mainly) only one way to perform it, and it's the way OpenGL - aswell as most API's - does it.

And to what john said, about he can't see SGI implementing gameroutines just to be able to call it 2.0. Well, I can't see it either. A way around this, which I have seen in other threads, might be to make a game-gl version. But that's no good solotion, in my oppinion. Because, then the openness will be slightly gone, and the two API's might not even work well together.

There's a thread about shadows, which says about the same as said here.

[Ludo]

Hi

About the collisions, OpenGL have a SELECTION mode it seems...

[Bob]

Collision is when two or more objects intersect in worldspace. The select feature is to determine what objects are drawn in a certain portion of the screen. Two completely different things.

[Ludo]

Bob> No. This is the same calculation (for 2 volumes ): take the first volume as your frustum (orthogonal), and the second as is.

[Ludo]

Bob> in worldspace or not, who care?

[Ludo]

Bob> JUST FOR BOUNDING BOXES...of course