Framework code WIP

[JRoatch]

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.

[pops]

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?

[JRoatch]

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.

Should anything else be happening?

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

[tepples]

Should it display this icon if a stack overflow occurs?

[pops]

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.

[JRoatch]

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.

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

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.

[Bregalad]

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

[JRoatch]

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:

Is there any problem to release work in progress ROM images to the public during the course of the competition?

I don't see any issue with sharing progress while the competition is going.

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.

[rainwarrior]

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.

[NESHomebrew]

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.

[JRoatch]

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

[JRoatch]

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?

[tepples]

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.

[JRoatch]

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.

[JRoatch]

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.