Datastructures in C++ for games
Author
Hello,
I've been programming games and normal applications in C++ for quite some time now and I was wondering what would be the best way to represent certain datastructures specific to games?
I'm talking, in particular, of datastructures that hold vertices, indices, room data etc...
Most of the online articles and C++ books I've read say I should always use STL types like std::vector in preference to classic arrays. But it seems a bit overkill and weird (and maybe slow) to use such methods for an application in which every frame counts. What's your opinion on this matter?
Jeroen
Well in all honesty that depends on what your useing say for a 3d game instead of useing vectors you can just use .. Say if you were useing Direct 3D .. a matrix to store a rooms data and just transform that into the display matrix now i don't know alot about Direct 3D but as far as im aware fo thats a good way to go if you can understand it ;p..
It may help other pepole trying to answer your question if you say what your trying to acomplish and what language and what lib's you are useing
Regards jouei.
It may help other pepole trying to answer your question if you say what your trying to acomplish and what language and what lib's you are useing
Regards jouei.
Quote:Original post by godmodder
What's your opinion on this matter?
Seems a bit half-baked. In what way do you think std::vector is overkill for a particular situation? In what way do you think it's weird for a particular situation? In what way do you think it's slow for a particular situation?
Author
Quote:In what way do you think std::vector is overkill for a particular situation? In what way do you think it's weird for a particular situation? In what way do you think it's slow for a particular situation?
Well for example, all the API functions accept the vertex buffer as an array. The vertex buffer will not change size frequently (not in my app anyway). I mean, why use a vector or any other container for it? Why not just dump it all in a big array? All the sources I've read from suggest I should always favor the STL containers above classic arrays, but it just seems more of a hassle for these simple things.
Jeroen
The basic reason for using a vector over manually managing an array is that using a vector makes it easier to avoid things like memory leaks, double deletion and other similar kinds of problems.
a std::vector is, at it's root, a big array (all elements are guaranteed to be contiguous in memory). so you can use it happy-dappy in the api calls and get all the benefits of STL protections
-me
-me
Author
If I wrapped the array around in a RAII class, wouldn't that essentially have the same effect?
Now that I think of it, another problem is multidimensional arrays. Say for example I have a room structure which contains several tiles. The room has a width, height and depth, so a multidimensional array seems very intuitive here. How would I go about and achieve the same easy method with a std::vector and why would I even want to do that?
Edit: Palidine, I did not know that. I guess that removes one of the restrictions. However, are you SURE they are always contiguous in memory?
Jeroen
Now that I think of it, another problem is multidimensional arrays. Say for example I have a room structure which contains several tiles. The room has a width, height and depth, so a multidimensional array seems very intuitive here. How would I go about and achieve the same easy method with a std::vector and why would I even want to do that?
Edit: Palidine, I did not know that. I guess that removes one of the restrictions. However, are you SURE they are always contiguous in memory?
Jeroen
Contiguous storage in a vector is guaranteed in section 23.2.4 paragraph 1 of ISO/IEC 14882:2003.
Quote:If I wrapped the array around in a RAII class, wouldn't that essentially have the same effect?
Yeah, so why reinvent the wheel?
Quote:Now that I think of it, another problem is multidimensional arrays. Say for example I have a room structure which contains several tiles. The room has a width, height and depth, so a multidimensional array seems very intuitive here. How would I go about and achieve the same easy method with a std::vector
std::vector< std::vector< int> > theRoom;
theRoom[x][y] = blah;
And if you don't like the template notation, just typedef it:
typedef std::vector< std::vector< int> > Room;
Room theRoom;
theRoom[x][y] = blah;
Quote:and why would I even want to do that?
As mentioned before, because it is safer than using a dynamic array built from a raw pointer.
Quote:Edit: Palidine, I did not know that. I guess that removes one of the restrictions. However, are you SURE they are always contiguous in memory?
According to the standard:
Quote:"The elements of a vector are stored contiguously, meaning that if v is a vector<T, Allocator> where T is some type other than bool, then it obeys the identity &v[n] == &v[0] + n for all 0 <= n < v.size()."
In other words, yes.
Quote:Original post by godmodder
If I wrapped the array around in a RAII class, wouldn't that essentially have the same effect?
More or less, but you'd have to write it yourself, and you'd lose the benefit of the existing research done into std::vector's implementation. In particular, the way std::vectors resize is clever but not especially intuitive, and there is also generally some tricky stuff done with placement new to avoid needless initialization of unused memory space.
Quote:Now that I think of it, another problem is multidimensional arrays. Say for example I have a room structure which contains several tiles. The room has a width, height and depth, so a multidimensional array seems very intuitive here. How would I go about and achieve the same easy method with a std::vector and why would I even want to do that?
You wouldn't (unless you're a masochist); you'd use boost::multi_array, which provides that kind of element access into a std::vector-like memory allocation. You'd want it because you could defer specifying the array dimensions to runtime, and also resize (and even "reshape") the array.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
