Difference between revisions of "Time"
MasterCassim (talk | contribs) m (Insert == Captions) |
|||
Line 1: | Line 1: | ||
− | + | == Ticks Per Second vs Game Speed == | |
The scripting engine runs with a certain number of ticks per second depending on the current game speed setting. To calculate this, you can simply take the base number of updates per second in normal speed (32) and multiply it by the current game speed modifier (retrievable by using the GameGetSpeed() native). Yes, it actually does use non-integer values for the number of updates per second, so do not round to the nearest integer or your timing calculations will become inaccurate. | The scripting engine runs with a certain number of ticks per second depending on the current game speed setting. To calculate this, you can simply take the base number of updates per second in normal speed (32) and multiply it by the current game speed modifier (retrievable by using the GameGetSpeed() native). Yes, it actually does use non-integer values for the number of updates per second, so do not round to the nearest integer or your timing calculations will become inaccurate. | ||
Line 9: | Line 9: | ||
Tick Duration | ~0.052083, 0.0390625, 0.03125, ~0.0260416, ~0.0223214 | Tick Duration | ~0.052083, 0.0390625, 0.03125, ~0.0260416, ~0.0223214 | ||
− | + | == Wait 0 == | |
Now, about the Wait function. Using either Wait(0, c_timeReal) or Wait(0, c_timeGame) has precisely the same effect: the function will resume during the very next tick. This means that a 0.0 Wait loop will iterate during every single tick of the scripting engine. ANY other value than 0.0 will cause the next tick to be skipped. The number of iterations per second will be decided by your current game speed as shown in the chart above. The actual duration of a Wait 0.0 is equal to the Tick Duration on the chart above. In other words, the speed at which 0.0 loops iterate scales directly with the adjustment of the game speed. | Now, about the Wait function. Using either Wait(0, c_timeReal) or Wait(0, c_timeGame) has precisely the same effect: the function will resume during the very next tick. This means that a 0.0 Wait loop will iterate during every single tick of the scripting engine. ANY other value than 0.0 will cause the next tick to be skipped. The number of iterations per second will be decided by your current game speed as shown in the chart above. The actual duration of a Wait 0.0 is equal to the Tick Duration on the chart above. In other words, the speed at which 0.0 loops iterate scales directly with the adjustment of the game speed. | ||
− | + | == Timers and Wait >0 == | |
Timers and the Wait function when used with non-0 values both share something in common, and that is that they are incapable of expiring on every tick of the scripting engine. They will only expire every OTHER tick. This means that a Wait 0.00001 loop will expire half as quickly as a Wait 0 loop! The minimal expiration time of timers and non-0 wait loops for each game speed is listed in the chart below. If your wait or timer duration isn't a multiple of those values, it may cause a rather large amount of inaccuracy which has the potential to compound in itself if you repeatedly restart the wait or timer. | Timers and the Wait function when used with non-0 values both share something in common, and that is that they are incapable of expiring on every tick of the scripting engine. They will only expire every OTHER tick. This means that a Wait 0.00001 loop will expire half as quickly as a Wait 0 loop! The minimal expiration time of timers and non-0 wait loops for each game speed is listed in the chart below. If your wait or timer duration isn't a multiple of those values, it may cause a rather large amount of inaccuracy which has the potential to compound in itself if you repeatedly restart the wait or timer. | ||
Line 22: | Line 22: | ||
Minimal Expiration Time | ~0.10526, 0.078125, 0.0625, ~0.052083, ~0.04464 | Minimal Expiration Time | ~0.10526, 0.078125, 0.0625, ~0.052083, ~0.04464 | ||
− | + | == Real Time == | |
Here's the first thing you should know: StarCraft 2's perception of real time does not match match your clock's perception of real time. The game engine is meant to pretend that time is not elapsing during any lag or slowdown. If you watch SC2's real time (viewable in the debug menu with an option), it will never progress quite as quickly as a clock, and the more stuff that's going on in your map, the larger the gap will become. If you have large amounts of slowdown, SC2 may believe that time is passing much more slowly than it really is. Also, time does not advance while a player is lagging. During optimal conditions, SC2's real time may fall behind a clock by about 1 second each minute. | Here's the first thing you should know: StarCraft 2's perception of real time does not match match your clock's perception of real time. The game engine is meant to pretend that time is not elapsing during any lag or slowdown. If you watch SC2's real time (viewable in the debug menu with an option), it will never progress quite as quickly as a clock, and the more stuff that's going on in your map, the larger the gap will become. If you have large amounts of slowdown, SC2 may believe that time is passing much more slowly than it really is. Also, time does not advance while a player is lagging. During optimal conditions, SC2's real time may fall behind a clock by about 1 second each minute. | ||
− | + | == Tracking Real Time == | |
Starcraft 2 lacks a native to return the current amount of elapsed real time. You can use this simple function to do so: | Starcraft 2 lacks a native to return the current amount of elapsed real time. You can use this simple function to do so: | ||
Line 34: | Line 34: | ||
} | } | ||
− | + | == Game Time == | |
It is possible to view the current elapsed game time by using the native GameGetMissionTime(). However, you can expect 3 strange behaviors out of this native: first, it only updates the time it will return on every other tick of the scripting engine. Second, its time output is directly scaled by the game speed modifier, i.e. in fastest mode, time will pass 40% more quickly. Third, the passage of time will also be influenced by SC2's perception of real time, as described above. | It is possible to view the current elapsed game time by using the native GameGetMissionTime(). However, you can expect 3 strange behaviors out of this native: first, it only updates the time it will return on every other tick of the scripting engine. Second, its time output is directly scaled by the game speed modifier, i.e. in fastest mode, time will pass 40% more quickly. Third, the passage of time will also be influenced by SC2's perception of real time, as described above. | ||
− | + | == Real Time vs Game Time == | |
With Waits and Timers, you have the option to use either c_realTime or c_gameTime. As we mentioned before, this distinction has no effect on 0.0 wait timers. It is simply up to you whether you would prefer to have your waits and timers speed up or slow down based on the game speed modifier, or whether you would like for them to expire in the same amount of real time regardless of game speed. There should be different times that each is appropriate. | With Waits and Timers, you have the option to use either c_realTime or c_gameTime. As we mentioned before, this distinction has no effect on 0.0 wait timers. It is simply up to you whether you would prefer to have your waits and timers speed up or slow down based on the game speed modifier, or whether you would like for them to expire in the same amount of real time regardless of game speed. There should be different times that each is appropriate. | ||
− | + | == Credits == | |
[http://www.sc2c.org/showthread.php?t=169 http://www.sc2c.org/showthread.php?t=169] Used without permission, because it doesn't look like he posts there anymore. Going to ask him on thehelper.net though if it's OK with him. | [http://www.sc2c.org/showthread.php?t=169 http://www.sc2c.org/showthread.php?t=169] Used without permission, because it doesn't look like he posts there anymore. Going to ask him on thehelper.net though if it's OK with him. | ||
[[Category:StarCraft II]][[Category:Reference]][[Category:Triggers]] | [[Category:StarCraft II]][[Category:Reference]][[Category:Triggers]] |
Revision as of 19:51, 25 November 2010
Ticks Per Second vs Game Speed
The scripting engine runs with a certain number of ticks per second depending on the current game speed setting. To calculate this, you can simply take the base number of updates per second in normal speed (32) and multiply it by the current game speed modifier (retrievable by using the GameGetSpeed() native). Yes, it actually does use non-integer values for the number of updates per second, so do not round to the nearest integer or your timing calculations will become inaccurate.
Code:
Game Speed | Slower, Slow, Normal, Fast, Faster Speed Modifier | 0.6, 0.8, 1.0, 1.2, 1.4 Ticks Per Second | 19.2, 25.6, 32, 38.4, 44.8 Tick Duration | ~0.052083, 0.0390625, 0.03125, ~0.0260416, ~0.0223214
Wait 0
Now, about the Wait function. Using either Wait(0, c_timeReal) or Wait(0, c_timeGame) has precisely the same effect: the function will resume during the very next tick. This means that a 0.0 Wait loop will iterate during every single tick of the scripting engine. ANY other value than 0.0 will cause the next tick to be skipped. The number of iterations per second will be decided by your current game speed as shown in the chart above. The actual duration of a Wait 0.0 is equal to the Tick Duration on the chart above. In other words, the speed at which 0.0 loops iterate scales directly with the adjustment of the game speed.
Timers and Wait >0
Timers and the Wait function when used with non-0 values both share something in common, and that is that they are incapable of expiring on every tick of the scripting engine. They will only expire every OTHER tick. This means that a Wait 0.00001 loop will expire half as quickly as a Wait 0 loop! The minimal expiration time of timers and non-0 wait loops for each game speed is listed in the chart below. If your wait or timer duration isn't a multiple of those values, it may cause a rather large amount of inaccuracy which has the potential to compound in itself if you repeatedly restart the wait or timer.
Code:
Game Speed | Slower, Slow, Normal, Fast, Faster Maximum Expirations Per Second | 9.5, 12.8, 16, 19.2, 22.4 Minimal Expiration Time | ~0.10526, 0.078125, 0.0625, ~0.052083, ~0.04464
Real Time
Here's the first thing you should know: StarCraft 2's perception of real time does not match match your clock's perception of real time. The game engine is meant to pretend that time is not elapsing during any lag or slowdown. If you watch SC2's real time (viewable in the debug menu with an option), it will never progress quite as quickly as a clock, and the more stuff that's going on in your map, the larger the gap will become. If you have large amounts of slowdown, SC2 may believe that time is passing much more slowly than it really is. Also, time does not advance while a player is lagging. During optimal conditions, SC2's real time may fall behind a clock by about 1 second each minute.
Tracking Real Time
Starcraft 2 lacks a native to return the current amount of elapsed real time. You can use this simple function to do so: Code:
fixed GameGetElapsedTime () { return GameGetMissionTime() / GameGetSpeed() ; }
Game Time
It is possible to view the current elapsed game time by using the native GameGetMissionTime(). However, you can expect 3 strange behaviors out of this native: first, it only updates the time it will return on every other tick of the scripting engine. Second, its time output is directly scaled by the game speed modifier, i.e. in fastest mode, time will pass 40% more quickly. Third, the passage of time will also be influenced by SC2's perception of real time, as described above.
Real Time vs Game Time
With Waits and Timers, you have the option to use either c_realTime or c_gameTime. As we mentioned before, this distinction has no effect on 0.0 wait timers. It is simply up to you whether you would prefer to have your waits and timers speed up or slow down based on the game speed modifier, or whether you would like for them to expire in the same amount of real time regardless of game speed. There should be different times that each is appropriate.
Credits
http://www.sc2c.org/showthread.php?t=169 Used without permission, because it doesn't look like he posts there anymore. Going to ask him on thehelper.net though if it's OK with him.