wasm-snake VS waforth

All of the game graphics, state and logic are written in WebAssembly Text. The host environment (Javascript) is responsible for:

Game tick loop

User input

Providing characters "0123456789GAMEOVER" byte data on game startup

Blitting the pixel buffer to the display with WebGL2

The game uses 3 virtual pages of memory (64kb each) for a total of 192kb. Within those exist the pixel buffer contents, the characters data and snake positions. For more detailed breakdown you can check src/snake.wat.

The memory is shared between WASM and JS. On each game tick, the pixel buffer region of the memory is transferred to a WebGL2 texture, uploaded to the GPU and blitted to the screen.

For more info you can refer to the repo - https://github.com/gnikoloff/wasm-snake

Super nice project! I also spent the last month writing a WASM interpreter ( https://github.com/rrampage/wart ) using Java 21. I started it as an excuse to try out the pattern matching in switch / sealed classes in Java. It kind of snowballed in scope and can now run Doom and Waforth ( https://github.com/remko/waforth )! Have not yet tried compiling it to WASM and running it as a meta-circular interpreter.

Concerning the point 8. There is an online Forth system demo Thurtle (in the browser) with turtle graphics, which is based on WAForth.

There's a note on the page from 2022-08-19, that a lot has been added to it. It also links to the github page[1] for the up-to-date changes.

I am a Lisp, April, APL/J/BQE, and Forth[2] aficionado. I did some file munging programs in Factor back in 2012 at my job to sort through theater attendance logs in Word to compile statistics.

[1] https://github.com/remko/waforth

[2] https://factorcode.org/