Objects in GL

[M/\dm/\n]

I would like to make some sort of object support in my game engine. So it would be nice if I could define every object from vertex+bounding box data & maybe even some physics stuff. Only thing I can imagine right now is classes, but I still can't see how to implement that till the end. Maybe someone have tried that allready and could give me advice. The current sitution is that I must calculate physical&collision data & then draw geometry. But they aren't connected as one data stream. BTW, clases are prety costly, arn't they?

[dheitbri]

I usualy use dynamic arrays of structs, there pretty light weight.

[Deiussum]

Classes aren't that costly unless you mis-use them.

[fringe]

Hi,

I often hear alot about using classes being expensive and alot of people defend them saying that as long as you use them correctly it will still be fast. Could you expand more on what you have to do to a class/program to make sure that they run quickly. (mention things even if you think they are too basic I am a self taught C++ person so my knowledge is patchy)

Cheers, fringe

[MickeyMouse]

I did a little benchmark recently that showed me classes are _exactly_ as fast as structures (something a short time ago I was refusing in advanced forum, lol! ).
You shouldn't be afraid to use classes even for smallest beings like vectors or triangles. Sizes of class and struct with same arguments are eqaul, not what some may think (I did too) they require some extra bytes.

[Deiussum]

I tend to use structs for things like vectors, vertices, color, etc. Usually I use classes for larger entities such as objects consisting of triangle strips, lists of objects, world data, etc.

Some things that you can do to keep classes performing well include:

- Use inline functions for simple Get/Set functions.
- Don't rely too heavily on overloading operators. There can be some extra overhead involved in this. It's not something I would say avoid completely, but just be aware of where the overhead lies when you do use them. (Extra copying, function call overhead if not inline, etc.)
- Where possible, provide constructors that can take in values to initialize the class.

Anyway, I'm sure there are more things that I'm not thinking of at the moment, but I think the first couple points above are a couple of the biggest areas you can look at when keeping classes perfoming well.

Just like in C, though, the absolute BEST way to keep your code running nicely is to use the right algorithm. If you use an algorithm that is O(n^3) for something that only requires an algorithm that is O(n), it doesn't matter what language you use, you're going to get less than ideal results.