Aug 5 2015, 10:01 pm
In response to Bravo1
|
|
Doohl
 |
You should be storing unused particle effects into some kind of queue for use later. Ideally, you should never have to destruct a single particle - and after a point - never construct one either.
|
Bravo1 wrote:
Mmmm.... I guess this means me calling del dozens of times per second for all my particle effects is a bad thing? It's not good, but technically when del() is used to forcibly remove all old references, as soon as there are none left it will bail out. If the object's only reference is pretty much just that it exists on the map, that shouldn't be a problem. But it's always far better not to rely on del() working out so well, and instead soft-deleting the object whenever possible. | |
The real trouble is when it actually has to inspect lists. That's where worst-case deletion behavior starts to occur.
| |
Doohl wrote:
You should be storing unused particle effects into some kind of queue for use later. Ideally, you should never have to destruct a single particle - and after a point - never construct one either. I was considering doing that depending on how it would work. The design I had in mind was a procedure that would handle the particles. When called it would pull a particle from a pool of available particles. If the pool is empty it'll create a new particle effect. Afterward it assigns all the necessary variables and places it on the map accordingly, then tells it to run through it's little process. At this point the particle itself would do it's business and, once finished, it'll wipe it's own variables, add itself to the pool and essentially just wait till that handler procedure pulls it out for another run. That's my general idea of how it'd work, but I'm not sure if that'd be the best way to go about it. | |
Wiping the vars is probably unnecessary if they're all going to be overwritten when the object is reused.
| |
Very true. I took the time to code it and although I did have a bit of trouble, it's working fine.
Turns out I was able to create about 500 objects tops at any given time, and I was averaging 20-40 effects being created and deleted per second. Now, I'm only creating them initially the first time around and then they stick around in the game and just get recycled. So that's nice. I'm considering setting up another recycling system for the projectiles in the game, as they have a very similar setup to the effects. I didn't realize the multiple calls of new and del was so bad until I checked the difference in cpu between both instances. Lots of processing time shaved off. | |
Most projects I work on now build a recycler into the core, in my current project it recycles just about any object that I use over and over. Projectiles, spell effects, etc...
As for resetting the variables, it's not needed but it does help if you accidentally forget to set one of them somewhere and end up with an old value popping up randomly. | |
RAM is a non-issue. CPU is THE bottleneck.
Adding extra instructions to conserve RAM just leads to a reduced impact on an actual problem that instance recyclers are actually trying to solve. | |