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.

This week was quite uneventful, but I managed to get a little more progress on my battle engine.

I am currently at the point that I need to prototype some code that actually makes the entities move and perform attacks. I'm still figuring out where to go exactly... For now, I think a good way ahead would be to make everything driven by a really mindless "AI" controller. This could issue a basic attack move and picks a target any time they're not currently attacking. Then try to prototype some logic for moving around the battle map, getting characters into range, and resolving the attack moves.

It would be nice if I can push past the "blank slate" problem things are currently at with this, and prototype a rough pass.

I also played more Star Ocean 2.

Getting to the mid-way point of the game and started mastering a few skills to allow breaking open more of the games systems in time. I now fully mastered Pickpocket-related skills on Claude so I can steal items from NPCs during Private Actions (if you do this with other party members in your group, it apparently lowers your reputation with them, so good to avoid that I guess! Pickpocketing your teammates within the town, when your group is only one member seems to be ok though).

Went back to a few towns and gathered some items -- nothing too significant yet, but the occasional nice accessory + crafting resources. There's one crafting item called a Rainbow Diamond I really want to steal off an NPC near the start of the game, but they make it extremely challenging to take. Pickpocketing an NPC only has one attempt each, so you pretty much have to follow a guide to know what each NPC will give you, and restart if you fail on any significant items. Also SO2 was made in the days before soft reset was common on RPGs, so every failure requires resetting the console, or getting a game over so you can reload your save. Eventually I decided I'd call it on attempting some of the rarer stuff for now in the interest of getting further in the game. The pickpocketing is entirely optional, but it yields some items that are hard to get for crafting ultimate gear later.

Eventually, I went back to the main story. I just completed the sword tournament in one of the cities. A story event forces you to lose in the final round to help show off how "cool" your rival Dias is as a sword fighter. I usually don't care for these scenarios in RPGs, but it's one of those ok cases where it's one of those very clear 1-shot wipeouts where you know you can't win.

I also went on a side-quest and recruited Bowman, a pharmacist who can rapidly throw handfuls of poisonous and explosive pills for special attacks. In order to recruit Bowman, you have to gather a rare herb from an annoying cave filled with lots of different herbs that you need to try collecting one-by-one until you find the right one. When I was doing the side-quest, my other characters gained tons of levels, because of the extremely high encounter rate and annoying branching maze-like nature of this dungeon. Using the "Scout" specialty set to avoid encounters at level 10 didn't seem to have any impact. Some enemies in the cave provided a fun challenge but others were just annoying to hit and wasted lots of time targeting. But now that my party is all the way up at Level 45 for this point in the game, my magic characters can cast lots of heavy attack all spells to wipe most annoying encounters.

Bowman joined at Level 25, so it'll take a little to build him up rest of my team. Either way, finally have a party of 4 members, so I guess once I recruit one or two other characters in the side-quests, my party will more or less set up for the rest of the game.

Starting to get a better impression of the game, and it's got some definite rough edges in spots but still enjoying my time with it. I'm hoping now things will start to move faster in this as well, since this annoying dungeon side-quest is over + not needing to grind as much.

I also had a few ideas to work on my high-level assembly language Wiz again (which I use for making most of my personal homebrew projects). Before I can do that though, I really need to work on cleanup + refactoring of the codebase a bit. I have already made a few plans on how to gradually split up the compiler code into smaller pieces so that it can be easier to maintain, but it's always a matter of motivation. Doing this sort of code-cleaning isn't very rewarding to work on, but leaving it to work on new features makes those more tedious than they could be, and makes the mess grow more.

None of these are impossible changes, it's really just sort of burnout and dread thinking of going back to this part of the code. Even though I like the process of creating a programming language and making compiler tooling, it's a different story about re-organizing the internals. It takes a lot of building up motivation to do these sort of tasks, for me, sometimes months away from the project until the right things align. Anyway, it's been on my mind more again, so it might mean I end up going back to it again. We'll see.

Anyway, that's all this week. See you again soon!