Making TPT faster
-
I suggest that powder toy have an "element count". I'm no programming expert but I think powder toy is getting slow because it has to check for all the elements. The element count would be a an array somewhat like this:
bool element_count[PT_NUMBER]
Every few frames, working along side the elements "if()" so it doesn't have to check the screen twice, the program would check for what elements are there, it would keep a list of those in "element_count". Therefore keeping the amount of elements to search for down. In case an unlisted element appears, an element that is not of one stated present in "element_count" it will search the rest. In most saves the element types do not appear and disappear too quickly so it might speed powder toy up a bit.
As I said I'm no programming expert, so I'm not sure if this will work. -
The idea sounds good. Lets hope it works.
-
@devast8a (View Post)
Instead of cycling through to Particlemap twice (once for particle logic, once for drawing) you could make a list (an array with the size XRES*YRES) that stores the ID of the existing particles. You would also have to make an integer or so that stores the current size of that list. So once you start drawing you don't loop through particlemap but the list you created. This way you'd save time that it wasted due to not existing particles in the particlemap.
A not-too-bad idea. -
The particle map is so that you can find which particle is at a certain position. Element interactions loop through positions in the pmap within a certain radius (mostly 1 or 2 pixels in all directions), checking whether each position contains an element that it interacts with.
@JoJoBond (View Post)
I thought it looped through parts for drawing, not pmap?
In fact, I believe it iterates through the parts array three times per frame (update pmap, particle physics, draw particles). I experimented a little while ago with finding the last occupied position in the parts array and limiting the update_particles_i loop to that, but I forget whether it made much of a difference....
Storing the ID of existing particles might be worth a try. -
@Ace (View Post)
That actually sounds like it could work. Great idea. Couldn't be too hard to implement. -
@jacksonmj (View Post)
One more thing about this:
If there is an particle that is created within the particle logic it will not be in that certain list. So you'll have to add it when it's created (I think there is a function that creates particles 'create_part' or so...). You'd also have to make sure that the loop reaches the newly created particles. BUT depending on what particle is created this can have odd effects (both, even you add them to the list and when you don't add them). -
@JoJoBond (View Post)
Yeah. But I don't think anything would break if the list is only updated once per frame, meaning newly created particles don't get updated until the next frame. Updating the list whenever particles are created or deleted could get messy.
Under the current system they aren't always updated on the same frame as creation anyway - since the ID of a new particle is not guaranteed to be greater than the current particle. -
use less elements.
