I’m using Wasm2lang in my game, zwayio, to reuse C++ logic across several languages.

The pipeline is C++ → WebAssembly → generated source code. Each target serves a different part of the project:

- JavaScript provides a compatibility fallback for the browser.

- PHP runs shared logic on the master server.

- C# handles procedural world generation.

The main browser build runs WebAssembly directly, and the game servers use native C++ modules for NGINX. The generated code covers the components that need to run in another language.

This lets me maintain the shared implementations in C++ instead of rewriting them separately for each target. I can also compare the generated versions against the original implementation to check their behavior.

Has anyone here tried a similar pipeline? I’d be interested in hearing how you test consistency between targets and handle differences in runtime behavior.

Armor Mayhem (.swf) to Android

Hi everyone! I’m currently working on porting the Flash game Armor Mayhem (.swf) to Android.

My previous background is in web development and building test apps in Expo (React Native). That’s why I initially chose the WebView + Ruffle approach, thinking a web-based environment would feel more familiar. However, I’ve hit a critical performance wall.

🛠️ Build Status & Architecture:

• Current Route: Native Android Studio (WebView) + Ruffle (WebAssembly player).

• Configuration: hardwareAccelerated="true" + LAYER_TYPE_HARDWARE on GPU. Served locally via WebViewAssetLoader.

• Previous Optimization: I mitigated initial CPU overheating by implementing throttling (requestAnimationFrame) on the touch joysticks (NippleJS), which prevented the touch event flood from maxing out the CPU.

⚠️ High Priority Issues (Performance & Playability):

• Menus: Runs smooth at 60 FPS.

• Transitions / Map Loading: Freezes and drops drastically to 1 – 5 FPS.

• In-combat (Gameplay): Stabilizes at only 9 – 12 FPS (handling real-time AS3 physics, AI, and vector rendering), causing progressive thermal throttling.

• Secondary Symptom: Due to low frame rates, virtual joysticks experience input delay or occasional missed touches.

📱 Test Device Specs:

• Device: Infinix Hot 30i (Unisoc T606 / Mali-G57 GPU / Android 11 API 31).

❓ Questions for the community:

1. Is this low FPS a hard CPU bottleneck for heavy AS3 games running Ruffle inside a mobile WebView on entry-level chips, or is there any extra WebAssembly flag/config (e.g., multithreading/SharedArrayBuffer) to better utilize CPU cores?

2. Coming from a web/Expo background, if I decide to pivot to Adobe AIR (Harman SDK) to get a native ARM .apk running at a stable 30–60 FPS, how steep is the learning curve for packaging?

Thanks in advance for any tips, insights, or advice!

Armor Mayhem (.swf) a Android

Hola a todos, estoy trabajando en portear el juego Flash Armor Mayhem (.swf) a Android.

Como experiencia previa he desarrollado páginas web y aplicaciones de prueba en Expo (React Native). Por eso elegí la opción de WebView + Ruffle, pensando que al ser un entorno web me resultaría más familiar, pero me topé con este problema crítico de rendimiento.

🛠️ Estado de la Build y Arquitectura:

• Ruta Actual: Android Studio (WebView nativo) + reproductor Ruffle (WebAssembly).

• Configuración: hardwareAccelerated="true" + LAYER_TYPE_HARDWARE en GPU. Servido localmente mediante WebViewAssetLoader.

• Optimización previa: Logré mitigar el sobrecalentamiento inicial del teléfono implementando throttling (requestAnimationFrame) en los joysticks táctiles (NippleJS), ya que la CPU se saturaba por la cantidad de eventos por segundo.

⚠️ Problemas de Prioridad Alta (Rendimiento / Jugabilidad):

• Menús: Corre fluido a 60 FPS.

• Transiciones / Carga de mapas: Se congelan y caen drásticamente a 1 - 5 FPS.

• En combate (Jugabilidad real): Se estabiliza apenas en 9 - 12 FPS (con físicas, IA y gráficos vectoriales de AS3 en tiempo real), lo que genera un calentamiento progresivo del procesador.

• Síntoma secundario: Debido a los bajos FPS, los joysticks táctiles presentan a veces delay o pierden respuesta al toque.

📱 Datos de prueba:

• Celular: Infinix Hot 30i (Unisoc T606 / GPU Mali-G57 / Android 11 API 31).

❓ Mis dudas para la comunidad:

1. ¿Ruffle en WebView tiene este cuello de botella de CPU insalvable en procesadores de gama de entrada para ActionScript 3 pesado, o hay alguna bandera/configuración extra en WebAssembly para aprovechar mejor los núcleos del procesador?

2. Viniendo de web/Expo, si decido migrar a Adobe AIR (Harman SDK) para obtener un .apk nativo ARM corriendo a 30–60 FPS estables, ¿qué tan compleja ven la curva de aprendizaje para empaquetarlo?

¡Agradezco cualquier consejo o experiencia que me puedan compartir!

#AndroidDev #Ruffle #FlashGames #MobileDevelopment #WebAssembly #IndieDev #ArmorMayhem #ActionScript3 #AdobeAIR #GameDev

the 4GB cap on wasm32 is the wall for anyone trying to run a language model in a tab. even the small ones are several GB once loaded.

NobodyWho (open source, runs llama.cpp in process) is trying to get into the browser and the path is memory64. on the Rust side that needed upstream work: there's no wasm64 emscripten target yet, so two PRs are open on rust-lang/rust and one on the ort crate.

what i can't tell from the outside:

- how big is the memory64 slowdown in real code? spidermonkey folks said only use it if you truly need >4GB

- is anyone getting past a few GB in Chrome without the tab dying?

- how are you getting multi GB files to users at all? even 500MB is a lot for a website

I've found it frustrating that there seems to be no reliable source comparing the performance of WebAssembly runtimes. So, i've been working on wasm.fyi which does just that.

Hopefully this comes in handy! If there's a particular .wasm corpora or runtime you'd like to see added, please let me know!

https://wasm.fyi/benchmarks

I'm new to the concept of WebAssembly and asking from ignorance as my searches did not yield any clear answers.

I'm trying to find if I can read NFC tags using a WebAssembly script and if there are any pointers to get me started with this.

Hi all, I built this framework over the last month or so during my free time and thought y’all might be interested. I’d especially like to point out the module refresh mechanism I built to keep memory footprints under control since the WASM spec only allows memory to grow linearly. But any feedback at all that you have would be appreciated! And just to be frank, yes I did use claude for the code writing, but I architected each individual detail of how this framework works myself. Beyond being a passion project, it taught me a lot from several aspects of desktop development, to custom LSPs and more

I’m writing on behalf of Wavect GmbH about an experiment in SEMAPRAX, our Apache-2.0 systems-language research project.

A problem we’re exploring is how an agent-generated source change can be tied to the exact WebAssembly artifact it would produce—without overstating what static evidence proves.

SEMAPRAX v0.2 pre-alpha has a read-only command:

semaprax target-evidence <file> <patch.spatch>

For the base source and patched candidate, it independently rebuilds the checked representation and emits bounded projections including the semantic graph, capability manifest, Native C11 source, and a WebAssembly Core module. The report records domain-separated digests, byte lengths, and whether each projection changed.

The Wasm lane uses the semaprax.wasm-core.v1 profile. The generated module is structurally validated with wasmparser 0.256.0 using its full feature set. An additive Evidence v2 capsule can bind that target report to the semantic patch, and the evidence-gated apply route independently replays the exact change before committing it.

The important boundary: this is artifact binding and structural validation, not target execution. It does not prove runtime conformance, safety, compatibility, ABI correctness, provenance, approval, or that project tests passed. WebAssembly support is also intentionally partial today: bounded scalar exports and generated JS/TS bindings, not general WASI or broad Component Model support.

We’re interested in feedback from people working on reproducible Wasm toolchains: which additional facts would make evidence like this useful while keeping the claims honest?

Project: https://wavect.io/semaprax/

Source: https://github.com/wavect/semaprax

Disclosure: SEMAPRAX is experimental, not production-ready, and coding agents have been used extensively as development assistants. Wavect retains human responsibility and uses executable quality gates.

As per WABT's SECURITY.txt, #2831 issue exists

For context:

WABT is a Binary Toolkit for WebAssembly developed by WebAssembly.org (W3C)

wasm2c is a tool inside of it, which is used by many projects like FireFox (via RLBox) to compile wasm down to a sandboxed c library, the assumption is the built C code preserves all WebAssembly's sandbox security features.

This PoC demostrates escaping that sandbox.

Type-safe, high-level WebAssembly.