There was talk of starting up “Gruedorf” again – a little competition made by McGrue and Kildorf, where all entrants would be required to work on something each week and post something about it. Once a post is made, you have 7 days (168 hours) to make your next post, or you “lose”. The goal is to keep a consistent stream of progress each week, and try to minimize “losing” by doing a little work and posting about it.

As far as I know, there is no requirement that the project remain the same throughout all posts, which I’m thankful for. I accept that at this age that my attention span is all over, and I constantly cycle projects even on the best days. Although, finishing something is better than meandering between 3000 unfinished things that get abandoned for the next thing… Probably other rules I’m forgetting.

Anyway, this sounds like fun. Like many regular routines in my chaotic day-to-day life, and like previous attempts when I had way more free time, I’m not sure I’ll be able to stick to any sort of consistent schedule, but going to give this a try in any case!

With full-time work, and general lack of time organization, I have a few projects going on that I am cycling between depending on my general energy. Here are the ones I can remember off the top of my head, but it is not an exhaustive list:

• Wiz, a high-level assembler. The compiler is a work-in-progress, but it’s already capable enough to write demos and games (and comes with working example programs included). It’s a strongly typed language, with C-like structured programming that compiles directly to machine instructions on different retro CPU systems (6502, 65c02, HuC620, Z80, GB, 65816, SPC700). It has gathered a small community on its Discord channel (linked in the project page). This helped stress-test the language, and uncover neat uses I didn’t expect were possible with the language, as well plenty of hair-pulling bugs. But it’s still nice that this tool has a userbase and came in useful to others, even if it was written as a hobby project for my personal use at first. Hopefully more iterations can be made to improve the syntax, the documentation, the compiler tooling, write more example programs and games, add more platform backends, etc.
  
  Dive into the “examples” folder included with the repo to see some examples of things you can do with it. I’ve included a Hello World for many systems, as well as a partial shmup demo for NES, a virtual pet sim on GB, a multiplayer VS game with ducks on Atari 2600, a few VFX tech demos, some libraries for some hardware register definitions and common utilities (GB and NES are most right now, but others are grown as examples and personal projects are made), and some other miscellaneous things.
• nrpg, a turn-based RPG for the NES. This is written with Wiz, and is a real NES program. I’ve been wanting to design a game that has tile-based overworld puzzles such as Final Fantasy Mystic Quest, Lufia 2, Fairune, and others. It will have a battle system similar to classic FF games, with maybe a sprinkle of the SaGa series.
  
  So far I have a working MMC3 tech demo ROM that allows the player to walk around an top-down map with tile-based map. The map can scroll in all four directions without visible scrolling artifacts. The player is so far able to move across the map and jump (like FFMQ and FFL3/SaGa 3), but there is no support for interactive tile objects, zones or NPC system yet. There is also menu system with a working inventory subsystem. Still early, but the foundation needed to make an RPG is slowly coming together. I had to shelve it for a bit but I want to pick it up again soon.
  
  Here’s some screens and mockups (note some GIFs needed to crunched to 1x size to fit in imgur upload limits)
  
  (tileset / map mockup)
  
  (item system - capture from the NES ROM)
  
  (overworld jumping mechanics - capture from the NES ROM)
  
  (a mockup of a battle scene – not yet implemented in game, in typical Verge community style of not having a battle system yet)
   
• Wandering Magic, an action RPG, which started as a PICO-8 demo title (released for the 3-color Jam in late 2017).
  
  Here is the original jam entry – you can play in your browser, and it’s about 30 minutes in length. It features simplified Ys-like bump mechanics for the combat, as well as simple leveling system that balances fast-paced grinding with finding/buying new items to enhance your combat abilities. Most areas are gated by your player’s stats (health, attack, defense), and equipment works as key items.
  
  I wanted to rewrite the game, so I ported the game to regular Lua + Love2D, as a cleanup exercise to make the PICO-8 source legible code again. But eventually, I wanted to rewrite the game again in C, as something that can compile out of the box with SDL, doesn’t require a dynamically-typed scripting language, and doesn’t depend on a heavyweight engine or content pipeline. I also wanted to double the game’s internal framerate to 60FPS (rather than PICO-8’s default 30FPS), increase the size of art assets (already redrawn but not integrated), write a coherent quest, and make the action more compelling. The bump combat mechanics were neat, but sometimes it felt like the enemy melee damage could be telegraphed better so the player could evade things more easily.
  
  (dark mages teleport around and shoot fireballs at you, as slimes spawn in from the sides.)
  
  (fighting a skeleton that guards the entrance to the next area.)
   
• vg - a virtual console system in C (working name, but might stick). This probably requires some elaboration – it simulates the experience of writing games for older consoles, but picks limitations that can be nicely fitted to a modern widescreen 16:9 desktop with gamepad support.
  
  It calls two user provided entry points, one for resetting the game, and one for updating the next frame. All data shared with the engine is global arrays, or through functions that act as ‘system calls’ that convert user-provided data into backend internal texture formats/sound formats/etc. Games are able to tileset graphics and palettes, and then draw them using either tilemap or sprite primitives, which are hardware accelerated. The user of the engine doesn’t need to know the nitty gritty about how the graphics get internally represented (it may be different depending on the platform), and can talk about things in terms of 2D tiles and sprites. Ideally, all games include all data directly as static global data in the source program, and work without solely using the exposed engine functionality. Programs can be written using no stdlib/stdio (except internally to the engine), so to allow extra portability, minimal load times, avoiding the runtime overhead of dynamic memory management by using the static data segment instead, and minimizing runtime issues relating to file I/O.
  
  The screen is resolution is 320x180 (very close to the 320x200 used in the Verge days, but it’s 16:9). Backgrounds can be made from 3 tilemaps of 64x64 each, which can either be comprised of 8x8 or 16x16 tiles. You also get 128 sprites which can be between any of the 3 layers. Tiles and sprites can have 16-step alpha blending applied, and palette remapping for hitflash effects and color swaps. Tilesets are capable of holding up to 512 16x16 tiles at once. The sprite layer and individual tilemaps can select which 256-tile window they are allowed to see of tileset (so one layer could point at a font, while another could be used for the main background graphics or sprites, the arrangement is up to you), Palettes are 256-color 24bpp RGB data. It’s possible to update the tileset graphics on the fly (to load another tileset or modify the current one), and upload new palettes. Input supports gamepads or keyboard input. Persistent saves of up to 16KB are possible (this limit might be expanded)
  
  For audio, it supports wavetable sound synthesis (similar to the PC Engine, SCC soundchip on MSX, Namco N163 expansion chip on the Famicom, GB wave channel, etc) with 6 channels. There is storage reserved for holding short 32-step wave samples and instrument envelopes. There is an MML-like SFX command data that can play different notes, change tracker speeds, apply pitch slides, note slides, vibrato, etc. Playing songs or sound effects works by playing different pieces of the sfx data memory, and is written so that multiple sfx issued on the same frame are played together (for allowing polyphonic music with synchronized channels). The audio thread can run on its own, in parallel with the main game logic, but receives updates from the main thread at roughly 60FPS during normal circumstances.
  
  There’s tools for importing tileset assets from PNG files, as well as converting text files containing an MML-like domain specific language into binary blobs that contain SFX commands.
  
  So far I’ve managed to get a working engine with an example program that I wrote at the same as the engine, need to write actual game with this next. There is a backend currently for SDL that so far compiles on Windows, Raspberry Pi 400, and Emscripten with minimal dependencies (user-installed SDL on non-Windows). It is intended to be easy enough to write other backends in the future, so that porting to non-desktop platforms is a possible option.
  
  Wandering Magic might be a good candidate to port to this engine, since it has enough features at this point.
  
  (a little demo mockup)
   

…Wow that was a lot more rambly than I intended, lol. This initial post is a quite wordy summary of some projects I have going on and the state they’re in, but intending for future posts be more short and concise, unless something interesting warrants more elaboration. Let’s see if the habit of posting here will stick! Hopefully other folks will be posting on here too, to keep things interesting.

Unfortunately, this week I didn’t get as much new work done as I had hoped, because my time was pretty divided.

However, I did manage to contribute some changes to the v2wasm project, which is a project started by Andy Friesen / thespeedbump to emulate playback of Verge 2 games on the web. I made a few tweaks to improve its compatibility on certain verge2 games. These can hopefully be merged upstream soon.

• Added more key[] bindings work in v2 games, by mapping more virtual key code into DOS/Win32-style physical key order that VC’s key[] array expect.
  
  Note that while this solution works on desktop devices, it may have issues with non-QWERTY physical key layouts.
  
  It also doesn’t address key[] usage from a mobile/tablet device which has no external keyboard – something that v2wasm will want to address later. Possibly we can handle this entirely in the web player that comes with Verge Archive, .
• Added a compatibility option in user.cfg named recursive_render, that enables Render() to be called recursively with from a Hook Retrace callback. v2wasm is based on Verge 2.6 which disables recursive rendering by simply returning if you Render() while one was in-progress.
  
  However, this particular decision in 2.6 causes an compatibility issue with Beyond Babel, a game written for Verge 2.5 and winv2. It relies heavily on manual render loops that can be called inside of hook-retrace callbacks. During combat, it handles battle sub-menus by starting different menu loops within its retrace handler. To prevent infinite recursion, it calls HookRetrace(0) and manually Render() + ShowPage(). By unbinding the retrace function, it will do nothing when hitting the R layer while already in a retrace, and then restores the retrace hook after the menu is done.
  
  Since other games might rely on the 2.6 behaviour to not crash, this was made into a user.cfg setting that is off by default. Sort of unfortunate this settings needs to be added manually, but I think it’s the best way to support both versions without requiring VC code changes.
  
  The short version: a new compatibility switch fixes the screen not clearing correctly during battles in Beyond Babel, it might fix other games too.
• Fixed the “manifest.txt” file listing for Beyond Babel so it’ll be possible to play in the Verge Archive player.
• Added support for Fugue to the Verge Archive player. It seems to work pretty well!

I also looked at Wiz, my high-level assembler, a little bit. I received some new bug reports I want to get around to soon, and I also thought a little bit about how to fix some things. No new commits, but planning is just as important when it comes to projects like this.

• using pointer-to-struct to access nested struct members doesn’t work, when indexed addressing modes are available:

struct Stats {
    hp : u8,
}

struct Monster {
    stats : Stats,
}

var monster : *Monster in ix;

monster.stats.hp = a; // error.

This is because currently, the compiler isn’t able to fold the index offset expression into a single constant. Converting the struct member access into indirected addition results in a reduced expression that looks like

*(((ix + offset1) + offset2) as *u8) = a;

to the pattern matcher, which isn’t a valid instruction on the Z80 CPU. However, *((ix + displacement) as *u8) = a exists on Z80! If the compiler could more aggressively fold constants together in this case, Then the issue would go away, and people will be able to use registers as general struct pointers.

• Currently using a far function won’t validate that all call expressions are also far. When the calling convention doesn’t match on 65816, this results in runtime bugs. This is because a subroutine called with JSL must return with RTL, and a JSR must return with RTS, so the call and return convention must match.
  
  Wiz should make 1) far funcs imply far calls everywhere, or b) make it an error to call a far func without far. On platforms where far and near calls can be mixed without introducing problems, I might relax this restriction.
• I also did a little planning for an eventual refactor I would like to do to Wiz’s C++ codebase. I’ve been trying to break out the compiler code into smaller parts in an incremental way.
  
  The compiler.cpp is a 7000+ line source file, and it is becoming a bit messy in its current state. Since passes of the compiler depend on each other, it’s not a super easy thing to just start splitting stuff up immediately. But there are definitely some subsystems and passes that don’t interact, as well as some common things that can be moved into their own file, with clearer data structures and code to operate on them. With a bit of cleanup, the project will be easier to read and maintain. Things would be more clearly separated, and it could eventually add test seams for unit testing.
  
  (Some candidates for clean-up: the scope stack + name resolution, the attribute stack, the inline stack, expression reduction (constant expression folding + typing + qualifying the expression trees), type-checking, type resolution, instruction operand creation, statement-to-IR compilation, IR passes)
  
  The code should have been written with unit tests in mind earlier on. However, I don’t know if Wiz would have ever made it to as far as it did, if it were encumbered by TDD when the basic language design was still being figured out and implemented.
  
  We do have some functional tests, but these run the compiler as a kind of black box, confirming the compiler will generate certain machine code or produce specific errors. Having more compiler-internal unit testing would improve things a lot. Not only would it aid in ensuring build stability, but it would also serve as documentation for some of the finer details in the compiler.
  
  Going to try to aim for some low-hanging fruit to start moving things out, and hopefully this will make it clear about other subsystems that can be split up next. Then once there are more. I know this order to write tests after-the-fact, especially after a refactor, is a little less conventional. But my thinking is that it probably won’t be possible to write good tests until the code is smaller organized chunks with easy tests to begin with. I need to dig things out of the hole they’re in first.
  
  Still not rushing this, but thinking about it.

Aside from that, I drew a little bit. I made this little pixel sketch;

The background is a little bit too visually noisy, and needs a bit more variety in the wall tiles, but it was still fun to draw something. It could be cool to make the walls more crystalline and glossy/reflective (maybe some bright white speculars), and better hue + value-separate the background and foreground tiles.

Anyway, that’s all for this week!

This week I ended up expanding on that MSX mockup of Wandering Magic, and started planning a possible true MSX port of the game.

Then I sat down and learned a bunch about coding for the MSX1.

Along the way, I learned the MSX has a pretty extensive BIOS that provides many routines for common interactions with the hardware, so it took some learning to do things the “best practice” way. Some performance might be sacrificed, but it ensures compatibility between versions. And there are also faster methods for looking up I/O ports for some things, for stuff like graphics coding – where it probably matters most.

I updated Wiz’s MSX “hello world” example to use these BIOS routines: https://github.com/wiz-lang/wiz/blob/master/examples/msx/hello/hello.wiz

Previously I thought you had to write to I/O ports directly if you wanted any sort of speed, since I’m so used to that with other systems, and figured the BIOS was for BASIC programs only. But happy to be wrong here, and it’s easier to write code this way too.

Now back to Wandering Magic. I also coded some sprite drawing code that handles scrolling the sprites off both sides of the screen, and an entity system (so far just spawning/updating/drawing – no collisions, no gameplay specifics yet). I also split the art work into bg and sprite tiles, and convert them using tools.

Next up, I want to draw the background map, and see if I can get some player input and movement. The MSX has tons of RAM available, so it’s probably possible to unpack the entire room into individual 8x8 tiles in RAM, and transfer it to the MSX’s tilemap VRAM afterwards. I guess I’ll try this soon!

See you next week!

Hello! This week, I made more progress on the MSX port of Wandering Magic in my spare time in the evenings.

I managed to implement a few things that are pictured in this GIF.

First off, I made a map loader, It loads an uncompressed tilemap from ROM into RAM, each part of the map is made up of 16x16px blocks called “metatiles” – 2x2 arrangements of 8x8px hardware tiles, along with some associated metadata like collision flags.

In addition to loading the tilemap into RAM, the metatiles for each cell are then unpacked into the raw 8x8 tilemap format that the MSX VDP expects, and this will be copied to the screen between room switches.

The upper area of the screen that contains playfield of the game is 16 tiles wide x 10 tiles tall. The lower part is reserved for HUD elements. The camera doesn’t scroll – the MSX1 is bad at hardware scrolling, and I designed the game around having individual screen-sized rooms.

Next, I added player input and movement with the keyboard. That was pretty fast! One thing that was a little tricky is that the MSX returns a directional code from 0 - 8 (0 = no direction, 1 = up, 2 = up-right, 3 = right, 4 = down-right, etc. going around the circle clockwise), rather than having a separate input for each direction. This is at least if you use the standard “direction reading” routine from the MSX BIOS, so turning that into independent x and y axis takes a little bit of translation. But a nice feature of the BIOS, is that it standardizes reading both keyboard or joystick for directions and buttons.

There’s also a way to read the keyboard matrix directly, which is necessary if you want to use other keyboard keys besides arrows + space bar. It seems pretty common to find MSX games that use arrow keys, space bar as a primary action, M as subaction, function keys for menus, and support 2 button gamepads. So I guess eventually I’ll need to look into all of that.

After that, I added entity movement with tile collision support. The entity movement was pretty challenging to write but after some trial and error and lots of debugging to step through things, I managed to make something functional,

The collision code even supports a neat feature – corner nudging! This will automatically slide the player around corners when it detects only one side of the collision test is obstructed. For example, if you’re walking up into a corner that is obstructed to the right but not the left, then the movement code will redirect your movement to the left, off the obstruction. As soon as the way is clear again, the movement code goes back to behaving as normal, proceeding in the direction the player inputted. Corner nudging makes it much nicer to do pixel-based movement through narrow spaces (especially single-tile wide ones), without needing to lessen the size of the player’s collision box too much.

Collision still needs a lot of work to optimize things better, since it does slow down when there are several entities on screen. For testing this, I duplicated the player entity 32 times. I observed the framerate dip as soon as the movement began, with even more slowdown happening when moving on diagonals (since it needs to test on x and on y). When the entities are still, or there are less entities, no slowdown occurs, This slowdown problem also occurs at 16 of 32 entities, but only when moving in both directions at once. I’m not sure the exact tipping point where things spill out of the available frame time, but there’s a bunch of things that could be improved. I can live with some slowdown in heavy scenes, but I’d like to push things better than they stand right now.

I need to measure things better, but there’s a quite a few steps involved:

• converting values between 2’s complement fixed-point formats (4.4 -> 8.8 -> 16.8 with sign extension)
• adding large numbers, using the carry flag to synthesize larger additions from smaller additions.
• bounds-checking the entity position. This takes a fair amount of time, but is necessary since entities can move off the sides of the map.
• converting pixel coordinates to tile coordinates
• reading the actual data out of the tilemap
• branching on the collision results
• updating the position (if succcessful/unobstructed), or stopping the movement (if failed/obstructed)

Here’s some code for anybody interested.

The optimization steps to improve this could be messy, but hoping that my experience from writing programs for the Game Boy should help here. The Z80 is more powerful than the GB’s processor, so hopefully some of the more ugly tricks for performance aren’t needed, but I still have ideas for things to try.

The performance issues are also not even accounting for the added processing required to do entity-vs-entity hitbox collisions, going to need to do that soon too!

Lastly, I looked at adding a graphics loader for entities, so each room can have unique sprites depending on what is spawned there.

Half the sprite tileset is reserved for the player + common sprites like treasure chests, item icons, explosions, enemy spawn indicators (like Zelda 1’s cloud puffs), etc.

The other half is loaded between each room, allowing for entities to reserve their own sprite art, as well as the art for all their subobjects ahead of time. Then when the game is in action, no new graphics are required – simply spawn things that reference tile indexes based on what’s in the loader cache (cleared each room).

This approach of loading ahead does mean that any particular room’s full contents (including subspawns) must be known ahead of time, but it also frees up more performance to gameplay, since graphical loading when the screen is in use means sacrificing vblank time, and potentially causing things to split across multiple frames. This quickly becomes messy, and I’d rather avoid any of that for this.

There’s still a big list of stuff remaining! Not sure what I’ll do yet, but hoping I can continue to chip away at stuff on this.

These are all features from the original Wandering Magic game that still need implementing:

• entity-vs-entity collisions
  • support for obstructing other entities
  • hit-scanning for bump attacks (think Ys, Xanadu, Fairune, and similar games)
  • pushback on attack hits
• entity movement/collision optimizations
• hit flashes (temporarily colors the entity palette upon a hit)
• HUD drawing
  • health bar + exp bar
  • health number + level number
  • attack + defense + gem icon and values
  • enemy health bar HUD (shows health bar and name + sprite when attacking an enemy)
  • modal full-size textboxes (hides HUD and displays text until player confirms)
  • short timed messages (uses same area as enemy health popup, disappears after time)
  • pause menu - lets you look at your equipment, and use healing items.
• room switching
  • switching rooms when the player moves outside the screen.
  • doors that switch rooms when walked over
• entity implementations
  • enemies (walk into to attack)
    • slime (weak, moves randomly, infrequently attacks unless the player hits them)
    • bat (alternates between flying around the room, resting, and flying at the player)
    • ghost (floats around the room slowly, occasionally moves toward the player)
    • dark mage (teleports around, shoots projectiles aimed at you)
    • snake (fast and aggressive, charges at the player a lot)
    • knight (slow and indestructible, you need a much stronger weapon)
    • skeleton (fast and runs around around, throws bones)
    • “red”/stronger versions of enemies (these have improved hp/atk/def/speed, and also grant more exp for defeating)
    • new enemy types
  • destructible trees/doors
  • chests (walk into to open)
  • dialog npcs (walk into npc to see their textbox)
  • player projectiles
  • enemy projectiles
  • shop items (stand over with sufficient gems, press action button to buy)
  • mini doors (if the player stands in front of them with a ring, transform them to a miniature form, and allow the player to proceed through the door)
• save system
  • loading
  • saving
  • checkpoint tiles that trigger saving when the player presses the action button while standing on them.
• game systems
  • level ups and experience
  • attack and defense stat gains on level up
  • healing HP to full on level up
  • equipment (automatic, each item belongs to exactly one slot, the next piece of equipment is always better than the last so it replaces it)
  • magic (an infinite use item that spawns a projectile when the player presses the action button)
  • healing items (consumable / limited use, restores player HP)
• joystick input
• support for more keyboard keys
• title screen
• game over

The above list started as an immediate task list, but quickly grew to a larger list of stuff to do while I was writing this. Heh, whoops!

Well, that’s all for this week! Hope to see you again soon!

This week was slower!

I worked on Wandering Magic MSX some more. I’ve been porting the enemy logic from the original Lua code to Z80 Wiz code, So far, it’s going okay, but some things that are really easy arithmetic / comparison / math library calls in a high-level language, have to tediously be rewritten in assembly. Things like comparisons, while easy when comparing 8-bit values, quickly get messier when extended to 16 or 24 bits. Also, there’s a fair amount of counter variables that need to be split into multiple 8-bit pieces since (IX + dd) indexed addressing mode can only address a single byte at a time – so increments/decrements/adds/subs need to propagate intermediate results across the carry, zero, or negative status registers so that 16-bit math can be done. Eventually register pressure becomes important too, and book-keeping all of this can be tiring. I put it down for a moment, but I’m getting closer!

The “patrol” AI for the slimes, snakes and knights is a bit complicated, but the good news it will make a few enemies in the game work at the same time, once supported. Going to keep pushing this porting effort, and see about phasing features in a bit at a time, until each can be tested and verified separately.

Also, my MegaFlashROM SCC+ SD flash cart arrived in the mail:

Still awaiting my Panasonic FS-A1, but once I have that, I’ll be able to try things out on a real MSX system.

Recently, I was also a bit bored, and decided to write some data structure code in C. It had been a while since I wrote a hashtable/dictionary type, and so I made a hashmap implementations.

The hashmap does open-addressing / linear-probing and uses user-provided storage for tables with zero heap allocations during insertion. Instead the hashmap’s put operation simply fails when the table is too full. Like most hashmaps, it has best-case O(1) constant time, and worst-case O(n) linear time for lookup/insertion/removal, and it has O(capacity) iteration time.

I also provided some helper functions to adapt this to a dynamically-allocated + resizable hashmap, by adding an insert operation that will swap the storage to a bigger area on the heap as the capacity is reached. I also made it so hybrid static/stack allocation + dynamic allocation could be used in the same hashmap, by keeping the user-provided storage and only allocating when capacity of the current user-provided storage is exceeded. This allows optimization akin to the SmallVector type in LLVM, but for a hashtable.

In addition, I also did some library functions for a contiguous list data structure. Like the hashmap, they both serve as a simple wrapper over a plain array of data, or when wrapped with some dynamic-allocation, a resizable vector. And it’s possible to mix both pre-allocation + heap use again.

Stuff that doesn’t need the heap though, will be able to cleanly avoid this and build lightweight lists and hashes, or statically-allocated ones that are loaded when the program begins.

I also worked on a lightweight parser for a toy language. In some ways the scripting language could be thought of as similar to VergeC in some ways, where there are only a few built-in data types, no garbage collection. But unlike VC I was thinking to have automatic memory management through unique pointers to data + ownership/move semantics. Not going to allow refcounting, because the whole cyclic resource ownership problem it can cause.

Within the compiler I had the idea for some kind of language that could target a fairly “robust” set of features with a single-pass parse, but no Abstract Syntax Tree, instead convert directly to Immediate Representation, and either interpret that in a VM as a “scripting language”, or translate into something like equivalent C code, WASM or LLVM IR.

The idea being this language could be used to prototype stuff fast as a scripting language, and then build to C or IR when performance is desired.

I was also thinking of potentially digging out an old register-based VM (that I think I called “lilvm” heh, not to be confused with llvm) I had started, and see if any ideas from that mesh.

Anyway, I don’t really know what I’m doing yet, this idea is very much in the air, and so far I’m just building pieces that could potentially be used in a compiler. and coming up with ideas for a simplistic scripting language that uses strong typing, and compiles quickly.

My hope is something as easy to embed as Lua, but with no GC, C-like + simple to learn, and have the ability to turn into native code later. I don’t know if I’ll finish this, but having fun trying stuff out.

Also, outside that, I turned 33 and relaxed a bit. Happy Birthday me! Next weekend is easter so an extra day to relax again soon. Talk more next week!

Heyyy! What’s new with everyone these days?

I figured it would be nice to start a topic since the forum reboot and stuff and see what’s new.

.

Something lately has made me interested in looking at Verge again for fun. The other day I was feeling nostalgic, and started messing around with Maped2 in DOSBox and drawing tiles and maps. (It’s pretty fun! even if DOSBox crashes frequently!)

I’ve also played around with PICO-8 a bunch and something about an environment where it’s easy to draw sprites to the screen and make little scripted stuff is fun. I think some of the appeal that PICO-8 has is similar to what Verge had going for it, quick and easy to throw together projects and make small games.

(Part of me sorta wants to go back and revisit Verge 3 (and bring back VC from the 3.2 release into the master) and port it over to SDL2 for better portability, and add some sleep/vsync stuff to ShowPage so it runs with less CPU consumption for most games. It could be kinda neat as a small change to make the engine more usable/preserve older stuff and make it run more stable on new computers)

.

So yeah, other stuff. For a while I worked at Tribute Games in Montreal here. In April 2017, I released a game called Flinthook for PC/PS4/XB1/Switch, which is a roguelike action platformer with pirates in space and run-and-gun action. Since then, I did a few odds and ends and eventually left there. This year has been all over the place (part freelance, part new job) but been poking around with little projects here and there.

What has everyone else been up to?

This past week, despite being very busy, I managed to be a little more productive than previous weeks.

I closed a few bugs in Wiz:

• Fixed SNES debugger symbols to work again, so now you can get nice named labels and variable names in Mesen-S and bsnes-plus when debugging SNES programs.
• Someone reported a Mac OS crash in the compiler! It was caused by C++ argument evaluation order being unspecified. This means that the order depends on the compiler vendor (usually dictated by the calling conventions of the target system).
  
  Usually this is easily avoidable, however std::move is a core feature as of C++11, which will transfer ownership of resources (eg. using unique pointers to enforce single ownership and prevent memory leaks, or for avoiding expensive copies of heap-allocated data structures). For unique pointers such as std::unique_ptr (or Wiz’s equivalent-but-better-inlined wiz::UniquePtr), moving is necessary, and the copy assignment and copy constructors are deleted to enforce move semantics.
  
  There is is a bit of a hidden “foot-gun” waiting to go off though: std::move has the side effect of moving its contents to the destination and nulling out the source afterwards, to preserve the single ownership of a piece of memory. This is how std::move is meant to work, so nothing unexpected here so far. But often, there is the need to move a value AND access some its members in the same call.
  
  Code like f(std::move(ptr), ptr->member); is easy to slip into the codebase by accident, especially as compilers don’t generate any warning for this. On x86-based Windows machines, where the argument evaluation order is right-to-left, this code will compile and run as expected. On Mac OS, this will compile too, but it will always crash at runtime, because it evaluates function arguments left-to-right – this means the std::move(ptr) is called before ptr->member is evalated.
  
  The fix to this crash is to store things into locals before a move occurs, so that you don’t use-after-move. But the nature of this being “unspecified” by the C++ standard means that the compiler never warns about this bug, and it may even appear to work if the vendor/platform-specific evaluation order just happens to works in the program’s favor. As a result, any change to the code could introduce this bug without notice. This reliance on the evaluation order is never desirable when wanting to write portable cross-platform programs in C++ that run reliably (and without crashing).
  
  Thankfully, clang-tidy is a useful static analysis tool that can detect these sorts of problems by running with the bugprone-use-after-move check enabled. It caught the crash and a number of others within the codebase.
  
  VS2019, for all of its bloat, even comes with clang-tidy. This would be great, but MS unfortunately messed this up somehow and shipped an update that breaks being able to do static analysis – I had to manually patch my VS2019 install’s version of intrin.h to get things working. Sigh. Anyway. A long journey later and things are working better.
   
• Fixed the issue with nested struct access, Now you can declare an alias for register, and use as a pointer-to-struct by going var monster : *Monster in ix; and then use it like monster.stat.atk = 10;

With that weight lifted, I started to get planning out the battle system and monster encounters for my NES RPG.

I thought that it might be useful to design the encounters in a sort of “top-down” kind of way. having families/categories/taxonomies of monsters that all share common traits and behaviour. Within each family, the monsters would be divided into tiers, a sort of “evolutionary hierarchy” (for monsters) or “chain of command” (for humanoid types), where each tier is a higher difficulty and more powerful.

Then, monsters families themselves belong to different environments. Things would be designed such that there’s a nice variety of different encounters spread across the environments – gradually increasing in difficulty, or introducing a new challenge or mechanic to the fights to keep things interesting.

My hope is that this sort of approach will make it easier to get a general image of how the game should “look”, and allow me fill in boxes as I go. This should give a more coherent idea of the big picture of how things flow across the game area-to-area, something which usually gets lost when doing in a bottom-up method, one-map-at-time.

Monsters themselves would have distinctive behaviour, and use a combination of some state-machine driven logic, turn-based countdowns, and reactions (counters). Each state would be capable of producing a list of actions that it wants to consider, as well as a preference score to each one. States could transition depending on specific conditions like HP %, being hit X many times, detecting the player doing something, etc. Monsters themselves could also track grudges, prioritize protecting other monsters and other stuff.

But I am thinking of implementing monster AI in a way that it’s mostly driven by the monster’s state and a few other scratch variables. I think this method of monster design could be pretty versatile despite being fairly simplistic.

I also had some thoughts about the battle system itself. I had originally made a mockup in FF6 style, but I was thinking it might be nice to use something a little different from ATB battles. I was thinking it could use initiative-based turn orders with a combination of randomness + character speed to help determine the order. Combatants would decide and act at the same time when their turn comes up. Some actions could potentially have a charge time (that resolves as its own turn between combatant turns). Actions could also have a cooldown that affects the timing of a combatant’s next turn.

I also drew this little mockup of Wandering Magic if it were a game for the MSX 1:

The mockup tries to follow MSX “Screen Mode 2” restrictions – 256x192 resolution, a fixed 16 color palette, backgrounds are composed of 8x8 tile patterns that can have 2 possible colors per 8x1 area, sprites are 1-color and 16x16 in size.

That’s all for this week!

Another week passes.

I didn’t get as much progress done as last week, but I did do a few useful things.

I’ll start with the more interesting, which was to implement sprite flickering. This allows being able to see all the sprites on screen when there are too many on screen / too many per scanline, by alternating which ones are drawn each frame. This isn’t a built-in feature to the MSX sprite hardware, so games must manually cycle their rendering order to be able to flicker between the different sprites.

My flickering system works by adding a prime number to the draw order each frame, and using another prime to walk through the array. Basically: index = (index + PRIME) % COUNT; at each loop iteration to shuffle the drawing order in a nice way, so that every sprite can be seen.

Warning: Minor flashing Images (flickering sprite system):

So far I only implemented a sprites/scanline respecting flicker, but not something that will show everything if there was overdraw. But thankfully, I constructed the entity system to be 1:1 with sprites for now – it should be easy to do overdraw detection+cycling later if other things such as the HUD need it, or just reserve an entity for the HUD (sort of a hack but a cheap way to keep common sprite drawing structures).

I also optimized the movement code for Wandering Magic a bunch. Now it is possible to move 16 copies of the player entity at once without lag. Beyond that it’s still not perfect though (the earlier GIF uses 24 sprites and slows down when moving, 32 is even slower). Not sure what the next steps would be to optimize performance, if we want to do all 32 entities, but I think I’m okay with slowdown after reaching 50% capacity of possible stuff to put on the screen. and 16 entities is enough to have room for the player, a few enemies, and a few projectiles. A little slowdown is okay as long as the control still feels responsive and works in the player’s favor. But I might try to do a deeper optimization pass later.

Some optimizations I performed:

• Reduce number of temp push/pop to the stack when not needed to preserve things.
• Relieve register pressure by re-using more registers when their previous calculation is no longer needed. (This took a lot of careful reading of the code to figure out what registers were no longer live, something that liveness analysis in a compiler could probably do easily, heh.)
• To multiply by 16, use repeated 16-bit self-addition (add hl, hl), instead of 8-bit shift left + rotate-left-with-carry. It takes less bytes and less cycles.
• Comparison: Use inc/dec (which set the zero flag) to avoid overhead of comparing to 0 and 0xFF, when registers can be modified.
• Sign extension: Use rotate/shift left by 1 (so the sign bit goes into the carry), then subtract a from itself with carry, to get 0 or 0xFF.
• Use immediate load instructions when loading stuff into memory pointed at by index registers, rather than loading into a register first and then loading into memory

Some possible (much later) optimization pass:

• page-align the tilemap array + tileset array
  • possible because we load into RAM these can be easily located even if the source arrays aren’t aligned to the 256-byte boundaries
  • page-alignment speeds up all pointer math, since single 8-bit adds / bitwise or can be used, rather than 16-bit addition.
• replace 4.4 with 8.8 fixed-point. Speed is passed as an argument through static RAM variables, so direct 16-bit stores can be accomplished.
• page-align entity array + remove use of index registers (probably not worth the extra complexity)
  • indexed register usage is slower + takes more code space than indirected register pairs.
  • register pairs don’t have random access, but page-aligning kind of gives you this back.
• use shadow registers more effectively.

I also updated OpenMSX (and downloaded the debugger) and tweaked a few settings to have cleaner quality captures / better workflow. I fought with settings to get a nice clean integer scale render of the MSX screen. By default OpenMSX seems to like to use a bilinear filter over everything. Eventually after asking around, I figured out a some settings you need to open the F10 terminal in OpenMSX and set horizontal_stretch to 320, (which I couldn’t do from Catapult – OpenMSX’s GUI frontend) well as set scaler to simple, renderer to SDLGL-PP, disable all blur, glow, scanline noise, etc under video controls or from the OpenMSX F10 terminal. Anyway, way less friendly than most emulators in this regard, for getting a nice image without pixel blurring, when nearest neighbour is the standard in most emulators, but that problem aside it’s a useful tool. The earlier GIF was taken after fixing the scaling interpolation issues, making for less blurry screens than some of my earlier game captures.

The OpenMSX Debugger seems nice too. But I’m not sure if I might still fall back to the less-accurate BlueMSX because I’m more used to its debugger by now, and I don’t do anything that requires too much hardware accuracy (I hope). But I’ll definitely test with both emulators, and eventually true MSX hardware, I hope.

Other than that, I shopped around for a possible MSX to test development on. I found a Panasonic FS-A1, an MSX2 computer. It’s currently being recapped and then sent in the mail, if all goes to plan. There are probably cheaper ways to have gotten an MSX to test with, but not much to look for in North America, especially in Quebec.

I also ordered a MegaFlashROM SCC+ SD, which is a flash cart that allows playing software, and includes a reproduction of the SCC+ soundchip (that Konami used in their games, such as Metal Gear 1 - 2, Space Manbow, Nemesis 1 - 3, Snatcher, SD Snatcher, and so on). The MSX is definitely a more expensive system (though I think cheaper than the PC Engine), so hopefully after these two purchases I’m set.

I also bought a controller adapter to allow use of Atari/Genesis style controllers with the MSX, which is much, much cheaper than buying a nice Hudson Soft Joy Card or less comfy looking Panasonic 2-button controller. Controllers are weirdly expensive. So this adapter saves you about $100, heh. It’s not as essential since the MSX has a keyboard that can be used for games/programs too, but still nice this adapter makes it possible to get controllers.

Anyway, buying all of this equipment with the partial intent of enjoying games, but also to test my creations on the real hardware, since I can copy my MSX test programs onto an SD Card that gets interacts with the flash cart. We’ll see how that goes, and hopefully be able to set it up and take captures of the game running on the real console.

So yeah, that’s all for this week. Thanks and see you again soon!

Heyyy everybody, it’s egg here. Another week has flown by, and as usual things were very busy at work.

But not-so-usual, on this weekend, I ended up participating with some friends in the Ludum Dare 48 game jam.

We made a short game named “Frog”, which you can download here!

You’re a frog and you shoot bubbles! Descend the depths, find the treasure!

Credits

• 2bitcrook - art
• cacciatc - programming
• Kulor - programming
• dustmop - programming
• eggboycolor - programming

Plays in an NES emulator, or on a Famicom/NES/Famiclone that supports VRC6 sound expansion.

Try it out!

The game is pretty short, but considering the timespan and that it’s a real NES game, I’m pretty happy with what we manged to accomplish.

Thankfully, we picked the category of Ludum Dare that allowed not only team collaboration, but using existing code. Chris Cacciatore provided his NES-based game engine Veil to work with, and it was pretty fun learning how to write code with this toolchain. Chris, Dustin, and I collaborated on the coding side. 2bitcrook did the excellent pixel art for the backgrounds and frog + bubble sprites. The game supports VRC6 expansion chip audio, and kulor provided really cool music and sounds for that take advantage of this.

It had been a while since doing any sort of game jam/compo, so it was great being able to team up with a few friends to make this. It was a bit tiring at time, as I forgot how stressful fitting things into single weekend can be, but once I found the right rhythm and got used to working in the tools, things started to snap in place. It was helpful to synchronize on tasks each night + morning during the jam, as it let us brainstorm and change plans/limit scope when we were getting a bit stuck.

We originally had a few ambitious plans for the frog and the level layouts originally, with scrolling levels, multiple enemy types, and a tongue mechanic, but we quickly scaled it back. The final game has a bubble mechanic + static obstacles to navigate in order to reach the goal in each room. I’m happy the readjustment happened early enough that we could salvage the idea, and we managed to make some neat levels around it.

Hopefully people get a chance to play and try it out! It’s a bit buggy, as with any jam game (especially a crash at the ending, some sprite and physics glitches), but for the time allotted I’m pretty happy with the little platformer creation we accomplished.

Getting to jam was a nice way to recharge motivation for personal game projects. But on the other hand, it was also very exhausting to spend an entire weekend basically only working on that, with small breaks for food + walks. So that’s definitely not a regular thing I want to do. However, I’d potentially do another jam if circumstances were to work out again.

That’s all for this week! Hopefully soon I can finally dust off my projects and talk about something new.

This week is very short to summarize. Other parts of my life have been competing for spare time lately. But in spite of that, I did manage to squeeze in a couple hours of work on Wiz.

I improved integration with debugger integration with Wiz programs. I added some work to improve debug symbol sorting in wiz, so that fully-qualified / global names have precedence over anonymous / compiler-generated names. This means that it will be much easier to search for a particular symbol by name in the debugger and go to it – and its given name (since Mesen annoyingly only allows one alias for each address of memory) will prefer a deliberate user-chosen name over auto-generated stuff.

I have wanted to also fix Wiz’s symbol exporting for the SNES.

The problems are better explained by first explaining what a “debug symbol” is – basically, a label or identifier that gives a name to an address in memory, constant, or similar thing. This allows you to view these symbolic names rather than hex values inside of a debugger’s disassembly viewer. These give names to better indicate where functions, labels, variables, and constant data appear in the program.

The problem is, currently the way addresses are mapped to the symbol file is incorrect. As soon as you have a program outside of bank 0 of ROM, the address calculation is wrong. Or rather, wrong depending on the ROM’s map mode that is used.

The SNES is peculiar because the system allows several different ways to access the same memory areas. Firstly, on the CPU-side, the 65816:

• you can access an 8-bit address, which is offset by the direct page register existing somewhere within bank 0 of the memory space.
• you can access a value on the stack.
• you can access a 16-bit absolute address, which has its upper byte of the effective 24-bit determined through the its data bank and program bank registers.
• you can use 24-bit absolute long addressing. It allows you to access the full 24-bit address space of the SNES memory map. This is a similar concept to “far addresses” in 8086 parlance, but bit simpler. For familiarity, Wiz also names this far addressing.
• you can index an 8-bit direct page address, 16-bit absolute address, or 24-bit absolute address.
• you can use a variable within the direct page or stack as a pointer to a 16-bit or 24-bit address in memory.
• Also, there’s two different sizes of stack-based call/return, which use different lengths of addresses:
  • 16-bit jumps with JSR (jump to subroutine) and RTS (return from subroutine).
  • 24-bit jumps with JSL (jump to subroutine long), and RTL (return from subroutine long).
• and so on (there are more address modes)

At the end, the operands to these addressing modes are decoded at some point into an effective address by the CPU. The way this is done is determined by the memory map of the SNES, which is configurable by the cartridge.

There are LoRom, HiRom and FastRom SNES roms. (Going quick to not miss the Gruedorf post deadline hahah. But edited slightly for clarity and typos.)

Here’s a small summary of the “map modes” on the SNES cartridges:

• LoRom lets each bank of memory you access view of ROM in 32K blocks and the 32K of address space contains other stuff (RAM, the hardware registers, etc). These are located at banks $00 .. $3F / $80 .. $BF.
• HiRom also lets you view your memory like LoRom (in banks $00 .. $3F) – but if you do this, each bank of memory is actually 64K, you only access the upper 32K in each view. But there’s another ranges of bank address that let use this as a full contiguous 64K block (in banks $40 .. $7D, or $C0 .. $FF). This potentially works better with games that have different data banks and program banks, so the program bank can point to a 64K area, but data bank if, or each can point at a different area.
• HiRom allows more memory to be accessed at once, but requires using banks that contain only ROM space when they are selected, which means you will need to manage your data and program bank registers more, or use 24-bit far addressing more often. HiRom can still be used in LoRom fashion, but will be less efficient when used this way. It steps in 64K increments, but only sees each the upper 32K of a 64K block when viewed in the LoRom compatibility banks.
• LoRom has less memory it can view at once and less maximum capacity, but its modes may be easier to work with because even if the ROM bank changes, the program can still access RAM and at the same time – which might be useful if you want to copy stuff within the same page using faster+smaller 16-bit instructions. It always steps in 32K increments.
• FastRom mirrors the entire LoRom/HiRom address space in the upper area of the bank address space, but starts from $80, $81, ... instead of $00, $01, .... This high bit in the address line is used as a signal that fast access mode can be made (I think the cartridge hardware is responsible for checking this after a game software activates “high speed mode” on the SNES, but the exact details don’t matter for writing a program.)
• The main takeaway from this is, the same memory area in the ROM can be accessed in many different “mirrored” banks of memory. (there’s more nuances if you get into expansion chips, or weird third-party cartridges which could have their own memory mapping schemes)

Emulators such as bsnes-plus and Mesen have opted to, for whatever reason, import addresses from the symbol file as absolute addresses that are unmirrored (even though the addresses when fetched by the CPU are mirrored) As a result, this means a name can map to exactly one absolute address – no mirroring occurs.

Maybe because that’s what WLA DX already used? Not sure! Anyway, so I need to adapt the debug code to use the absolute bank addresses exactly as they’re declared in the Wiz program, which are normally meant to relocate the program counter during assembling, but aren’t necessarily the true position in the ROM. Before this, Wiz was only using output-relative offsets: This is a better, relocatable concept, which refers to the exact address in the ROM, and the emulator could load this with mirroring in mind to resolve things. However, since not every emulator works like this, and we don’t want to fork existing emulators just to incorporate what we think would be better, a change is needed.

I haven’t had a change to sit down and support this mode yet. I need some way to make these two addressing schemes be selectable by debug target:
a) output-relative byte offset, or
b) cpu memory map address space.

This way, WLA DX-style .sym exports conform to CPU memory maps on all symbols. I’d like to make the default settings for auto-detected by debug symbol file format, to make it so that exporting doesn’t have to configure this. Need to think on this a little more.

Anyway! Hopefully soon!

Hi! It’s been a while! I haven’t posted in a while, I might try to write a proper full blog post at some point. But for now, I thought I’d do a little “Happy Holidays” post and share something neat I’ve been working on:

These are screenshots from an in-the-browser version of Verge 3, running a few games I’ve tested/gotten working with it. It’s built on top Emscripten, and targets a WASM binary. Only tested in Chrome, but should probably work in Firefox too – needs a fairly modern browser to support the features it needs to run, like audio worklets. Some of these aren’t even compatible under the newest Verge, so this was simultaneously a project to port to the web, and to add compatibility configs to Verge so that it could open older versions.

Try it out: https://make.vg/v3wasm/wip-2022-12-22/ (fingers crossed the bandwidth for this isn’t going to be too heavy and melt down my poor server, these are pretty big downloads, but we’ll try it for now!)

The source branch is here: https://github.com/verge-rpg/verge3/tree/ovk-wip-3.2-wasm-2022


 

Thanks to the work already done by Andy Friesen on v1wasm + v2wasm (Verge Archive: https://andyfriesen.com/verge-archive/) a lot of stuff was already figured out. This builds off that, makes some improvements, and also solves more problems unique to V3. I’d eventually like to merge it in with the rest of the Verge Archive page.

It would potentially be neat to cut a new desktop build when this is done, too.

Basically, I undo the trunk changes after Verge 3.2 that removed VC in favor of only Lua + some other sweeping ‘kill legacy code’ changes that didn’t pan out. In hindsight, it was probably overambitious, and also didn’t anticipate that running old versions of Verge would become increasingly harder in newer OSes.

I added a bunch of compatibility stuff to deal with incompatible versions of system.xvc – the sad part is, Verge 3 had a version in its system.xvc, but not once did we bump it as we changed the format. I guess the assumption there was we’d never want to run an xvc from an older version with a new one, you should always redistribute it with the verge.exe it was meant to be played with, and we’d always have source access to generate the xvc. But that doesn’t really work as great if you want to play those old versions years later, after the source was lost, and the version of executable they came with is maybe not working that well in newer Windows.

There’s also some compatibility for compiling VC code, re-adding some language features that were previously removed, allowing a way to override the built-in library functions in user code (min, max, abs redefinition problems come up a lot), and ignoring duplicate definitions for some stuff (some games redefine things more than once, and it used to compile because it would ignore the second definition).

Another thing is this uses SDL 2 instead of 1.3 like it used to for its SDL backends. This means it builds against something that actually has long-term support and unlike 1.3, SDL2 has a native wasm build provided with Emscripten.

The Linux and Mac ports could benefit from the SDL 2 migration, if they were dusted off. The Linux build will no longer need X11 to do MessageBox since SDL provides its own implementation now, joysticks support hot-plugging in the SDL build. I implemented some window scaling stuff for the SDL version that previously was only done for the GDI windows version. Additionally, the WASM build of the game has an interesting thing where it will auto-escape slashes + lowercase all the paths you pass it as part of opening a file – it would be cool if we had a mode to let desktop builds also do this, so Windows-only games can be portable without changing the original game.

One thing I’d really like to see is a way to run games from .zip. Then it wouldn’t need to prepare a manifest.txt (a file listing used by the web version can preload the files), since the listing could be taken directly from the zip directory structure, and the browser could fetch less things + have slightly more compression. (maybe not a big deal in light of GZIP’d http responses, but still, could be worth looking into). The other advantage, is the paths don’t need to be lower-cased. And overall, more games could be run as-is directly out of their archive, aside from potentially needing verge.cfg edits.

Anyway, posting it in case so other people can check out / potentially help continue the effort! I’m going to be busy with holidays, and may need a break from this project. Still, I’m impressed what was possible in such a short time. I started this a couple weeks ago + plugged away at it on nights/weekends and a little bit on my break.

Seeing this engine suddenly run these old games in the browser is kinda magic, I hope it can keep being improved!

Hi, here’s another weekly update.

I started blocking out some other rooms. I made this forest / plant zone underneath the “castle” zone:

Still super rough, and it will probably need to change as enemies and interactive objects are placed, and game progression is figured out. Anyway, having fun trying stuff out.

Trying to keep to decorating things with a limited amount of tiles, conveying the general texture / theme of stuff with a couple small repeating patterns. The forest uses about 3 main tiles:

• foreground “grass”/“bush”/“leaf” tiles
• background tangled knot of roots/branches
• background vines/branches

Then there’s a couple blocks or bricks over that, but they’re less common in the central rooms of this area.

In designing the rooms, I tried to make sure every area has multiple exits and distinct areas that can be reached. I’ve been trying to make branching paths that have you weave through multiple rooms, so you need to figure out how things connect. It’s pretty basic so far though. There’s no key items or collectable abilities yet, so it’s pretty easy to “solve the maze” heh.

I still don’t know how I’ll fill in the rooms yet, but it’s a start.

Also started mocking up this HUD, just tossing something very basic in:

Since it’s a “fixed-screen” platformer, I thought a static full-width HUD probably makes the most sense. I was originally thinking of a HUD that repositions itself depending on your spot, but realized those are a bit annoying. And hiding the HUD isn’t really an option unless player health is communicated some other way, or you have a life bar over your player (ugly). And a fixed, floating HUD like Mega Man is more fitting for a game with a scrolling camera and fairly tall corridors, it doesn’t really work here. So static HUD it is!

To compensate for the 8px of space used by the HUD, I scrolled the camera up a half-tile (4px) which seems to work ok. And it saves the need to edit all existing rooms to be 15 tiles tall instead of 16. I prototyped scrolling the camera slightly as you navigated but found it a bit annoying in practice to see it pan every time you go. So a fixed half-tile offset seems to be an ok compromise.

Still seems like I’m in recovery mode, but every couple of nights, I poke at this prototype for an hour or so. Wish I could eventually figure out where this is headed, but it’s still nice to make minor progress somewhere.

I also got my second shot on the weekend. Aside from a bit of a bruised/heavy feeling in my arm, and being a bit drowsy afterwards initially, there weren’t really a lot of other side-effects. After the 2 week recovery mark passes, this may mean more changes, as it will be possible to do a little more outside of the house. I’m still pretty hesitant about being too ambitious with that though, since lots of people still aren’t vaccinated yet, and the new delta variant, etc. Also it may mean working outside of my house a couple days a week, and I have mixed feelings about this. We’ll see.

Anyway, catch you next time!

Another week passes. More tweaks and polish were made to last week’s untitled PICO-8 platformer prototype.

I added some bat enemies, adapted from some old code but with slightly modified behaviour. Then I added the ability to hurt and defeat enemies, with small hitflash on damage and small sprite vfx when they dematerialize. I also drew a new player hurt animation and implemented the reaction in-game (no player HP at the moment though).

I also adjusted the player art to have more readable poses, and some of the background tiles were slightly cleaned up. The art was edited even more since the above GIF was captured. I’ve tried different hair styles and color schemes for the player but couldn’t find anything satisfactory yet for mood / readability against background colors. So the self-insert miniature character remains for now.

The player walk speed was slightly slowed, so that you can’t completely breeze through rooms, and it effectively makes it so there’s more area to cover within one screen. The collision code was improved to allow corner nudging when jumping into a ceiling corner, for better control while still allowing a full tile-wide collision box on the player.

Progress has sort of slowed down from there. I struggled to put together other rooms that seem fun to navigate. I couldn’t figure out ideas for how the game should progress yet. And I couldn’t figure out many adjustments to the player character for the time being, but this is less crucial at this stage than the other elements.

I’m still under the weather at the moment, and it’s become very easy right now to have small things completely stop me in my tracks. I was away from my computer this weekend, which helped a little bit for morale, even if it meant not doing creative work. But then, returning to the work week sort of deflated that, and drained my batteries once again. Hoping I can snap out of this and bounce back.

It would be nice to continue things, if I can figure out where to go with it. The progress that’s there is early enough that there’s plenty of room to still change the game and expand on what’s there. And in the worst case, not too much time was lost, if for some reason it’s not continued. But I’d ideally like to keep going, rather than abandoning the project, if I can work back the energy to do more sideproject work.

I’m getting my second vaccination this Saturday, Depending on how that goes, I’ll probably be recovering from that for a couple days. If I’m not completely out-of-commission, I might get a bit of time to focus on side-project things some more. We’ll see.

Anyway, have a good week! Bye for now.

Hi, sorry I missed last week’s post.

Been pretty burnt out or something lately! To the point that, lately whenever I sit down to do something for a side project, my mind just sort of goes blank mid-way. I can manage for simple things, but as soon as more elaborate problem-solving or creativity is involved, it’s an uphill battle and a chore. I’m trying to get back to some sort of balance again, I’ve just felt mentally tired and creatively blocked on my existing side projects.

I mean, otherwise I feel good! This doesn’t feel like depression or something. It’s just that, any time I’ve tried to do something, I just spin my wheels and stay in the same spot. Even if I cleared the time, psyched myself up to work on a thing, and wrote down steps of what I wanted to do, somehow there’s a mental block keeping me from doing the work, Sometimes, even the process of trying to write a plan down, I would just get distracted in the middle, and end up zoning out and doing something else.

Work has been rather exhausting with its current place in production. Having two back-to-back holiday long weekends was nice, but an extra day or two still isn’t making up for a real vacation. Anyway, sometimes that’s how it goes.

Putting that aside though, I somehow managed to do something over this weekend.

I made a small platformer prototype, using PICO-8:

You’re a quick-moving adventurer that can jump around and throw daggers.

So far, it has basic character animations: idle, walk, jump, fall and shoot. There’s also some background tiles, and a repeating foreground layer with some simple oval-shaped clouds .

The platforming code handles the basics of moving and jumping around, I recycled a lot of old code to get going on this. Dug up things from like 5 or 6 older unreleased projects of mine, and recycled various code to do with entities and collisions. Everything was adjusted to fit better after the fact, so it felt a bit more cohesive rather than just tossed together. Still, having some existing groundwork definitely helped with iterating quickly instead of spending all my energy on coding yet another entity system from scratch, heh.

I implemented input buffering, so if you hit the jump button or attack slightly early, it will do the action if it becomes possible in a short moment after you press the input. This allows jumping slightly before landing, and hitting attack without needing to be as precise. I will probably add support for jumping for a short window into falling too, but in practice I think this this is not as vital to game feel as buffering – some newer games depend too heavily on “coyote time” for their jumps, in my opinion, and I’m okay with late input having a penalty.

Another nice aspect of recycling old code, is that with only a few minor edits, room logic and enemy designs from the PICO-8 version of Wandering Magic can be dropped into this. While the enemies were designed for a top-down game, some work just as well in a platformer and can be used for prototyping. I need to implement a couple more things before the player and enemies can hurt each other, but the basic movement code for these could be carried over.

So yeah. On the one hand, I started another project rather than trying to continue existing ones. But at the same time, given my current mental block, just being able to work on anything again was nice. I’m unsure where I’ll go with it, but it was fun to jam. I think it was possible because I could create without too much care, just whatever seems neat and letting my mind drift there.

At this point I still have no idea what the game is about, or whether I will keep working on it, but at the very least it was neat to play around with something over the weekend. It’s also still at a stage where it’s relatively easy to iterate and adjust, even if I shelved it for a little.

I’m trying to move the creative challenges into the level design instead of code, and stick to a format that fits easily within PICO-8’s confines. PICO-8 has a bunch of limitations, 128x128 screen, limited code, limited map + tile space, a 16-color palette, etc. If you don’t compress your maps, PICO-8 gives the choice of either 128 tiles + a 128x64 map (or 8x4 = 32 screens), or you can do 256 tiles but you only get a 128x32 map (8 x 2 = 16 screens). I’d rather have the extra map space since the art is quite small and I can make that work. But even then, only 32 screens for the whole world is a challenge.

If you do compress your maps, then you can fit more data, but this comes at the expense of a much more complicated development process, since for anything that doesn’t stick to the basic format, you need to make your own tools and lose out on the built-in map editor tool. You also need to sacrifice code space to write a decompression routine. It can pay off for some kinds of games I guess if you’re willing to put in that sort of effort, but I would rather not go down that road! (this time)

Too many past projects of mine tried to fight against these size limitations and ended up getting stuck mid-dev. So instead, attempting to embrace the limitations, and design stuff to extend the length of the game in the confined level space, and make it more interesting to navigate the space, it will probably have some non-linear elements, as well as gated challenges, puzzles, events, and reasons to revisit areas.

The PICO-8 version of Wandering Magic stuck to the 32-screen format and managed to get a demo that was about 30 minutes long, with plenty of room to spare, so I think it’s possible to do something interesting in this limit design space. Might need to tweak the movement speeds slightly so the player can’t breeze through rooms, but hoping it can stay pretty fast-paced overall.

Still trying to figure out how to build the maps for this, thinking of drawing an 8x4 grid of boxes on paper, and figuring out in the abstract what challenges and exotic elements each room have + as well as coming up with neat paths through this space. Fill in the blanks. Then actually craft the rooms, using those constraints. I have no idea if this a good approach to the design, but it’s what I had in mind to try for starters.

Anyways, that will do it for this week. I’m still very much under the weather and this new project is if nothing else, a nice diversion from a mental and creative block. Hopefully can keep this momentum going and turn things around for the better.

Hi! Short update. Work has been busy, but holidays going on thankfully split things up a bit and give a couple extra days to unwind.

I managed to squeeze in a little bit more sideproject time between other things. With Wiz, the initial rework to split everything into free functions is over with. The forked source is compiling again. The actual code organization is still a bit lackluster, and needs addressing. There’s also the matter of release mode code size increasing by about 30KB. It seems I only get a couple hours each week to poke at it.

I can’t wait to move on from this work. It’s somewhat nice to see things getting there, but refactoring code and working on compilers isn’t always the most rewarding work. Especially between pretty dull and painful dayjob work that needs doing atm. I might just shelve what I did and start making projects again so I can give myself a little recovery from my dayjob.

I keep pushing myself to do something each week on Wiz so I can finish this, but it’s also having the side-effect of sapping most of my enjoyment and energy for other projects. It’s unfortunate because finishing this work will open doors to allowing new bugfixes + feature work, and make homebrew projects nicer to do. Honestly, I could use a month or two long vacation to recharge and dedicate to solo work hahah, maybe eventually there’ll be a good moment for this.

But yeah, that’s all for this week. Suddenly, most of North America is in a massive heatwave atm, Montreal being no exception here. The humidity is probably the worst part though, and makes it feel like a sauna. I have yet to install my A/C since it’s a two-person operation. Hoping I can survive through the week and maybe will finally get assistance installing it over Canada Day weekend.

My week was pretty rough due to falling sick. My fever had worsened, and my condition progressed to the point that I went to get a COVID-19 test. The tests came back negative, thankfully, but it still took me a few days to get better. I still worked from home in the meantime, but otherwise rested and drank lots of water, and didn’t do much.

By the end of the week, I had finally recovered. I managed to squeeze in a little bit of time towards working on Wiz. I continued pushing along the refactor, finally lifted out all the compiler methods into free functions that act on a CompileContext (or its sub-members) instead. I am still not 100% on how to organize things but at least now all the data managed during compilation is contained in a simple struct with public members. This makes things easy to access by various passes/compilation subsystems. and functions that act on this data can now be moved around/regrouped a lot easier. Eventually, the actual data for things like scope registry/attributes stacks/etc could be refined to use custom data structures with a better-organized set of operations. But at least this simple move-out approach is able to work with the existing code with only a few edits / adjustments.

I’m happy to be making some headway on things. I just need to fix a few more pieces, and hopefully the rework will compile again. I am hoping if I can get past this part, and tidy things up a little bit, I can bump the code on Github with the changes. Also, starting to feel like I might also have the capacity to work on game sideprojects again, after feeling drained and lacking motivation for a while.

Anyway, as rough as the past week was with being sick, overall I’m doing much better now. And two short weeks in a row ahead: one for Quebec’s provincial holiday, one for Canada Day. Maybe this will give a chance to recoup a little bit more, and dive into more sideproject work. Let’s see how it goes!

Quiet week.

Work was busy, and the particular feature work I’m doing right now is really not that enjoyable to look into, but necessary for the project. Trying to motivate myself to finish this, so I can look at something else, but there’s a ways to go with it.

I did a little more coding on Wiz, moving things around and attempting to clean things up. Still lots of mess to still go with this, but starting to see the other side of it. The intermediate work is kind of unenjoyable to do, but trying to keep working through this. Lots of stuff that probably needs to get organized better, and it’s painful to look at. Trying to split things out into the smaller subsystems, and fix up all the dependencies between the different subsystems, so the whole thing can compile again. Even if it means a mess in the meantime, hoping I can close this out at some point.

Again, it would likely be way easier to do this cleanup work if it was tired to a direct feature or something, but unfortunately, I put off cleaning up the technical debt for too long. Making it hard to add features without growing the mess, and hard to adapt much of what was there without a refactor in the first place. But this is stuff I’ve said already at this point.

I’m kind of discouraged how slow this is going, but considering I maybe only spent a few hours total, spread out across days, it’s understandable why this is a slow and tedious process. Still, if I can finish up this initial pass at splitting everything up in some form, then I can worry untangling things. It might be easier at that point, because it will be possible to divide-and-conquer the pieces to tidy up, without impacting the others.

Also, on Sunday I got sick. Originally I just thought my apartment was stuffy, or maybe I was dehydrated or something, because it was really warm out. But I drank plenty more liquids, and the symptoms persisted overnight and during the rain. I don’t have a thermometer, but it’s 17 C at night and I didn’t really feel this at all. During the daytime today, I actually thought I was better, but tonight the fever-like aspects returned. I’ve been isolating at home and have the windows open and fan on. I currently only have 1 of 2 vaccination shots, so there’s always a potential risk.

I had originally planned to have a stay-at-home vacation at the end of this week, but I’ll most likely need to cancel, so I don’t burn my vacation days as sick days. Unless I get very lucky and this thing resolves itself by the morning or something. I have a feeling I’ll need to get a test and self-isolate at home more, which is not fun.

Wishing that this blows over quickly and crossing fingers that it isn’t what I think it is. Hope to talk more next week.

Howdy. Another week, another update!

Since last week, I continued some more refactoring on Wiz when I got some free moments. I kept working on splitting the compiler code into a few smaller parts. The division right now is a bit arbitrary, but it’s good to start somewhere.

A lot of functions that used to be instance methods were rewritten to be free functions instead. One nice advantage of this, is free functions can’t act on private state (without gross C++ features like the “friend” keyword). As a result, more fields become public, and data structures are a reworked to be bit more transparent.

Another nice property of using free functions, is that it’s possible to move these functions around between source files without problem. Also, for places where the information hiding is useful, or the implementation details don’t need sharing, some things that were previously private data + functions within Compiler could be put into a file-local anonymous namespace instead.

For now, some things were rewritten to take a common CompileContext, containing various smaller systems and state across the course of compilation. Eventually the big mess of data members can be organized better into smaller logical parts, and some things that take a full-blown CompileContext could take a (possibly const) reference to a specific subsystem they need. This would make dependencies and their usage clearer to tell from the function signature. Some of the reworked functions already do this, but still working out the details for others.

I’m currently working on just moving the code, with minimal changes inside the actual function body. But I intend to clean things up more when things are divided further.

As an example of something I want to clean up better, reduceExpression is a function that reduces an expression tree into a smaller form. Given a abstract syntax tree for an expression with no extra information, it does semantic analysis and produces a partially-folded expression tree with type-annotation on the nodes. It can also take a previously-reduced tree and attempt to reduce it further. For example, expressions with references to constant symbols that can’t be fully resolved during the initial compile, but can be figured out during the final code generation.

Anyway, turns out this function is like 1000+ lines of different cases + logic, basically it sorta outgrew itself and code just kept getting added there. This could easily be split up into a bunch of smaller functions. Splitting up the big mess has made it easier to spot the clutter within.

There’s also the issue of naming things better across this codebase. For now I just sort of called things the first name that came to mind, but there’s room to rename and make it clearer. Ideally naming should be short, concise, and clear, and consistent where possible.

Trying to not fall into the trap of nitpicking over minor things forever. Better ideas might come up when more important changes are made anyways. And there’s a point where it’s “good enough”. I just want to get it far enough that I hopefully won’t feel that I’ve coded myself into a corner anymore. It still will probably not be code I want to look at or work on every day. But having things more organized still goes a long way.

Anyway, more work to do. Hopefully I can keep the motivation to continue this. I’d really like to finish this cleanup so that it’s easier to add testing, do bugfixes, add new features, etc. like I’ve been talking about. If I keep working a little bit at it every couple nights or so, I can eventually get this into a more maintainable state, but it’s a matter of having the energy and attention for it.

In other news, the MSX2 computer I ordered way back in March finally arrived. The model I bought was the Panasonic FS-A1. The box art on this is… pretty incredible hahah. The orange-on-black look of the console system is very cool too.

Here’s a brief video I posted on Twitter of it running!

Unfortunately, the phone didn’t pick up the audio from my TV (unless you crank up your volume), but the flash cart also supports the SCC expansion audio chip that Konami games for the MSX used. Nemesis 2 has a solid soundtrack, and it sounds excellent coming out of a real console hooked up to an old CRT.

It doesn’t have all the bells and whistles of some of the last generation MSX2 systems, like the MSX2+ and Turbo R, but I can live with it. This console was in great condition and in my price range. Meanwhile the later revisions are exceedingly more rare and expensive for only a handful more titles, and only slightly better specs. I think the middle-of-the road option is good enough since it supports all the MSX1 games, and most MSX2 games work ok except for a few exclusive releases for the later models.

The seller also had the option to add some kind of RGB mod, but I don’t have equipment to handle that at the moment. And from reading online it sounds like I maybe dodged a bullet there. They didn’t appear to have great feedback online for this particular thing.

Meanwhile, they took a picture of the recap they did before sending, and thankfully the work they performed looked okay, from observations as a layperson. No damaged traces or anything like that which I could notice, so hopefully all good on that front. Always a bit risky to get unknown eBay sellers to do work on a system, but thankful that it all looked good. Especially since I found out this information by searching the seller name after the fact.

In any case, it works great when plugged into my old C64 monitor over composite. I could also probably plug it into my RetroTink 2x and use that for capture. Even if the signal isn’t going to be super crisp, it’ll probably look good enough. I could possibly find a reputable modder to install something down the road if it’s possible to have a cleaner video output, but not in any hurry for this.

There’s more encouragement to get back to MSX development, now that I have the ability to run and test stuff on the real thing. I can continue my port of Wandering Magic and see the results on an actual console, instead of just in an emulated environment. Or maybe tinker around and work on something else that seems fun to make, too.

That’s all for this week. Catch you later!

Hey everyone. This week flew by fast. I did my last update two days late, so there’s been less time than usual between my posts. I almost missed my post tonight, even with things back to normal + the usual notifications I have going for posting on Monday nights.

I got a little spark of motivation to resume work on Wiz, my high-level assembly language. I’ve been working with the private repo branch I recently re-made, so I can take my time to mess around with these changes and not block the public upstream.

I decided against the ‘delete code and re-add’ approach when it came to refactoring the project. This is because it would mean losing the ability to run the program against example source code until the refactor was completely finished. These examples are currently the closest thing I have to tests for the compiler. And because they’re fully running programs, not only do I get to see if the compiler works, I get to look at the resulting program in an emulator to see the product of my work. So anyway, that’s why I don’t think that a clean slate fashion of rework would go very well, without putting a lot of old code back, which would inevitably probably end up rushing things back to the position they already were.

(Well, there are some functional test suites, but they aren’t as interesting to run right now, since they mostly test the codegen pass. I eventually will rerun these though. And I also want to write seams to allow for some proper unit tests…)

Instead of the “destroy-and-rebuild”, I decided that I would start by moving existing code into separate smaller subsystems: lifting things out of the compiler source and into their own file. For a good place to start, I moved all code related to scoping, name generation, and symbol resolution. Thankfully, all of the scope-related stuff has almost no dependency on the rest of the compiler, so it’s an easy candidate to move. This is just moving things over mostly so far, but I did make some minor improvements. It is giving me a chance to re-read the various pieces and see things that could be done better.

Things still have a long way to go, but if I can have like 4-5ish smaller systems, rather than 1 giant intertangled mess, I’ll feel better. For some reason, doing this sort of cleanup on a personal project seems like such a chore. I guess because it’s an unpaid project, I’m the only maintainer, and there’s limited appeal to work on a compiler in the first place. For me, I have to be in a specific mindset to want to do tools-related work. Also, I don’t want to break the publicly-available upstream version of the code, since a few people are using it. With the project already “released” kind of, it feels more difficult to continue do new things to it, even though I’m in charge of its development.

With a compiler especially, people tend to expect minimal breaking changes to the language. and any change needs to be considered carefully so it’s actually an improvement, not a step backwards. Anyway, this is why getting to this point has taken a few failed attempts at wanting to get around to fixing the project, months apart. Having a private dev branch has made things feel a little less risky at least. I also have less anxiety in general around making bad choices, since I can at least squish any bad decision before it becomes a part of the public release,

If I stick with this and finish on this, I would maybe like to take a crack at improving some of the data structures in the compiler, and improving some of the patterns for memory management. The data structure things would be mostly a learning exercise, but also to have better control over the performance characteristics and share the same data structure implementation code across platforms, rather than depending on STL vendors.

In the case of the memory management, using arenas would allow things to be packed closer in memory, making them more cache-friendly. It would also potentially also allow more stuff to use cheap non-owning pointers to each other, and potentially avoid cloning in some places that currently need to do this. Cloning was needed preserve the current model of unique pointers + immutability, but in some cases, non-owning sharing would be possible. Shared-ownership pointers were deemed too messy a model since I didn’t like the unclear ownership situations it could create, and I didn’t want to pay the cost of refcounting, nor risk the possibility of a circular references being formed. Arenas are nice because they’re simple to reason about, efficient to allocate, and can even speed up destruction if I refactor things to ensure everything is trivially destructable, since I could just release entire blocks of things at once.

I’d also like to see if I could make the code for describing the various instruction sets entirely data-driven – it’s mostly there but there’s a few things that could use some work. If this were done, potentially it would open the door up for Wiz to define platforms and their instructions directly within .wiz. This would let people use use Wiz to target any architecture that there are rulesets defined for, even custom virtual machines too, if desired. It would also lessen the time spent maintaining these platform bindings, since they wouldn’t need to be baked into the compiler anymore. I’d probably bundle some bindings built-in but allow superseding them with newer versions.

I thought adding compile-time arguments to inline functions would also be cool. It’s an idea I had since early on, but something sorely missing. Writing specialized code without going for the manually unrolled and edited copy-paste approach is appreciated. Since Wiz allows constant-folding of if statements, there’s also the possibility for compile-time specialization based on the arguments passed. Some people have even hacked in their own preprocessor pass to wiz just have #define macros heh. I had originally held off doing this feature so that I could evaluate how to do things, but I think I have an idea of what I’d like to do.

It could also be neat to structure the tooling such that it could interact with the Language Server Protocol used by modern code editors such as Visual Studio Code, Atom, Sublime, etc. If such a service was made, potentially tool-guided autocomplete and refactoring would be doable. My compiler needs a bunch more work to support that though.

One thing at a time though, let’s see if I can keep cleaning things up and maybe spark more motivation I’ve been missing for a while. See you next time!

I’m late for my usual weekly update. It was a long weekend (Victoria Day weekend in Canada), so this threw off the normal schedule a bit. The weather in Montreal also warmed up, which was pretty nice outside. Indoors the humidity made things a bit less pleasant, and I had to get out a fan.

I’ve been struggling to make much headway on anything programming-related outside of work in a little while. I’m not sure why, but I guess sometimes this happens. I was a bit tired with my current projects, so I decided to start on something a bit different.

I had the idea to write a music engine for my homebrew NES games. I wanted to support FamiTracker, since it’s the most popular music tracking software for composing music for the NES.

Before going down this road, it’s useful to evaluate what’s already there. A few other music popular NES engines exist that support importing from FamiTracker, such as FamiTone (or the older, original version here), GGSound and Pently. I’ve used Famitone and GGSound a bit, but they lack some features for making richer audio tracks in some regards. Never had a chance to try Pently.

There’s also another tool FamiStudio, which is a separate piano-roll style desktop music editor. It has FamiTracker import, and supports targeting directly for its own improved engine fork of FamiTone. But from the page’s own description, it sounds a bit closed to outside contribution and it’s a larger codebase, so I’m bit unsure about it for this reason.

Anyway, I looked at what was there but wanted to try writing my own thing. Hopefully something that has easy integration into my own projects, and has good support for some of the tracker effects that FT has available.

I also wanted the potential for supporting expansion chips, to approximate the sound capabilities in other game consoles, such as the MSX, PC Engine, or Game Boy. It wouldn’t sound 100% the same, but it would give a way to test these things out at least.

(MSX has on-hardware stuff like Trilotracker, and Game Boy has on-hardware LSDJ, and Nanoloop. But these are more strictly for writing and listening to music when nothing else is happening. Not meant as much for gameplay when the CPU is needed for other tasks too. There’s also Deflemask or XPMCK, which support a bunch of platforms but also don’t really have drivers that work great for a game. GB also has Paragon5 Tracker, but it’s ancient and clunky. So in light of all this, something like using FamiTracker to approximate ends up sounding like a good possible alternative.)

I’ve previously worked on a a couple attempts on different music engines, but these always relied on notation similar to MML (Music Macro Language), or byte-code interpreters that used command opcodes for notes+effects. In these cases, I was writing the engine, but didn’t have easy integration to a usable music editor. They had sample data or text-based formats that they could convert, for the purposes of testing what sound engines were capable of, but nothing easy to actually make music with.

There was also Bleep, an unfinished piano-roll music maker I was working on that ran on the GB hardware directly. While this was neat, and I want to continue with that someday, it’s less practical for game music making, and was more meant as a fun way to make songs on the go. For my current idea, I wanted something with easier integration with a desktop music editor that does chiptune music. Different goals.

Alright. So this time, I wanted to make a project that took things in the other direction – rather than engine-first like usual, I decided to try doing an importer tool first, then a converter tool. This way, I could write a music player that can interpret the parts of FamiTracker song that I support so far. This would allow making music in FamiTracker from the beginning. I can incrementally add support for more things, while being able to compare the output from my engine vs the FamiTracker. I can also use my past sound engine work to fill in some of details later when I get to that point.

FamiTracker’s normal file format is a binary and seems a bit annoying to handle. Not impossible but probably would take some extra time to get right. Thankfully, it also has a text-based file format that it can export that is (comparably) much easier to handle. Sadly, according to its own documentation, this export is not guaranteed to stay stable between versions… However, it turns out FamiTracker doesn’t change all that often anymore since it lacks active maintenance for the official version (last release in 2015). I also find it unlikely that they would abruptly throw it away fully, since lots of external music engines + converter tools depend on the format working a certain way now. So yeah, text format it is!

The format documentation is included in the .chm help file that comes included with FamiTracker’s installation. I couldn’t seem to find a direct online version of the text format specification on their wiki or website.

However, through a roundabout way (a github page that can link to .html files in github repos), I’m able to link to doc for those interested: https://htmlpreview.github.io/?https://github.com/HertzDevil/famitracker-all/blob/master/hlp/text_export.htm

This format is a simple enough: text-based format with line-based commands consisting of space-delimited tokens. But there’s some slightly tricky business comes with how it handles strings, which need some escaping. Otherwise, not to much to say about the format itself. The commands of the format do stuff like define tracks, instruments, macros, etc, piece by piece, as each is read and interpreted. It’s kind of unfortunate that it’s a custom text format, rather than just using JSON or something, which would make it a bit easier to integrate without other tools needing to write a new parser. But what’s there is still pretty nice. Parts of it can be more easily be human-read, and the music patterns themselves essentially look very similar to how they’re written in the editor, so it’s easier to inspect.

I originally wanted to write this tool in C++, but kinda regretting the decision to not just phone it in with a Python script or something instead. Writing anything that handles I/O and text handling with nice graceful error-handling always takes some work to get right. All in all, it’s pretty much the equivalent of split() with maybe a couple regexes, but I ended up settling on a simple character-by-character scanner instead since I could have finer control over the memory usage and more easily do input validation and errors with line info.

Aside from the text input stuff, I made decent progress on some data structures representing the in-memory representation of a FamiTracker document. That part was kinda fun to work out, going backwards from the description of the various commands in the export spec. I’m sure if I need I can read the FT source later too, but I wanted to “clean room” things a bit for now.

Anyway, I did manage to write most of a parser + a bunch of struct definitions for the FamiTracker’s document structure, individual tracks, patterns/rows/columns, instrument definitions, macro sequence definitions, etc. Didn’t quite get to the end, but close.

If I can manage to get this parser done, I can start selectively outputting parts of FamiTracker songs from this tool. Or potentially toss it out, treating it as an exercise only, and maybe think about doing it as a Python script after all heh. We’ll see.

I ended up returning a little bit to development plans for Wiz, too.

I created a private Git branch of the source to allow me to try stuff. I like open development most of the time. However, for big changes, it can be annoying to make sure breakage doesn’t happen at every step of the way, once people are able to see. And I’d rather make intermediate commits that break things and fix it. I could make a separate public WIP branch, but for this, I don’t really feel there’s much value in people seeing my in-between meanderings and prototyping that I might toss away or never finish. So private repo it is.

The project doesn’t yet have unit tests, so that’s one thing I want to fix. I also want to work on splitting the compiler into smaller modular pieces, which I’ve probably talked in another post before. Decided to just rip the entire compiler code out for starters, and phase it in piece by piece. This way, I can put more thought into where things should go this time around. I can potentially I clean up some inelegant things, and can review and make fresh notes about what to improve along the way.

I’m still not sure about it, but I’ve long hoped to add features that can define platform backends directly in the .wiz language. Wiz already has it so that every platform provides definitions for register sets, addressing modes, instructions, and their encodings. Right now these are done directly in C++, but if these could be moved, that would make maintaining these bindings easier and allow new ones to get integrated too.

With a little bit more work on top of that, it could even possible to allow mixing raw assembly with Wiz-style high-level code. This would allow interop with code written in other assemblers, allowing the inclusion of libraries that weren’t written in Wiz, without needing to port their sources.

Another thing is that, Wiz currently targets binary opcode formats directly from its IR, and doesn’t have any text dump of the final program code. Having this feature would allow easier verification of the code generated for bug-checking the asm and potentially for writing some functional tests of the compiler.

There’s also some language warts I’ve wanted to iron out, this gives a chance to potentially revisit that in the process.

Lastly, I got a new laptop, an Asus Vivobook Flip 14.

It just arrived after the long weekend, and so far it seems pretty decent.

The 2-in-1 laptop-and-tablet aspect wasn’t needed but it’s a nice extra. So far, I managed to uninstall the bloatware, disable a bunch of Windows 10 features + apply registry edits, and install a bunch of basic applications for getting development stuff done on it. And there’s Chrome, Steam, Spotify, etc.

The half-size arrow keys are unfortunate, but unfortunately all Windows laptops I looked at had some drawback or another for my personal preference. Also, this laptop seemed to have some of the better specs for comparable things of its price. And didn’t do things like remove the headphone jack or only have one USB port.

Overall, pretty happy to have a functioning laptop again. It’s been a long time since I’ve been able to do development away from desk.

My previous laptop was from 2013. While still kicking somehow, it has a keyboard that’s barely longer usable. They don’t make it easy to clean the keys without breakage. It’s been like that for about 1.5 years now (basically keys died right after xmas break in 2019). So it’s made me do all development work exclusively at my desk. With the pandemic requiring my home desktop to become my full-time workspace, being able to do projects on a different computer, away from my desk is quite nice.

I’ll probably keep my old machine as media box until it completely runs into the ground, since it’s still possible to type short parts of a url into a browser and then autocomplete and click on things.

Okay, see you next week if I can remember this time! Now, to try to sleep again.