Show HN: Sprig, open-source game console and engine, by teenagers for teenagers
Hey everyone, I&#x27;m Cedric and part of the Sprig team. I&#x27;m 19. I&#x27;ve been trying to make games since middle school.<p>Right now I&#x27;m working on getting Lingdong Huang&#x27;s - who has made a bunch of really cool interactive experiences[0] (like a human face eating simulator) - he made a Sprig game for us[1], I&#x27;m trying to get it working on the physical device - but there&#x27;s a problem, since the device is Raspberry Pi 2040 based and only has 256kb of available RAM (yet the games are written in JavaScript - we run them using our own little JerryScript based runtime[2]).<p>The runtime also runs on personal computers, not just arm-eabi-none, to help us test the games to get better error messages than the physical hardware can give (because no operating system). We call this our Sprig emulator, even though it&#x27;s just the runtime compiled to a different architecture, hooked up to CoreAudio and a minifb window. Thanks to the emulator, we know Lingdong&#x27;s game theoretically only uses 180kb of RAM, so we should be fine. And it actually works great in the emulator, but when I try to run it on the device it doesn&#x27;t get past the startup screen ... which hurts because the entire reason we made the emulator was to get better error messages.<p>All I can do now is puts(&quot;&quot;) debug everything and figure out what code is reading or writing out of bounds and making the device freeze. I probably configured the heap to be too small again.<p>I have always loved finding excuses to figure out how things _actually work_, which is why every time I sit down to make a game, one thing leads to another and I&#x27;m making a game engine. Working on Sprig has taken this to a whole &#x27;nother level because it&#x27;s essentially our own operating system, too. Nobody tells you if you overflow the stack, the stack guard is only 32 bytes and disabled by default. It all started as a module for Kaluma, but we hit so many performance, RAM and flash constraints that we found it was better to write our own JS runtime. Apologies to Kaluma which is also trying to frontpage HN right now! We both use JerryScript heavily, but Kaluma connects you directly to the GPIOs and IRQs. We just connect you to the screen and the buttons through the same API as in the web browser, which is handy for making tile-based games.<p>[0] - <a href="https:&#x2F;&#x2F;lingdong.works&#x2F;" rel="nofollow">https:&#x2F;&#x2F;lingdong.works&#x2F;</a>
[1] - Lingdong&#x27;s game. Keep in mind the controls are all WASD and IJKL because the device only has 8 buttons. <a href="https:&#x2F;&#x2F;editor.sprig.hackclub.com&#x2F;?file=https:&#x2F;&#x2F;raw.githubusercontent.com&#x2F;hackclub&#x2F;sprig&#x2F;main&#x2F;games&#x2F;generic_dungeon_crawler.js" rel="nofollow">https:&#x2F;&#x2F;editor.sprig.hackclub.com&#x2F;?file=https:&#x2F;&#x2F;raw.githubus...</a>
[2] - github.com&#x2F;hackclub&#x2F;spade