Streemerz NES port

[thefox]

I've made quite a bit of progress:

- Fine-tuned the player physics so they're pretty close to the Flash original now.
- HUD face palettes are now uploaded and restored properly.
- Worked on some sound effects.
- Added frame skipping when the game runs on NTSC (internally it always runs at 50 Hz like the original). The frame skipping doesn't look as bad as one might expect.
- System (NTSC/PAL/Dendy) is detected on bootup and everything is automatically adjusted.
- Thunder.
- Wipe in/out level transitions.
- Fixed all visual glitches from screen transitions (palette uploads outside vblank, disabling rendering midscreen, that kind of stuff).

It's starting to resemble a real game now. I may do a little video of it later.

[jayminer]

I love following your progress!

A video would be awesome!

[thefox]

I went vacationing in my hometown for a couple of weeks, so there's been little progress during that time. On 16th and 17th I fixed several small things and started working on the player death related stuff. It's time to get back in the flow.

3½ more weeks until school starts again. At this point it seems unlikely that I'll be able to complete project by that time, but I'll try my best.

[thefox]

Some progress:
- First revision of "music2". Unfortunately I don't have the MIDI/whatever for this so figuring out those snare patterns sucks.
- More sound effects: landing, death, thunder (some of them need more work still).
- Generic module for uploading data from CPU memory to PPU memory when rendering is enabled.
- Sprite tiles, nametable and attribute data are restored when HUD closes.

[thefox]

I've made 19 commits after the last post, so a lot of progress has been made:

- Checkpoints.
- Rewrote the collision checking routines (these were very old and kind of messy, some of the stuff like bounding box inclusion/exclusion wasn't well defined, now it's nice and clean).
- Keeps track of collected money.
- Sound effects: money, checkpoint.
- Fixed a bug in MUSE where channel volume didn't get properly applied on the triangle channel.
- Placeholder title screen state.
- Placeholder music: title screen, boss.
- Death collisions against all objects.
- Breakable blocks work perfectly now (they are restored when player dies etc.)
- A ton of other small miscellaneous changes/fixes.

In the original game Master Y's balls (as well as the grappling hook) use a rounded collision mask, next I'm probably going to look into how I could implement that in an efficient enough way. First I wasn't sure whether it's really worth it to implement it at all, but I've found that there are a couple of places in the levels where the collision mask does make a significant difference in difficulty (i.e. my version is harder right now). It looks like I can get a pretty close approximation by using 3 rectangles.

The biggest thing left on the TODO list (unless I've completely forgotten about something) is the boss fight (if you can call it that). I need to find an efficient way to store the route that Master Y takes together with all the other required state info (animation frame, streemer state). Fortunately that level is only about 1 minute long so it shouldn't be a problem. Hardest part will probably be actually constructing the data in the first place. If I had the source of the original, I could make it dump the state info for the entire run in a file, but no such luck.

[tepples]

Circle to circle collision detection is easy, or at least it was when I implemented it in Thwaite (missiles to explosions) and ZapPing (ball to paddle ends). First do the rectangle test, then look up (x2-x1)^2 and (y2-y1)^2 in a lookup table. You have a collision if (x2-x1)^2 + (y2-y1)^2 > (r1+r2)^2.

Circle to square, or in fact the more general case of two axis-aligned rounded rectangles, is quick too. Do you want me to draw a diagram explaining it?

[thefox]

Circle to circle collision detection is easy, or at least it was when I implemented it in Thwaite (missiles to explosions) and ZapPing (ball to paddle ends). First do the rectangle test, then look up (x2-x1)^2 and (y2-y1)^2 in a lookup table. You have a collision if (x2-x1)^2 + (y2-y1)^2 > (r1+r2)^2.

Circle to square, or in fact the more general case of two axis-aligned rounded rectangles, is quick too. Do you want me to draw a diagram explaining it?

Thanks for the offer, but no need, I think I have it figured out.

[thefox]

More good progress. First of all, I implemented the circular collision mask for background tiles. I yet have to do that for obj-obj collisions, but that's not super important anyways. Then I started working on the boss level by exporting the invisible AI objects and using them to trigger stuff like moving left/right and shooting the streemer (the original games does this too). Unfortunately, my physics were off just enough to cause it to not work. So I rewrote the physics completely based on bytecode disassembly of the original game, so now they should be 100% faithful to the original (plus or minus some bugs I may have added ). After some time I also got the boss run level to work from beginning to end.

Of course I can't actually use the AI triggers in the final game because of problems that have already been discussed earlier in this thread (e.g. not having access to collision data for the full level at all times [technically it could be done, but it's just not worth the trouble]). So the next step is to log the boss state for each frame of the boss level, and then look for some way of compressing the data.

[thefox]

So the next step is to log the boss state for each frame of the boss level, and then look for some way of compressing the data.

And done (ended up using delta encoding + RLE, works well enough). I also started working on the 6502 code to play back said data. Bulk of that works as well, I just need to modify my player CHR uploader to be able to handle more than one upload simultaneously (one for the player, one for the boss, probably switching priority every frame).

[thefox]

And done (ended up using delta encoding + RLE, works well enough). I also started working on the 6502 code to play back said data. Bulk of that works as well, I just need to modify my player CHR uploader to be able to handle more than one upload simultaneously (one for the player, one for the boss, probably switching priority every frame).

The boss run thingy now works for the most part, phew! Running out of things to do... well, not really.

[tepples]

You asked in this post about tile compression. I used a pixel-level RLE codec for the Midwest Gaming Classic multicart that was similar to the codec tokumaru implemented. But after being disappointed in the decompression speed for a slightly more demanding application, I came up with something I called PB8 because it works on 8-byte blocks. I used it for an experimental update to my old Who's Cuter demo, and a couple months later, I refined it into the PB53 codec that I'm using for the menu in Action 53 and for the user interface graphics in my NES graphics editor.

• Works on 8-byte blocks
• Can decompress to a RAM buffer while rendering is turned on
• Byte-level RLE for speed
• Efficient even for tiles with only 2 colors, such as font glyphs
• Can decompress multiple streams in parallel and repeat the corresponding tile from the previous stream, useful for NROMs that share a lot of tiles between banks such as Lawn Mower, LAN Master, and Slappin'
• Maximum 12.5% expansion

[thefox]

You asked in this post about tile compression. I used a pixel-level RLE codec for the Midwest Gaming Classic multicart that was similar to the codec tokumaru implemented. But after being disappointed in the decompression speed for a slightly more demanding application, I came up with something I called PB8 because it works on 8-byte blocks. I used it for an experimental update to my old Who's Cuter demo, and a couple months later, I refined it into the PB53 codec that I'm using for the menu in Action 53 and for the user interface graphics in my NES graphics editor.

• Works on 8-byte blocks
• Can decompress to a RAM buffer while rendering is turned on
• Byte-level RLE for speed
• Efficient even for tiles with only 2 colors, such as font glyphs
• Can decompress multiple streams in parallel and repeat the corresponding tile from the previous stream, useful for NROMs that share a lot of tiles between banks such as Lawn Mower, LAN Master, and Slappin'
• Maximum 12.5% expansion

I took a look at it, seems pretty good! I'll definitely consider using it.

[thefox]

So, I didn't quite get it finished by the end of my summer vacation but I got much closer than I would've thought possible a couple of weeks ago. School started this Monday so it's going to slow things down a bit but I hope to get this finished in the next couple of months. If it has not been finished in 2012 somebody can come and kick me.

- Placeholder "win" state (when the end has been reached).
- STREEEEEMERZ mode (the gravity flipping thing) works 100%. All the other game modes are in place too (just needs specific stuff like the timers for the time trial levels).
- Added the rest of the HUD faces, though they need polishing still (went over the 8 sprites/scanline limit in some cases).
- Added RLE decompression routines (based on/copied from Shiru's unrle routine, so I can use NES Screen Tool).
- Added apLib decompression routines (based on/copied from mic's source, with a couple of small optimizations).
- Screens are compressed (got about 30% ratio out of apLib, I'm pretty happy with that). My goal is to fit the game in 128 KB.
- Menu selections can be made in the main menu.

All the big stuff has been done now, I think, but I still have plenty of small tasks left (60 or so items on my TODO list). By the way, if anybody is looking for a good Windows software for maintaining TODO lists, I recommend ToDoList.

[tepples]

Is this UNROM, BNROM, or some more complex mapper?

[thefox]

Is this UNROM, BNROM, or some more complex mapper?

MMC1 right now, but I'm going to convert it to UNROM later.