Framework code WIP

Edit: Changed thread title for updated code in a new post in this thread. What follows in this post is the framework code I had last year.

Hello,
I have been working on a metroidvania style game for the 2014 compo for the past 3 weeks. So today I decided to attach what I have so far. It's going to use the A53 mapper solely for the mirroring switch. I intend to restrict it to 32k for the possibility that all mapper register selecting be done in the multicart menu.

Little things I'm happy about accomplishing:

• TV system detection in the second "bit $2002" wait.
• A PPU uploading system in vblank that works with five 32-byte buffers.
• A simple callback from nmi, so that I can also have a background process for level unpacking.
• Modified famitone2 to support Dendy.
• An interesting system function I coded yesterday. (try holding 'A')

Things that I hoped to have done by this time:

• progressive metatile loading to nametables via the PPU uploading thing I made
• pattern shift rotation for fake parallax.
• main character jumping from a flat ground.

I'm aiming to get this done in time for the compo, but it's doubtful, seeing as I may not have the graphic and music skills needed, and 1 out of 3 months have already passed. I thought about going for a simpler idea, but that may not be best, as I have a clear general design for this game already. Category 3 or next compo are options for going over the time budget.

Thanks to the editors of nesdev wiki, and everyone involved in unregistered's thread (it was quite a read). I'll continue to post updates to this thread, and I'll rename the topic when this game is finally named.

The stack overflow display is a neat idea. I have one byte at $01BF that I check once a frame for a stack overflow (Stack shouldn't go deeper than $01C0), but I hadn't thought of displaying the stack on error. You could expand this, I assume, for a debug view - the ability to display any page of memory at any time.

I can see a line and can make it scroll to the right. Should anything else be happening?

Maybe as a septate debugger, because the stack overflow routine is currently starving for memory (it only uses $00ff which is reserved for "sta $ff" breakpoints). It also happens to fit in the last page.



Nope, the text for tv system detection is all there is, maybe in a few days I'll get scrolling backgrounds or something.

Should it display this icon if a stack overflow occurs?

I laughed out loud. And promptly added it to my game.

That said, if he's limiting the game to 32k, he might not have 64 bytes to spare for the icon.

Still haven't got scrolling figured out completely. Maybe I'm giving myself to much requirements for it. Anyway here's what was done this time:

• A silly loss-full font compression that saves 30% compared to black and white
• A bit more complex of a process manager, that can have multiple cancelable stacked processes.
• At least defined some sort of meta-tile scheme.
• Just for this demo a tile parallax effect. (still needs to be worked on)

The demo simply scrolls down, pressing down scrolls faster.


I'll drop the whole routine first if I really need the extra 64 bytes. In any case I added a bomb icon, reminiscent of old Macintosh crashes, in my font. I think that the stackoverflow icon represents the website more then it does the concept.

If this is for the contest : Aren't you supposed to keep everything private until April 1st (except for category 3 maybe) ?

I didn't think there was a problem. I didn't see a rule forbidding it and then there was this:



I'm also too used to another compo's guideline of "keeping an informative and interesting account of their development". and just like in that compo I'll most likely go over time anyway, forcing this to be submitted as category 3.

Unless entries are to be submitted anonymously for impartial judging, I can't think of any reason to keep them private before the competition, except that it's fun to surprise people.

There is no rule about posting. People do it in irc, I don't see why a forum would be any different. Some people don't have others to test their work.

I'm shelving this for a month as I'm going for a simpler game in the contest.

Attached is the current source code for those who are interested. system.s is the most interesting file I think.
The scene is unchanged from last post but there are a few changes source wise.

• The ppu uploader can now write individual tiles/bytes
• the process manager is now a simpler task list, (but each task is still theoretically cancelable by a higher task).
• A 50 byte subroutine to fill chr-ram with bad apple/game genie like tiles

Ok I was split between posting in this thread or in controller test.
I decided this thread because the majority of the source was working towards the eventual metroidvania project.

Major accomplishments:

• Async event loop with optional vblank timers! (hilariously only used for vsync now).
• Nametable Compression
• 32-bit RNG

Things todo soon:

• Documentation. It's so lacking now it hurts.
• A APU system that can hopefully mix together different music and sfx streams.
• reimplement progressive CHR loading under the new event loop
• Modify PPU uploading system to read from PPU as well, so that CHR RAM can be used for general ram storage
• More use of the data stack. Especially for 16-bit physics computation.
• Figure out how to represent Nerdtracker2 steams more compactly.
• Interbank calls

Questions:
For reading the new controller state, does it make sense take The bitwise Majority of the previous state and two new reads?
My module convention it a mess. How should it be improved? lazy65?

I considered bitwise majority of previous, new read #1, and new read #2, but that can cause spurious Up+Down presses.

Hold Up + Left, then within a frame move to Down + Left.

Previous: Up + Left
Read #1: Down + Left
Read #2: Bit deletion prior to Up makes it appear as Up + Down
Result: Majority for Up, majority for Down, majority for Left

So instead, I just go with new read #1 if new read #1 == new read #2 else previous.

I'm actually OK with the result of that case. because if the next frame is also Down+Left, the net effect is that only the Up button transition was delayed for a frame.

The problem I'm concerned about is that a single bit accidentally toggles for 2 consecutive frames, resulting in a random pause glitch or some phantom right button presses. The disadvantage of this bitwise majority over "if read1 == read2 then state = read" is, as you pointed out, the button transitions are not synchronized and can cause issues for naive game logic failing to account for Up+Down, etc. Also I'm hoping there won't be a noticeable pattern of transition lags, like somehow the Right button will feel less reliable then the A button.

If I wanted to also deal with the problem of failing to catch a single frame press and release, I should probably just do a majority of three reads.

I do not have a comprehensive code set now, but I wanted to say a bit about the new goal I've been aiming for so far. For now I'll name this project "NES Toy Box", and I hope someday I can get the code to a state were I can start soliciting contributions.

It started with the todo list of coredump v1.2 and grew into an idea that I mentioned at the beginning of this year, a collection tech demos and toys with fun and interesting menu navigation. controller test was kind of the first toy I imagined for this. Then GTROM was announced I've been targeting that ever since. In the past weeks, the desire to do this project has been growing stronger, especially now since Tepples is working on the 240p test suite and KHAN Games released The Incident.

A few conventions I've came up with for this:

• Extensive use of a Forth like data stack (use of the Zeropage,X and Indirect,X opcodes) for parameter input/output.
• FamicomBox inspired header (16 bytes title, 2 bytes checksum, 8 bytes reset stub, 6 bytes vectors)
• NMI and IRQ located at $07f8 and $07fc respectively. Chosen to be power of two aligned, and to be compatible with blargg's romless format as long as the locations are prefixed with NOP and JMP opcodes.

The header checksum is verified by summing every 2 byte word in the 32KiB bank and checking if the sum is zero. The 8 byte reset stub is like the classical 10 byte reset stub but without setting the stack pointer.

Wanted to post this before the year end. So I pushed to get something presentable fast today.

Along with everything explained in the previous post. Here's the additions:

• Upgraded the nametable compression format to now handle tile graphics much better. (more on this later)
• Rom checksum program that may theoretically be triggered the same way as the "Codemasters smiley test"
• This...
• Again fixed some bugs in coredump and bumped it's version number to 1.4
• Controller Test now works like I intended it to. Feedback on it's musical playability would be appreciated.

There's so much to clean up and work on before I can start any physics related thing, and unfortunately "Controller Test" is a smelly pile of copy paste code. I'm glad that 16-bit number computations are nicely handled with a data stack, but I wish I could find a way to represent state machines with something better then trees of branches.

Edit: Found a bug in Controller Test where you can not play a a-flat, but I'm not going to be fixing it today. Also found a colorful crashing bug when interacting with the menu of thefox's PowerMappers.

Your bug or mine?

A little of both. I knew for awhile PowerMappers had difficulties saving and restoring APU state. I have a strange setup where the main logic happens in response to the APU frame IRQ. I'm thinking the IRQ handler is possibility looping infinitely and that there's no locking variable for it either, in which case that would be my fault. From that, the stack overflows to the attribute table buffer, NMI colors the screen, and the main threads no longer can be returned to.