A Respawned 80s Game Developer who got bored writing insurance software and decided to misspend some more time in much the same way as he misspent much of his youth: making games.
Except this time not in 100% Assembly Language or on 8-bit home micros. Probably.
Friday 3 July 2020
Turbo Tomato: 0xc0dedbad
In the previous devlog or two, I've been grinding through the work required to shift the bulk of the game graphics over to a better overall palette.
But now it's time to level up and dive into to the matrix.
OK, I admit, the palette change work isn't fully complete. I did add a number of new asset pipeline scripts for assorted other graphics, and I'm aware there's a fair chunk of work left to convert the end of world boss assets too. The bosses need review so that's postponed for now.
The big news though is that I actually dived into the TT code and started making some changes! Here be dragons.
How I see myself writing 68k
It's been ten years or more since I last worked with 68000 assembly language, and I was pleasantly surprised that it came back to me very quickly. I guess when you do something pretty much every day for the best part of twenty years, it kinda sticks.
The first task was to remove the use of lowlevel.library from the game. This is an AmigaOS shared library developed by Commodore that first shipped with the CD32 console and later as part of Workbench 3.1, intended to abstract away some details of using the Amiga hardware. TT was using this library for reading joystick and keyboard inputs, but its presence was causing several headaches.
Firstly, it blocked me from taking advantage of debug mode in Amiga-Assembly, as libraries can't be loaded from disk in that environment for various reasons. Next, it might actually hurt compatibility as I'm not sure the library would work on some of the Amiga configurations TT would otherwise be compatible with. Finally, it could be a problem for distribution as I would have to ship a
copy of the library with the game, and I don't think I'm allowed to do
Clearly, it had to go.
After some thought, I decided to cut keyboard controls from TT. It's a fast game, it's best with a controller, and my keyboard implementation may have been a bit crashy anyway. That was one use of lowlevel.library gone.
Reading controllers on an Amiga can be tricky depending on what you need, but lowlevel.library can take care of the tricky-ness for you. However, TT only needs the basic directional controls and one fire button, which is a very simple scheme to read directly from the hardware. No tricky, no need for the library.
So goodbye to lowlevel, and goodbye to a few sigificant problems with it.
should be a fanfare for this next one. I finally replaced all the power
up sound effects with on-screen text sprites, so it's clear what you
actually just picked up!
Updated collectable and powerup sprites
This, however, fell foul of some of 1997 me's bad coding habits.
1997 me was apparently obsessed with using the 68k movem instruction to
read and write from data structures. Sure, it saves a few cycles, but at
the cost of code and data gymnastics to use lots of registers in the
right order, making it hard to understand and change what's going on.
Undocumented magic values and bits with special meaning are scattered
across unrelated data just so the movem pattern could be used. Overlay
another apparent obsession with interleaving unrelated code so it would
run marginally faster on later 68k CPUs and you get ... a tangled web. A
mess. Much of the codebase is like this.
90's me liked to movem movem
I could probably have added the power up texts in the same style, maybe by abusing bit 14 of a collectable's x-coordinate as a flag (not joking), but 2020 me decided to more or less rewrite the collectables subsystem in a cleaner style first instead. It was easy to add the texts after that, and not noticeably slower.
Premature optimisation; put it in the bin.
If I was writing TT now, I'd probably clean this design up further and make a collectable and a collected-collectable two different entities.
I'd also be writing it in C. Either of those seemed like too much for now though.
The level timer was next on the list. I felt it was tacked on, and quite
arbitrary how it just killed the player if the time ran out. I changed
it so enemies get harder if the timer runs out - classic move - and
added different colours and/or flashing depending how low the timer is.
On boss fights, which don't have timers, it will flash DANGER now for a
bit of fun. I'm much happier with this design, and it saved a chunk of
chipram too as I was able to drop a large TIME UP sprite and sound
DANGER - WIP Graphics
I will also update the level complete sequence to give a time based bonus. I considered adding a "kills" statistic here as well, but it seemed out of place with the otherwise fun and light feel of the game.
Outside of the code, I worked on a more concrete plan of how to get to the finish line, and I'm pleased to report that it's not super intimidating.
Also, some very exciting Turbo Tomato related happenings have kicked off
in the background. I can't say much now - I hope I'll be able to very soon - but [squeee] !
With that, and with getting away from the asset pipeline grind, solidfying a plan, and seeing some actual improvements in the game, it's been positive time.