Monday, September 5, 2016

Backgrounds and debugging

One of the hard things. Ok, so far the ONLY hard thing about NES development is how the background tile maps work.  In theory, they're pretty simple -- a big array of memory where you write a tile number, and the PPU (the video chip) draws that tile at that position.

But there's so many little gotchas:


  • The nes addresses 4 different screens' worth of data, but by default only has ram for 2 of them. So unless you provide more RAM on the cartridge, you set up (via actual wiring on the cartridge!) mirroring where data is duplicated between screens. 
  • The screen nicely pans and wraps between screens'-worth of background data. Except that there's only 240 tiles high, so you have to do math instead of letting bytes just wrap around
  • Setting color palettes for tiles is painful -- you do it in a separate block of memory, mapped in a funky way where you map 4 tiles to 2 bits of a particular byte.  Which means you have to do odd math to work out how to change colors of backgrounds.
  • Mid-screen scroll changes are weird.  To do a header bar, many games will switch scroll positions after the header (since there aren't layered backgrounds). But switching scrolling mid-frame requires more weird math, because you can't just write to the scroll registers like normal -- you have to do weird gymnastics with the various PPU registers instead.
It's not horrible, but it's driving me a little crazy. Really, I just wish I had better debugging tools. I got really used to Stella (the Atari emulator)'s quirky debugger, and realized how awesome it was. The nintendo debuggers I've used just aren't nearly as usable, at least with my current level of experience with them.

This is a debugging diagram of the four screens of data. I'm mirroring vertically, so the top and bottom are cloned.
The left half is my game background. The right half is the header bar.
Each frame, I start by telling the NES to set the scroll to where the header bar is.
Once it's drawn, I reset the scrolling to point to the correct position on the left half.


I finally broke down today and wrote routines for my game that let me do some primitive on-screen debug messages, displaying decimal versions of values using the player score headers. That will help, I hope.

Tuesday, August 23, 2016

Atari vs NES

It's really interesting to me the differences and similarities between Atari and NES programming. They both use the same 6502 processor (well, a variation on the same processor -- the Atari's is missing a few address lines, and the NES is missing a BCD mode), clocked at similar speeds (the nes is about 50% faster).

But beyond that, things start to diverge.  The most interesting to me is fundamentally where things happen, based on how their video chips work.

On the Atari, the video chip (the TIA) is designed to handle a scanline at a time. Which means that, like I've mentioned before, the whole time your TV is drawing, you spend that time babysitting the process, using all your processing time updating each scanline.  Then during vblank (the time the TV is repositioning the electron beam), you get to hurry and do your game logic updates.

On the NES, it's practically the opposite. The video chip (the PPU) is designed to handle a whole frame at a time (GASP!).  So during rendering, unless you're doing any fancy effects, you get all that time free to do your game logic updates, while the PPU does its thing in the background. Then during vblank, you hurry to push new data to the PPU so its ready for the next frame.

There's still hurrying involved in the NES -- there can be a lot of data that you want to shove into the PPU (new tiles for scrolling, etc), and not a lot of time to do it (most video data has to passed to the PPU over a janky serial interface, written one byte at a time), but compared to the Atari, I feel like I have EONS of time to work with.

It also helps having more RAM than I know what to do with. The Atari had 128 bytes. The NES has 2048 bytes. (Two whole kilobytes!)  It's crazy town.

There's still some challenges. Talking to the PPU is weird, you're limited to only 8 sprites per scanline, mid-screen scrolling (ie if you want to add a status bar) is tricky.  But so far, it's a different world.

Sunday, August 7, 2016

NES Game and LiveCoding

Well, I started messing around with making a NES game. I'm not sure I'm ready to tackle another big project right now, and there's still bits of work to be done with Atari Anguna (mostly fixing bugs as they get reported, then getting it ready for production), so I'm doing a little project:  sort of a simple 4-player space race game.

Tonight's tasks was writing the code to support the 4-player adapter, and scrolling the starfield.


The fun part is that I thought I'd try LiveCoding it, which is basically where you live stream yourself writing code and explaining it as you do.  I've tried this for the past 3 nights.  It's a really weird experience.

First, I don't know why anybody would want to watch someone code. I mean, at least watching someone stream video games is interesting because there's a lot of action. Coding is mostly thinking and typing.

Second, it's REALLY HARD.  Now I'm trying to do all my thinking out loud. Which is a really weird process.  Everything feels blurry and sluggish in my head. I feel like I'm not coding well, and not explaining well.  Maybe it gets easier, I don't know.  Then on top of that, trying to actually be somewhat entertaining while coding and talking?  Yeah right.

Third, I'm used to writing my hobby game code in the late evenings, as a way to sort of wind down. Only this doesn't wind me down, it winds me up. I've been finishing a bit after 11, and I'm all jittery and high-strung. There's just no way I can go to bed after spending an hour performing for strangers on the internet.  And I can't really do it sitting next to my wife on the couch as she watches TV, which is normally where the coding happens.

So I don't know how long this will last. On the one hand, it's tons of fun, because I have an audience. On the other, it's exhausting.  But hey, I might as well have fun with it for now.



Friday, July 29, 2016

Finished world map

Well, I'm still making a few tweaks (the most recent was based on feedback that the off-centered sword was annoying, so I made the sword centered by default, but let you use the difficulty switches to change it back to the old off-centered setting), but thought I'd share the final finished world map:


Sunday, July 24, 2016

Beta Testing Time!

Ok, Anguna 2600 is ready for some testing!  I'm looking for testers to try playing the game (either in an emulator, or on an actual Atari with a Harmony cart or similar device), and let me know what bugs and issues you find!

The main features aren't likely to change at this point, but I'm looking to fix any bugs and possibly tweak the game difficulty.

You can download the instruction manual and current build from this post on AtariAge.  Please email me (nathantolbert at gmail) or leave comments if you find any bugs or issues.  If you find any problems that I fix, I'll also credit you in the instruction manual if you'd like, if so, let me know how I should credit you.


Next steps:

  • My friend Tim Lapetino, author of the upcoming Art of Atari book, is designing art for the cartridge label (hopefully to be re-used on the manual as well).
  • I'll be updating the game and manual to fix any issues found during the beta test
  • Hopefully later this fall, if all goes well, everything will be finished, and I'll do a cartridge release through the AtariAge store.



Tuesday, July 19, 2016

First full playthrough finished!

When I get near the end of a video game release, I have this phase. Where I play through the game, fix all the bugs I found, play through it again, fix all the bugs I found, play through it again....and so on....until I finally play through and don't find any new bugs.  (I've done this before)

It's somewhat miserable. But here we go again.

I finished the first full-playthrough tonight. Fixed a ton of bugs. Tomorrow I need to do another full playthrough, and then attempt a full playthrough on the actual Atari (which I'm not sure if I'll pull off, because my Atari controller is in poor enough shape that it will be really painful to go through the whole game!)

For anyone that wants to try the always-newest build and help me test, you can grab it from my jenkins server, which I'll be happy to email you the address to.....


Sunday, July 10, 2016

Tons O Bugs

Well, my friend Daniel (AmishHack3r on Twitch) decided to give my game a try. And let me tell you folks, this guy is an amazing tester.

He found ALL SORTS of bugs for me. And diligently recorded video of each one, made drawings on a map of areas with glitches, and so on.  I couldn't ask for a better tester, thanks Daniel!

That being said, I have a lot to fix!

Thursday, June 9, 2016

Getting close to done

I've been quiet here, because at any given point, playing Overwatch has sounded more fun than blogging about my game.

That being said, I've finished a preliminary "first draft" of the game, and on my first quarter of a playthrough, I've discovered quite a handful of little bugs. Mostly minor things (a couple screens where enemies glitch out, the reset switch not working exactly right, etc), but a few might take a little bit of work.

After this playthrough and testing round, then I get to play through it AGAIN, fixing any bugs along the way. When that's done, it's time for a sort of beta test, and hand it out to anyone willing to test it.  Once I get the bugs fixed that others discover, it's time to call it good!

Monday, May 23, 2016

Updated Map (Spoiler alert)

I've been chugging along filling out content, and getting really close to being finished!

Tonight I added a bunch more rooms, then realized that I really need a few more room layouts for variety. With some playing around, I was able to create 3 new room layouts using the existing graphic chunks, only rearranged slightly. So each of these layouts only requires 4 bytes of rom space each, instead of the 75 that I'd normally need!  I haven't added them in yet, I'll need to go back and replace some other rooms.

Until then, here's the current map! Just a few white spaces left to fill in!


Monday, May 16, 2016

Overworld finished!

As the title says, I finished the overworld tonight. 45 out of 196 rooms left to go (dungeons 4 and 5).

I don't have an updated map to show yet (I updated the engine by 1 scanline, so my new screenshots don't exactly match the old, I need to update my script that crops and adjusts them before I can get the new rooms on the graphical map).

I'm at the point now though, where every bug that gets fixed requires searching through old code to find places I can optimize a few bytes away. Fun times.