The initial version was a test adaptation of Rowan’s BASIC game. I tried to enhance its performance by compiling it with PetSpeed and RTL-Basic, but both methods failed, either crashing or yielding non-functional output.
Along the way, I uncovered an interesting issue: none of the PetSpeed versions for the PET seemed to work correctly in an emulated environment. Each version I tried caused a disk error during the compilation process. A deeper dive revealed that nearly all the PetSpeed compilers hosted on Zimmers.net still check for dongle protection at memory address $14AD.
While navigating these challenges, I was also working on another project: developing a PET version of Berzerk. I even created a maze generator that used a seed value to ensure the mazes would be consistent upon revisitation. However, when I began tackling enemy movement and firing mechanics, the project quickly became daunting.
At that point, I opted for the path of least resistance—and the most enjoyment: I decided to build a PET version of Qix from the ground up, entirely using machine language.
As with all my projects, I started by drawing a border around the screen and setting up the display. I then programmed the enemy sparks to navigate the border in alternating patterns.
Flood Fill
The next challenge was to create a flood-fill routine. It proved to be quite tricky, especially figuring out how to identify the inside of the polygon to fill. After several days of confusion, I discovered that many versions of this game tested flood filling in the opposite area of the screen. I didn’t want temporary characters appearing while the algorithm determined the Qix-occupied zones. Instead, I decided to fill the outer area with a shifted space that would be invisible, allowing me to flood fill the area containing actual spaces (character #32).
My initial flood-fill attempts worked, but I found that creating L-shaped lines caused the fill to stop prematurely. The problem stemmed from using over 255 values for a stack, which would overflow after 128 characters, given that each screen location required both an X and a Y value.
Eventually, I revised the stack fill to use zero page memory, which enabled a 16-bit stack, resulting in perfect functionality.
Trailblazing
The next challenge was perhaps the most daunting, although it should have been the simplest task in the game’s coding. I needed to let the player move through the borders seamlessly, and when entering the inner area, begin drawing. Tracking the last movement was essential; a 90-degree turn from the north would differ from the same turn from the south. I spent hours working with ChatGPT to address these issues.
The trail functioned fine if using a single character (which got boring), but when I attempted to use the full Petscii set, it would place the character one position too late. ChatGPT understood my dilemma and helped me create a value table for each of the four directions, but my code persistently failed.
Ultimately, I decided to take a break and return the following day. I wiped my previous code and started the drawing routine anew. Surprisingly, it took only about six hours to finalize the line drawing. You’d think the flood-fill would have taken longer, but it didn’t.
After some trial and error, I finally got the trail working and literally jumped for joy at conquering this challenging task.
The Qix
The Qix proved to be the toughest part of the game. I searched for any 8-bit versions that might assist me but found none. The C64 versions of the Taito game were too complex to decipher. I spent time with ChatGPT, which provided some code, but utilizing AI can sometimes be frustrating. In the end, as is often the case with my work with AI, I abandoned it and rewrote it from scratch myself.
During this process, I discovered Claude AI, which was incredibly helpful. It identified bugs in my code. Initially, my Qix consisted of just a single character.
I requested it to generate a trail for the Qix, which it did by implementing its own line drawing routine. I wanted the Qix to consist of actual lines in 80×50 mode, but I was unclear on how to manipulate the other end of the line to replicate the original game’s dynamics. While a sinus maker could have sufficed, it would have resulted in a repetitive pattern.
Over the course of one night, I managed to get the Qix functioning. I utilized Claude AI to simulate arcade-style behavior, including sudden speed-ups and area navigation. Remarkably, it nailed the implementation on the first try, with no errors in C64Studio. However, this was a rare occurrence, as Claude AI often used excessive relative branches and redefined labels, which C64 Studio does not tolerate.
You might think that relying on AI undermines the essence of programming, but without this assistance, I likely wouldn’t have been able to finish the game or make it challenging. The rest of the game represents my own work.
Unfortunately, the gameplay isn’t very difficult, as the sparks only navigate the border. I dedicated about four days and numerous hours trying to get them to enter the playfield and follow the lines. ChatGPT, Claude, and Google Gemini provided tips, but ultimately, I conceded defeat. While the game may be engaging for a younger audience, it might not be challenging enough for experienced players.
Currently, I am halfway through adapting it to the 80-column PET display, which will align more with the original game’s feel. The 40-column screen isn’t ideal for a PETScii rendition. If anyone knows A* pathfinding well enough to enable the sparks to pursue the player, I’d be willing to share the source code, as both player and sparks are defined by X and Y coordinates.
The C64 prototype is included, as the game was first created on the C64 before being ported over.
Until the next release…
Download
https://milasoft64.itch.io/qixie
Original article by www.commodore.ca
