You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 17, 2020. It is now read-only.
Currently in stepModel, here, the engine will continously execute the update function of a game and recursively execute any commands returned by the engine user and then pass them to stepModel again. This would be fine if commands were executed on a separate thread, but in order to support the case of engines that have to be run on the main thread, they are not. To prevent the rendering process from being blocked, the stepModel function should only run the first Cmd returned from the update function, and queue the rest. This will cause some delay but will ensure that rendering always processes in the case of an engine user writing an infinitely-looping command tree.
Currently in
stepModel
, here, the engine will continously execute the update function of a game and recursively execute any commands returned by the engine user and then pass them tostepModel
again. This would be fine if commands were executed on a separate thread, but in order to support the case of engines that have to be run on the main thread, they are not. To prevent the rendering process from being blocked, thestepModel
function should only run the firstCmd
returned from the update function, and queue the rest. This will cause some delay but will ensure that rendering always processes in the case of an engine user writing an infinitely-looping command tree.Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
The text was updated successfully, but these errors were encountered: