Browser ports
category: general [glöplog]
fr-041: debris. by farbrausch
https://demoports.github.io/fr-041_debris/
https://demoports.github.io/fr-041_debris/
Quote:
fr-041: debris. by farbrausch
Nice.
State of Mind by Bomb
https://jasper2-0.github.io/bomb_state-of-mind/
https://jasper2-0.github.io/bomb_state-of-mind/
Nowhere by threestate, (reverse engineered, no source available), with sagacity's blessing
jasper2-0.github.io/threestate_nowhere/
jasper2-0.github.io/threestate_nowhere/
Quote:
State of Mind by Bomb
https://jasper2-0.github.io/bomb_state-of-mind/
Thank you! I can remove that one from my list. I'll do Tribes then 😀
Quote:
Nowhere by threestate, (reverse engineered, no source available), with sagacity's blessing
jasper2-0.github.io/threestate_nowhere/
Yesss! I can go back at listening this song over and over again 🙏
Makes me want to do Nonstop Ibiza.
@coat: Thanks for the Nowhere port! Really good vibes coming from that demo. Last time I tried to run it realtime on my Windows machine (when I had one) there were rendering glitches and whatnot.
The Nonstop Ibiza Experience by Orange
https://demoports.github.io/ibiza/
https://demoports.github.io/ibiza/
Second Reality by Future Crew
https://demoports.github.io/2nd_real/
https://demoports.github.io/2nd_real/
I'm not sure the music in State of Mind is 100% synced (seems late to the visuals).
wouldnt it be nice to have all of those "ports" on a single portal page with sort/search and such?
Quote:
wouldnt it be nice to have all of those "ports" on a single portal page with sort/search and such?
👉 https://github.com/demoports
Quote:
I'm not sure the music in State of Mind is 100% synced (seems late to the visuals).
I think this was already the case in the original (at least the version I remember which may or may not be the Windows port).
yeah, SoM originally already has some bad sync here and there with those lyrics
Elevated by RGBA & TBC
https://demoports.github.io/rgba_tbc_elevated/
https://demoports.github.io/rgba_tbc_elevated/
Really cool stuff, guys! Love seeing 4Ks and 64Ks running in the browser, really handy.
One little suggestion: it would be great to have a shortcut in the presentation to see some basic info, like the bundle size of the 4K/64K, and a key to enable/disable framerate stats such as FPS, min, max, and average.
I’m asking because I’ve noticed some really bad experiences and framerate issues in quite a few prods, so it’d be nice to be able to confirm those issues out of the box without having to install additional browser extensions or whatever.
But anyway, really awesome stuff! Guess Heaven7 and Lifeforce are next? ;)
I really love seeing people enhance and showcase the browser as such a handy platform/sandbox for demos, especially <=64KB prods. Bringing these experiences to a new generation of platforms and making them more accessible and visible outside the demoscene can only be a good thing.
Even more importantly, I think this could be a fantastic way to get a new generation of coders excited about the scene and the beauty of proceduralism, seeing how much you can create with code, algorithms, and such tiny constraints. Making 4K/64K prods easy to discover, run, experiment with, and share could really spark that curiosity.
Getting people to discover what’s possible in <=64KB could be huge for the future of the scene.
Huge thanks to everyone putting in the time and effort to make this happen!
Really love seeing this direction! Keep it going ❤️
One little suggestion: it would be great to have a shortcut in the presentation to see some basic info, like the bundle size of the 4K/64K, and a key to enable/disable framerate stats such as FPS, min, max, and average.
I’m asking because I’ve noticed some really bad experiences and framerate issues in quite a few prods, so it’d be nice to be able to confirm those issues out of the box without having to install additional browser extensions or whatever.
But anyway, really awesome stuff! Guess Heaven7 and Lifeforce are next? ;)
I really love seeing people enhance and showcase the browser as such a handy platform/sandbox for demos, especially <=64KB prods. Bringing these experiences to a new generation of platforms and making them more accessible and visible outside the demoscene can only be a good thing.
Even more importantly, I think this could be a fantastic way to get a new generation of coders excited about the scene and the beauty of proceduralism, seeing how much you can create with code, algorithms, and such tiny constraints. Making 4K/64K prods easy to discover, run, experiment with, and share could really spark that curiosity.
Getting people to discover what’s possible in <=64KB could be huge for the future of the scene.
Huge thanks to everyone putting in the time and effort to make this happen!
Really love seeing this direction! Keep it going ❤️
Quote:
One little suggestion: it would be great to have a shortcut in the presentation to see some basic info, like the bundle size of the 4K/64K, and a key to enable/disable framerate stats such as FPS, min, max, and average.
You can enable frame stats in the rendering tab of the inbuilt browser developer tools.
Quote:
Making 4K/64K prods easy to discover, run, experiment with, and share could really spark that curiosity.
Except that the browser ports do not adhere to those limits.
Quote:
You can enable frame stats in the rendering tab of the inbuilt browser developer tools.
Oh, cool, nice gem, thanks :) That helps confirm my suspicions... A lot of framerate drops, spikes, sudden spikes, red areas, <20 FPS or even less, and max rates at around 40 FPS (rtx 3050 ti over here)... That's the thing: if you want to make the experience smoother, you'll really need to optimize your JS code. In C++ demos such as Debris, it runs smoothly at >60 FPS, stable at high-res, natively. Still, not a criticism, that's what you paid for. It'd be nice to have some log stats, though, to get the minimum framerate, etc. I still think there's a lot of room for optimization.
Quote:
Except that the browser ports do not adhere to those limits.
Hehe, exactly... That's why I suggested showing the bundle size in the presentation of each intro. I'm not sure what the intent is from the guys, though: just transpiling to JS code with a nice UX/UI without bothering of size constraints, or truly showcasing that a 4K/64K intro can be ported to JS in bundles that are equal to or smaller than their native counterparts.
In any case, no criticism here, I love this initiative overall. Let's see how it evolves; I may give it a shot myself eventually :)
Quote:
Second Reality by Future Crew
https://demoports.github.io/2nd_real/
Sorry for being so blunt, but I just can't stay silent about this :) The scene with the bouncing glenz-polyhedron is horribly broken. The bounce “physics” are nothing like the original. It’s like it doesn’t hit the floor hard enough.
Maybe I’m the only one who notices this?
Quote:
Sorry for being so blunt, but I just can't stay silent about this :) The scene with the bouncing glenz-polyhedron is horribly broken. The bounce “physics” are nothing like the original. It’s like it doesn’t hit the floor hard enough.
Can you make a screen recording? I compared the port with the youtube capture side to side 🤔
Ohm, I'm noticing it's missing some squashing... Is that what you mean with horribly broken?
@BPL:
Feel free to have a look (or ask your favourite AI to investigate). All the ported code is on github 👌
Quote:
Oh, cool, nice gem, thanks :) That helps confirm my suspicions... A lot of framerate drops, spikes, sudden spikes, red areas, <20 FPS or even less, and max rates at around 40 FPS (rtx 3050 ti over here)... That's the thing: if you want to make the experience smoother, you'll really need to optimize your JS code. In C++ demos such as Debris, it runs smoothly at >60 FPS, stable at high-res, natively. Still, not a criticism, that's what you paid for. It'd be nice to have some log stats, though, to get the minimum framerate, etc. I still think there's a lot of room for optimization.
Feel free to have a look (or ask your favourite AI to investigate). All the ported code is on github 👌
Quote:
Ohm, I'm noticing it's missing some squashing... Is that what you mean with horribly broken?
@mrdoob:
took you up on it. I didn't optimise anything, but I built a measuring tool, so the "it feels choppy" complaint is numbers now.
First, my earlier report was garbage: Chrome was on the laptop's Intel UHD, not my RTX. On Windows the per-app GPU setting overrides the NVIDIA control panel, so laptop framerate reports are probably all integrated GPU.
What I see on the RTX 3050 Ti, redone properly: the demo runs at roughly half the frame rate it should, and it stutters in a way you can feel. About a third of the running time is spent on frames that arrive late, plus a handful of outright freezes of a fifth to a third of a second when a new scene comes in. But here's the useful bit: the graphics card is not what's holding it back. It's the JavaScript work happening every frame. In the three stretches where that work happens to be light, the demo locks to a rock solid 60 fps and looks perfect. Everywhere else the frame rate is simply whatever that work allows. So the ceiling isn't the GPU, it's the main thread, and every bit of work taken off it turns straight into frame rate.
Using it: serve the folder over any local web server, open the page, and you'll see a "benchmark" button next to start. Click it and let the demo run without touching anything. A graph appears in the corner while it plays, and at the end you get a report with the verdict, the numbers, the worst moments with their timestamp in the demo, and buttons to copy or download it. F9 cycles that overlay during any run, R opens the report whenever you want. It's one file, no dependencies and no build, so you can drop it into any of your other ports with a single script tag.
Zip with your code plus the tool, do what you like with it: fr-041_debris_with_benchmark.7z
I won't be taking this further myself, I'm busy with my own stuff, so don't wait on me. And I profiled nothing, so I don't know which part of the code owns that time yet. But it's measurable now instead of a matter of taste, and hopefully that's a useful starting point for whoever wants to dig in.
Thanks for doing the port in the first place. Seeing this thing run in a browser at all is great, and it would be even better to see it hold a stable 60+ fps.
Quote:
Feel free to have a look (or ask your favourite AI to investigate). All the ported code is on github 👌
took you up on it. I didn't optimise anything, but I built a measuring tool, so the "it feels choppy" complaint is numbers now.
First, my earlier report was garbage: Chrome was on the laptop's Intel UHD, not my RTX. On Windows the per-app GPU setting overrides the NVIDIA control panel, so laptop framerate reports are probably all integrated GPU.
What I see on the RTX 3050 Ti, redone properly: the demo runs at roughly half the frame rate it should, and it stutters in a way you can feel. About a third of the running time is spent on frames that arrive late, plus a handful of outright freezes of a fifth to a third of a second when a new scene comes in. But here's the useful bit: the graphics card is not what's holding it back. It's the JavaScript work happening every frame. In the three stretches where that work happens to be light, the demo locks to a rock solid 60 fps and looks perfect. Everywhere else the frame rate is simply whatever that work allows. So the ceiling isn't the GPU, it's the main thread, and every bit of work taken off it turns straight into frame rate.
Using it: serve the folder over any local web server, open the page, and you'll see a "benchmark" button next to start. Click it and let the demo run without touching anything. A graph appears in the corner while it plays, and at the end you get a report with the verdict, the numbers, the worst moments with their timestamp in the demo, and buttons to copy or download it. F9 cycles that overlay during any run, R opens the report whenever you want. It's one file, no dependencies and no build, so you can drop it into any of your other ports with a single script tag.
Zip with your code plus the tool, do what you like with it: fr-041_debris_with_benchmark.7z
I won't be taking this further myself, I'm busy with my own stuff, so don't wait on me. And I profiled nothing, so I don't know which part of the code owns that time yet. But it's measurable now instead of a matter of taste, and hopefully that's a useful starting point for whoever wants to dig in.
Thanks for doing the port in the first place. Seeing this thing run in a browser at all is great, and it would be even better to see it hold a stable 60+ fps.
It does run at 60fps on my MacBook Air M1...
Quote:
Quote:Sorry for being so blunt, but I just can't stay silent about this :) The scene with the bouncing glenz-polyhedron is horribly broken. The bounce “physics” are nothing like the original. It’s like it doesn’t hit the floor hard enough.
Can you make a screen recording? I compared the port with the youtube capture side to side 🤔
Sure, I made a side-by-side comparison with the original. Please check it frame by frame:
http://chiptown.ru/SR_port_vs_original.mp4
Quote:
Ohm, I'm noticing it's missing some squashing... Is that what you mean with horribly broken?
I'm glad you noticed it. Yes, in the port, the polyhedron doesn't squash vertically when it hits the floor. Instead, it changes size along all axes, and the oscillation continues in the same way afterwards. So essentially, it just changes its overall size.
In the original, when the polyhedron hits the floor, it gets flattened (increasing in width and decreasing in height), and the subsequent oscillation follows the physics of an elastic body.
You may think this isn't “horribly broken” and is just a minor detail. But it has a huge impact on how the whole thing looks and feels.