💾 Archived View for republic.circumlunar.space › users › korruptor › blog › 2022-07-20-VirtualConsol… captured on 2024-06-16 at 12:22:21. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

🕹 Virtual Console

My recent retro coding on the Amiga got me thinking [far too much] about another idea I’ve been cogitating on for a while: what shape would a"virtual console" for my own stuff take?

Why a “Virtual Console”?

I’ve got a lot of ideas for simple-ish, 2D games, that I’d like to make without the overhead of a “big” engine. I could use Unreal, but that’s the definition of a sledgehammer cracking a nut. I could use Godot, but again, that feels too heavy for my needs. Unity is out because, well, I think it's shit.

There are a lot of existing virtual consoles, but most aim for an “8bit plus” vibe; think Pico 8 / Tic 80, that kinda thing… And they’re great! But not quite what I’m after. I want something a bit more Amiga-like. Well, a fancy 16bit console, really. Something with some sane, but hard, limitations, that’s easy to maintain, and (more importantly) portable. I especially want to be able to recompile it onto whatever hardware exists, 20 years from now.

Limitations

Here’s my high-level, mental tick list:

384x216 resolution
3 tile map layers (Far background, background, foreground)
Each tile map can have an independent palette of 16 colours
1 layer of collision (also built from a tile map — would automatically track the foreground layer)
Fixed number of sprites (256?) that can be positioned on one of two planes (Front / Back)
All sprites share a palette of 16 colours
No blending. It’s dithered Alpha, or GTFO.

Any set of restrictions is arbitrary, but I’ve arrived at these for a few reasons.

Tiles make sense for retro games
There’re a bunch of existing tools — TileD, Texture Packer — that would make a pre-compile cook simple to script together.
Palette restrictions force me to make simpler pixel art!
Doing this, the VC framework can be incredibly dumb. For each level, it needs to load an image for each tile map layer, one for the sprites, and build the collision. Everything else can be exposed as “registers” for “game code” to tweak.
Which means… I can embed a simple scripting language for game code.

What to build on

So, nothing too complicated, but it’d be nice to leverage an existing library for the windowing and event handling. I want to use straight C, so I had a look at SFML and SDL2.

SFML is modern, clean, well supported and has great platform coverage, but, it’s focused more on OpenGL & HW Accelerated contexts. I want a strictly indexed colour (fixed colour palette) workflow, so SDL2 – surprisingly – suits my needs better. It’s easy to have an indexed colour, SDL_Surface based setup, that can be pushed over to accelerated SDL_Textures at runtime.

And the other plus: SDL is already 20 years old. I suspect it’ll still be around in another 20. Especially given how many other game engines use it, under the hood.

Oops

So, er, since I’m sliding into a couple of weeks of summer holiday, I started building it out. The EH500 is just at the stage where I need to parse and build the tilemaps. I’ll report back soon.