Is it preferable to run the game's main loop in Run or should it be put on the main clock? Run is the underlying thread's main and thus runs as fast as it can, while main clock should be run at the target/vsync framerate, right?
Clock callbacks will be on the same thread than the one executing orx
(ie. where you called orx_Execute()), if you access resources shared
with another thread from there, you'll have to take action accordingly
(locks, sync points, etc...).
Thus both main clock and run method will execute on the same thread.
Run method is called every run loop iteration.
I am guessing that clock may not execute more frequently than Run method.
My take on it that you process user input such as mouse events and keyboard input in Run method. For example, you may set user data structure on Object to start moving to target, but you don't calculate yet what the speed vector is (if it is highly complicated). Clock callback can be used to execute calculations to get object moving. That's the direction I've been taking.
You can use Clock for tasks such as watching the state of your game objects. So, if clock runs at 60 Hz you can expect that whatever changes you make to object will be as frequent as human eye can catch.
I am not sure of the impact of long running Clock callback on frame rate.
It's usually not recommended to do any game-related stuff in the Run() callback.
I mostly use it for handling screenshot and quit inputs in tutorials, but that's about it.
Everything in orx will get updated via calls from the clock module. The whole frame sequencing relies on the main core clock execution. Doing anything in the Run() callback might not always yield a 1:1 ratio with the game frame.
The other issue is that the clock system makes sure the time is consistent within all its callbacks calls. You always get an orxCLOCK_INFO structure as parameter of a clock callback which tells you how much time has elapsed since the beginning of the game and, more importantly, what is the current's frame duration (DT for delta time).
This will ensure that when you do any time-related computations, such as speed or acceleration, you'll always get the same result, no matter how fast or slow the underlying hardware is.
If a frame is longer than the previous one, you won't see any weird acceleration peak, same thing when the game runs in VSync or not, the results will always be time-consistent as long as you use the DT value.
An added bonus is that you can easily pause all logic or do time distortion. Setting a clock multiplier (like scaling the DT), will allow you to speed up or slow down the action.
You can even do it in a localized fashion by using an extra clock you create yourself and by linking it to some orxOBJECTs. When you'll stretch the DT of that clock, only the orxOBJECTs that are bound to it will get affected (even the sound pitch of sounds playing on those objects will get updated accordingly).
By default it runs as fast as it's allowed, ie. without vsync, as fast as the hardware can render your world, otherwise at the frequency defined by the vsyns (often 60Hz).
You can modify the core clock frequency either by code or from config.
Comments
Thus both main clock and run method will execute on the same thread.
Run method is called every run loop iteration.
I am guessing that clock may not execute more frequently than Run method.
My take on it that you process user input such as mouse events and keyboard input in Run method. For example, you may set user data structure on Object to start moving to target, but you don't calculate yet what the speed vector is (if it is highly complicated). Clock callback can be used to execute calculations to get object moving. That's the direction I've been taking.
You can use Clock for tasks such as watching the state of your game objects. So, if clock runs at 60 Hz you can expect that whatever changes you make to object will be as frequent as human eye can catch.
I am not sure of the impact of long running Clock callback on frame rate.
I mostly use it for handling screenshot and quit inputs in tutorials, but that's about it.
Everything in orx will get updated via calls from the clock module. The whole frame sequencing relies on the main core clock execution. Doing anything in the Run() callback might not always yield a 1:1 ratio with the game frame.
The other issue is that the clock system makes sure the time is consistent within all its callbacks calls. You always get an orxCLOCK_INFO structure as parameter of a clock callback which tells you how much time has elapsed since the beginning of the game and, more importantly, what is the current's frame duration (DT for delta time).
This will ensure that when you do any time-related computations, such as speed or acceleration, you'll always get the same result, no matter how fast or slow the underlying hardware is.
If a frame is longer than the previous one, you won't see any weird acceleration peak, same thing when the game runs in VSync or not, the results will always be time-consistent as long as you use the DT value.
An added bonus is that you can easily pause all logic or do time distortion. Setting a clock multiplier (like scaling the DT), will allow you to speed up or slow down the action.
You can even do it in a localized fashion by using an extra clock you create yourself and by linking it to some orxOBJECTs. When you'll stretch the DT of that clock, only the orxOBJECTs that are bound to it will get affected (even the sound pitch of sounds playing on those objects will get updated accordingly).
You can modify the core clock frequency either by code or from config.