Unthrottle script update() selectively

I want certain scripts to be able to run at a higher rate than they currently are allowed to. Currently they run at 16.666… ms at 60 update frequency, and average to 16.666… still when variable update dt is checked (I thought variable dt would let scripts fun as fast as they could?)

I want to be able to assign some script to run as fast as they actually can unthrottled. I’d guess not possible or not easily possible due to the engine does updates?

dt * 1000 sample with variable dt checked

DEBUG:SCRIPT: 17.002999782562
DEBUG:SCRIPT: 16.000999137759
DEBUG:SCRIPT: 16.998000442982
DEBUG:SCRIPT: 16.000999137759
DEBUG:SCRIPT: 17.000000923872
DEBUG:SCRIPT: 16.999000683427
DEBUG:SCRIPT: 16.000000759959
DEBUG:SCRIPT: 17.000000923872
DEBUG:SCRIPT: 16.999000683427
DEBUG:SCRIPT: 16.000999137759
DEBUG:SCRIPT: 17.000000923872
DEBUG:SCRIPT: 16.994999721646
DEBUG:SCRIPT: 17.004000023007
DEBUG:SCRIPT: 15.999000519514
DEBUG:SCRIPT: 17.000999301672
DEBUG:SCRIPT: 17.000000923872
DEBUG:SCRIPT: 15.998000279069

headless

Looks like headless builds are actually allowed to update as fast as they possibly can with variable dt checked? Kind of weird to see the occasional 16.666666ms

Yes, headless builds are not throttled (although you can configure them to be). Those 16ms frames look strange though. @Johan_Beck-Noren is an expert on these things and can hopefully explain this on Monday.

1 Like

The update loop for components is not decoupled in a way that allows for example script components to update at different intervals than other components.

If it’s just a different dt you are after, can it be solved by placing the desired script components in a separate collectionproxy and setting the timestep of that collection?

But is it possible to set the timestep at a higher rate than the update rate of the game? I want for example a script (or collection as a whole) to have an update rate of 90. If the factor is 2 will the collection be updated at 120?

I should test this… I assume what would happen is multiple updates for the collection will happen on the same game frame, but the game will still stay at a max of 60 updates per second which wouldn’t help I think. The reason I want a higher rate is so that servers can respond more quickly without the extra latency of a frame. I don’t want to force users to run a headless server while they play for peer hosted games.

You can set the timestep for a collectionproxy to match any update frequency you like (e.g. slow-mo or fast-forward), but the collection’s update function will still only be called in sync with the rest of the engine.

The update frequency in game.project is capped at 60. Here is a more detailed explanation of how update frequency, variable dt, swap interval and gpu drivers play together: Variable dt causes game to run twice as fast (DEF-3146) (SOLVED)

1 Like

Do you know the cause of the random 16.6666666 delay of dt in headless builds? This could also cause issues for servers. You can test this by printing dt on update.

I guess I’d still ask for the ability to make some scripts able to update at a higher rate even if they are forced to interact with the rest of the game engine at its own rate.

Hard to say from the numbers alone :slight_smile:

Does inspecting the frame in the profiler give any hints?

It’s a headless build so…

Also tested with a completely empty project just headless + printing dt.

Hmm, web profiler should still work right?

I’ll test that now, although it may give different results because it’s a different platform target.

A “headless” HTML5 build appears to lock up my browser tab. :face_with_raised_eyebrow:

I mean run the game as you would normally do, then point your browser to http://localhost:8001.

1 Like

I honestly forgot that was even a feature!


2018-08-20%2000_17_15-Window