TIC-80 is indeed a generally more capable console.
The main reasons I'd personally pick WASM-4 over TIC-80 would be touchscreen controller support, more complete documentation, and better performance on resource constrained devices. (WASM-4 can run on the ESP32 and Nintendo DS, while TIC-80 struggles on the significantly more powerful 3DS.)
WASM-4 is a lot of fun! The programming interface is really simple and a great way to learn about the basics of WebAssmembly. No high level language necessary, just write simple programs in WAT format. We used WASM-4 at work as a very early test that our WebAssembly toolchain was working end to end, before we were able to run larger programs in web browsers.
I wonder if anyone is working on a fantasy console with PS3-level graphics. A lot of games on Steam today have retro aesthetics and aren’t very demanding. A game runtime that works on Linux, macOS, and Windows would solve portability and digital preservation.
PS3 graphics aren't that different from modern day graphics, just lower fidelity and the hardware was a bit quirky but other than that they didn't have any particular aesthetic; I don't think the PS2 had either. The PS1 did though, the weird texture shimmering that was reproduced in for example the Bloodborne demake [0] and subsequent Bloodborne Kart, which had to be rebranded to Nightmare Kart for copyright reasons. But that one's made in Unreal Engine 4, with a forum thread [1] saying the effect can be reproduced across multiple engines like UE4, Unity and Godot, using a shader.
* Even more platforms: Chrome OS, Meta Quest, Tesla cars, Xbox, smart fridges, etc. The web is unmatched in platform support and more importantly allows you to completely bypass the software distribution monopolies on all of them. Ship freely without anyone's permission!
I'm making a wasm runtime called Taca that has approximately low-end modern capabilities that can run in either web or a separate native player. https://github.com/contextfreeinfo/taca (I also made the intro video for WASM-4.)
Do I understand correctly that KWAK-8 is designed such that porting applications from the fantasy console to actual hardware (or vice versa) would be relatively easy? That's pretty cool.
Maybe like what the Game Boy would have been if it had had a framebuffer. It's a little bit sad, actually, that WASM-4, like the Pico-8, is a framebuffer console - there's less cool tricks you can do with raster interrupts and the like.
Were you thinking of changing the 4-color palette for every scanline, like the Atari 8-bits and the Amiga could do? Impose arbitrary limitations so you can find clever ways to circumvent them - sounds like fun!
The Game Boy has less memory than would be required for a full frame buffer, so its “just in time rendering” of sprites and tiles is one way to support its full display resolution and still leave some space for game state in the RAM.
> The Game Boy has less memory than would be required for a full frame buffer
This isn't quite true—you need 160 * 144 pixels at 2 bits-per-pixel. This weighs in at 5760 bytes. There are many other reasons why a framebuffer wasn't ideal for the hardware of the time, though.
Ah, sorry, I think I mixed that up with the opposite practical limitation then – IIRC you can't actually display a fullscreen bitmap on the original GameBoy without some hacks, as the full screen fits 360 tiles, but there's a limit of 256.
But in any case a frame buffer would use up almost the entire available VRAM of 8 KB and would have probably also been more expensive since it would have to be dual-port RAM (I believe the Game Boy's VRAM isn't).
I thought it was clear that arbitrary here refers to any modern reimagining of said limitations, which obviously don’t have to be identical constraints either.
Might be a nice way to get into WASM development, but 4 colors sounds very limiting. Ok, I know the original Game Boy made do with only 4 "colors" (but that was on a black and white display where you probably couldn't have told the difference if there would have been more "shades of gray"), and the Game Boy Color showed these games using a palette of 4 colors, but actually even that device could show 56 colors at the same time!
It's a little bit more complicated than that. The system is limited to displaying 4 colors at once, but the palette can change at any time. Check out what Phantom Shift does with a dynamic two color palette.
The idea of the 4 colors and 160x160 screen is, from my pov, to focus on the gameplay more than the graphics. A lot of people get stopped from attempting to make games because their art skills suck, this removes that element from being an issue.
> A lot of people get stopped from attempting to make games because their art skills suck
As a developer with no art skills myself, I can sympathize with that. But I think that is already taken care of by the low-res display - making pixel art is (in my experience) a lot easier than higher-resolution art. I don't think having 8, 16 or 32 colors instead of just 4 really makes an impact on the art skills required for a game...
OTOH, the PlayDate is a hardware device, so using a monochrome LCD makes sense for cost saving and power consumption reasons. But, even for a hardware device, once you decide you want to have a color screen, in this day and age there is no real (technical) reason anymore to limit the number of colors.
> so using a monochrome LCD makes sense for cost saving and power consumption reasons
The Sharp Memory LCD used in the Playdate is more expensive than a similarly sized IPS LCD. Whilst power consumption was probably a consideration, the main justification was to impose a deliberate game design constraint IMHO.
I agree, I think it’s more of a novelty reason, just a constraint for the sake of encouraging creativity / not just being another place for the same things we already have.
