Andre Weissflog

oh that is awesome, well deserved! congrats @ocornut.bsky.social

(I would actually love a "builtin" Win32 'window system client-library' on top of Wayland instead of Xlib or xcb)

Argh, not like that! :D

(tbf, XWayland works perfectly fine as "sanity wrapper" on KDE Plasma)

...at the same time I think that Linux+Proton will have a more robust and performant implementation of the Windows APIs that are relevant for PC games than future-Windows, and when Microsoft inevitably kills Xbox+DirectX in a couple of years I hope most of the smart peeps will end up at Valve ;)

Tbh, the UI it was all downhill after Windows 2000 ;)

> I get OS is not a profitable business anymore

Was an OS ever profitable though? It was always just the infrastructure for apps to generate profit on.

But yeah, shame about all the solid tech that sits *below* the UI (kernel and DirectX).

...of course the failing projects always blamed the engine, not matter if Unity or inhouse engine ;)

IME it's always about the team. I've seen plenty of Unity game projects fail and plenty of 'inhouse engine' projects succeed. The failure was often about losing focus, e.g. people will always find their distractions, be it in some inhouse engine code, or random game feature ;)

Yeah I know this workaround (haven't tinkered with it yet though, I just avoid WASM threading), but I also read in various Github issue threads that this isn't a reliable solution.

...this overload was added as an 'afterthought' but allowed to avoid creating a temporary ArrayBuffer object in the JS shim.

IME it's such little details which can help a lot to reduce the runtime overhead in the WASM => JS shim layer (and I guess also without the JS shim).

GPURenderPassEncoder: setBindGroup() method - Web APIs | MDN The setBindGroup() method of the GPURenderPassEncoder interface sets the GPUBindGroup to use for subsequent render commands, for a given index.

IMHO a good first (and much less controversial) step is adding 'wasm-friendly / garbage-free' helper functions to web APIs for high-frequency calls which reduce work in the JS shim.

E.g. things like the last overload of WebGPU setBindGroup: developer.mozilla.org/en-US/docs/W...

...

PS: another urgent problem that needs solving is the COOP/COEP requirement for WASM multithreading btw, since this requires access to the web server configuration, which popular hosters like Github Pages still don't allow...

...but that would probably a century-project ;)

(man the tweet-size limitation on Bluesky sucks ass)

A properly layered and completely rebuilt 'web api stack' would be nice (e.g. a 3D API at the bottom, on top of that a proper text and fonts API, on top of that a 'layout-engine', and only on top of *that* a DOM-like API. Next to that a drastically simplified audio API, file IO, network, input.

E.g. people seem to expect that with the ability to compile their favourite language to run in browsers that the web is "just another desktop platform" like Windows, macOS or Linux, but in reality it's an entirely different solar system ;)

I thing the what makes WASM on the web "hard" for newcomers is that web APIs are so entirely different from native-platform APIs (with the exception of WebGL), and some web APIs are just terribly designed (WebAudio, Fullscreen, Clipboard, and of course the DOM).

I mean ok, the one good thing coming out of this endeavour is that it will shut up that eternal "why doesn't WASM allow direct DOM access" whining whenever some WASM topic makes it to the HN frontpage ;^)

Ooof, sounds like they started vibe coding the whole thing ;(

E.g. I don't buy the performance argument unless you do really silly things (like setting/getting DOM properties with one WASM=>JS call per property). This smells like solving one specific problem (accessing the DOM from WASM) with a very overengineered general solution.

This overhead is mostly a problem for string-heavy web APIs though (like trying to manipulate the DOM via from WASM), for most other APIs (WebGL, WebGPU, WebAudio), the JS shim overhead is much less of a problem, there is much more time spent *inside* the web API implementation.

...I haven't noticed Intellisense problems so far though... but may code is also mostly simple C code with some old-school C++ sprinkled in, and the project files are generated via cmake.

VS2026 is actually a good update compared to VS2022 ;)

It starts significantly faster, loads complex solutions with many target *much* faster, and overall feels snappier. I also haven't noticed any 'in-your-face' annoying Copilot stuff yet (maybe I disabled that already in VS2022 though).

...it seems to be mainly useful for passing strings across the 'boundary', but talking to string-heavy JS APIs (like the DOM) and expecting any sort of performance is silly anyway.

Making WebAssembly a first-class language on the Web – Mozilla Hacks - the Web developer blog This post is an expanded version of a presentation I gave at the recent WebAssembly CG meeting in Munich. WebAssembly has come a long way since its first release in 2017. The 1.0 version of WebAssembl...

This idea of eliminating the JS shim for WASM running in browsers sounds great on the surface, but the more I try to think this through the more questions pop up in my head:

hacks.mozilla.org/2026/02/maki...

What an Xbox founder thinks of the new Xbox CEO | Seamus Blackley interview Seamus Blackley was one of the renegades who got the Xbox started. We asked him what he thinks of the big executive changes at Xbox.

Some people really have a way with words. Me not have way here Dean with. gamesbeat.com/what-an-xbox...

I just merged an update to the sokol_app.h iOS backend which replaces MTKView with CAMetalLayer+CADisplayLink (followup to the recent macOS backend update), and also migrates the iOS backend to 'UIScene lifecycle events'.

Details in the changelog: github.com/floooh/sokol...

TL;DR, I think server/backend and client/frontend can be used mostly interchangeably, even within the web world there may be vast differences between 'products' (no matter if web games or 'applications'.

While in the web games I'm now involved with, the backend is mostly concerned about login, game state persistency, in-app purchases, chat/messages, leaderboards, but the gameplay is running entirely in the 'frontend' (these are not multiplayer games though).

When I worked on Drakensang Online, both the game server and game 'client' were running the full gameplay loop, the client to hide latency, and the server as the 'single source of truth', e.g. the client speculated ahead and might have been corrected by the server when the speculation was wrong.

Do you hook into Steam services like cloud saves? There's your backend, it's just developed and maintained by somebody else ;)

It's webdev lingo, but replace 'backend' with 'server' and frontend with 'client' and it fits neatly into the game development world (e.g. as soon as you have multiplayer features you'll need some sort of backend, e.g. even the most simple peer-to-peer-games need at least a matchmaking service).