Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / Best Practices for Object Management with C++,

Author
Message
TechLord
21
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 27th Jun 2009 15:56
Hi All!

I'm having fun getting into C++, DGDK, MSVC++. What I'm looking for is input on best pratices for managing a group of objects, items, etc. There are so many ways one can go about it with STL Containers {vectors,list,deques,stacks,maps}, Arrays, Pointers, etc. Any and all ideas are welcomed. thanks in advance.

Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 27th Jun 2009 16:14
It depends entirely on when you want to access them and how.

Diggsey
18
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 27th Jun 2009 16:16
Each STL container has a certain purpose, for example:
If you are going to be adding and removing lots of items at random places, but you won't be doing much random access into the container, then a list is ideal.

However, if you are only adding/removing items occasionally, but need easy access to any element, a vector might be best.

If you only need to add or remove items from one end of the container, use a stack.

If you need to add and remove from both ends, but not in the middle, use a deque.

If you need to add items on one end and remove from the other, use a queue.

If you don't need to resize the container, and you know the size at compile time, use an array.

If you don't need to resize much, but you don't know the size at compile time, use a dynamically allocated array.

If you need to access items by a key, use a map (if you want to be able to use multiple keys with the same value, use a multi_map, and if you want to increase access speed, use a hash_map)

Quite simple really

Here is a page explaining the speed of various operations for the STL classes:
http://www.cplusplus.com/reference/stl/

IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 28th Jun 2009 20:19
My initial advise to you would be to use a boost ptr_vector for general polymorphic ownership of objects.

Beyond that, you need specific use cases to give specific advice.

TechLord
21
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 27th Jul 2009 09:43 Edited at: 28th Jul 2009 00:41
Quote: "boost ptr_vector for general polymorphic ownership of objects."

Sorry Ian, but, I'm new to the language and barely understand basic OOP polymorphism, if that - lol.

I have other questions about general Object management in C++ using DGDK. I'm basically looking for opinions here. Like DBP, DGDK uses integer `IDs` to reference individual 3D Objects, Lights, Images, Files, Memblocks, Vectors, etc. I realize that there many other options to manage objects, but, I chose to use a integer ID system for managing my own objects.

My system relies on arrays and I use two techniques to automate ID assignment. For `Permanent` objects (objects that are initialized once and exist until the App is terminated), I use a integer and simply increment it when a new object is initialized. With `Temporary` objects (objects that are repeatedly intialized/de-initialize during run-time), I use a stack to manage IDs.

I'm curious if anyone else is using a integer IDs to manager their objects. If you do or don't lets discuss. Thanks in advance for your participation.

IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 27th Jul 2009 16:56 Edited at: 27th Jul 2009 20:39
Unfortunately, you need ID's for a lot of things you do with Objects, so that's pretty much how you have to do it.

I've also used a stack in the past to allow reuse of ID's - it's the obvious way to do it, but it has a few drawbacks. You can't use a single stack if you need an object ID from a range for example.

I have a few thoughts on other methods, but nothing I could really post here yet.

Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 27th Jul 2009 19:42
When I created my Sprite class I used a static class integer as a counter. My inclination was to increment the counter when a new sprite was created and decrement the counter in the destructor. However, if a sprite were included in a vector then it would be possible to call a destructor out of LIFO.

I've thought of using an ID factory to spit up a number but even that could get complicated and chew up CPU time depending on the need. In general it's not an easy thing to manage unless you have a predefined number of objects to generate.

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 27th Jul 2009 20:49
I have 2 classes I use in my library for pulling unique indices, though I think I only use them for my particle system. For other things I just store instances in a vector where finding a unique ID isn't important.

h


cpp


I think I prefixed the variables because they were originally part of one of my particle classes and I prefixed EffectCounter as to avoid any potential clashes, but I guess that's redundant now and I'd rather not recompile everything.

Zuka
16
Years of Service
User Offline
Joined: 21st Apr 2008
Location: They locked me in the insane asylum.
Posted: 28th Jul 2009 15:58


Simple as that... not sure how efficient it is, but it works great.

Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 28th Jul 2009 19:20
The potential inefficiency has kept me from using that approach even though I typcially don't use a large number of sprites. And even then they're usually declared all at one time and before the game begins so it doesn't impact the game run time. I just have this compulsion to keep the numbers compact and clean but I guess the code I'd write around that would be just as time consuming.

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
TechLord
21
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 29th Jul 2009 09:04
For me, I relate using integer IDs for objects to using integer IDs for Primary Keys in DB Tables. In fact, I mimic techniques I've used in writting Relational DB Tables in my objects design.

From my experience it is very rare to actually `delete` a record which makes using a unique autoincrementing index Logical. However, in a game, many objects are constantly initialized/de-initialized, so why keep incrementing the ID index when you can recycle them and that's where a stack comes in handy. Particle systems are a good example of objects that are constantly init/de-init during runtime.

Quote: "I've also used a stack in the past to allow reuse of ID's - it's the obvious way to do it, but it has a few drawbacks. You can't use a single stack if you need an object ID from a range for example."


I use a ID stack to automate recycling and assignment of IDs and any other additional containers: list, vectors, etc to manage special sets of IDs (ie range).

Login to post a reply

Server time is: 2024-10-01 08:39:18
Your offset time is: 2024-10-01 08:39:18