The initial version was a test of Rowan’s BASIC game. I attempted to speed it up with PetSpeed and RTL-Basic, but both efforts failed; the compilers either crashed or the output didn’t work.
I also found something intriguing: none of the PetSpeed versions for the PET function well in emulated environments. Each one caused a disk error when trying to write the compiled file. Upon investigation, I discovered that almost all PetSpeed compilers available on Zimmers.net still check for dongle protection at memory address $14AD.
While grappling with these challenges, I was experimenting with another project — a PET version of Berzerk. I even managed to create a maze generator that used a seed value for consistent random mazes. However, when it came to programming enemy movement and firing logic, the task felt daunting.
So, I opted for the path of least resistance and more fun: I decided to build a PET version of Qix from scratch, entirely in machine language.
I started, as I always do, by drawing a border around the screen and setting up the display. Next, I added the enemy sparks to navigate the border in opposing patterns.
Flood Fill
The next task was developing the flood-fill routine, which posed a significant challenge as I struggled to determine how to identify the area inside the polygon to fill. After a few days of confusion, I learned that most iterations of this game tested flood-filling the opposite area of the screen. I didn’t want the screen cluttered with temporary characters during this process. So, I decided to fill the outer area of the lines with a shifted space that was invisible, allowing me to flood-fill the actual spaces (character #32) afterward.
My initial flood-fill attempts worked, but I encountered issues with L-shaped lines, where the fill would stop on the right. This happened because I was exceeding 255 values for a stack. Given that each screen location required an X and a Y value, the standard stack overflowed after 128 characters.
I eventually switched to using the zero page for the stack, allowing for a 16-bit stack, which fixed the issue perfectly.
Trailblazing
The next challenge was my most difficult yet, even though it should have been simpler. I had to ensure the player could navigate through the borders without issue and draw within the inner area. To draw correctly, I needed to keep track of the last movement, as a 90-degree turn from north differed from one made from south. I utilized ChatGPT for a few hours while troubleshooting.
The trail worked well using the same character each time (though it was boring), but when I tried to use the full Petscii set, the character would appear one position late. ChatGPT understood my issue and even generated a table of values for each of the four directions. Despite my efforts, the code failed in multiple ways.
I decided to take a break overnight and return the next day. When I resumed, I erased my code and rewrote the drawing routine from scratch. It took me around six hours to finalize the line drawing. Surprisingly, the flood fill wasn’t the time-consuming aspect.
After some trial and error, I successfully got the trail working and celebrated my achievement.
The Qix
The Qix proved to be the toughest part of the game. I searched for any 8-bit versions to assist, but found nothing helpful. The C64 versions of the Taito game were far too complex to understand. I spent some time with ChatGPT (which some may consider cheating) and received some code, but it led to a lot of frustration. Ultimately, I went back to my usual approach: giving up on that assistance and writing it from scratch.
That’s when I discovered Claude AI. This AI was remarkable; it identified bugs in my code. My Qix initially consisted of a single character.
I asked it to create a trail for the Qix, and it inserted its own line drawing routine. I wanted the Qix to consist of actual lines in 80×50 mode, but struggled with moving the other end of the line, limiting the Qix’s movement like the original game. I considered various approaches but wanted to avoid a repetitive pattern.
After working through the night, I managed to get the Qix operational. I used Claude AI to mimic the arcade game’s sudden speed-ups and directional shifts, and it managed to execute my request flawlessly, producing no errors in C64Studio. However, this was a rare occurrence, as Claude AI repeatedly used relative branches beyond 127 bytes and liked to reuse labels, which C64 Studio does not tolerate.
You may feel that leveraging AI isn’t “true” programming. Nonetheless, without that help, I might not have completed the game, or at least made it as engaging. The rest of the game is all my own work.
Sadly, the game isn’t too challenging, as the sparks only travel along the border. I spent four days and countless hours trying to get the sparks to enter the playfield and navigate along the lines. ChatGPT, Claude, and Google Gemini provided useful tips, but in the end, I reached a standstill. The game might be difficult enough for younger players, but it may not be as engaging for more skilled gamers.
I’m halfway through porting it to the 80-column PET, which aligns more closely with the original game’s dynamics. The 40-column screen isn’t suited for a PETScii version. If anyone proficient in A* pathfinding is interested in helping the sparks pursue the player, I’d be happy to share the source code. Both the player and sparks are defined as X and Y values.
Includes C64 prototype, as the game was initially created on the C64 before being ported.
Until the next update…
Download
https://milasoft64.itch.io/qixie
Original article by www.commodore.ca
