7 ms·
Very slick and opens up so many possibilities. WebAssembly, WASI, like WebRTC/WebGPU/WebXR/WebAudio, just makes webdev, gamedev + native/networking very very i
by drawkbox 3y ago
Very slick and opens up so many possibilities.
WebAssembly, WASI, like WebRTC/WebGPU/WebXR/WebAudio, just makes webdev, gamedev + native/networking very very interesting in this phase of technology where js frameworks are culty bloated/verbose and apps are the main thing for marketing/tools. Web apps + tools are opening up with wasm/wasi.
Runno (https://runno.dev/ https://runno.dev/ + https://runno.dev/wasi https://runno.dev/wasi) is a great idea and helps make interesting native stuff in a sandbox locally. Running all this directly without having to mash into assembly is a great idea. Awesome job on this!
> Runno helps you make runnable code examples that can be embedded in web pages. This is very handy for educational tools, it means:
> - You can make code examples that don't need users to install scary tools.
> - No need to run a server, it all runs client-side in the browser.
> - Your users can edit and re-run any code examples you make.
> - The examples are extremely customisable with HTML, CSS and JavaScript!
- pjmlp 3y agoYet I am still waiting to see a game with the same capabilities of Infinity Blade, that Apple used in 2011, as an example of a game showing of the newly acquired OpenGL ES 3.0 capabilities of iDevices. Or the Unreal Engine 3.0 citadel demo, also in 2011, for Flash/CrossBridge. It seems the only thing usable is running ShaderToy demos, and 3D views on ecommerce sites.
- parasti 3y agoThat expectation is off by nearly a decade. WASM games in terms of performance are closer to 2000 than 2010. Here's an open source indie game from 2003 that I ported to WASM [1]. It struggles to hit 60 FPS on devices that were released a good 15 years after the game itself. Browsers sometimes struggle to animate simple lines at 60 FPS still to this day, because they're just hugely massive platforms with thousands of moving parts with no room for big, complex apps on top of them. [1] https://neverball.github.io/ https://neverball.github.io/
- speps 3y agoI need to double check what you're saying, how do you show the FPS in your WASM port?
- parasti 3y agoDevtools or F9 while in game. Type a famous magic word in the title screen to access all levels. Not sure how to do this on a phone which is what I was referring to - but framedrops are pretty obvious.
- speps 3y agoThanks, I suspect it might be gl4es but I need to find my old phone to investigate. Magic word is "xyzzy" for anyone else looking.
- speps 3y agoI've done a quick test and it runs very smoothly on my original OnePlus One from 2014 (so 11 years after the game). This is on latest Chrome, Android 11 (LineageOS 18.1). I still find it amazing that this game never made with this in mind, the web tech at the time on the OnePlus One was nowhere near able to run this in browser and it works perfectly today!
- parasti 3y agoTo be fair my reference browser is Firefox, WebGL is a fair bit slower there. What blows my mind with this technology is little things: porting the game to the browser gave me a half-working mobile port basically for free (had to implement touch input handling in Neverball). On top of that, thanks to SDL2 and the game controller web API, I can attach a game controller to my phone and play the game in the browser on my phone with a game controller. It just seems unreal that this combination of technology just works.
- pjmlp 3y agoIf we hadn't lost a decade with what Flash and PNACL already offered us in 2011... No wonder studios rather bet on streaming than a tech that will never deliver.
- SahAssar 3y agoThe unreal citadel demo was running in a browser without flash in 2014: https://blog.mozilla.org/en/mozilla/mozilla-and-epic-preview-unreal-engine-4-running-in-firefox/ https://blog.mozilla.org/en/mozilla/mozilla-and-epic-preview...
- pjmlp 3y ago3 years to catch up with 2011 tech, and a decade later nothing better to show.
- SahAssar 3y agoMy hypothesis is that monetization on the web is harder so there are not as many resources spent on games in browsers. If anyone is willing to spend a lot of time on the game they are probably willing to install it, people arent conditioned to pay up front for websites, the UX around microtransactions isn't at all smooth.
- fulafel 3y agoApple has been slowing down WebGL I think. See eg people complaining in https://developer.apple.com/forums/thread/696821 https://developer.apple.com/forums/thread/696821 and https://discourse.threejs.org/t/horrible-3d-three-js-performance-in-latest-safari-on-macos/25940 https://discourse.threejs.org/t/horrible-3d-three-js-perform...
- pjmlp 3y ago80% of the browser mobile market belongs to Google, plenty of customers, even better when looking at the desktop market. Usually a good excuse why the tech doesn't get uptake.
- flohofwoe 3y agoThese are mostly business issues. If the business problems would be solved, the games would be built, despite any technical limitations of the web platform (which are not much different than limitations on low-end Android mobile devices). Nobody has figured out so far how to make money with high quality games on the "open web" to get the same return on investment like simple ad-driven 2D games running on closed platforms like Facebook which can technically be cobbled together by 3 dudes in their mom's basemement (exaggerating a bit here of course). E.g. no matter how you approach it, the Citadel demo wouldn't have led to a web game that would make the same profit relative to the development cost like a simple ad-driven Tetris style game.
- pjmlp 3y agoNo they aren't, at least low end Android devices support GL ES 3.2 and have proper debugging tools. After a decade Web 3D keeps having spectorJS as the only alternative. Naturally there are also some masochists that enjoy debugging the browser 3D stack on RenderDoc, while trying to figure out what belongs to their application.
- flohofwoe 3y agoIf you use WASM+WebGL, you'd typically debug a native build outside the browser. According to here GLES3.2 support on Android is currently sitting at 80%, while with GLES3.0 you would reach about 95%, and with GLES2 100%. https://developer.android.com/about/dashboards#OpenGL https://developer.android.com/about/dashboards#OpenGL If I would try to ship a native app on Android I would still at least try to only use GLES3.0 features to get that extra 15%. You enthusiastic charactization of Android debugging tools isn't exactly how I would describe the situation ;)
- pjmlp 3y agoA kludge to work around lack of tooling for the past decade, and when doing that, no need to WASM anyway. Even if we consider GL ES 3.0, native comes out winning, due to missing features on WebGL 2.0. Not only has Android the GPU debugger from Google, that beats anything available for Web, each mobile GPU vendor has their own set of graphical debuggers.