I’ve been posting on Twitter, because after the Brick Rick: Graveyard Shift release I went back to engage; but that will stop and return to very low intensity –I don’t even have a Twitter client on my phone–, because I haven’t changed my mind.

So that means one thing: it is Thursday and that here comes another gamedev update!

ubox MSX lib release

This is a maintenance release that basically fixes a potential problem when changing song with the play function being active in the interrupt handler.

I have used that same code in several games, and you only need to be a bit careful and wait for vsync before changing the song, to ensure that the code will finish before being interrupted. Given that this is a library for others to use, I have decided that it makes more sense to avoid interrupts explicitly.

I had the change in the repo for a while, and I still have a couple of things in my TODO, but the fix deserves a release just in case there is someone out there working on a game.

Targeting the ZX Spectrum 48K

When I was working on “Graveyard Shift” I half added support for 48K games, only that… it wasn’t really working.

The library I wrote for Brick Rick on the speccy is for the 128K models only because it uses double buffer by hardware (and therefore, memory banks), so a lot of code targets 0xc000 as video memory instead of 0x4000.

I have reviewed that code and made a few things configurable:

• By disabling the 128K support, all the tables are using the 48K memory addresses; and the bank changing code won’t work –48K models anyway–.
• The interrupt setup code is now fully configurable, so for example the 257 bytes table for the Z80’s IM 2 can be located at a high address (on the 128K models can’t be over 0xc000 because of the banks).

At the moment the same library can be configured at compilation time to target 128K or 48K, which is perfect.

I have a work in progress memory map that should work great for 48K games:

This leaves probably too much memory for the library and the stack, but for now I think is fine. I may move non speed-sensitive library code to that 0xf900 address, so I have more space for the game itself.

In my TODO there is also some sort of support to build a 128K version of the game, that should be the same game but adding AY sound. I’m not a fan of that, because I prefer to offer the same experience in all models, but people expect AY sound in 128K models, even if the game is targeting 48K. For now this is low priority, but it shouldn’t be too difficult.

I have a few possible ideas for the game, although it doesn’t need to be necessarily a ZX Spectrum 48K game. In reality I could jump directly into making the game, without having to write any new library code, if I was using my Amstrad CPC or MSX libraries, but I still want to make a speccy game on 48K, so there’s also that!

Crash was a British magazine specialised on the ZX Spectrum home computer, that run from February 1984 to April 1992.

There were a healthy number of magazines back then, and the speccy had very good coverage with several publications dedicated to it, but Crash was one of the most popular –if not the most!– in the UK.

Crash was already back with us, to some capacity, in the form of an annual. But more recently, the same publisher has launched a bi-monthly 60 pages publication in A5: Crash Magazine.

You can buy specific issues from the publisher’s website, or subscribe via Patreon –that has the option for PDF as well–.

I’ve subscribed and read the first two numbers, and I like it very much.

Looking at the last number (Feb 2021, using the cover of the second issue of the original Crash magazine!), there are three features (Cover crackers, Crash investigates and Crash back), three articles (Simon Buttler’s screens, Dreamworld Poggie, Software house capers), all the regular sections (Editorial, Lloyd Mangram’s Forum –reader letters–, Adventure trail, Nick Robert’s playing tips, Preview and Sign off), and lots of reviews of new games!

I already liked the annuals (I have 2018 and 2019), and this new Crash keeps the good things, and builds on top of them in a shorter and more immediate format.

The reviews are nice and balanced –mostly notable games, why would you like to review a bad game when most of the new releases are free to download and play?–, with the right tone and attitude. The regular sections have a nice “back in the day” feel to them, and the articles are also a good read.

There is some coverage of the ZX Spectrum Next as well, that I must confess I’ve been mostly ignoring until now; and overall I can’t find anything to improve. I couldn’t enjoy the original magazine back in the day, but I’ve been flicking through its pages on archive.org, and this Crash Micro Action feels like a good spiritual successor.

Anyway, I know it sounds crazy that we can still play new games for our loved 8-bit machines, but I must confess that reading a new number of Crash in 2021 was totally unexpected!

Two days ago I released the source code of Castaway, a game written in C for the ZX Spectrum 48k.

I had released this game in 2016, and it was my last game using Z88DK compiler. Back then SDCC was much better, so I changed compiler, but I’m told Z88DK has improved a lot in the latest releases and it is, in fact, the recommended compiler for Z80 microcomputers. I’m too invested in SDCC at this point –in 3 different systems!–, but I really like how Z88DK is evolving.

Anyway, that may not be relevant because I doubt Castaway’s sources compile with a modern release of the compiler –although I made the effort to ensure that it compiles with the appropriate version–, but I wanted to release the source code for two reasons: I had planned to do it for a while, and I read this post by Drew DeVault: the complete guide for open sourcing video games.

May be the title of the post is a bit clickbait-y, but I found interesting that Drew shares some ideas with me:

Video games are an interesting class of software. Unlike most software, they are a creative endeavour, rather than a practical utility. Where most software calls for new features to address practical needs of their users, video games call for new features to serve the creative vision of their makers.

That’s why I think that most games don’t really work well in a open source development model: release early, release often. Who wants to play an incomplete game in version 0.1.0 to play it again in 0.2.0 because it has some new feature? Although there are exceptions to this, like for example game engines, in general I don’t see the point of open source games.

But then, why did I make Castaway open source? Because what I have done is a code dump, and not really what open source is about.

Drew explains how some open source engines have been very influential –like Id’s engines–, but what finally convinced me to do it was:

Publishing open source games is also a matter of historical preservation. Proprietary games tend to atrophy. Long after their heyday, with suitable platforms scarce and physical copies difficult to obtain, many games die a slow and quiet death, forgotten to the annals of time. Some games have overcome this by releasing their source code, making it easier for fans to port the game to new platforms and keep it alive.

This is very relevant looking at current news that Sony’s PS3, PSP, and Vita digital stores may be closing this summer, and in a world where games are “digital only” that means a lot of games will be lost. And we know how many missing in action games we have in our classic platforms, despite the huge community effort to preserve everything.

Although I don’t think my games are at risk of getting lost –I believe most, if not all, have been preserved–, there’s also some value for anyone willing to learn by reading the code, despite not being the best code (I was learning, and Z88DK had its own limitations back then that translates into a lot of includes).

So it is done. Arguably I should be doing the same for the most recent games, but it is difficult; so Castaway is also preparing me to release more current code that is more what I am today instead of what I was as gamedev about 5 years ago. We will see!

Finally, Brick Rick: Graveyard Shift has been released!

The initial import to the git repo was on October 1st 2020, and I tend to do that as soon as possible because my backup is git! If the latest pure development commit was on February 2nd 2021, that was around 4 months.

As I mentioned here, the physical edition delayed things, and last Saturday I finally made the game public.

So far the reception has been excellent, I’m happy!

Some reactions:

• Full interview, where we talk about both Brick Ricks and game design (in Spanish)
• David ‘mamehaze’ Haywood (MAME developer) streams the game (and finds a bug!)
• The announcement on Twitter got 115 RTs and over 38K impressions, so that’s something!

This is the first long-play that I know of –warning: spoilers–. A quote from the review:

It is tough to come up with something new when it comes to platform games, but this one seems to be rather special for the Spectrum scene. It is a huge and challenging game where you will need to play tactical to defeat the different type of monsters.

The final score is 90%, which is pretty good.

Releasing software is always stressful, there’s no much difference to what I do in my day job, but it wasn’t too bad. Two early bugs that were easy to fix, and it looks like that will be it.

May be software is rarely bug-free, but I call it success if there are no known bugs!

I’ve been thinking how I can unit-test a big part of the code, and my next project hopefully will be verified in a better way, instead of relaying on manual testing only –oh, my games are always very well tested and yet!–. In fact on all my recent projects I’ve settled in a structure that splits logic and presentation (update vs draw), so it sounds possible; and at very least writing the tests will force me to have a deeper look at the code, meaning: less mistakes.

Anyway, go an grab the game. It is fun! And if you have the real hardware and fancy collecting, you can treat yourself with a TFW8b 499 copy.

Scala made me change the way I use vim, not only because relying on LSP for code navigation (previously gtags via gen_tags), but because the projects’ directory structure is way more complex than what I used to have in Python.

I used to rely on plain :ed filenameto open files, and then change buffers by just using :b name<TAB> (listing occasionally with :ls and selecting by number with :b number). But enter Scala and, for example, in my Gemini server the code lives in server/src/net/usebox/gemini/server/.

So I ended installing NERDTree and, although I have it always closed and only display the file browser when I need to open a file that I can’t reach immediately by using LSP navigation, it changed the way I work.

For a while I had a partial solution via the :find command. By setting this in my .vimrc:

set path=$PWD/**

In this way :find will search in all sub-directories, for example I can do:

:find filename<TAB><TAB>

But this is far from ideal. It kind of works, but very slowly and is not smart at all, so you get a lot of guff when it tries to find files by scanning all subdirectories (and when you want to open filename.scala you may find that filename.class gets in the way).

Why I didn’t use –or know– the awesome fzf? I can’t tell, but I installed it last night and I’m in love!

Not that I’m going to get rid of NERDTree, but I suspect I’ll use it less and less, because as Tom MacWright puts it in the return of fancy tools:

[…] This is obviously not the future of coding: shouldn’t I be navigating the source tree in 3D like in Jurassic Park? Sure, but the names of things, their functionality, and how it all fits together should be things that exist in one’s mind, not just in a computer.

That resonated with me, because that’s exactly what I was doing in Python, so I tried that fzf tool that he mentions in the post. I guess late is better than never.

I’ve been vim (or neovim) user for around 20 years –can’t say how long exactly, but that sounds about right–, and I’ve tweaked my way of using the editor every now and then, adapting to whatever I’ve been working on at the time.

For example, 5 years ago I was happy writing Python with syntastic and just calling Pydoc from my editor; but now I think I prefer using Python language server, plus some auto-formatting “on save” to conform to PEP8. It’s just a nicer experience.

On that context, I recently gave another go to emacs with LSP Mode, because it looks like the most complete LSP experience around (LSP comes from Language Server Procol), besides I guess using VS Code.

Not that I’m unhappy with vim-lsc, but LSP Mode has support for code lenses (for example), that add some context based operations to your code, such as “run this test”. The LSP server I use for Scala is metals –I don’t think there’s any other option–. It keeps improving on each release, but I’m aware vim-lsc doesn’t support all that metals offers. I just wanted to know what I’m missing.

So basically I gave emacs vanilla a go, after installing from a PPA repo version 26 (my Ubuntu at work only ships up to version 25), and got a very basic emacs configuration, enough to run LSP Mode. And it is nice, although I didn’t see anything that I would consider essential, it was enough to make wonder if I could move full-time to emacs (again; is not the first time I try!).

To make this attempt different, I decided to give Doom emacs a go, because if I need to get my own emacs configuration to the point where I can do the equivalent work I do in vim, is not going to happen. I just don’t have the motivation.

I compiled emacs 27, with only console support –I find the X11 version adds to much latency, and I’m very happy with tmux–, and Doom emacs took around 8 minutes to install with Python and Scala support (both with LSP). That already put me off considerably. To be fair: if I did’t want that level of complexity, I could be using vanilla emacs (but we would go back to not having the time or will power to get all configured).

Long story short: Doom emacs didn’t work for me. Not only because the overwhelming amount of options, but also because after all the steps, I couldn’t get LSP Mode to work as well as I managed to make it work on my hand crafted emacs configuration.

Although I didn’t get anywhere useful, it was a good experience. I think know now that emacs is not the answer to any vim’s shortcomings, because emacs comes with its own issues. So I guess I will give the JetBrains IDE a go, and see if a full IDE is worth it. I suspect is not going to be it, for the comments I hear around me: slow, bloated and complex. oh, isn’t that an IDE?

I was commenting my experience with my team mates, one of them long time emacs user (Clojure guy!) and the other one VS Code user, and the first conclusion was that part of the problem is Scala, or may be its ecosystem, because without the assistance of a smart editor or an IDE, it is very difficult to use third part libraries because the usual complexity of the type system.

The other was that IDEs have got to current levels of complexity (and power, to be fair) because of languages like Java, that really can use the help of such tools.

I know I’m not an IDE person, but I still want to know what is the state of the art, in case there’s anything I can add to my work with vim so I’m perhaps a bit more productive.

It is Thursday and, if you were paying attention, last week there was no gamedev update.

Life is sometimes busy, and you know I have been a bit intense with my Gemini server. Considering that I can do only one thing at a time (mostly), I haven’t progressed any of my new projects, and I was waiting on some things for Graveyard Shift.

And good news: the cover is ready, the inlay design is ready, the loading screen is almost ready, so what is left?

I need to write a short press release to be sent to a handful of specialised websites that cover retro-gaming, and that’s pretty much it.

When I have the loading screen, I will assemble a release candidate. There will be some last minute smoke tests, and finally release; likely next weekend.

I always prefer waiting a few days before sending a master to the publisher, so expect the physical release to be out from one to two weeks after the release. Remember tfw8b, 499 range.

Now, is not 100% accurate that I haven’t done anything else related to gamedev, but let’s keep it a secret for a bit longer, shall we?

So Python has pattern matching in 3.10:

# the syntax highlighter doesn't know what to do
# with this new construct ;)
match point:
    case Point(x, y) if x == y:
        print(f"Y=X at {x}")
    case Point(x, y):
        print(f"Not on the diagonal")

And I think it looks fantastic!

I always found the chains of elif a bit awkward, but I guess that was part of what made Python simple yet powerful.

And this feature goes beyond that –take a look at the tutorial, search for value extractors-, and being this one of the features I liked most in my first contact with Scala, this is probably one of the few recent changes in Python that I find truly exciting (I must admit I didn’t like type hints initially, but now I think they are a very good idea).

It is still an alpha release, and it will need some time until it lands my Linux distribution (this Debian box is still on 3.7.3), but if I go back to do Python professionally, looks like it could be a lot of fun!

So finally I decided to use one of my underused servers and deploy my Gemini server, and host some content.

If you don’t have a Gemini browser, I guess this link is not very useful, but there you go:

gemini://capsule.usebox.net/

I found it quite funny because, after configuring everything and checking that all was working, obviously nobody is going to visit my capsule –like a website in the Gemini jargon–, because nobody knows it is there.

But it was exciting nevertheless. I used the opportunity to write a short “how to”: deploying SpaceBeans on Debian.

It is using systemd to manage the service. Nothing special, but it works nicely. Not 100% happy with the logs, so I may revisit that part explaining a few options to deal with them.

One thing I’ve noticed is that the library I use to parse the command line depends on a library that is a bit heavy. Well, not that much in the grand scheme of things, but let’s say that adding 10MB to a project like this, sounds excessive.

So on the next version it will use scopt, that is excellent and it will make the distributed bundle smaller. It is a learning process. Worrying about 10MB in my day job would be laughable, so I’m not used to it.

I have a few more ideas to add to the sever, so I may implement something from that list before making a new release.

Last night I finished the tests, or at least enough tests, so I could make a first release of my Gemini server: SpaceBeans.

With the name I tried to link the Gemini space theme with the idea of the server running on the Java Virtual Machine. So those beans are coffee beans, of course.

In case you haven’t read about it on this blog, the current list of features is:

• Static files, including optional directory listings
• IPv4 and IPv6
• Configurable MIME types, or a built-in resolver
• Virtual hosting, with SNI support
• User provided certificates or auto-generated in memory (for development)
• Configurable SSL engine (e.g. TLSv1.2 and/or TLSv1.3), with configurable ciphers

Which I believe it the minimum to make the server useful.

This is also my first release of anything Scala –out of what I do in my day job, that is–, so it has been an interesting experience.

Other than the source code (MIT licensed), you can download a .jar file that bundles everything you need to run the service on the JVM. My experience releasing services so far has been via Docker images, but in this case I think the lightweight nature of Gemini makes it a bit overkill.

There are a good number of Gemini servers out there, and some of them are very popular already, so I don’t expect anybody to use this; but you never know!