Corallium

Devlog #14
ITS DONE!!!!!!!!!!!!!!!

The demo’s pretty much done! I just have to add a background track for the game, and make the running animation look better! We’re done ppl! After 5 months, I present the first demo of Corallium, Strider!!!!!

Devlog #12
Our first demo game works! This technically means that the project is fully finished, but I want to polish up the game in the remaining 3 days. A short video of the gameplay of Strider (the demo) is attached below. This project has probably been my most ambitious one yet, considering that it not only included building my own custom virtual machine that interprets bytecode (at a pretty fast pace actually, considering the fact that the demo runs well even though the compiler is absolute trash when it comes to optimization), building a compiler for Coral (my custom language for Corallium), and a standard library, plus graphics, audio and disk subsystems. This is probably gonna be my penultimate devlog, so thanks for following along! I’ve attached some of strider’s source code along with the gameplay below.

Devlog #11
All driver integrations are done! Audio, Graphics, Disk, Console, and Clock access is now possible from within coral code! I now have to add memory management, and some string manipulation, then the stdlib is done! I also gotta give the ability to link random files into the final binary produced by the compiler, so that sound samples and spritesheets can be loaded from the disk, but that’ll come later. For now, enjoy the demo below!

Devlog #10
GFX is integrated! There’s some video footage of it working below, and some of the compiled assembly, along with the source.

The compiler works!!! All tests produce the correct results, and imports are now working. Below you can see the first fully-fleged programs read, tokenized, parsed, compiled, and executed by the VM, along with some of the tests! At this point the main things to work on next is allowing structs to have methods, and from there, building a basic standard libary that allows users of the language, Coral (not very creative ik) to use the VM’s subsystems (gfx, audio, disk, etc), and also dynamic memory allocation, as based off an attemt a few moths ago, it’s too complex to implement in assembly without losing my mind, so this lib will be the first large program that the compiler will handle. With that done, the project’s gonna be complete! I’ll have to make a few demo’s, but those will proably be a seperate thing.

Well, it seems building a compiler ain’t as easy as I thought it would be. I’ve started to build out a test suite(images below) of sample programs, and it turns out that my backend was very, very delicate, and broke nearly all the time. Adding in defer statements had me spend nearly a week debugging the backend, but it seems fine now. I still have to add generics, error handling, and modules, so this’ll proably take a while. But all the samples do work now!

Devlog #7
It’s been a while, hasn’t it. I’ve been busy building a compiler! So I;ve finished the rough draft version, but it took quite a while, leading to the gap in devlogs. The language, Coral, looks like the first image below. The way compiling works is that it first parses the source code into an AST(Abstract Syntax Tree, the code represented as a tree), then converts that to a relatively high level IR (Intermediate Representation), which has similar syntax to the final Assembly, but has infinite virtual registers, and abstracts away having to select specfic instructions for diffrent data types (Unsigned vs Signed, Floats vs Ints, Int32 vs Int16). Then that IR is feed into the backend which translates it into bytecode.
Below is one source example, and its bytecode. From here, I have to implement generic types, defer and error handling and the compiler will be done! Or at least for now. Hopefully my next devlog isn’t in a month.

Devlog #6
The compiler kind works! It can parse in source code similar to the first image, and spit out IR at this point. I still have to implement some more language features, mainly match statements, and custom types, and implement IR->Assembly translation. Sorry for the long gap between devlogs, the midterms were quite bad. The stack system was also fixed.

Devlog #5
The graphics subsystem is finally done! I’ve integrated it into the device system, and now you can render sprites, layers, and mode-7 style graphics from the assembly code. I’ve also further expanded the capabilities of the executable builder, now it supports symbols for each function that’ll be initialized upon running that function, and I’ve reworked a few internal systems, mainly the data tagging system, so now the VM supports 32bit and 16bit ints, and 32-bit floats. The main thing I’ll tackle next is redoing the VM’s stack system, as currently any data type can be pushed on and off, with no tagging, so accessing the stack from a ptr is a bit messed up. That devlog will probably be in a while tho, as I’m burdened by midterms.

Devlog #4
The graphics engine kinda works now! See the demo below.

Devlog 2.5
I forgot the executable structure photo from the last devlog, so here it is.

Micro-16 Devlog #2
The loader works! We can now load executables, which are structured as shown in the first photo, from disk (A virtual one at least), into memory, and execute them! The driver system was also refactored to be more modular, and I implemented the audio system. We have 4 square wave channels, 2 triangle, 2 sample channels, which support loading wav files into, and 2 sawtooth channels. I’ve included the system diagram (which I forgot last week, sorry), a concept logo(sorry for it being so blurry, I forgot to upscale it) and the code for a test executable in the image gallery. The next major component to work on will be the graphics system, and it seems that it’ll take quite a while until that is done, so see y’all in a week!

Our first devlog! Up until this point, I’ve mostly worked on the inner workings of the interpreter, because, as this project is aiming to be a better verion of the Atto-24, having a strong core to stack more functionality on is pretty important. At this point, we have all arithmetic, stack, memory, function call, and IO instructions implemented. Since Micro is designed to allow for multiple games on one “cartridge”, I’ve been working on a executable format which allows us to load in games and libraries at runtime, at specific memory locations chosen at build time. The actual executable format and processing code is done, I just need to finish writing the loader. That’s gonna be done by the next devlog probably, and from there, we will tackle graphics and the other external devices needed to make this system work. The photos attached show the general architecture, and a sample executable I’ve been using for testing. I have been working on this project for a little bit before flavortown started, which accounts for the codebase size.