A few days ago, I started working on a new game called Nemezyro. As usual, I’ve packed in some “non-standard” features—mostly tech and tricks I’ve never actually messed with before.

So, what’s the deal with Nemezyro?

It’s a relaxing logic/reflex game where randomly generated sequences of three-colored tiles scroll from right to left. Your job is to clear them out for as long as possible before any tile hits the left edge of the screen. You eliminate tiles by clicking on them with the joystick-controlled cursor, which also wipes out all adjacent tiles of the same color.

The specific twist here is that the “adjacency” rule also loops between the top and bottom rows. Because of that, it can feel a bit trippy at first—sometimes it looks like tiles are just vanishing on their own! 🙂

Let’s dive into how it’s actually made and where things got a bit sticky…

I started grinding on this game on August 20th. Unusually for me, the first thing I had to do was come up with a project name. I had all sorts of ideas, but I eventually found a handy name generator online. After scrolling through hundreds of generated nonsense words, my eyes landed on Nemezyro.

Once the name was settled, I jumped into the code. I hammered out the scrolling engine first, then fired up Graph2Font to layout the colors and the DLI. I exported that and hooked the generated DLI routine right into the game. At that stage, there were actually four different colored tiles, but I ended up ditching the orange one while fixing a glitch. In the end, I just decided to leave it out for good.

After pause that lasted 3 days I told myself that it is time to proceed with this project so I started adding player interactions quite furiously.

I was honestly a bit worried about the timing—having a normal-width playfield with four color changes per scanline plus scrolling is a lot to ask—but to my surprise, everything ran buttery smooth without a single glitch.

After taking a day off, I got stuck into the game logic and that special “adjacency” feature. I started working on the delete_adjacent routine and spent some time browsing the web for a clever floodfill algorithm. Eventually, I realized I’d just have to rely on myself, so I wrote my own simple buffered floodfill (no recursion/stack). It had a few hiccups at first with the wrap-around between the top and bottom edges, but for the most part, it worked like a charm:

In the meantime, I reached out to Poison. I’m a huge fan of his tracks, so I asked if I could use some of his work for this project. He got back to me surprisingly fast—he’d actually just finished a new tune intended for Fandal’s Multijoy4 game, but Fandal turned it down because it was stereo. Of course, the track was top-notch, so I jumped at the chance to use it. Poison uses SDCMC (Stereo Double Chaos Music Composer) by Datri. It’s a modded version of the classic CMC that handles 8-channel stereo and a “mysterious” double mode. I’ll get back to this “gem” in a bit.

Lately, almost every Atari game uses RMT (Raster Music Tracker) because it has pretty solid SFX support. I’m not sure if CMC has anything like that—I have a vague memory that it might, but documentation is impossible to find—so I decided to try something a bit more innovative.

What’s left to be innovative on the Atari? Well, every now and then something special pops up, and this time I was playing with the idea of using the keyboard beeper for SFX. That sound isn’t handled by the Pokey (audio) chip; it’s actually the GTIA, which usually deals with PMGs, multi-color modes, and the console buttons (Start, Select, etc.).

Not long ago, XXL created a GTIA sample player that plays modules as if they were samples. It works using a frequency-modulated signal (since you can’t change the amplitude). The whole trick to making noise through the GTIA is just rapidly toggling two values into CONSOL ($D01F)—the “magic” is all in the frequency of those writes.

After a few tests, I realized I wasn’t going to get anything fancy out of a VBI (Vertical Blank Interrupt) routine, so I just settled for a basic VBI buzzer. To get decent sound, you need to write to the register way faster than 1/50th of a second. I even checked in with XXL to see if I was on the right track, but I quickly realized I couldn’t pull off any real sorcery for this specific project. I just left the buzzer as-is.

The turning point came on August 30th as the deadline started breathing down my neck. I was pumping out content, but I only managed a single SVN commit the whole day. Once I dropped Poison’s music into the game, I knew the GTIA buzzer had to go. You couldn’t hear it at all over the music, so I scrapped SFX entirely.

The day before that, though, I was messing with another cool tool: RastaConverter. It’s a genius piece of software that displays an insane number of colors in a static image. It uses a “hill climbing” algorithm to iterate through PMG and bitmap color changes to get as close as possible to a full-color original. Ilmenit (man, you’re a legend!) wrote it, and while there was a big buzz about it on AtariAge a couple of years back, I don’t recall anyone actually using a Rasta-image in a real game. I’d only seen one simple scroller demo using it. Challenge accepted—I wanted a Rasta-image title screen! I spent some time brainstorming the look and finally went with a colorful grid with the title centered.

I went through several versions and spent a ton of time tuning the title—fiddling with the size and font face—until I finally found a combo that the converter could handle well. I basically killed a whole day on it, tweaking colors and dithering algorithms. This final logo was generated over 160 million iterations and took about 4 hours on my quad-core Elitebook, but man, the result is awesome.

The generated code for the image was absolutely massive (over 20kB). When I hooked it into the game along with the music, I got a nasty surprise: the SDCMC player in “double mode” couldn’t fit into the VBI, so it started interfering with the logo rendering. The result was a glitchy mess, especially when the drums kicked in, and the music would even slow down in spots.

In the meantime, Poison sent over a slower version of the track for the game’s “Slow Mode.” I had to call him back into action to strip out the drums and tune it for “normal” (non-double) mode. I was hoping that version wouldn’t mess with the timing so the logo and music would stay nice and stable.

Now, it might sound like smooth sailing from here, but the reality was a total nightmare. I went through some serious “bleeding” thanks to the SDCMC player. I had to hash it out with Fandal—huge thanks to him, because I probably wouldn’t have gotten it working otherwise. He’s trashed SDCMC on his blog twice before, and now I’ve officially felt that pain firsthand. The player handles stereo in normal mode, but you have to set a specific flag to enable “double mode.” This double mode uses a modified replay routine that eats way more CPU time, though you get much better drums in return. It’s a bit like running an RMT player twice per frame, except this only runs once.

The funny (or frustrating) part is that in double mode, one channel plays total gibberish, and part of the routine tries to read data from random memory addresses ($FF00). Fandal warned me about this, and I patched what I could based on his advice, but I couldn’t fix that weird memory-page reading. Eventually, I fixed it by trial and error—I just changed one byte in the music file to a different value. Before that fix, the song refused to loop and would just go silent at the end. Another “fun” thing about SDCMC is its Disk Manager: “load” only works on the second try, and “save” only works in Atari800WinPlus (and I think SIO patch has to be off). Trying it in Altirra is a lost cause—it won’t write to disk at all. That really “amused” me, since I use Altirra exclusively and spent about 25 failed attempts trying to save a module before Fandal told me it was a no-go.

August 31st arrived—deadline day. Status: title screen works, but the music causes glitches (check the frame-blended screenshot below to see the bug). The game logic was still in its infancy; you could click tiles, but nothing was actually disappearing or animating yet.

Poison delivered the new drumless, non-double version of the slow track, and it didn’t cause any flickering on the title screen—success! But I was still battling a bug I haven’t mentioned yet. Basically, the whole thing would randomly lose sync, the screen would flicker, and then everything would just go black. The weirdest part? The game acted like everything was fine. Usually, you’d expect a crash or an illegal instruction, but here, everything kept running… just without a display.

I’d never seen anything like it. In total despair, I sent the binary to Fandal to see how it looked on his end. He told me it looked fine—not perfectly synced, but okay. I thought he was messing with me. Fandal is a hardcore old-school coder (he doesn’t touch macros like MVA/MWA or .PROC/.LOCAL) and still uses the ancient Atari800WinPlus 4.1 for debugging. I’ve been on Altirra for three years, but to my shock, the binary was perfectly stable in the older emulator. I’d been chasing a ghost based on the wrong symptoms the whole time. Just great… “absolutely brilliant.”

I finally managed to fix the issue—turns out HSCROL was the culprit. I’d tried to write the whole program without using those “dumb” screen-sync loops (like LDA:CMP:REQ 20), which meant I was accidentally changing the HSCROL value at some “forbidden” time. It was enough to make Altirra completely lose its mind.

Anyway, great—the picture wasn’t a total mess anymore, but it still would’ve given an epileptic a run for their money. There was this hideous flicker every 8th frame, right when the fine scroll switched over to a coarse scroll and the entire video RAM needed to shift. That might have been manageable, but instead of just shifting the RAM, I was basically redrawing the whole scene tile-by-tile, which is impossible to pull off in a single frame.

I jumped into coding a double-buffer system, and surprisingly, I had it running smooth and stable in less than an hour. It just swapped between two video RAM locations while keeping the Display List in sync. I was pumped—finally, some real progress! I could actually focus on the game itself instead of constantly chasing down glitches and flickering.

The only catch? It was already 8:00 PM, leaving me with exactly four hours until the deadline.

I hammered out the fonts, added a simple (but I think pretty sharp) in-game logo, and threw in some lines to give the screen a bit of “class.” At that point, I didn’t even know what to tackle next; there was so much left to do that I started losing hope I’d even have a playable version ready by midnight.

 

Suddenly, my phone beeps—it’s PG telling me he submitted his game to ABBUC just one minute before the deadline. I’m thinking, “Wait, what?” He must be confused; the deadline is always at midnight. I check the rules online and can’t believe my eyes: the deadline was actually 10:00 PM!

I took a second to figure out my next move, then decided to just go for it. I grabbed the build as it was, attached it to an email for Sascha Kriegel (skr), who runs the software compo, and sent over a quick description. I explained that I’d had no idea the deadline had been moved up compared to previous years.

I was pretty rattled for a bit, but then I figured, “Whatever, I’ll just finish it anyway and at least have it ready for an early release.” Around 11:00 PM, I started on the relocations. Developing for an emulator is great, but real hardware has a major hurdle: loading data under the ROM. In an emulator, it’s instant, but on a real Atari, you have to load data into RAM first, kill the ROM, and then move the data into that address space. Since the ROM holds the disk-loading routines, if you turn it off and try to load something, the system crashes instantly. This isn’t my first rodeo—I’ve dealt with this in every project since my Summertime demo—but the problem here was that crazy Rasta-image. It eats over 22kB, and squeezing that under the OS or BASIC ROM is no small feat. I thought an hour would be enough for the relocations… “Man, was I wrong.”

I eventually gave up on the standard approach. It just wasn’t working, and it’s incredibly frustrating to take a perfectly functional game and break it so badly it won’t even boot after an hour of tuning. Plan B was to use a runtime packer for the relocations. I usually use TeBe’s SuperPacker, but even after ten attempts, I couldn’t get the game to depack and run. “Okay, it’s late and my nerves are shot.” I reverted the source code back an hour using my SVN repo and walked away from the relocations.

I kept developing, and by 1:00 AM, I had a simple score counter working. I started on the difficulty levels and game modes. Around 1:30 AM, after fixing a bug that made the tiles occasionally “move backward,” I finally called it a night.

The next morning, September 1st, I found an email from Sascha Kriegel. I read it and could hardly believe it: Nemezyro was officially registered for the contest! He just needed a description and a playable version by the deadline, which I’d technically provided. Plus, the actual deadline had been pushed back! It wasn’t entirely clear at first—I even debated it with MaPa—but it turned out the deadline moved by three days, with bugfixes allowed until Sunday (Sept 7th).

With the wind back in my sails, I got back to finishing the game for the ABBUC contest. I “bled” over those relocations from morning until 3:00 PM when I finally got it booting on a real Atari. I’d been trying to relocate the actual RastaConverter code (stupid move), but then it clicked: leave the code where it is and move the video data under the ROM instead. You never stop learning—it’s just a shame you have to relearn the same stuff when you forget it from the last project!

Finally, I designed the Options screen to include the three game modes. I gave it some polish and topped it off with an infinite loop that writes random values to the background color. It looks like a decompression visualization. I hesitated for a moment on whether to keep it, but in the end, I figured, “Why not? Let’s leave it in.”

I spent some time smoothing out the game loop and the state machine—basically defining the flow from the title screen to options, then into the game, and back to the title after a “Game Over.” That evening, I finally fixed the cursor logic. Before that, the math for mapping the PMG cursor to the actual tiles was way off, and my remote testers were definitely letting me hear about it!

Just before midnight, the options screen was finished, complete with high scores and your last score. I tweaked the parameters for each game mode and added a “reload time”—basically a cooldown so you can’t just spam tile eliminations. The cursor turns orange and only lets you clear more tiles once it fades back to white. Naturally, this meant even more difficulty balancing, but I finally called it a night just before 12:00.

The next day was all about balancing the difficulty and making sure it scaled properly as time went on. This required a ton of playtesting, but there’s really no shortcut for that. I also spotted one last major graphical glitch: during the Game Over animation, when a tile hit the left edge, all the tiles would suddenly jump one full space to the left. A similar thing happened at the start of a new game where tiles would “magically” skip back a few pixels. Once again, it was all down to incorrect HSCROL values. I fixed the initialization logic and finally put those glitches to rest.

By the evening of September 3rd, I was doing some final difficulty tuning. I actually had to add a stopwatch to the game just so I could see what I was doing while balancing the levels. At 10:40 PM, I built the final Nemezyro binary and sent it off to ABBUC.

It was quite the challenge once again. There are always new surprises on this thorny road, but that’s exactly why I love it…

Download “Nemezyro” nemezyro.xex – Downloaded 2175 times –