0.03 clock?

[aple]

What exactly is the reason for this? This simple test proves the game can run faster.

• Untitled Trigger 001
  • Events
    • Time - Every 0.01 seconds of game time
  • Conditions
  • Actions
    • Set testvar = (testvar + 1)

• Untitled Trigger 002
  • Events
    • Time - Elapsed game time is 1.00 seconds
  • Conditions
  • Actions
    • Trigger - Turn off Untitled Trigger 001 <gen>
    • Game - Display to (All players) the text: (String(testvar))

Results in testvar reaching 100, which is one execution every 10ms. @ 0.02 this becomes 50 or one every 20ms, and 0.03 becomes 33 which is one every ~30.30 ms. @ 0.00 makes the game runs as fast as the game (or maybe the machine) can handle, and on my system that caps out at 10,002 executions per second or one every ~0.099 ms. These are consistent results, every test for each of these numbers resulted in the exact-same number. All of these calculations being in game time seconds, as I'm not really sure what the conversion is to real-time seconds.

So it doesn't seem like the reason is the game can't run faster, unless I'm missing something. What else could it be?

 

[DracoL1ch]

you simply shouldn't use anything less than 0.02, there's no point, as wc3 operates everything within its own frames. can't imagine what do you want to do exactly from GUI level, but anyway - game cannot use lesser frequency

 

[aple]

Yes, but there appears to be significantly more logical frames per second than it appears most people have thought. More proof:

• Untitled Trigger 001
  • Events
    • Time - Every 0.01 seconds of game time
  • Conditions
  • Actions
    • Set testvar = (testvar + 1)
    • Unit - Create 1 Footman for Player 1 (Red) at (Center of (Playable map area)) facing Default building facing degrees
    • Unit Group - Pick every unit in (Units of type Footman) and do (Actions)
      • Loop - Actions
        • Unit Group - Add (Picked unit) to footman

• Untitled Trigger 002
  • Events
    • Time - Elapsed game time is 1.00 seconds
  • Conditions
  • Actions
    • Trigger - Turn off Untitled Trigger 001 <gen>
    • Game - Display to (All players) the text: (String(testvar))
    • Game - Display to (All players) the text: (String((Number of units in footman)))

Spawns 100 footman as expected, in a single game-time second. This is 100 executions in a single game-time second (Which is calculated by a ms delay between each logic frame afaik. Could be affected by game speed, don't really know). I would imagine most people thought it didn't go higher than 30, 40, maybe 50 right? Which would make sense where the 0.03-second timer comes from as that's kind of around that mark. Well, that's completely blown out of the water. Theoretically it could spawn 10,002 Footman in a single game time second but it would probably take significantly longer than that in real-time (Probably minutes? Maybe even hours?) but in the end it would count: 10,002 executions and 10,002 footman in 1 game-time second. I did try testing it but obviously spawning 10,002 footman at a reasonable real-time pace is not realistic.

Personally I don't see much of a point of using anything faster than about 0.05, that's 20 executions a (game-time) second. that's already insanely fast. If you have big triggers then executing them any faster than that may cause lag. But if you need frame/time-sensitive things then better accuracy will always be better. (Thus having a clock of say, 0.01 or even 0.0)

 

[DracoL1ch]

well, there's tons of frames running even while the game is paused, mostly for draw purposes. 0 second repeatable timer literally triggers on every major tick. iirc you're able to use extra-low values like 0.005 too with no more effects.
jass timers uses all the same timer mechanics as every high-leveled structure in the game - units, abilities, etc. I can't see if there's hardcoded limits on numbers, or it's JASS float's restrictions (which doesn't allow to use very low (not null) values for timers).

 

[aple]

While I will agree that there probably isn't much of a reason for the average trigger to use this, it is nice to know that if you need more accuracy you can have pretty much as much accuracy as you need. There will never be a reason to have anything faster than 10,002 logic frames per second, for anything, ever. If you want anything between that and 100 though, you'll have to use JASS instead of GUI though as it doesn't let you put in anything lower than 0.01, just defaulting to 0.0 but I'd imagine JASS doesn't have that limitation. Probably around 200 to 200 executions per second is probably the most accurate anyone would ever need as that's probably starting to check several times every actual rendered game frame.

Please note I was just experimenting, here. I have no real need for something to be this fast right now.

 

[DracoL1ch]

jass VM being executed only at some predefined ticks, instead of calling it everytime. so operations being accumulated until then, resulting into:

for code

function Inc takes nothing returns nothing
    local integer h=GetHandleId(GetExpiredTimer())
    local integer c=LoadInteger(HY,h,0)
    call DisplayTimedTextToPlayer(LocalPlayer,0,0,10,I2S(c)+" t="+R2S(TimerGetElapsed(GlobalTimer))+" "+R2SW(TimerGetElapsed(GlobalTimer),1,4))
 
endfunction

function testticks takes nothing returns nothing
    local timer t=CreateTimer()
    local integer h=GetHandleId(t)
    local real r=TimerGetElapsed(GlobalTimer)
 
    call TimerStart(t,0.005,true,function Inc)
    call SaveInteger(HY,GetHandleId(t),0,5)
    set t=CreateTimer()
    call TimerStart(t,0.002,true,function Inc)
    call SaveInteger(HY,GetHandleId(t),0,2)
    set t=CreateTimer()
    call TimerStart(t,0.001,true,function Inc)
    call SaveInteger(HY,GetHandleId(t),0,1)
    set t=CreateTimer()
    call TimerStart(t,0.0009,true,function Inc)
    call SaveInteger(HY,GetHandleId(t),0,9)

endfunction

TimerGetElapsed returns all the same timing for all of the calls made within any 0.01 tick, which means some stuff may be simply unreliable at this frequency. but still it works as intended. I believe 10k footmans are somehow related to 8k ops limit per tick, which killed most of your perfomance (just guessing, dont wanna check it out since no real purposes)

 

[aple]

Not really sure what your results in that image means. Can you explain?

 

[DracoL1ch]

tick + timestamp from a global timer, read the code for details

 

[IcemanBo]

He starts one global timer which he uses for time measurement. (as he can use TimerGetElapsed() function to see how much time has passed)

Then he starts 4 new timers with only a minimal of difference, the timeouts are: 0.005, 0.002, 0.001, 0.0009.
And when one of the 4 timers is finished he prints the measured/elapsed time of global timer, and it ends up that it prints the same elapsed time for all 4 timers when they finish, even they all had a different timeout values.

 

[TriggerHappy]

0.03 is used for performance in "heavy" operations. It makes a significant difference on lower end machines.

I'm pretty sure it's common knowledge that timers accept periods below 0.01, but as it's been pointed out, it's mostly useless due the JASS VM or Frames Per Second not able to keep up.

For example in my custom user interface, no matter how low of a timer period, I cannot have the UI follow the camera without stuttering/jumping because the frames update too slow.

 

[aple]

Okay, I was wondering why this was the case. This makes some sense why my results were like that while these results are like this.

 

[Dr Super Good]

Anything below 1/60 of a real second is pointless as the game is pretty hard locked to 60 FPS.

 

[DracoL1ch]

Anything below 1/60 of a real second is pointless as the game is pretty hard locked to 60 FPS.

OP just demonstrated that there's up to 10k ops possible, idk what do you mean

 

[Dr Super Good]

OP just demonstrated that there's up to 10k ops possible, idk what do you mean

The game runs at 60 FPS. Changing the state more than 60 times a real second is pointless because the extra changes are invisible and might even manifest with some form of aliasing.

Timers and events use game seconds. Game seconds are scaled by game speed into real seconds. As such for perfectly smooth animation one needs to run a timer faster if the game is set to slow speed and slower if the game is set to fast speed. Since people mostly lock game speed to faster (fastest available setting) one can assume this is the case and build triggers around it.

 

[DracoL1ch]

not every change should be visible, just like creating units doesn't have to be fps-precise. w/e

 

[aple]

if I'm understanding it correctly, what Draco posted proves it's not completely accurate anyway, right? The faster you go the more accuracy you lose, I think?

 

[DracoL1ch]

in case if you care about timing of something else. you can use 0.005 to spawn 200 footmans, but not to check how good are your 1s timers

 

[aple]

So far the only real thing I can think of that you will need a really fast timer for spawning units is for something like Footman Frenzy or PMP, being able to upgrade your spawn speed so you can practically have as much spawn speed as you want this way.

 

[Wietlol]

The whole point of using a 0.03s timer should be pretty clear by now.
In simple terms, you will skip some game states, thus not having much gain from using a lower interval.

There are some exceptions, but most of the game should run on a 0.03s interval if it requires a low one.

If not taking native code into consideration, yhe use of a lower interval is useless.
You can increase a real by 0.001 every 0.001 seconds, but for greater performance, you should increase it by 0.03 every 0.03 seconds instead.

If this real is for example the x or y coordinate of a unit, this interval should be enough to give a smooth movement.
If you dont really use the value actively, you could even choose to not update it at all and recalculate the value whenever you need it. This is the most wanted behavior.

If you create 200 units in an instant or create them equally separated over one frame, you wont see the difference.
However the wc3 native code might do different things with these different situations.
I havent really experimented with spawning units that much, but i dont really think it would make any difference what so ever.

In general terms 0.001s timers are useless.
But i think we all know how jass code can do weird stuff.