Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Ludus

Member Since 16 Feb 2013
Offline Last Active Jul 16 2014 01:42 AM

Topics I've Started

Efficiently Handling a Large amount of Objects with Short Lifespans

24 March 2014 - 10:34 PM

I have searched this topic a number of times, but could not find satisfactory answers. My question is, what are some good ways to efficiently handle a large amount of objects with short lifespans in C++? (think bullets, spells, massive amounts of enemies that appear and disappear off screen) More specifically, what kind of container should store these objects? Should these objects be dynamically allocated and deallocated with "new" and "delete", thus making this a container of pointers to the objects? Instead of deleting objects directly from the list at the end of the objects' lifespan, should they be flagged as "dead" and be removed or replaced at a more opportune time?

I know that when using a vector there is a trick of swapping the element to be deleted with the very last element of the vector, then using pop_back to delete it, thus avoiding relocation of elements in the vector. What are some other tricks when dealing with a large number of short-lived objects?

 

The container these objects are stored in will double as a way of iterating through these objects for the purpose of updating logic, so iteration needs to be quick as well.

 

 

 

 

 


Mage's Quest

28 August 2013 - 06:36 PM

Inspired by the platformer games of the early to mid 90's, Mage's Quest is a fast-paced action platformer with an emphasis on speed-running.

Click here to view the project


Memory Management

06 June 2013 - 05:41 PM

I am setting up a simple memory management in my program and I would like some feedback.

 

During the "loading" portion of my program I use something like this to create the dynamically loaded objects:

 

new CObject(0, 0, 1);
new CObject(0, 6, 4);
new CObject(21, 0, 21);

 

As you can see, I do not assign the address of any of these objects to pointers - I just create the objects and assign their constructor values. However, the constructor of "CObject" contains this bit of code:

 

ObjectList.push_back(this);
 


This places the address of the object in ObjectList. "ObjectLIst" is a vector of pointers for CObject, and it exists within the global scope of the program. Now during the "clean-up" phase of my program I use this to delete the allocated memory:

 

  for(int i = 0;i < CObject::ObjectList.size();i++) {
        if(!CObject::ObjectList[i]) continue;

        delete CObject::ObjectList[i];
    }

 CObject::ObjectList.clear();
 

 

I should mention that CObject is always created dynamically during the "loading" phase. It is never created anywhere else in the program.

 

Is there anything wrong with handling memory in this manner? Am I overlooking any potential problems with this method?

 

 

 

Edit: Just a note for future readers - I've realized that this is bad coding practice for the following reason: an object should not manage its own memory. That is the responsibility of the memory manager.


Questions about Entity-Component Systems

06 April 2013 - 06:12 PM

I have a couple questions regarding entity-component systems. From my reading, it seems that components are to be "data only". Does this mean they should not contain any functions? Say, for instance, I have a "movement" component. This would be given to entities that are able to move, and it would contain variables such as speed, acceleration, max speed, etc. Would it not make sense to give this component the functions that deal with with collision detection and updating position?

 

Second question. This entity-component system is aimed to replace the inheritance structure of traditional OOP. Does this mean inheritance should be avoided all together when using such a system, or are there cases where it can be used to create a sort of hybrid system? I can imagine using inheritance with the components themselves (such as when some objects require different types of physics calculations).

 

Third question. In implementing an entity-component system, what does this actually do to the compiled program? As opposed to a traditional inheritance structure, does the compiled program take up more hard drive space? Does it take more processing power to run? Is there more overhead? If so for any of those, by how much?

 

Edit: Fourth question. What would warrant a project to make use of an entity-component system over a traditional inheritance structure? Is it something that should be used without exception, or is it really only beneficial for games with a large scope and with many programmers working on it?


Easter Eggs

01 April 2013 - 08:16 PM

Imagine that you're hiding an Easter egg in your game. Perhaps it's some text or an image that pops up after doing some obscure set of tasks. Whatever the case, you want this Easter egg to remain hidden for a long time. Now, you're worried that someone will discover it by going through the game's resources or even by using tools to search through and modify the game's values in the memory (or by going through the compiled program file). What kind of countermeasures would you employ in your code to ensure (as much as possible) your Easter egg would not be found by illegitimate means?

 


PARTNERS