3 ms·
If anybody is wondering "how the heck did Raylib solve the problem of running an actual render loop in the browser without a requestAnimationFrame callback", ta
by flohofwoe 3y ago
If anybody is wondering "how the heck did Raylib solve the problem of running an actual render loop in the browser without a requestAnimationFrame callback", take note of the "-s ASYNCIFY" option that's passed to emcc.
I guess the WindowShouldClose() function yields control back to the browser event loop, which only works if the WASM code has been transformed into an async/await style state machine (and that's exactly what ASYNCIFY does).
I still wonder though how well this approach synchronizes with the swapchain presentation interval (which AFAIK is one advantage of using requestAnimationFrame).
- baudaux 3y agoSwap buffers is done “automatically” by the browser after the drawing loop
- flohofwoe 3y agoYes, but you'd want your per-frame code to be called as early as possible after a swap so that your code has as much time as possible to do work without missing the next swap (YMMV of course if there's a pipeline of buffered frames waiting for presentation - but this should be kept low to reduce button-to-screen latency).
- baudaux 3y agoYou can do what you want during a next event loop (timer, key press, …)
- rzzzt 3y agoSource code for the method: https://github.com/raysan5/raylib/blob/c5ebdb8ba77afa5745eb01032cf1909b5a03bffa/src/platforms/rcore_web.c#L128-L138 https://github.com/raysan5/raylib/blob/c5ebdb8ba77afa5745eb0... Asyncify docs (different from the emterpreter-async option mentioned in the comment block): https://emscripten.org/docs/porting/asyncify.html https://emscripten.org/docs/porting/asyncify.html
- flohofwoe 3y agoHmm, that Emterpreter comment might be a leftover from the asm.js times.