C’è qualche novità per il web, nell’ambiente dei giochi C# e .NET. Già la roba fatta con quelle tecnologie poteva girare da anni sul web eh, ma… non farò finta di sapere cose che non so (non uso nessuna delle due tecnologie), ma ciò che voglio dire è che i gaymers sono passati all’attacco; ora pare esserci qualche risorsa in più, tipo FNA.WASM.Sample, che fa vedere come portare a WASM un gioco fatto con FNA-XNA. 🤔️
Quindi? Beh, un’idea venuta a caso la settimana scorsa era “cosa se portassi Celeste al browser?“, ma non ho poi fatto nulla, presa da altre cose. Volevo quasi quasi iniziare stamane, ma giusto per scrupolo cerco di nuovo sul web “celeste wasm”, sia mai che la volta scorsa mi era sfuggito qualcosa. E, nell’arco di precisamente questa settimana, non so se mi hanno letto nel pensiero o spiato spacctorium, ma hanno effettivamente iniziato e finito il fottutissimo celeste-wasm. Un po’ mi rode, ma meglio così, ho più tempo per altre imprese. 🤯️
Già a dir poco godurioso, ma qualcosa da sistemare rimane, tant’è che mi sono permessadi aprire la issue #1 per consigliare compressione e streaming degli asset. Vi invito a provare direttamente su https://celeste.r58playz.dev, ma per copyright hanno fatto che gli asset sono criptati e bisogna dare un file da un’installazione di Celeste per decifrarli… se vi serve, non lo linko, ma l’ho caricato sull’homeserver come altre volte, e se ravanate lo trovate. 👾️https://octospacc.altervista.org/2024/05/25/gayming-web/
Quei gamer che come me hanno nell’animo il PC masterrace, ma nella pratica odiano il tedio contro cui ci si imbatte appena si vuole effettivamente giocare a qualcosa per PC, staranno con ansia aspettando progressi sulla questione di giochi Windows nel browser. Quindi, che ho fatto ieri? …Un cazzo di niente! 🥰
Ho perso mezza giornata cercando invano di far funzionare prima alcuni programmi di benchmark, e poi Touhou. Ho dovuto installare DirectX 9 per quei programmi, ma poi comunque questi non partivano, perché a quanto pare DX9 non include rendering via software per Direct3D, e in v86 non c’è alcuna GPU. Pazienza, per quelli me ne farò una ragione, non ho vitale bisogno dei benchmark… però per i giochi è una rogna. Sorprendentemente, Touhou 6 parte in questo ambiente mezzo sfasciato, ma c’è un problema: non so come il gioco gira, riesco anche a muovermi nei menu alla cieca e avviare una partita, ma viene renderizzato solo lo sfondo e letteralmente null’altro, quindi non si può effettivamente giocare. (Dettagli più precisi in questa chat qui.) 🤬
https://octospacc.altervista.org/wp-content/uploads/2024/05/photo_5080513907201780824_x8412736725975051660-320x169.jpghttps://octospacc.altervista.org/wp-content/uploads/2024/05/screenshot_2024-05-24-00-21-42-337_org2221662542601539196-960x418.jpgHo provato allora con DirectX 8a, che pare essere l’ultima versione con software rendering prima di DX10 (che lo ha reintrodotto dopo che fu tolto tipo), e stando a Wikipedia ES dovrebbe essere il minimo richiesto da Touhou 6 (altre fonti specificano semplicemente DX8 generico). E qui il gioco però smette di partire, restituendo un errore non molto chiaro… che ho decifrato con Reddit e Google Traduttore, ma la cosa non mi ha dato alcun aiuto, non so a cosa si riferisca l’errore esattamente, e nessuna opzione disponibile tra configurazione del gioco e impostazioni di Windows ha risolto il problema (chiede di cambiare una roba che online non vedo discutere, probabilmente manco esiste). 🐭Proprio stamattina ho voluto dare una chance a Boxedwine; pensandoci, posso usarlo in maniera complementare a v86, nei casi in cui questo non va bene. Fare tutto tra telefono e tablet (dato che non sono a casa) è stato un casino, tra lentezza generale, memoria che si satura (per questo devo usare due dispositivi alla volta) e via… e ugualmente non è servito A NULLA. A parte il tempo perso (tanto, maneggiare con gli ZIP sullo Ximi non è veloce) tentando di avviare gli ultimi pacchetti distribuiti dall’autore per Wine 1.7 e 5.0, che evidentemente non funzionano (il primo non so perché, il secondo è colpa di #11), usando il pacchetto di boxedwine.org sono riuscita ad almeno avviare il gioco, ma termina con un errore che credo sia proprio lo stesso di Windows 2000. Nella console di Wine vedo prima del crash una riga fixme:win:EnumDisplayDevicesW ((null),0,0x32f898,0x00000000), stub!, che può confermare i miei sospetti, ma non so se centri o sia una coincidenza. Guardando i file di Boxedwine credo ci sia DirectX dall’8 al 10, quindi non sarà un problema di librerie mancanti. 🐞
Se avete idee, per favore suggerite, perché sono proprio alla frutta, ho finito di giocare ancor prima di iniziare. Il problema è che il gioco non parte con software rendering, anche se in teoria potrebbe usarlo, sospetto che cerchi appunto una GPU e halti se non la trova. (Qui ho caricato il log di Wine.) Ieri sera ho fatto anche tardissimo per andare a letto, per via di questa roba, ma vi giuro ci ho messo un secolo a prendere sonno… questa cosa ora mi tormenta e devo risolverla: so che Touhou è abbastanza leggero da poter girare nel browser, se giochi anche molto più pesanti ce la fanno, quindi ora pretendo di averlo nel browser! Voglio giocarci in Sala Museo! Il problema sono ste cazzo di API; possibile che solo sulle console i giochi funzionano e basta? (Dovrò fare un emulatore Switch per il web, a proposito…) 🧱
@frankel yeah, probably something like that! When I first heard about WASM I thought “thank god, I don’t have to use JS anymore”, but that assumption was also wrong and is now partly a non issue due to typescript. I wonder if there will be any “main stream” usage for WASM as it seems to be still a niche thing…
Be sure to check out Deepti Gandluri's and Austin Eng's talk on #WebAssembly and #WebGPU enhancements for faster Web AI: https://youtu.be/VYJZGa9m34w?si=_PPuJQJ9Zor5AyID. Running Al inference directly on client machines reduces latency, improves privacy by keeping all data on the client, and saves server costs. To accelerate these workloads, #Wasm and WebGPU are evolving to incorporate new low-level primitives. #GoogleIO
Our #GoogleIO talk is finally online 🎉! Thomas Nattestad and I share how Goodnotes ported their award-winning iPad app to the Web thanks to #WebAssembly, and SwiftWasm specifically. Next, we give an overview of how #Wasm is being used by various product teams at Google, including Google Photos, Sheets, Meet, and others. Lastly, I show how C++ image filters from a fictitious iOS and Android app called Delayedgram (🥁) can be ported to the Web and the filter code be shared!
I thought I would take up the challenge of getting @enhance_dev#WASM working with #aspnetcore with the ability to SSR web components directly into the request pipeline.
Someone big doing this has been such an inevitable development but it has taken so long! With #WASM now included in standards and supported in pretty much every browser there is an opportunity to treat the browser as the target platform abstraction for high performance stuff like #games. And there is nothing the actual underlying OS can do to gatekeep that content without breaking the web! https://www.gamedeveloper.com/mobile/microsoft-launching-web-based-mobile-game-storefront-in-july
@Migueldeicaza I was thinking this ever since you made .NET cross-platform way back in the day, but MS didn't manage to get it taken up as a standard in browsers.
Without Nix, how do you set up complicated build/test environments on other systems? The sheer amount of sedimentary layers you need to do #WASM or #WebGPU stuff is astounding, and then you add the various utility Python libraries needed to glue together a test harness.
🎧 Just recorded episode 2 of the #WasmAssembly podcast with ✨ Deepti Gandluri ✨. In this episode, we talk about #Wasm's standardization, bleeding-edge and mature #WebAssembly proposals Deepti is excited about, and—of course—#AI and #WebGPU!
It's scheduled to be released in two weeks 🗓️. Now is a good time to subscribe to the show in your favorite podcast application: https://wasmassembly.libsyn.com/!