Metatile Designer

For the NES game, I'm building my levels out of 32x32 pixel metatiles.  What is a metatile?  The NES background tiles are 8x8 pixels, but that's too small for a lot of purposes.  Loads of games were built out of bigger blocks (16x16 is very common, which is what Mario or Zelda used, making the standard "block" size you see in many NES games).

The smaller your blocks, or metatiles, the more ROM space a level takes up, but the more flexibility you have in laying out your levels.  For this game, I'm planning to use 32x32 blocks.  (which I've built the whole engine around, so if that changes for some reason, I'm in for a lot of work)

Here's a picture of Super Mario Bros.  By this time your eyes are glazing over
and you don't even remember why I was talking about Super Mario Bros anyway.
Warning: the next paragraph is even worse.

The reason I chose 32x32 is because of how the NES handles palettes. In memory, there's a byte for each 8x8 pixel space on the screen, to indicate which tile should be drawn there. But each tile can have one of 4 palettes, and that byte doesn't include any palette information. There's another block of video memory where you assign palettes to tiles.  BUT, there's a few limitations.  You can only assign one palette for every 16x16 pixel block (group of 4 tiles), which is one reason it's so common to have blocks that size in games.  AND 4 of those groups (a 32x32 pixel block) shares a byte in memory (2 bits for each 16x16 block).  So in my case, each 32x32 metatile can map to a byte of palette memory, which simplifies writing palettes. 

So between the ROM savings for large levels (64 bytes to represent a single screen) and the ease of writing palettes (also called attribute tables), I picked 32x32 metatiles.

Now the problem is that I need a better tool for designing my metatiles.  There are a few tools out there (NES Screen tool by Shiru, Sumez's editor, etc).  But for one reason or another, none of them quite did want I wanted.  So it was time to start tool building, which is a sometimes-miserable, sometimes-nice distraction in the middle of a project.

In the past I've tried a few different technologies for quick-and-dirty gui tools.  It used to be Borland Delphi.  Then C#.  Then the web with either raw javascript, or Angular.  This time I wanted something cross-platform but I hate the web, so I decided to try javafx, which I've heard is decent.

I considered forcing myself to use Kotlin or Clojure for the sake of learning another language, but once again, the pragmatism of getting something done quickly set in, so I cranked it out in java.  Java 8's lambdas makes gui programming a little less unpleasant, so it didn't take long to have my metatile designer working but ugly.

Now it's time to actually try to put together some decent-looking metatiles and start building a cool demo level.

Quad-Games and PRGE

Well, I have 3 games (of hopefully 4) of my "Quad-Games" collection done: Quad-Joust, Quad-Tank, and Bomb-Defense.  Thanks to some friends that came over for an evening of testing (thanks guys!) we found a bunch of bugs and potential new features.

I've spent the past couple weeks hammering out bugs, and re-testing repeatedly, mostly with my family.  Now PRGE is almost here, so I'll have to call it done for now.  I'm pretty excited to have it out to demo, and see what people think when they play it.

Bomb Defense is the preferred game for my wife and daughter, who prefer co-op play.

A few other updates:

• Some bugs have been reported in Atari Anguna, so I've been working feverishly to fix and test them before PRGE, so new carts sold there can include the bug fix
• I've also had a request for a PAL-compatible version of Anguna, so I've been working on a PAL-60 version that will play in whatever places used PAL TVs.
• I've finally gotten back to work on the NES game.  The scrolling engine seems to finally be working, so I was pretty quickly able to add a main character that can jump around and collide semi-properly with the environment.  More on that soon!