4 ms·

This made me want to look at raylib. It comes with some cute examples that run using WebAssembly: https://www.raylib.com/examples.html https://www.raylib.com/e

by sgt 3y ago

This made me want to look at raylib. It comes with some cute examples that run using WebAssembly: https://www.raylib.com/examples.html https://www.raylib.com/examples.html One thing that's always bothered me about Wasm and browser 3d/2d graphics is that I often find minor issues such as scrolling. Look at the example called "Background scrolling & parallax" here: https://www.raylib.com/examples.html https://www.raylib.com/examples.html I've tested on several devices and it's definitely not smooth scrolling, unless there's something wrong with my eyes. How can 2D smooth scrolling not be a solved problem in 2024?

dekhn 3y ago
the answer to your last question is "inner platform effect" and "second system effect".
modeless 3y ago
In that sample the foreground scrolls perfectly smoothly for me, but the background looks jittery. This indicates to me that it's not a platform issue at all. That sample is just doing something weird with the background.
- sgt 3y ago
  Yes, the background is odd but the foreground is definitely not smooth. I see small little jitters occasionally. At one point I had to wait 15 seconds for it to jitter, though.
  - jay_kyburz 3y ago
    Yes the back and foreground is quite jittery for me on Firefox, and I'm almost certain its the browsers own requestAnimationFrame that's the problem. Update: Although, having a closer look at the scene, I see its pixel art, so I bet the author is snapping floating point positions to a pixel point to prevent sub pixel blurring. Another small update: I was sure requestAnimationFrame was locked to 60fps, but I noticed on Chrome the other day it was 144hz, the full speed of my monitor.
    - kragen 3y ago
      yeah, http://canonical.org/~kragen/sw/dev3/qvaders http://canonical.org/~kragen/sw/dev3/qvaders is unplayable on 120-hertz monitors because i'm running the game physics from raf ;)
      - sgt 3y ago
        Also noting that it's choppy on iPhone, but it's really barely noticable. Cool little game!
        kragen 3y ago
        thanks! the choppiness is for the same reason; if the frame rate drops temporarily due to cpu load or whatever, the vaders move slower
- joeld42 3y ago
  This jitteryness is because the sample doesn't have antialiasing enabled (since it's pixel art) and the background scrolling is 0.1pixels per frame, which means every 10 frames it snaps 1 pixel. The scrolling is also updating on fixed amount per frame instead of looking at deltaTime, so if there are lags or small differences in frame time this might look choppy. But I think it's more meant to demonstrate drawing parallax layers rather than subpixel scrolling.
  - sgt 3y ago
    So by modifying it to look at delta time it would be smooth?
deleted 3y ago
[deleted]
flohofwoe 3y ago
Because it's a surprisingly tricky topic on modern operating systems [1], and even trickier in web browsers (smooth scrolling was actually much easier to achieve on hard-realtime systems like the 8- and 16-bit home computers of the 80's and early 90s). TL;DR: if you base your animation- or scroll-speed on the 'raw' measured time between two frames, you'll get micro-stutter because it's pretty much impossible to obtain a non-jittery frame duration on modern operating systems or web browsers, all you can do is try to remove the noise via filtering, or 'align' your measured frame duration with the display refresh interval, which on some platforms cannot be queried. In web browsers the most important problem is that you can't measure the exact frame duration (which is fallout from Spectre/Meltdown), or obtain a precise 'presentation timestamp', or even query the display refresh frequency. Even in the native OS APIs that provide a presentation timestamp (like DXGI on Windows or CVDisplayLink on macOS) that timestamp has considerable jitter and has not much to do with the actual presentation time when the frame becomes visible to the user. And as soon as you base your animation timings on such a jittery timestamp you'll get micro-stutter (the easiest way to get smooth animation is actually to assume a fixed frame duration, but then your animation speed will be tied to the display refresh rate). It's often possible to eliminate the timing jitter with 'noise removal' filters or just tracking an average over the last couple dozen frames, but those then may behave funny in situations where the frame duration changes drastically (such as moving a window between displays with different refresh rate, or when rendering stops and then resumes because the window or browser tab is fully obscured and then becomes visible again). PS: Raylib's frame pacing code on the web is also a bit on the crude side [2]. ...e.g. it just sleeps for 16 milliseconds, and relies on ASYNCIFY to enable a traditional render loop in browsers. It would actually be better to use a frame callback via requestAnimationFrame (or the Emscripten wrapper function emscripten_request_animation_frame), but this means giving up the cross-platform 'own the game loop' application model. Not that requestAnimationFrame alone solves any of the above mentioned time jitter problems though. [1] https://medium.com/@alen.ladavac/the-elusive-frame-timing-168f899aec92 https://medium.com/@alen.ladavac/the-elusive-frame-timing-16... [2[ https://github.com/raysan5/raylib/blob/f1007554a0a8145060797c0aa8169bdaf2c1c6b8/src/platforms/rcore_web.c#L151-L156 https://github.com/raysan5/raylib/blob/f1007554a0a8145060797...
- samiv 3y ago

by sgt 3y ago

dekhn 3y ago

the answer to your last question is "inner platform effect" and "second system effect".

modeless 3y ago

In that sample the foreground scrolls perfectly smoothly for me, but the background looks jittery. This indicates to me that it's not a platform issue at all. That sample is just doing something weird with the background.

sgt 3y ago
Yes, the background is odd but the foreground is definitely not smooth. I see small little jitters occasionally. At one point I had to wait 15 seconds for it to jitter, though.
- jay_kyburz 3y ago
  Yes the back and foreground is quite jittery for me on Firefox, and I'm almost certain its the browsers own requestAnimationFrame that's the problem. Update: Although, having a closer look at the scene, I see its pixel art, so I bet the author is snapping floating point positions to a pixel point to prevent sub pixel blurring. Another small update: I was sure requestAnimationFrame was locked to 60fps, but I noticed on Chrome the other day it was 144hz, the full speed of my monitor.
  - kragen 3y ago
    yeah, http://canonical.org/~kragen/sw/dev3/qvaders http://canonical.org/~kragen/sw/dev3/qvaders is unplayable on 120-hertz monitors because i'm running the game physics from raf ;)
    - sgt 3y ago
      Also noting that it's choppy on iPhone, but it's really barely noticable. Cool little game!
      - kragen 3y ago
        thanks! the choppiness is for the same reason; if the frame rate drops temporarily due to cpu load or whatever, the vaders move slower
joeld42 3y ago
This jitteryness is because the sample doesn't have antialiasing enabled (since it's pixel art) and the background scrolling is 0.1pixels per frame, which means every 10 frames it snaps 1 pixel. The scrolling is also updating on fixed amount per frame instead of looking at deltaTime, so if there are lags or small differences in frame time this might look choppy. But I think it's more meant to demonstrate drawing parallax layers rather than subpixel scrolling.
- sgt 3y ago
  So by modifying it to look at delta time it would be smooth?

deleted 3y ago

[deleted]

flohofwoe 3y ago

Because it's a surprisingly tricky topic on modern operating systems [1], and even trickier in web browsers (smooth scrolling was actually much easier to achieve on hard-realtime systems like the 8- and 16-bit home computers of the 80's and early 90s). TL;DR: if you base your animation- or scroll-speed on the 'raw' measured time between two frames, you'll get micro-stutter because it's pretty much impossible to obtain a non-jittery frame duration on modern operating systems or web browsers, all you can do is try to remove the noise via filtering, or 'align' your measured frame duration with the display refresh interval, which on some platforms cannot be queried. In web browsers the most important problem is that you can't measure the exact frame duration (which is fallout from Spectre/Meltdown), or obtain a precise 'presentation timestamp', or even query the display refresh frequency. Even in the native OS APIs that provide a presentation timestamp (like DXGI on Windows or CVDisplayLink on macOS) that timestamp has considerable jitter and has not much to do with the actual presentation time when the frame becomes visible to the user. And as soon as you base your animation timings on such a jittery timestamp you'll get micro-stutter (the easiest way to get smooth animation is actually to assume a fixed frame duration, but then your animation speed will be tied to the display refresh rate). It's often possible to eliminate the timing jitter with 'noise removal' filters or just tracking an average over the last couple dozen frames, but those then may behave funny in situations where the frame duration changes drastically (such as moving a window between displays with different refresh rate, or when rendering stops and then resumes because the window or browser tab is fully obscured and then becomes visible again). PS: Raylib's frame pacing code on the web is also a bit on the crude side [2]. ...e.g. it just sleeps for 16 milliseconds, and relies on ASYNCIFY to enable a traditional render loop in browsers. It would actually be better to use a frame callback via requestAnimationFrame (or the Emscripten wrapper function emscripten_request_animation_frame), but this means giving up the cross-platform 'own the game loop' application model. Not that requestAnimationFrame alone solves any of the above mentioned time jitter problems though. [1] https://medium.com/@alen.ladavac/the-elusive-frame-timing-168f899aec92 https://medium.com/@alen.ladavac/the-elusive-frame-timing-16... [2[ https://github.com/raysan5/raylib/blob/f1007554a0a8145060797c0aa8169bdaf2c1c6b8/src/platforms/rcore_web.c#L151-L156 https://github.com/raysan5/raylib/blob/f1007554a0a8145060797...

samiv 3y ago