Tuesday, June 6, 2017

Blaster MetroidVania

Well, I've been working on the next game, but not saying much.  Mostly because the majority of my free time involves working on fixing things in my new house, or getting ready for the arrival of a new baby in a couple weeks.  So when I do manage to squeeze in some development, I don't have time to say much about it.

That said, I've found someone to collaborate with on the next game, so things are moving forward!  We're doing a metroidvania-style Blaster Master-inspired adventure.

First things first, while Frankengraphics is working on some preliminary art, I'm trying to get a scrolling engine working.  Which on the NES, is a beast.  The nametables (the chunk of video memory that tells the graphics chip which background tiles to draw where) work somewhat similarly to how they worked on the GBA, but with a few things that make the whole thing more complicated, the primary ones being a slow processor, and a slow and unwieldy method for accessing video memory.

The biggest hassle is doing the math to keep track of what address corresponds to what location on the screen, once the screen starts scrolling around.  I won't go into detail now (I'm too tired -- see this post from Spacey McRacey which talks about some of it), but it's math that's simple until you have to do it quickly on a primitive 6502.

All that to say, getting a multidirectional scrolling engine working isn't quick work.

Tonight, I got fed up with trying to debug my function that renders a new column of tiles when scrolling left or right, and decided it was time to add some on-screen debugging.  Usually with any project, there's a point where I get fed up enough to write some decent on-screen debugging features, and that time is now.  The trick is, because I'm trying to debug background tile rendering, I need to make my debugging tools use sprites instead.  So while normally a text system on the nes is rendered using background tiles (because the nes can only render 8 sprites per scanline), I'm going to display it using sprites for now.  Which means no matter how badly I goof up the background layout, I should be (in theory) able to see debug information on the screen as sprites.

I haven't gotten very far with the debugging system yet.  Mainly because I don't have any sprite code at all yet, so I need to start from zero.  That was tonight's goal: get some basic functions set up for rendering general sprites.  Then next time I can add some debug functions that dump data to the screen.

Ok, bedtime.  I realize this post has been pretty rambly and incoherent.  I guess that means I'm tired.

No comments:

Optimization and C

Starting this next game in C, I've known there will be places where C isn't fast enough, and I'd have to drop to assembly to ...