Skip to main content

Crossing Page Boundaries

For awhile, everything was working perfectly in my 3-enemy display kernel on Atari Anguna. Then this weekend, I added some new graphics (for the crocky boss monster at the end of dungeon 1).

Suddenly, things stopped working right. Enemies started jumping around horizontally instead of smoothly moving. It looked choppy and horrible. And all I did was add some new graphics data.


Well, the issue was probably pretty obvious to any veteran Atari programmers.

On the Atari, when you reuse a sprite with a new horizontal position, you often get the weird black lines that appear on the left of the screen. I wrote a post about it awhile back, how if you write to the re-positioning register on exactly the 74th clock cycle the scanline, you'd prevent the line. If you did it earlier, you'd get the line. If you did it later, it might not HMOVE at all.

I've shown pictures of this before, but here's a sample of the black lines from doing the mid-frame HMOVE

Another important piece of the puzzle is the 6502's conditional branch opcodes. In general, they take 2 clock cycles if the jump wasn't taken, and 3 if they do. BUT if the jump passes a memory page boundary, it takes 4 cycles. (the 6502 divides memory into pages of 256 bytes each).

So it turns out, by adding additional graphics data, which ended up coming BEFORE my kernel code, it relocated the kernel code slightly, pushing one of my branches across a page boundary, and changing the clock cycle count of the routine by 1. Which made the HMOVE come too late, which made my re-position fail!

Well, the solution ended up being really easy, once I figured it out. Moving all the graphical data AFTER the kernel logic fixed it, and made sure that additional changes won't end up moving the kernel code.


And with that, I have most of a re-creation of the first dungeon of Anguna finished for the Atari. Since I had decided somewhere along the line that the first dungeon would be the same, but the rest would be mapped out differently, this means it's time to start doing level design again!

Fighting the Crocky boss. Like the GBA version, the Bow and Arrows make this fight easier!

Really, at this point, the majority of the game logic is done. I still want to add a title screen, game over sequence, maybe a subscreen that shows what items/keys/etc you have, maybe a password entry system (like old NES games) so you can save your progress, and if I'm not sick of the game by then, a shop where you can buy stuff.  Wow, that sounds like a lot when I list it that way....


Popular posts from this blog

Retrospex 32 Review

RetrospexInternational recently sent me a couple units of their new handheld device, the Retrospex 32, a new dedicated GameboyAdvance emulator handheld.  To make the unit playable out of the box, they pre-loaded a handful of homebrew games, including Anguna, which is why they were kind enough to send me 2 of the units to play with.  I was pretty excited to get my hands on the device and try it (I loved my old GBA micro with a good flash cart!), and see Anguna running on it. So here's my thoughts after playing with it.

Their website lists the Retrospex 32 for £59.99, which is around $100 USD. It seems like it's marketed toward people into retro-gaming (which makes sense for a dedicated GBA emulator device). At that price, with that target market, and such a limited set of functionality (why not make it a multi-machine emulator, and emulate all the old consoles?), it would hopefully do a really good job of it.

The short version of my review: it doesn't. It has one job (emula…

Making the game fun

The real trick for Spacey McRacey (as I'm calling it now) is going to be making it fun.  And that's what I'm rather unsure about at this point.

I have a game design that basically works. The technical issues are mostly sorted out, I just need to get a few more implemented before I can seriously play test it.

But fun? It's hard to know if it's actually going to be any fun to play.  With a 4-player party-style game, it's seems like it might be hard to hit that fine line where everyone is close and competing, where everything feels exciting and tense, as opposed to tedious and boring.  And despite envisioning my game as fun, it might just be boring to play.

Some of that comes down to tweaking it. Tweaking the speeds, difficulties, etc, will make a difference. (If it's too easy to shoot people from behind, then it will be nearly impossible to hold a lead for very long, which could ruin it and make it no fun. If it's too hard to kill the guy in front, it wil…

Killer Queen

So at PRGE, I played an arcade game that just left me amazed.  Killer Queen.

It's a 10-player game. You have 2 cabinets linked together, and 5 players huddled on each one. Each one is a team of 5 people, working together to play a simple one-screen 2d platformer.  But what made it work was the high quality game design.

First, the game is relatively simple, yet there is a lot going on at once.  One player plays the queen, the most important and powerful character on the team. The others start as workers, but can become warriors who can fly around and attack in a very joust-like flappy contest of height.  The real trick is that there are three completely different ways to win: either collect a bunch of berries and bring them back to your base, or ride a REALLY SLOW snail across the screen (while other people try to kill you, and you hope your team protects you), or kill the enemy queen 3 times.  There's some other things going on as well (using berries to upgrade, capturing upgr…