I’m back, and I have a retro computing related thing for youall! I’ve been doing a lot of art lately and almost no programming. I’ve even been taking art classes to really level up! But I also wanted to keep my bunny toes a bit in the retro world, so I’ve been learning how to use the most recent version of the quintissential Amiga art program, DeluxePaint V (or 5 or Five or whatever). It’s an amazingly powerful art tool for the time, and it didn’t take long after reading the manual to see how to translate a decent chunk of my Krita-based workflow over to DeluxePaint. Not everything, of course, but enough to be dangerous.

Here’s a couple of the pieces I’ve done in DeluxePaint. I also post these on my personal site, Pixelfed, and FurAffinity:

An important part of getting fast with digital painting workflows is keyboard shortcuts. Even today, using menus or toolbars to navigate is not as fast as hitting keys on a keyboard. On older computers, whose help features were limited to non-existent, and whose manuals could be difficult to slog through, games and applications came with printed keyboard overlays that listed hotkeys and common operations.

I couldn’t find any overlays for DeluxePaint V online, and I wanted something silly to give away at VCF East 2026 this weekend, so I assembled a keyboard overlay for DeluxePaint V that works on the Amiga 1200, and should work on the Amiga 500 too!

Download my custom Amiga DPaint V overlay template PDF. It’s a two page PDF. Print it on US letter paper in landscape mode, then use a window or light table to line up the two pieces and tape them together. Reinforce the indicated areas with more tape, then cut out the grey parts, cut around the border, and lay over you A500/1200’s keyboard.

So much code and art this week! The pencil art from last week is now in sticker form and I’ll have them at VCF East:

I built the first full level of the game in Inkscape. My level generation code takes an exported PNG and turns it into the correct binary map data:

This process was sufficient to get a single level together, and revealed a bunch of gameplay bugs around jumping that I fixed this week. Jumping should feel more like how tighter platformers like Celeste or Mega Man work.

I also realized the single tile type for the VCF East release was going to be very boring, so I reworked the architecture to allow for different tile types. Here’s the game rendering the spike tiletype, which will cause instant death if you touch it with your feet or head:

Next is getting those collisions actually working, then updating my map editor to allow for different tile types. Once that’s in place, I’ll get my basic music playback working and get this onto a few different machines to test out the results. I also have a few friends I’ll send it to to get some basic feedback before the VCF East release.

I’m getting close to having all of the game code in place for an alpha release for VCF East. I finished up a lot of smaller tasks that would unlock bigger things down the road:

• dynamic palette loading, as all the palettes so far were hard-coded
• fading the bottom info screen in and out along with the main game screen
• loading compressed music MODs

I decided this week to start working on the game’s main menu screen. I want to have a small (skippable) animation that eventually drops you onto a much nicer looking main menu. For this, I decided to start with a nice, clean rendition of the game’s player character in a pose I’m quite proud of:

I drew the original on paper, then turned it into a vector image in Inkscape. It’s high quality enough that I’m going to get stickers printed to bring with me to VCF East and other cons.

There’s other art incoming, but I want to get the art pipeline to Amiga graphics in place, and build the assembler code and tests for the menu, before I dig in even more into graphics. My current challenge is finding a way to build the graphics in such a way that I can have a consistent palette, with the ability to import art from Inkscape, Krita, or (maybe) Blender, and slice up that art into individual memory blocks that I’ll concatenate and compress with XPK, with as few manaul steps as possible.

The issue is that I have an indexed palette that I really want to build and preserve in LibreSprite across multiple images. This means that any automation using ImageMagick is out, as ImageMagick is insistent on rearranging indexed palette colors if you modify the image. Instead, I’ll start slicing up the image using GIMP automation and Scheme scripting. Using this code as the base, I’m able to build a bash one-liner that lets me crop an indexed PNG image, preserving the palette order. Of course, there’s an issue with this as well, as if the image has any pixel marked as transparent, GIMP will happily add a color to the colormap for you. For sprites I already need to have a solid background in LibreSprite for a similar reason, so this will extend to non-sprite images as well.

This week was a hodge-podge of work:

• Finishing up next level loading
• Allowing for variable length levels
• During warmup, only show each pose once
• Get the game working on the Amiga 500 (well, 68000-based Amigas)

The last one was interesting, as it required hunting down every place in the code where I had odd memory accesses and squashing them.

The symptom of this is when the Amiga would crash with Guru Meditation error 80000003. This is CPU exception 3, which for the 68000 means “Address Error”. This Antic Magazine article gives a pretty plain description of the problem, and in my case, it was a combo of odd address writes and misaligning the stack. Something like this would cause a crash pretty easily:

  STRUCTURE MyData.0
  APTR MD_someData
  UBYTE MD_someCounter
  LABEL MD_SIZEOF ; => 5

myCode:
  SUB.L #MD_SIZEOF,SP ; uh oh it's odd
  BSR somewhereElse   ; crash
  ADD.L #MD_SIZEOF,SP
  RTS

There were a few posts on various Amiga boards to point me in this direction, like this one. The reason I’d never run into this before is the 68020 in my emulated A1200 will work around odd memory accesses and not raise an exception that the Amiga would later present as a Guru Meditation.

I did manage to get a single run of my unit test suite on the A500, but it quickly corrupted memory. Unless things get real dire, I’m likely not worried about getting it working over there. Maybe before release, if it makes sense.

I’ve started work on being able to exit the level you’re on when you reach the end, and load up the next level:

Thankfully I already have a good testing approach for these non-interactive state machines, and so it was reusing the same approaches for warming up and colliding with an object. I also abstracted out more of the game’s physics engine for reuse, which I had started when dealing with the head konk animation.

A lot of my early code relied on hardcoding values into the assembler code just to get things working. Now that I’m much more competent with assembler, I’ve been removing the hard coding and replacing with code to generate values. For level loading, I needed to be able to specify the data files to load, which involved some string-generation code using exec/RawDoFmt. This is a function I already have a lot of experience using, as I use it whenever I need to debug intermediate values in assembler and don’t want to reach for a debugger. On the Amiga, sometimes it’s just easier to print everything to the console.

This week I finished up the warmup graphics. Lots of animation work and a good bit of unit testing and you now see randomized poses at the start of the game, and fewer of them if you just recovered from a crash:

Next up is being able to transition to a second level after you make it through the first. This is likely going to require restructuring a lot of code, since the current assumptions are all around having a single level.