Advanced "Timer" Optimization
Hey all,
I've been putting a lot of thought into timers while working on my new game, Simon and Mojo, and I found something that I want to ask about.
Has anyone replaced an "every" timer with a rule, and if so did it help your performance?
Here's the rule I came up with and it is functional when using whole numbers:
Create an integer attribute called 0 and leave it at 0 (this will never change)
Then whenever you want to have an "every" timer used at whole second intervals you will input this rule:
Rule:
...When attribute game.0 = self.time%3
......Change attribute a to a+1
In this example the "3" after the modulo "%" is the seconds you want in between each change of attribute, and the "a to a+1" was just some gibberish to give an example of an attribute being changed.
What's going on here is that as self.time changes, whenever it becomes an exact multiple of 3, the rule's conditions are valid.
This process removes a timer from being used, which seems like it would be good for performance, but is it really making a difference? It's hard to tell without seeing the code used for timers, but I'm curious to know if anyone has tried this out on a large scale before and can tell me what their experience has been.
I'll be testing this more thoroughly in the near future.
Any input would be very much appreciated.
:^)
I've been putting a lot of thought into timers while working on my new game, Simon and Mojo, and I found something that I want to ask about.
Has anyone replaced an "every" timer with a rule, and if so did it help your performance?
Here's the rule I came up with and it is functional when using whole numbers:
Create an integer attribute called 0 and leave it at 0 (this will never change)
Then whenever you want to have an "every" timer used at whole second intervals you will input this rule:
Rule:
...When attribute game.0 = self.time%3
......Change attribute a to a+1
In this example the "3" after the modulo "%" is the seconds you want in between each change of attribute, and the "a to a+1" was just some gibberish to give an example of an attribute being changed.
What's going on here is that as self.time changes, whenever it becomes an exact multiple of 3, the rule's conditions are valid.
This process removes a timer from being used, which seems like it would be good for performance, but is it really making a difference? It's hard to tell without seeing the code used for timers, but I'm curious to know if anyone has tried this out on a large scale before and can tell me what their experience has been.
I'll be testing this more thoroughly in the near future.
Any input would be very much appreciated.
:^)
Comments
QS
Dr. Sam Beckett never returned home...
Twitter: https://twitter.com/Quantum_Sheep
Web: https://quantumsheep.itch.io
elapsed time = elapsed time + system time - previous time;
previous time = system time;
if elapsed time => desired timing
{elapsed time = elapsed time - desired timing;
do whats inside the timer;}
While not quite timer free it did show a remarkable pick up with a lack of them.
Kipper