I don’t think it is a surprise that a big part of the community around Hacker News is against the idea of copyleft (e.g. licenses like the GPL, AGPL and LGPL to some extent). They are a clear example of what is the result of the corporations getting involved in open source: the more permissive is the licensing, the better. So they can take, and don’t be forced to give back.

Is not an easy topic. When I was at University there was a whole course to learn about laws around software, and that included licenses. It is very easy to get confused, and people often argue about free software vs open source, perhaps because the Free Software Foundation has often been divisive in their way of promoting the philosophical side of open source.

What is copyleft? From Write Free Software (licensed CC-BY 4.0):

Copyleft is a licensing tool unique to free software. It is designed to encourage the proliferation of free software and protect free software from being incorporated into non-free works. This works by giving you not only the right to share your improvements, but the obligation to share your improvements under some conditions. It is very important to understand these obligations when re-using copyleft software in your own work.

And that obligation is what is referred as virical, and what the corporations don’t like. Specially in today’s take of computing, with cloud computing and software as a service making them all that money.

I used to be an open source / free software advocate 20 years ago, but I stopped because, at some point, it looked to me like we had accomplished some of our objectives (and I guess I got tired). But the truth is that things aren’t as good as they could be.

What was always front and centre was user freedom, something that open source ideas don’t really care about. Not because the licenses are different –because most open source is free software–, but because what it was always important was the copyleft.

So we need more free software, and Write Free Software is a very good resource that explains all you need to know –not really, you don’t need to know all that; but if you make software, it should help you–. It isn’t as confrontational as the Free Software Foundation resources, and definitely easier to read!

I guess is a sign or getting old when we stop tinkering with Linux distros, desktop environments, and windows managers. After Gnome changed to their new idea of desktop in Gnome 3 –back in 2011–, I tried hard –and for an embarrassing amount of time, considering I wasn’t happy–, and finally landed on XFCE. It was a weird time in the Linux desktop space.

XFCE was a bit different to the Gnome 2 experience I liked, but when I tried XFCE 4 on Debian Jessie it felt like home.

And don’t get me wrong: it has never been perfect. There are some issues that have been bugging me for years, like the screen lock getting stuck after suspending –and because it is rare, plus not being clear who owns the bug, it seems unlikely it will be fixed–, but as a desktop environment it is out of the way. What else can you ask?

Then I know a lot of people using tiling window managers, to the point that I may have been the only one not using one already. I had a few key bindings in XFCE to give me some limited features of that type of window management, but I was wondering if there was something I was missing out.

So I finally tried i3wm after some research, because it looked like the most user friendly –despite having a steep learning curve, like all of them, but that’s true for most power tools–. I installed it alongside my XFCE, gave it a quick go, and I put it on the back burner because it wasn’t the right time to disrupt my workflow –I was finishing Hyperdrive–.

Until last week, that I gave it another go, and I love it.

i3wm feels fast and responsive, and being used to the vim + tmux experience, it felt a very natural way of working. Sure, it needed some effort to configure, and I don’t think I’m finished with it, but I’m getting there.

Currently I still depend a bit on having XFCE installed, which is not a problem, because I still use Thunar for example to browse files. If at some point I install a system from scratch, then I will do a more focused selection of applications I really use and I may not need a full desktop environment that I won’t use.

My i3 configuration is available, and it will need some time to get close to that perfection I’m talking about. I have passed the test of streaming with OBS, which was the part that I initially thought it would be “harder”.

However, currently I have a couple of issues:

• I’m using xfce4-screenshooter to take screenshots, and works beautifully, but it doesn’t give me the option to put the screenshot in the clipboard; which is mildly annoying.
• I’m using kazam to record videos, and when I try to select the window to capture, it goes wrong and I can’t see the windows. If I click where the window should be, it does the capture just fine.

Other than that, I’m converted already. And if (when?) I have to move to Wayland, I can move to Sway without much work –other than not using XFCE apps unless it has Wayland support by then!–.

So I guess I’m not that old yet, because there’s some tinkering spirit still in me.

Update (2023-07-08): because I got a couple of emails mentioning it and I had solved “the issue” already, let me update on the screenshot “issue”.

Just run XFCE’s climpan! In X11 there is no shared clipboard, so you need an application that can keep that data when the screenshot tool is gone. My i3 config has now:

# Clipboard manager
exec --no-startup-id xfce4-clipman

Then you just need to configure it to your personal taste. Because XFCE didn’t show the icon of the application when it was running, I didn’t know it was there.

Thanks again for the emails and the i3 tips!

So it all started because a copule of people I follow on Mastodon are into DOS game development, and they are doing very neat stuff. I looked at some of the games and I saw that DJGPP is still around! It was my first ever contact with GCC, GNU and free software –although I didn’t notice that last part, or I didn’t understand it–. It surely changed me, like having a ZX Spectrum as a kid had a lasting effect on my career, before I started using Linux.

I made a few programs with it, with different levels of success. Some of them even got “published” on a magazine at the time –via one of the sections, you could send them your stuff and they would comment it and include it in the CD-ROM distributed with the magazine–. Unfortunately I never managed to finish a game.

Today I’m better equipped on the knowledge side of things, and I have a few finished (and released) games under my belt. I also think I have better tools and computing environment today, so I thought: would it be that hard to make a DOS game today?

That type of question has always worked for me. That is how I got started making ZX Spectrum games in 2014, and a few other systems after that. I always answer if I could and never wonder if I should, which I will leave to you dear reader to decide if is a good or a bad thing.

Besides, recently I have passed the 4 years mark doing streaming of my coding sessions –with 40+ videos uploaded to YouTube–, and I thought it would be a nice experience to try and make a simple DOS game on the stream. There is also a DOS game Jam happening, so it is all there!

Obviously, this is yet another project, that adds more distractions and things to my already long TODO list; but considering that it should be quick, there is nothing to worry about, isn’t it?

It won’t be a tutorial, but I tend to explain what I do on the stream, and the source code is available. It all depends on the skills of the person following the series, but it could work as a good introduction or, at least, as inspiration.

That doesn’t mean all the streams will be “making a DOS game”, but until the game is completed, there are chances they are the majority of the videos. Nothing is happening with my unnamed Haskell game for PC, the TR8 fantasy console, or Outpost for the ZX Spectrum. Those are still on and healthy.

I’m streaming the sessions on my Twitch channel and the videos will shortly appear on this playlist on YouTube, so there are two ways for following the project.

I got the inspiration from the fantastic rasm –a Z80 assembler–. rasm supports a number of formats for input and output, and the input goes way beyond the “include” we can find in some assemblers.

As part of my TR8 fantasy console I have implemented .incpng "file.png", that does the following –from the docs–:

.incpng “filename”
Read the PNG image and add the content to the output at current position. The image colors will be matched with the TR8 palette and any non-matching color will be considered transparent and the index 128 will be used.

So it is like a “include binary”, but it understand and reads a PNG file, including the pixel data in the assembled output.

It converts the image to red, green and blue triplets –RGB values– and maps them to the EGA default palette –which is the palette I’m currently using–. If a RGB value doesn’t match the EGA palette, the tool uses 128. That value is used with the blitter if transparent is enabled to treat it as transparent –otherwise it will be black–.

It is so convenient to use! But obviously, this is only because I’m writing the assembler myself –and it has many limitations, currently–. Using other compilers, very often the options are very limited, and that is when my conversion tools written in Python save the day.

Over the years I have been playing with the idea of writing interpreters and compilers, and I say idea on purpose, because I haven’t been very successful at it. Something similar happens with operating systems and virtual machines, although I have been a bit better with the latter, I had many projects started over the years without results.

Considering that I have been doing game development consistently for almost 10 years now, the idea of a fantasy console is so perfect if you want to write those, that I would say it was almost inevitable I made one.

And that’s why the TR-8 fantasy console came about.

It is all very work in progress and, instead of spending a lot of time planing and designing without getting to make anything, I decided to start implementing and put together things as I go. And you can tell when you look at the design of the 8-bit CPU.

Without getting in too much detail, an example program:

.org 0

; address of the frame interrupt vector
.equ INT_VECT 0xff00

    ; setup an int handler so we
    ; can use the frame int to sync
    ld a, >INT_VECT
    ld x, <INT_VECT
    ld b, <int_handler
    ld [a : x], b
    inc x
    ld b, >int_handler
    ld [a : x], b

    ; enable interrupts
    cif

    ; loop filling the screen with one
    ; colour cycling the whole palette
    ld b, 0
loop:
    call fill
    inc b
    and b, 15

    ; wait 1 second
    ld x, 60
wait_loop:
    halt
    dec x
    bnz
    jmp wait_loop

    jmp loop

    ; fill frame-buffer with a color in reg b
fill:
    ld a, 0xbf
    ld x, 0
    ld y, 0x40
fill_loop:
    ld [a : x], b
    inc x
    bno
    jmp fill_loop
    inc a
    dec y
    bnz
    jmp fill_loop
    ret

int_handler:
    iret

That may give a bit of a taste of what is TR-8.

At the moment I’m working on three essential components:

• a virtual machine for the CPU
• an assembler
• a “player” that uses the virtual machine and provides the other bits of that make it “a console”

All written in C –hopefully portable–, with SDL2 for the player.

As I say, it is a work in progress, but this is what I have decided so far:

• Display: 128 x 128 pixels 16 colors (using the default EGA palette for now)
• Memory: 64K
• CPU: TR-8, 8-bit, 8M instr/sec (for now, likely make it slower when I add the hardware blitter)
• Sound: TBD, likely to be either a PSG or perhaps FM (OPL3?)
• Programming: ASM

The TR-8 CPU is inspired by the 8-bit CPUs I have programmed: the Z80 and the 6502; but also the MIPS (specially on how I’m encoding the instructions). This is not about a good design but about having some fun.

The main features of the CPU are:

• 16-bit registers: stack pointer (SP) and program counter (PC)
• 8-bit registers: 4 general purpose registers (a, b, x, y), flags register (F)
• frame interrupt (60Hz)
• port based IO (very Z80)
• a frame buffer (16K of RAM as video RAM; I thought about implementing a VDP but then I realised I was copying the MSX!)

I don’t know how far I’m going to get. I guess I will implement enough to feel satisfied, perhaps making a game for it, and that’s probably it. I don’t expect anybody using this, when you can make games for actual 8-bit machines –or more user-friendly fantasy consoles like the Pico-8 or the Tic-80–.

I think this is my first ever recently type of post, let’s see how it goes!

Trip to Spain

We spent a bit over a week in “Arenales del Sol”, in Alicante (Spain). Visiting family, enjoying the good weather, the beach, and resting. It was pretty good.

The less good part was that I couldn’t met old friends that I haven’t met in in years, because Arenales is kind of isolated and we had limited access to a car. Next time!

I didn’t write a single line of code on that period, at least on a computer. I wrote some ideas for a fantasy console, but all with pen and paper, so it doesn’t count!

IRC is the new IRC

I have been using IRC since February. I’m surprised because it doesn’t feel like was that long, but weechat logs don’t lie.

I started using it by the time I stopped using Telegram. We decided some time ago to only use Signal for the family communications –and a couple of old friends that happen to have my phone number–, or I should say my sister decided because she moved my parents from Google’s Hang out (or Meet or whatever is called this week!).

Closing my Telegram account wasn’t easy, because I had a few friends there that I don’t think I will talk by other means –people don’t do email any more–; but I don’t trust Telegram. Too big and freemium, not fully open source, and an unclear business model are a few of the reasons. Signal is not perfect, but is better.

IRC has been OK, I’m on a few channels and most are basically idle, with the exception of #haskell-game and #gamedev. The latter not being too different to some Telegram group chats I used some time ago, focused on a topic related to development, with the good and bad things –specially a lot of people that don’t do any actual development, so they add noise to the channel–.

Looks like everything is on Discord now. I guess if I really wanted the interactions, I would join one of those servers. Or I would still be using Telegram. It is complicated.

Persona 4 has gone cold

I started playing Persona 4 on the PS2 back in January, and I loved it. Well, I still love it, but it has slowed down too much and I find it hard to keep playing.

The downtime between events on the main story, where you are supposed to do the school routine, increase your stats by doing different small quests and interact with different characters, and grind; all got a bit shallow at a times. Like the school camping trip, with some conversations that help building the characters, but it was around 30 minutes of just press X to continue. I don’t want all combat, but it has become a bit dull at this point with not much feeling of progress.

There has been another event now that is part of the main story, so things are going back to be more interesting, but I’m not looking forward to keep playing.

So after 25 hours I’m about a third of the game. It is still an amazing game, and just checking a saved game to write this post and listening to the music it almost makes me want to play it, but it is a long one!

Revived Outpost and Haskell is fun

I mentioned here that I’m working on a game using Haskell and SDL2, and I used the “Outcast” sprites as a reference. So Víctor was wondering what happened to my ZX Spectrum project, and we reviewed what I had and together we completed the design of the remaining puzzles.

There are so many cool things on that game! It would be a total shame if that never gets released, so I have restarted the work on the project and things are progressing nicely.

It won’t be the same game I originally envisioned, but that’s probably for the best to be honest. The project is more focused now and I know exactly what is left to be done, although some of the ideas Víctor suggested are going to be tough to implement. But that’s OK, it is going to feel fresh. Do game design like you are 6 years old!

So there will be a ZX Spectrum 48K release from me in 2023, and the Haskell project keeps going. I have been streaming on my Twitch channel and some of the videos are in my YT channel, and it is a lot of fun –programming Haskell, the videos not that much–. It won’t be a big game. I don’t even know it if will be fun to play, but it will be finished this year –my first PC release in ages!–.

And that’s all that has happened recently.

I wrote here about gamedev in Haskell, but I didn’t have much to show. I was still exploring some ideas and I wasn’t sure it was going anywhere.

Now I think the engine is taking shape and there’s a public git repo, but I forgot to mention it here. For some reason, when I talk about these things in a channel, I forgot to do the same in the others.

Currently we have:

• My Mastodon account, where I tend to update often if I don’t stream, but I always forget to announce when I’m streaming.
• My Twitch channel, where I stream when I’m in the right mood –and I’m not too tired–. Sometimes I just want to code, and making it publicly requires considerably more energy.
• My coding sessions on my YouTube channel, where I upload a copy of some of the Twitch stream –Twitch removes the past stream videos after a while–. I don’t like Twitch too much, but I don’t like YT either; I seem to get more views and comments on YT though.

And, of course, there is this blog. So I guess a good way of following this project could be following me in one of those, and probably not this blog, because I’m not consistent enough!

The engine is nothing too special, other than it is written in a functional style, and in Haskell. I haven’t had to do anything hacky to make it work, so for now I’m pleased with the code. However, I’m still learning and I wouldn’t recommend the code specially to anyone willing to learn gamedev in a functional way. Some people with more experience than me have told me that the code is OK, so there is that too.

The original plan was to make a game jam type of game, so I don’t get in one of my “4 to 6 months” projects when I’m still not sure what I’m doing. Besides, it is a game for PC and not an 8-bit system, so there may not be much interest to play it when it is finished, so I didn’t want to invest too much time on it!

But then my boys are excited and suggesting ideas, so we shall see! For now it is a simple “collect them all to get to next stage” type of arcade platformer, and when I have a sufficient game I may just release and leave it there. You can watch a short video of the game –in YoutTube–.

Then all the lessons learned could be used to start an actual special project, with more of a plan and hopefully more chances of completing despite being a larger commitment.

Some time ago Juhang Park contacted me to say thanks for ubox MSX libs –which is always nice–, show me some work in progress games and ask for my permission to write a book about game development in C for the MSX using my libraries.

That was interesting. I don’t think anybody needs permission for that –even without considering the licence of the libraries–, so that is what I told Juhang. I wished them good luck and kind of forgot about it.

Well, the book has been published now in Korean: The retro game development bible. Which is very cool!

Apparently the book was rejected a few times because it was “only MSX”, so Juhang had to cover more ground by including MS/DOS and other “retro” targets –the site selling the book lists a lot of systems, but I can’t tell how deeply they are covered–. And there is something unexpected: Juhang wrote a translation layer so my API can be used with SDL1, SDL2 or Allegro as backends.

There is a reimplementation of King’s Valley 1 using ubox MSX libs –that I’m guessing it is used in the book–. It can be played on the browser thanks to WebMSX. There is also a repo with some info about the different chapters.

Juhang offered to send me a copy of the book, but I can’t read Korean, and told me that there are two MSX games that hopefully will be released soon: Galkave (a horizontal SHMUP) and Bomberman Special (a Bomberman clone).

It is complicated. May be my games aren’t that good or interesting, but if you can only play them if you compile them from source –and besides, written in Haskell–, that is perhaps too niche even for me.

This weekend I put some time into researching it, and there’s some documentation (for example: Cross Compiling GHC), but things don’t quite work. The most interesting issues I have found:

• Haskell is written in Haskell, so you need a Haskell compiler. Apparently 9.2.5 won’t compile 9.2.5, or I did something wrong. Using 8.10.7 seems to be OK.
• The cross-compiler is hosted in Linux and the target is Windows, yet the compilation of stage1 tried to include windows.h; which is not available in Linux. I must confess don’t quite understand what was going on, but I couldn’t get past that.

It is slow to try and repeat. Besides, once things fail, there isn’t much I can do.

So I shifted my focus to a different approach: can I run the Windows binaries in Linux using Wine?

It is possible, and I have put together some docs and scripts in cross-compile-hs-wine.

The first part was easy: getting GHC –the Haskell compiler– and Cabal –one of the Haskell’s tools to build Haskell projects– to run using Wine. I mean, is not trivial, but is not too hard. At least for pure Haskell projects, because if your dependencies need a C compiler, or even worse, are bindings to C libraries –like SDL2 and SDL2_Image–, things get very fiddly.

So at the end I had to get everything running in Wine, which includes:

• Cabal for Windows.
• GHC for Windows.
• MingGW-W64, a port of the GCC compiler suite to run in Windows.
• SDL2 and SDL2_Image development for MinGW.
• pkg-config-lite, a version of pkg-config for Windows.

Looking around, seems like installing Haskell on Windows (and SDL2) isn’t that easy.

For the second part, because Cabal is awesome, I only had to write a wrapper for it so it can find everything it needs when running from Wine, and after that it was just a couple of issues to get the sdl2 to compile. First I couldn’t get Cabal to find pkg-config, and second I think it might be a bug in sdl2-image –I will open a bug report–.

The compilation is slower than the native Linux versions, and the generated binary doesn’t quite work in the Wine version shipped by my Debian 11 (stable) –tried with unstable from a container, and Wine 8 runs it perfectly–, but this makes things OK: I can build and distribute binaries for Linux and Windows –even if the Windows part is a bit awkward–.

So now I can stop procrastinating and keep working on the game.

So at the moment I have a couple of 8-bit projects on hold, or what we could call my TODO list, but I also have a couple of ongoing projects in modern systems. As I mentioned, there are some ideas I would like to implement before I can do it in a 8-bit microcomputer (you learn by doing it wrong).

At first I thought about finishing my little Canvas 2D engine that I wrote refreshing my Javascript. And it all was going well, until I met again an old friend: I’m not sure if what I’m doing is correct, and the performance of Canvas 2D in Linux is just not what I was expecting. It uses too much CPU, and after a bit of profiling my code and comparing with other games online, I got to the conclusion that it wasn’t me.

I probably should release that engine “as is”, although I don’t know why anyone would use it.

I didn’t like the result –that could be an issue in Linux, or a recent regression–, and it didn’t matter if I was using Firefox or Chromium. I tried PixiJS, that is a nice framework that wraps all in a 2D API, so you can use WebGL instead of Canvas 2D, and it didn’t get better.

And to not make it a rant on the state of the web browsers on Linux –or in Debian, for me it doesn’t make a difference if I doesn’t work well enough on my system that means it may be like that or worse in other systems–, I also tried LÖVE, although my experiences with Lua in the past left me a bit cold.

Turns out LÖVE is great, despite spending with it only a couple of days. Good documentation, the poor performance I was experiencing with the web browsers is gone, and if you fancy going functional you have Fennel –which is a lot of fun!–.

But then –and this is my own fault– I decided to look at some libraries for LÖVE, and that didn’t go well. I should have done all myself, and I would have saved time fighting those libraries to get to something that was not really inspiring me. So I run out of energy, but I think LÖVE and Lua are worth revisiting. After all my time doing gamedev in Python struggling with performance, this felt great!

Then I remembered that I had a code base that I prepared to use C and SDL2, but never used it for anything. “This is the time!”, I thought. And that is one of my “projects to learn”, a simple JRPG that is progressing nicely –I’m currently working on some formulas and you could see my JRPG design notes (not anymore)–. I should write a post on how I’m integrating fe –a tiny Lisp-alike scripting language–.

And as I keep writing good old C I was looking for something else to do in Haskell, because I have done a couple of things, but my last project was too big and I was learning too many new things at the same time. So why not a simple gamedev project? That would limit the scope.

I have nothing interesting to show yet, because I’m still struggling to have some graphics or even an idea of what I want to do, but the SDL2 bindings for Haskell are excellent. The API has changed a bit to make it more high-level and closer to Haskell, but it wasn’t too hard to understand those changes –taking into account that I’m not an SDL expert!–.

The idea is to make something simple, closer to what I would produce in a game jam, and make it public to get some reviews and tips from friends.

So far my main struggle was around parsing JSON files –for tiled maps–, which I wouldn’t say is too gamedev, and it was a good learning exercise. At the end it was easier and cleaner than my C code using cJSON –that is pretty good–.

Anyway, I’m looking forward to have that small game ready. I’m using ReaderT + IORef and so far the functional and no variables bit hasn’t bothered me at all!

At the end this post is not that much about the title. Oh, well. As an example, this is how my map renderer looks at the moment.

-- | Renders a map.
render :: SDL.Renderer -> Map -> IO ()
render renderer (Map mapData tex) = do
  mapM_
    ( \layer ->
        mapM_
          ( \(x, y) ->
              renderTile x y $ tlTiles layer !! (x + (y * mWidth mapData))
          )
          index
    )
    (mlayers mapData)
  where
    mw = mWidth mapData
    mh = mHeight mapData
    index = [(x, y) | x <- [0 .. mw - 1], y <- [0 .. mh - 1]]

    firstgid = tsFirstGid (mTileset mapData)
    cols = tsCols (mTileset mapData)
    tileWidth = tsWidth (mTileset mapData)
    tileHeight = tsHeight (mTileset mapData)

    renderTile :: Int -> Int -> Int -> IO ()
    renderTile x y tile
      | tile < firstgid = pure ()
      | otherwise = do
          let tx = (tile - firstgid) `rem` cols
              ty = (tile - firstgid) `div` cols
              src = U.rect (tx * tileWidth) (ty * tileHeight) tileWidth tileHeight
              dst = U.rect (x * tileWidth) (y * tileHeight) tileWidth tileHeight
          SDL.copy renderer tex (Just src) (Just dst)

Considering that it is two functions –plus another one to get the SDL_Rect, but that’s not strictly necessary–, I’m quite happy with it!