Friday, August 18, 2017

Batari Basic and Fixed Point

When I'm too tired/frustrated to work on my NES game, I've been playing around with ideas for another hobby project that I've head for awhile: a 4-player atari adapter.

I'll get to the details of the hardware of the adapter at some other time, but right now I want to talk about a thing called Batari Basic.

Batari Basic was created by a talented guy (Fred "batari" Quimby) as an easy way to make games for the Atari 2600. It's a really-slimmed-down version of BASIC with a bunch of special keywords and such specifically for Atari.   The idea is that you write simple game logic in a very limited set of basic commands, which can easily be compiled to assembly language.  Then, for the display kernel, which is where you normally really have to work to optimize things and get assembly timings perfect, you just select and use one of a handful of pre-written kernels.

The end result is super-easy-to-write games that often have a very similar look (due to using the same kernel).

Blocky playfield with blank lines between chunks.
Nice-but-generic-looking scoreboard at the bottom.
Two sprites and not much else on the screen?
Looks like a standard Batari Basic game to me

The ease of using Batari Basic to make an Atari game has led to quite a few really interesting or cool games being made, but also boatloads of bland shovelware.  I wasn't remotely interested in using it for Anguna, as it removed most of what makes Atari programming interesting to me -- a challenge of working on the metal, understanding what the system can do, and trying to push the system a little (which admittedly, I didn't do much of)

BUT, for my four player adapter project, I'm going to need a sample game or two to sell with the thing.  But I really don't feel like taking the hours to fine tune a display kernel for something like this.  I never expected this, but I've become a Batari Basic programmer.

It helps that there's now a kernel that uses an on-the-cartridge-arm-co-processor (named DPC+, modeled after David Crane's co-processor that he invented for Pitfall 2), that allows multiple sprites, and selectively flickers them if 3 are overlapping.  (Similarly to what I did with Anguna, but that took me AGES to get right. Here, it's built into the kernel).

Batari Basic's DPC+ kernel makes it REALLY EASY to make a multi-sprite game like this.
So based on that, I'm going to use Batari Basic to churn out at least one four player game to go with this adapter.  I'm starting with something that's a modified version of Joust.  But for Joust to work, you need to use fixed point math, so that you can have smooth levels of acceleration and velocity.

Batari Basic supports fixed point math.  But only sort-of.  You can add and subtract fixed point numbers (with certain limitations).  BUT you can't really do comparisons with them.  It just doesn't work right.  Simple stuff like "if foo > 0" doesn't really work right.

Which means I'm doing a lot of hacky workarounds, dropping to assembly and such, to manage my fixed point math.

That said, it's still WAY faster to make a game this way.  Just a few hours of work, and I have a mostly-working joust game.  With four players.  Although I still haven't gotten the hardware in the mail to make the actual adapter, so I ended up hacking the Stella emulator to add emulated support for my controller.  But that's a different post for a different day.


Robo-Ninja Climb 2600

So I had this crazy idea. The game logic of Robo-Ninja Climb is really simple. And so is the display. So in theory, with the NES and the A...