Is it acceptable to call a destructor?
Wait, you move them "very far away". That is some really bad resource management. What you should do is stop drawing it altogether and delete all of it's member variables. I know there's some way to dot his without using new and delete, however I can't put my finger on it.
Author
I do stop drawing them altogether. I make it so the program doesn't access them anymore. The objects still exist, but nothing about them is accessed.
Yes, but it doesn't matter if you don't draw them or access them, you're still using the R.A.M. required for them. Resource Management, although in this case not vital (Because it's a small game) is very important. What's the point in having them there if you're not going to use them? There isn't one. You need to delete the memory to free up space for other programs / more variables / bigger programs.
Depending on the game, it may actually be more efficient to set a kill flag and ignore dead objects than to frequently new/delete objects.
Depending on the game, it may actually be more efficient to set a kill flag and ignore dead objects than to frequently new/delete objects.
true, but that should be an optimization that comes AFTER the new/delete has been proven as the application bottleneck. An application should use the right data structure for the problem that is trying to solve, and then, only if necessary, implement an optimized version hiding that optimization away from the rest of the application.
The possibility that a game will need frequent new/delete is very low.. it usually only applies to particles and bullets (which are usually designed with memory pools straight away for this very reason) .
99% of the time, this is a premature optimization that will only bite you back later in the dev process by making code more complex to reason about ( I always tell to the guys working with me, your code makes sense to you NOW, how much sense will it make in 2 months?) and, using dead flags, hide poor data handling until it's too late to fix it.
...
99% of the time, this is a premature optimization that will only bite you back later in the dev process by making code more complex to reason about ( I always tell to the guys working with me, your code makes sense to you NOW, how much sense will it make in 2 months?) and, using dead flags, hide poor data handling until it's too late to fix it.
That's why every project should have documentation: generated from code manuals, design doc, defined code convention, architecture doc and few other. This is programming too.
Author
The enemies only have a coordinate position, an unsigned short timer variable, a facing direction, and a bunch of functions that can move it around using random number generation. There is no graphics handling to take care of with these objects. You can think of them as practically invisible.
So are you saying that deleting these objects would be better for every time they intersect with my projectile? Or should I check out my CPU Usage every time they're deleted, and compare that against just shoving them off to the side until later, or what?
What do you think of a similar way of handling the player's projectile object? My player object has a projectile object that merely pops out of existence at the end of its run, and the player always has exactly one.
So are you saying that deleting these objects would be better for every time they intersect with my projectile? Or should I check out my CPU Usage every time they're deleted, and compare that against just shoving them off to the side until later, or what?
What do you think of a similar way of handling the player's projectile object? My player object has a projectile object that merely pops out of existence at the end of its run, and the player always has exactly one.
So are you saying that deleting these objects would be better for every time they intersect with my projectile? Or should I check out my CPU Usage every time they're deleted, and compare that against just shoving them off to the side until later, or what?
i think you should do the thing that is mapping better to the world you are trying to simulate and that results in the cleanest and (possibly) shortest code.
This is simply a vector of Stuff* or, shared_ptr<Stuff> ... add and remove objects in a standard C++ way. Because when things die, they are not part of the "living things set" (your vector) and they are destroyed.. dead people are gone, they don't wear a hat saying "I'm dead" ;)
Get the game to a prototype stage and then evaluate what parts of the code need special attention.
And, honestly, since I don't think you're working on the new Crysis, it's VERY unlikely you'll find any bottleneck in the C++ standard library.
Author
Ah, I hadn't considered a vector. Now that I look through the thread again they were mentioned once or twice.
Also, it's a small game, but I want to learn more about structure and efficiency. Even if it's small, I want it to be freakishly efficient.
Also, it's a small game, but I want to learn more about structure and efficiency. Even if it's small, I want it to be freakishly efficient.
Even if it's small, I want it to be freakishly efficient.
If you are obsessive about this kind of thing, I suggest you try to fight the impulse. If you can't, your psychiatrist might have some pills for you.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
