Anyone have information on the resolution of the d...

# coroutines

[Pedro Cortés]

Anyone have information on the resolution of the delay() function? I'm trying to make a game loop (needs sub 16ms precision) but seems it is not deterministic when providing low values like delay(10) is it even a per platform thing on KMP depending on resolution capabilities of OS ?

[ephemient]

it is platform-dependent

[ephemient]

even with JVM only, timer resolution will vary: https://hazelcast.com/blog/locksupport-parknanos-under-the-hood-and-the-curious-case-of-parking-part-ii-windows/

[ephemient]

for windows specifically, https://github.com/io7m-com/timehack6435126 tries to trick the JVM into using higher-resolution timers

[Pedro Cortés]

Ah i see... Is there like a common approach for this use case on KMP? I mean idling with more precissionor should i relay on busy waiting?

[Pedro Cortés]

At the moment wathever delay(3 to 16) gives always >30 ms delays

[ephemient]

not as far as I know. you'll probably have to use platform-specific APIs to get more accurate timers

[ephemient]

also increasing timer resolution on Windows changes it system-wide, causing all apps to use more power, and also triggers a bug in earlier versions which causes the system clock to run too fast… it's a mess

[kevin.cianfarini]

Note that delay will delay for at least the specified amount of time

[kevin.cianfarini]

You're probably reaching for the wrong tool if you need high precision timing

[ephemient]

it will delay for at least that amount of time, but it's not necessarily synchronized with currentTimeMillis or any other clock, so it's possible to observe what appear to be shorter delays

[Pedro Cortés]

ok thank for the info!

[kevin.cianfarini]

It might be worth researching how other game engines tick. For example, I doubt Godot or Unity use thread parking to govern their game loop (but also I don't know anything about game Dev)

[ephemient]

I assume games will use WinMM (they need to handle audio anyway)

[kevin.cianfarini]

I do vaguely remember from watching someone create super Mario world in Godot that the game loop gives you a delta amount of time that occurred from the last tick and you use that in all of your physics calculations

[Pedro Cortés]

quite interesting you mention mario world hehe... Its precisely what the emulator have loaded...

[Pedro Cortés]

just (land)

[Pedro Cortés]

imagen.png

[Pedro Cortés]

Anyway... i will try to fine tune my main loop thanks for all the info!

[kevin.cianfarini]

Perhaps this repo could be helpful as well. https://github.com/ElieJacquelin/Alesia/blob/main/Alesia/src/commonMain/kotlin/Screen.kt#L50

[kevin.cianfarini]

Just poking around it looks like it uses delay for one reason — if the current frame was rendered faster than 16.66ms then delay for the remainder. There’s a few issues with this code I can notice immediately: notably it’s using Clock.System instead of a monotonic TimeSource, and I’m still wary that delay would provide the amount of precision necessary for a game loop.

[Pedro Cortés]

yeah it doesnt its precisely the problem im having