Yoshifanatic's ASM Showoff: Part 13 (Day 3) - Winter 2022

Happy C3 guys!

So, these past 6 months, I wasn't able to get as much done as I did last C3 or the one before. Mostly because a few of the disassemblies took a month each and I dealt with burnout and a pet that I cared about needing to be put down. But, I still have a decent amount of things to show off, including a few surprises.

Here are links to each day's post:
Day 1
Day 2
Day 3

-----------------------------------------------------------------------

BS Zelda No Densetsu Disassembly
GitHub Link
Note: This covers Map 1 Week 2 and Map 1 Week 3. I also did Map 1 Week 1 Rerun and Map 1 Week 4 Rerun, but haven't merged them yet into the main disassembly.

You know what's Beeeeeee Esssssssss? Having a subscription service for games and not putting games like this on it *Looks towards Nintendo*.

Additional Info: Show/Hide

Regarding the technicals:
- This game makes use of the satelliview peripheral that was only released in Japan.
- This game was played alongside a radio broadcast that would not only play enhanced and remixed Zelda series music, but would sync up to the game in some ways. Due to this, you could only play the game for up to an hour at a specific time when the broadcast was happening.
- From screenshots, you may think this game is a 16-bit port of NES Zelda 1. But, it's more like a 16-bit remixed version Zelda 1, since it has new dungeons, a smaller (but similarly laid out) overworld, and various gimmicks revolving around the radio broadcast.
- This game was broadcast over the course of 4 weeks and would change with each broadcast. As the weeks went on, more things would be accessible and different events would occur.
- In theory, there are at least 16 possible releases of this game. There were 2 maps each broadcast for 4 weeks, and both maps had an original run and at least one rerun. So far, only 5 of those versions are dumped today (Map 1 Week 2, Map 1 Week 3, Map 2 Week 1, Map 1 Week 1 Rerun, and Map 1 Week 4 Rerun).
- This game had some components that were downloaded to PSRAM which are unfortunately lost. For this game, the PSRAM stuff was for non-important things (such as the end result screen, which is why this game returns to the BS-X BIOS when the timer is between :57 and :59), so the game is still playable for the most part. But other satelliview games may not have been as lucky.

As for my personal experience:
- Disassembling this game proved to be a bit of a pain, because the coding is BS. Despite playing near identically, Nintendo didn't port the NES Zelda 1 engine. The best I can describe the way it's coded is "a scripting language written by someone who doesn't understand the benefits of a scripting language". It's so incredibly wasteful and convoluted, that I don't understand why Nintendo didn't just port the NES Zelda 1 engine over and modify that?
- Map 1 Week 1 Rerun was dumped in November, technically making that the most recent game I've disassembled in a sense.
- This game plays so similarly to Zelda 1 that my knowledge of that game applied here. I generally knew what I needed to do at any given time.

-----------------------------------------------------------------------

Experimental Revamped SMW Sprite Draw Engine patch (WIP)

I can't believe it's not MaxTile!

Additional Info: Show/Hide

So, SMW has a somewhat messy way of handling the task of drawing sprite tiles, what with all its very inflexible OAM allocation (including splitting the OAM in half due to only using 8-bit indexing), its highly inconsistent handling of tiles across all the different sprite types, all the helper routines (ie. GetDrawInfo, FinishOAMWrite, the various generic graphics routines, etc.) that are sometimes inconsistently used, and various weird restrictions. While several patches exist to try to improve upon this (No More Sprite Tile Limits, Extended No Sprite Tile Limits, and the SA-1 patch's MaxTile feature), all of these simply build on top of the flawed foundation rather than attempt to fix it. That's where my patch comes in. This is an experimental patch that completely rewrites how SMW handles drawing sprite tiles across the board.

What SMW normally does is it buffers sprite tiles on the fly as the routines that draw them are processed. What my patch does is create a new global type of sprite called "Pose" sprites that are spawned in and processed at the end of a frame. These pose sprites are assigned a screen position, a pose ID to draw, a draw priority, and YXPPCCCT properties in order to determine what sprite tiles to draw and certain properties of the pose. Currently, this system supports 80 pose sprites (necessary because of the overworld switch block event) and 3 draw priorities. This system of drawing sprites has a few advantages compared to normal SMW's method of handling it:

- Any sprite can use any amount of tiles with no restrictions, since the OAM has no hardcoded slots whatsoever and the OAM buffer is indexed with 16-bit X. The image above shows exactly 128 sprite tiles being drawn at once.

- Sprite tiles are now always drawn from the start of the OAM buffer to the end, which means the RAM clear routine at $7F8000 is no longer needed (although, my code does clear every OAM index past the last used one after constructing every pose for the frame. And I initialize the OAM buffer on screen transitions).

- The draw priority of a pose sprite influences when the pose sprite will be processed. A lower draw priority means that pose will draw behind pose sprites with a higher priority, even if the lower priority sprite would be processed first otherwise. As an example, if a candle flame cluster sprite has a draw priority of 01, then it will always draw behind Mario if his draw priority is 02 or 03.

- Every sprite pose is defined in a consistent way, allowing any sprite to display any pose. Although, some sprites that animate in more complicated ways (ex. Mario, Yoshi, Chargin' Chucks, Wigglers, pokey, wall springboards, etc.) can spawn in multiple pose sprites to handle their individually animated parts.

- The data structure for poses supports flipping sprites in both directions, which enables you to have a right facing or upside down banzai bill without it looking garbled up for example:

- Normal sprites now have a new tweaker property table specifically for initializing $15F6. Although, instead of a "use second GFX page bit", they have a "use $64 for tile priority" bit.

- Various graphical glitches caused by inconsistent handling of sprite tiles are able to be fixed (ex. Magikoopa's wand wrapping around, extended sprites disappearing when going slightly off the left/upper part of the screen, one of Peach's "help" poses having a part of a poboboo tile in it, etc.).

- The sprite memory index is now unused. This means you can now spawn in more "large" sprites like banzai bills than you otherwise could. And it has no influence on how the OAM is used.

- The OAM tile size buffer no longer needs to be compressed since my global draw routine has a way to write to the upper OAM buffer directly (although it could be more efficient).

- Various sprite poses that originally drew more tiles than they needed (ex. The moving ledge hole, jumping piranha plant, compressed springboard, etc.) now draw fewer tiles, since the pose data structure defines how many tiles to draw for a given pose.

- Because I had to hack every single sprite graphics routine, this could lead to future improvements, like my draw system handling animations instead of individual poses, making most SMW sprites dynamic, or add widescreen support.

- Compared to both variations of the No Sprite Tile Limits patch, the draw priority system and ability to spawn multiple poses from one sprite would help solve sprite tile priority issues, it works on everything that draws sprite tiles, and my code doesn't waste time getting an OAM index for sprites that don't actually exist. Compared to MaxTile, this doesn't require SA-1.

The main disadvantages of this patch (besides it being unfinished) is that it's currently a fair bit slower than vanilla SMW's handling (standing by the koopas in YI2 currently takes 20 more scanlines, if you're not using FastROM or SA-1) and it completely breaks compatibility with custom sprites and several patches. I doubt it will get widely adopted due to the latter even after it's finished. Although, the work I put in may lead to future innovations and those willing to put in the work to use it would get a more flexible sprite drawing system.

For those of you that want to try this out, it doesn't work with the SA-1 patch yet and I highly recommend you have a save file with all exits acquired so you can look around and see what works with my new system. If a sprite tile shows up at all, then it's using my new drawing system, in order to give you an idea of how comprehensive the changes are currently. Although, there are still a lot of bugs and sprites that don't fully work with the new drawing system. As you may expect from a patch that changes so much, I've had to deal with a lot of bugs. Here are some of the interesting bugs I've fixed:

Bugs I encountered during development: Show/Hide

-----------------------------------------------------------------------

Click here to continue to Day 2's post

My Hacks:
Mario's Strange Quest V1.6
Yoshi's Strange Quest V1.3 / V1.3.1 Beta 4.6
Mario & Yoshi's Strange Quests (2/10/2023 Build)

Other stuff:
My SMW/SMAS/SMAS+W disassembly
Yoshifanatic's Discord Server: A place for fans of my stuff and/or Yoshi to chat with others.

That OAM system seems interesting, though being that much slower than the regular one is a pretty significant drawback. Do the poses exist in one big data table like they do in Donkey Kong Country? Does it work with sprites that draw one or more tiles above the rest of the sprite but behind the background (like the Piranha Plant and fire pillar)? And does it work with my spriteset system?

----------------

I'm working on a hack! Check it out here. Progress: 64/95 levels.

Originally posted by imamelia

That OAM system seems interesting, though being that much slower than the regular one is a pretty significant drawback. Do the poses exist in one big data table like they do in Donkey Kong Country? Does it work with sprites that draw one or more tiles above the rest of the sprite but behind the background (like the Piranha Plant and fire pillar)? And does it work with my spriteset system?

- From what I could tell, the situation I specifically tested for performance took about 30 scanlines in vanilla SMW and my patch adds an extra 20 to that. There is certainly room for improvement on my end though. Some ideas I had:
+ I ought to remove the ability to define a specific palette and priority to individual tiles in favor of spawning multiple pose sprites with the different properties. I already have to spawn multiple pose sprites to do that for some sprites anyway, so it would make sense to do it for more.

+I could sacrifice ROM space and use 16-bit X/Y disp offsets, which would help simplify the calculations for determining if a tile has gone off screen.

+ I could create alternate draw routines for specific things that would require less overhead (ex. A sprite pose that's meant to be fixed on screen, like the Bowser castle roof or the lava in the Iggy fight, doesn't need to check if its tiles are going off screen).

+I also have an idea of how I could write to the upper OAM buffer quicker (use ROL/ROR to shift the bits in a temp buffer on the fly, then write to the upper OAM buffer every 8 tiles and after drawing the last tile if sprite drawing ends before) but haven't figured out how I'll do that without issue.

- There are two pointer tables. One for every single pose, like DKC. And one that's indexed by various sprite ID RAM tables to help point to specific parts of the other one that belong to a given sprite (ie. $1602 = 00 will show a different pose for a koopa than it would for a goomba).

- Yes, it can handle sprite poses like that. You can either do that by spawning multiple pose sprites with different properties or defining the specific tiles in a defined pose to have different properties (although I'll likely remove the latter option for tile priority and palette to increase performance).

- I don't know what your spriteset system is, but probably no.

My Hacks:
Mario's Strange Quest V1.6
Yoshi's Strange Quest V1.3 / V1.3.1 Beta 4.6
Mario & Yoshi's Strange Quests (2/10/2023 Build)

Other stuff:
My SMW/SMAS/SMAS+W disassembly
Yoshifanatic's Discord Server: A place for fans of my stuff and/or Yoshi to chat with others.

It's definitively cool to see how to improve the graphics routines of sprites. A shared graphics routine like DKC and YI is one of the most practical (especially if it's separate from the sprite code which allows for an easy implementation of the ), though revamping the routine is naturally one of the biggest incompatibilities (compared to implementing a simple OAM index) as well.

That is is slow is definitively interesting. I know that NMSTL is so slow because it looks for the first used slot while a faster solution involves the use an OAM index (which can be easily implemented because of FinishOAMDraw). I guess, it's because the routine is so generic, optimising it for speed makes it difficult (particularly for flipped tiles) as well as the fact that it loops through every sprite slot of every sprite type multiple times to handle priority.

By the way, does it allow for filling OAM backwards i.e. in two directions like in Yoshi's Island? There might be some useful uses to it, after all.

Originally posted by yoshifanatic

- I don't know what your spriteset system is, but probably no.

"Sprite sets" allows for easily mixing multiple sprite types where the tile number of local sprites isn't completely hardcoded but rather dependent on which graphics are currently loaded (e.g. it could be tiles 20, 22 and 24 in one level but 00, 02 and 04 in another). It's how Yoshi's Island handles graphics, for example.

By the way, I tried out Mario & Yoshi's Strange Quest but I couldn't manage to run it in BSNES v115 (hack doesn't seem to get loaded). Do you know what's wrong or what I did wrong?

Originally posted by MarioFanGamer

It's definitively cool to see how to improve the graphics routines of sprites. A shared graphics routine like DKC and YI is one of the most practical (especially if it's separate from the sprite code which allows for an easy implementation of the ), though revamping the routine is naturally one of the biggest incompatibilities (compared to implementing a simple OAM index) as well.

That is is slow is definitively interesting. I know that NMSTL is so slow because it looks for the first used slot while a faster solution involves the use an OAM index (which can be easily implemented because of FinishOAMDraw). I guess, it's because the routine is so generic, optimising it for speed makes it difficult (particularly for flipped tiles) as well as the fact that it loops through every sprite slot of every sprite type multiple times to handle priority.

By the way, does it allow for filling OAM backwards i.e. in two directions like in Yoshi's Island? There might be some useful uses to it, after all.

Originally posted by yoshifanatic

- I don't know what your spriteset system is, but probably no.

"Sprite sets" allows for easily mixing multiple sprite types where the tile number of local sprites isn't completely hardcoded but rather dependent on which graphics are currently loaded (e.g. it could be tiles 20, 22 and 24 in one level but 00, 02 and 04 in another). It's how Yoshi's Island handles graphics, for example.

By the way, I tried out Mario & Yoshi's Strange Quest but I couldn't manage to run it in BSNES v115 (hack doesn't seem to get loaded). Do you know what's wrong or what I did wrong?

Yeah. In my opinion, for as nice as MaxTile is, I've never been satisfied with the fact that it builds on top of SMW's messy sprite drawing system rather than improve the foundation. I've disassembled a lot of games at this point, and it just highlights how inferior SMW's coding is in several ways (although SMW does do some things better. I don't think any 3rd party game I've looked at uses an object system to compress levels). That said, I'm well aware attempting to fix the bad foundation will cause lots of incompatibilities with other resources, but that's the price to pay if you set out to do something like this. XD

Funnily enough, this isn't the first time I attempted to re-write SMW's sprite drawing, as my C3 thread from Summer 2016 shows off a similar patch. That patch attempts to make every normal SMW sprite dynamic, which required me to change various graphics routines to use a generic one. However, that patch doesn't affect nearly as many things as this new patch does.

Regarding speed, yeah, the global drawing routine is generic by design. However, it doesn't work how you think. Pose sprites are a brand new sprite type that can be spawned in from anywhere in the code. The routine that processes them has no components used by any specific sprite types. Instead, pose sprites are spawned in through various routines that take the place of sprite graphics routines, and those routines have sprite type specific components. I'm not entirely sure where all the extra slowness comes from exactly, but I'll surely find ways to optimize this system. In fact, after posting this thread, I implemented the first two optimization ideas I mentioned to imamelia above and I saved at least a few scanlines in the situation I've been testing performance in.

Also, the OAM can only be written to in one direction. I don't see much reason to make it bi-directional, since it doesn't matter if the last tile uses index $0280 or $03FC (in vanilla SMW's buffer) since it's still going to draw behind every other tile anyway. My draw priority system helps ensure that sprites that need to go in front of or behind others will do so. Although, the priority system could use a bit of tweaking, since processing order still matters and 3 priorities is a bit too low.

Regarding the sprite set thing, my patch doesn't support it, but it could. The macro that defines tile numbers in the pose data structure has an unused 16-bit value that is intended as a relative offset in a dynamic sprite GFX file. I could see it being used for a spriteset.

As for MYSQ, are you using the 7/3/2021 build that I released last C3? Because it loaded up in BSNES V115 for me just fine.

My Hacks:
Mario's Strange Quest V1.6
Yoshi's Strange Quest V1.3 / V1.3.1 Beta 4.6
Mario & Yoshi's Strange Quests (2/10/2023 Build)

Other stuff:
My SMW/SMAS/SMAS+W disassembly
Yoshifanatic's Discord Server: A place for fans of my stuff and/or Yoshi to chat with others.

You never cease to amaze me with your work, yoshifanatic. Consistently, at every past C3 that I can remember, your ASM show-off threads always impressed me the most. It seems like you always pull off the crazy ideas that I might have thought about in the past, but never had the motivation to even attempt. Your sprite rendering rewrite is another one of those. Rewriting SMW's sprite rendering seems like an obvious thing that every programmer has probably thought about at some point, yet no one dared to attempt, because it seemed like way too much work. You going that extra mile will never not impress me.

Will it become the future standard of SMW sprite rendering? Probably not. There's just way too many sprites hosted on this site that would need to be rewritten. Though that doesn't make it any less impressive, and even there'll be only one or two hacks making use of this, I still think it will have been worth it.

Oh yeah, I'm also really impressed by how quickly you're pulling off these disassemblies. Seems like you've gained quite some experience with that. I mean, it looks like a new one pops up on your GitHub every couple of months or so!

Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!

(By the way, I've been working more on the sprite draw revamp patch this past day. I managed to greatly reduce the amount of scanlines it takes. It's now less than 10 scanlines slower than vanilla SMW rather than 20.

Also, I'm going to reply to RPG Hacker's post after this one.)

Day 1
Day 2
Day 3

-----------------------------------------------------------------------

Donkey Kong Country 2 Disassembly
GitHub Link

*Casually sips some apple juice*

Additional Info: Show/Hide

Regarding the technical stuff:
- This game has around 3,000 dynamic sprite poses. Dynamic sprites are stored with a header that determines how the sprite is constructed (much like the patch I showed off yesterday), although the graphics are stored alongside the header. There are a good number of unused frames and not just the "sad walk" ones mentioned on TCRF. For example, here is an unused animation of a rain cloud, which I think was meant to accompany said sad walk frames.

Another example being that exactly 1 of these shark fin sprites is used:

- Do I even need to mention how great of a soundtrack this game has? A lot of these songs almost sound like they're from a console generation ahead with how good they are quality wise.

- DKC2 has a surprisingly robust amount of copy detection related checks for an SNES game alongside a lot of traps if you were to modify different parts of the routine that does these checks. It's comparable to EarthBound in terms of the amount of effort put in, except the traps themselves are far less cruel. Although this one got a laugh out of me:

There is also this one:

- There are a lot of placeholder level/world names, mostly just "A".

- The splash screen animation of the Rare logo is a short but very interesting showcase of various graphical modes. It uses mode 3 and palette animation for the wireframe rare logo, mode 7 to shrink the logo, and mode 1 for when the Nintendo logo appears.

- There are two unused sublevels besides the beta Web Woods. One is a forest banana cache and the other is an unused warp room for Barrel Bayou.

- For some reason, all the levels of a given tileset are stored together and decompressed at once.

- There is an effect in the ship hold and castle levels that looks like a 3D polygon ledge that changes perspective on both axis as the camera moves. This is done using HDMA not just to change the X/Y position of layer 2, but also to change the tilemap location of layer 2.

- DKC2 uses scripting languages to handle animations and sprite spawning. The use of it for animations is pretty obvious, but the sprite spawning is kind of neat. Think of it kind of like the extra byte system used for SMW hacks, but taken a lot further.

- The infamous Castle Crush glitch is caused by sprite RAM index $26 being overwritten when you throw the null sprite ($26 determines what sprite you transform into). When a barrel leaves your hands, $26 can be set to 1 of 6 different values, many of which ultimately lead to a crash. I'm uncertain how this bug can brick your cartridge, but it may have to do with the copy detection checks being done before initializing the full state of the SNES. I did manage to get the game to load the copy detection screen with a bad palette by messing with the initial state of the SNES, so there is that. I have a feeling that "bricked" cartridges will work fine if you leave the SNES off for at least 10 seconds.

- DKC2's USA version has remnants of including a Dutch translation, since there is an unused Dutch option for the language select option. There is no Dutch text, though.

Regarding my personal experience:
- This game was one thing that inspired me to make that sprite draw engine revamp patch I showed off yesterday. However, the implementation of my patch is different from how this game handles it.

- Out of all the SNES DKC games, this one is my favorite. It's also the one that I happened to have the longest.

- Maybe it's just because I've played this game so much, but I don't find it all the difficult.

- Other than Yoshi's Island, getting this game to be edit friendly was a major headache. The programming is a bit confusing and it was hard to tell what was causing a glitch half the time. I did get a few funny glitches to happen, though:

I mean, Kaptain K. Rool is a bit intimidating, but come on...

Nevermind.

-----------------------------------------------------------------------

Donkey Kong Country 3 Disassembly
GitHub Link

Yoshifanatic's DKC disassembly double trouble!

Additional Info: Show/Hide

Regarding the technical stuff:
- Same notes regarding the dynamic sprites as DKC2, except DKC3 compresses some of them.

- Same notes regarding the music quality as DKC2, except I feel DKC3's original soundtrack is more mediocre overall. For whatever reason, the GBA version got an entirely new soundtrack, which I personally find better overall than the SNES's version's soundtrack.

- DKC3 is the only time I've disassembled a game where its SPC700 engine was 100% identical to another game's SPC700 engine (DKC2's). All I had to do was copy/paste and rename it and I was already done with the SPC700 disassembly.

- Same notes as DKC2 regarding the copy detection, except Rare got lazy and didn't implement any traps whatsoever.

- Same notes as DKC2 regarding the scripting languages, except the format is different.

- Same notes as DKC2 regarding the level data.

- DKC3's garbage data contains stuff from both DKC2 and DKC1 at the exact same location that data would be in the respective game. No idea how that was managed, since DKC2 had no DKC1 data in its garbage.

- Same notes as DKC2 regarding the unused Dutch language option, except the implementation was taken a lot further and there actually is some Dutch text in the ROM. Not in any of the compressed text banks, though.

- DKC3 has internal names for all the hitboxes.

- Meet Boris, the only wooden box in all of DKC3:

- There are at least 3 unused sublevels that I remember seeing. One is an early version of Bobbing Barrel Brawl, one is an empty duplicate of Doorstop Dash with Cavern Caprice as its music, and one is a snippet of Floodlit Fish meant for the photo album (not used because of palette glitches).

- The order the bonus room level IDs are stored suggests an early level order. For the most part, it's the same, but a couple levels are swapped around. The most interesting of which is that Lightning Lookout was originally the last level of World 2.

- The light shine layer 3 tilemap seen in Murky Mill is 64 bytes larger than what is loaded in game. The topmost row of tiles are what is never loaded.

- There is an invisible bug in Murky Mill with the layer 3 HDMA when a light is not on screen, but you normally can't see the glitchy scanlines because layer 3 is both transparent and its palette is blackened out.

- You can't skip transforming into Ellie in Stampede Sprint. If you somehow get past the barrel, then the camera won't scroll much further beyond it. In addition, the mice that spook Ellie have no collision if you were to somehow avoid the trigger that makes them spook her.

Regarding my personal experience:
- Unlike the other 2 DKC games, I actually prefer the GBA version of this one.

- One of my main issues with DKC3 is the audio, and not just the fact that I find a lot of the SNES version's music less memorable to the other games. The sound design in general just feels wrong to me. I think it's because this game is trying to be more cartoony than DKC2 or DKC1, but many of the sound effects used are trying to be more realistic or understated. The GBA version is a lot better in this regard.

- DKC3 is the only one of the SNES DKC games where I got the GBA version first before the SNES one. I did eventually get a cartridge of the SNES version, but that wasn't until after I became an adult.

- Like with DKC2, making this disassembly edit friendly was difficult. And like with DKC2, I had some funny glitches while doing so:

What an accurate description of what the programming became when I scrambled everything around.

Extreme snowball fight with Bleak. What makes it so extreme? Two words:

Nuclear winter

.

Koindozer? More like Koindancer.

Krosshair found the wave beam!

This one was not a bug, but was caused by deliberately changing a few bytes:

-----------------------------------------------------------------------

Click here to continue to Day 3's post

My Hacks:
Mario's Strange Quest V1.6
Yoshi's Strange Quest V1.3 / V1.3.1 Beta 4.6
Mario & Yoshi's Strange Quests (2/10/2023 Build)

Other stuff:
My SMW/SMAS/SMAS+W disassembly
Yoshifanatic's Discord Server: A place for fans of my stuff and/or Yoshi to chat with others.

Originally posted by yoshifanatic

Mario, no, what these poor boos did to you? Mario became a Poltergust and I love it.

Really interesting stuff for day one. I find weird too that they chose to do some weird code for the "remake of Zelda I" that they were broadcasting.

Also, I didn't know that DKC2 had measures against piracy. A game about pirates being anti-piracy. I find that very poetic and funny. This hook falling troll is something I would expect in a I Wanna Be The Guy kind of game.

Multiple big boos at once watch out

You are challenged by Champion Daisy!

LAYOUT FOOTER:

Being the other SNES game I was always into, I've wanted to have a go at hacking DKC3 for a while but the lack of a disassembly pretty much shut off that idea from me. Looks like it might be back on the table now though, so, thanks a lot! Great work as always.

It's definitively cool to see how you have.

Originally posted by yoshifanatic

- The splash screen animation of the Rare logo is a short but very interesting showcase of various graphical modes. It uses mode 3 and palette animation for the wireframe rare logo, mode 7 to shrink the logo, and mode 1 for when the Nintendo logo appears.

I figured out that 8bpp graphics and palette animations are used for the intro, though I didn't know mode 7 was only used for the shrinking and not for the appearance. Neither did I know that the Nintendo logo is 4bpp and not 8bpp as well.

Originally posted by yoshifanatic

- There is an effect in the ship hold and castle levels that looks like a 3D polygon ledge that changes perspective on both axis as the camera moves. This is done using HDMA not just to change the X/Y position of layer 2, but also to change the tilemap location of layer 2.

These polygonal backgrounds are one of the most impressive alongside Yoshi's Island's polygon sprites. I really should recreate the effect at some point on my own. That the tilemap changes is nothing new since I think Von Fahrenheit explained that when he explained how he did the 3D water parallax. Either way, I originally thought it was just X and Y position.

Speaking of ship: I am kind of impressed in how the water is handled. I know that layer 3 is only used for the surface while the colour of the water seems to be coming from the fixed colour. I know this has been implemented a couple times (including by me) but it is interesting how the gradient stops at some point and becomes a solid colour (compare windows below and above the water). I think Wye implemented something similar in APFAS in the winter water level but I still think, DKC2 does something different here.

Originally posted by yoshifanatic

- The infamous Castle Crush glitch is caused by sprite RAM index $26 being overwritten when you throw the null sprite ($26 determines what sprite you transform into). When a barrel leaves your hands, $26 can be set to 1 of 6 different values, many of which ultimately lead to a crash. I'm uncertain how this bug can brick your cartridge, but it may have to do with the copy detection checks being done before initializing the full state of the SNES. I did manage to get the game to load the copy detection screen with a bad palette by messing with the initial state of the SNES, so there is that. I have a feeling that "bricked" cartridges will work fine if you leave the SNES off for at least 10 seconds.

Thanks for at least a partial explanation. It's definitively interesting to see how SNES cartridges can end up being bricked and the closest cause is SRAM in which case the safe file merely gets corrupted and doesn't affect the whole game. It's still some missing information which can be solved with some more experimentation.

Originally posted by yoshifanatic

- There is an invisible bug in Murky Mill with the layer 3 HDMA when a light is not on screen, but you normally can't see the glitchy scanlines because layer 3 is both transparent and its palette is blackened out.

That reminds me a bit of Super Metroid where the lava surface has got a black and not a transparent one as expected, though not visible since Super Metroid enable colour maths for its layer 3 backgrounds.

Originally posted by yoshifanatic

- Meet Boris, the only wooden box in all of DKC3

Unique Enemy isn't limited to enemies, apparently. Also funny how some of the notable enemies and objects get a nickname (e.g. Bob from Metroid Fusion). By the way, you named the box, didn't you?

Originally posted by yoshifanatic

Is the text custom? Either way, it's such a fitting quote, considering current C3.

~~Please do Super Metroid next, please do Super Metroid next.~~

Seriously, some of its effects are noteworthy to discuss! I find the way how it handles layer 3 images, particularly the liquids, the most interesting.

Originally posted by RPG Hacker

You never cease to amaze me with your work, yoshifanatic. Consistently, at every past C3 that I can remember, your ASM show-off threads always impressed me the most. It seems like you always pull off the crazy ideas that I might have thought about in the past, but never had the motivation to even attempt. Your sprite rendering rewrite is another one of those. Rewriting SMW's sprite rendering seems like an obvious thing that every programmer has probably thought about at some point, yet no one dared to attempt, because it seemed like way too much work. You going that extra mile will never not impress me.

Will it become the future standard of SMW sprite rendering? Probably not. There's just way too many sprites hosted on this site that would need to be rewritten. Though that doesn't make it any less impressive, and even there'll be only one or two hacks making use of this, I still think it will have been worth it.

Oh yeah, I'm also really impressed by how quickly you're pulling off these disassemblies. Seems like you've gained quite some experience with that. I mean, it looks like a new one pops up on your GitHub every couple of months or so!

I'm glad to hear that! ^_^

The idea of revamping SMW's sprite drawing system has been an idea I've had ever since I was first messing around with SMW disassemblies back in 2016 when I attempted to make every SMW sprite dynamic (which required me to change how sprites were drawn, though not to the same degree as what this new patch does). However, I abandoned that after a while when my focus turned towards YSQ and later MYSQ. But, ever since Vitor Vilela implemented the MaxTile system in the SA-1 patch, I've been wanting to revisit the idea at some point (even more so after seeing how other games I've disassembled handle sprite drawing). As nice as MaxTile is, I've never been satisfied with the fact that it requires the SA-1 patch and the fact that it builds on top of SMW's messy sprite drawing rather than fix the underlying system. Obviously, trying to do that would cause all sorts of compatibility problems so I don't fault Vitor for that at all. But as someone who wants to push the base SNES as far as possible, I wanted to see if I could create an improved sprite drawing engine for SMW that doesn't require SA-1. This sprite draw patch was something I started working on on December 14th, and even then, most of the work I had done was prior to Christmas. I'm quite happy with the results, particularly after I took the time to optimize it.

As for the disassemblies, yeah. Besides just having a lot of free time, some of the scripts I've written to assist with ROM disassembly have helped a lot with being able to make these as quickly as I've been able to. Due to working on SMAS+W, EarthBound, and Super Mario Kart without these scripts, I can safely say that without them, I would have done far fewer disassemblies overall.

Originally posted by Anorakun

Mario, no, what these poor boos did to you? Mario became a Poltergust and I love it.

Really interesting stuff for day one. I find weird too that they chose to do some weird code for the "remake of Zelda I" that they were broadcasting.

Also, I didn't know that DKC2 had measures against piracy. A game about pirates being anti-piracy. I find that very poetic and funny. This hook falling troll is something I would expect in a I Wanna Be The Guy kind of game.

That particular bug is interesting, because I have absolutely no idea how I managed to break the boo ceiling in that manner. My patch does sometimes have to mess with non-graphical code in order to remove as much graphical code as possible, but I have no idea what I did to do this. And before I got a chance to investigate it, I somehow fixed it.

As for BS Zelda, yeah. It took me about 4 days to disassemble Map 1 Week 2, but it took me a month to add support for Map 1 Week 3. That was around the time I was getting burnt out (and when one of my pets sadly had to be put down), so I was not in the mood to deal with BS Zelda's badly designed engine. To give an example, nearly 1/4 of the 1 MB ROM is filled with these massive 64 KB pointer tables. Which wouldn't be so bad if not combined with there being hundreds upon hundreds of tiny routines. Trying to figure out what was new code, moved code, or shifted code between versions was an absolute nightmare to deal with.

Also, yeah, it's pretty fitting Rare did this for DKC2. There are even more traps, such as the water level changers not working if a certain check fails, but those two boss related ones are the most interesting. In addition, every one of these traps is obfuscated so it's not immediately obvious what the code does. Although, my disassembly makes these traps much more obvious.

Originally posted by OrangeBronzeDaisy

Multiple big boos at once watch out

Yep! It's possible to have multiple banzai bills and other large sprites as well. I could actually add a couple more, but then their sprites would glitch/not show up due to the 128 sprite tile limit.

Originally posted by JamesD28

Being the other SNES game I was always into, I've wanted to have a go at hacking DKC3 for a while but the lack of a disassembly pretty much shut off that idea from me. Looks like it might be back on the table now though, so, thanks a lot! Great work as always.

You're welcome! There was actually a DKC3 disassembly before I started making mine. I don't know how far along that one is, but I can say that mine is a full disassembly, I've identified most resources, and you can move things around without the game imploding.

Originally posted by MarioFanGamer

Thanks for at least a partial explanation. It's definitively interesting to see how SNES cartridges can end up being bricked and the closest cause is SRAM in which case the safe file merely gets corrupted and doesn't affect the whole game. It's still some missing information which can be solved with some more experimentation.

I have no clue how this bug could brick the cartridge, given I couldn't find anything about the SRAM that could lead to that. I feel like the idea of this "bricking" a cart came about because the person it happened to didn't think to leave their SNES off for at least 10 seconds. They probably tried to reset the game, it didn't "fix" it, and they assumed the cartridge was broken. DKC2 doesn't fully initialize the state of the SNES before doing its copy detection checks, so it's possible that resetting the console allowed certain elements of the state it was in when it crashed to persist.

Originally posted by MarioFanGamer

That reminds me a bit of Super Metroid where the lava surface has got a black and not a transparent one as expected, though not visible since Super Metroid enable colour maths for its layer 3 backgrounds.

This is what the glitch looks like if you're curious:

I noticed this in my scrambled DKC3 ROM, but I can confirm it happens in the vanilla game.

Originally posted by MarioFanGamer

Unique Enemy isn't limited to enemies, apparently. Also funny how some of the notable enemies and objects get a nickname (e.g. Bob from Metroid Fusion). By the way, you named the box, didn't you?

Yeah, I named it. I wanted to give it a more old fashion sounding name for no particular reason. XD

But, yeah, considering how common these boxes are in DKC2, I was surprised there is only 1 in DKC3. I think what happened was there was a point where the normal barrels didn't break upon hitting one enemy like in previous games. Then Rare nerfed them to give the steel kegs more of a purpose, and then they decided to remove the now redundant wooden boxes but forgot about this one.

Originally posted by MarioFanGamer

Is the text custom? Either way, it's such a fitting quote, considering current C3.

Nope. That's an actual thing Cranky can say in DKC3. The only thing I edited was the win condition of the minigame. Normally, Cranky is being a sore loser when he says this line, but here, I think he has a point. XD

Originally posted by MarioFanGamer

~~Please do Super Metroid next, please do Super Metroid next.~~

Seriously, some of its effects are noteworthy to discuss! I find the way how it handles layer 3 images, particularly the liquids, the most interesting.

I could barely hear what you said, but since you're interested in my disassemblies, I will say that I do plan on doing more. There are quite a few games I want to take a look at at some point, like Super Metroid for example. Look forward to it!

My Hacks:
Mario's Strange Quest V1.6
Yoshi's Strange Quest V1.3 / V1.3.1 Beta 4.6
Mario & Yoshi's Strange Quests (2/10/2023 Build)

Other stuff:
My SMW/SMAS/SMAS+W disassembly
Yoshifanatic's Discord Server: A place for fans of my stuff and/or Yoshi to chat with others.

Day 1
Day 2
Day 3

-----------------------------------------------------------------------

Donkey Kong Country Disassembly
GitHub Link

DK! Donkey Kong! DK! Donkey Kong is (actually) here!

Additional Info: Show/Hide

Regarding the technical stuff:
- Same notes that I wrote for DKC2 regarding the graphics and sound quality. I prefer DKC2's soundtrack more, but DKC1 still has a memorable soundtrack.

- Unlike DKC2 or DKC3, this game's copy detection is very minimal and is just the standard SRAM check.

- Same notes regarding the music quality as DKC2.

- DKC1's engine has less in common with DKC2 than DKC2 has with DKC3.

- Same notes as DKC2 regarding the splash screen animation.

- This game makes heavy usage of RAM buffered palettes that are modified to give sprites a different tint based on the level's lighting (or invert the colors when using subtraction mode with color math). The other DKC games also do this, but this one does it the most often.

- The USA version has a language select screen, even though there is no option for it on the menu.

- This game's garbage data is set up in a way where Rare didn't overwrite the full ROM with each compile and earlier builds' data is layered on top of one another in the space that the final game's code/data didn't reach at the end of banks. Some things, like the Puftup sprites (an enemy that appeared in DKC2) are only in the ROM simply because they managed to avoid getting overwritten.

- Same notes as DKC2/DKC3 regarding the scripting languages, except the format is different once again.

- DKC1's header has a small gag, where the unused vectors contain ASCII text spelling "DIDDY" and "DONKEYKONG" (as well as an unused garbage header that says "JUNIOR" instead of "DIDDY"). DKC2/DKC3 sort of keep this gag, but not quite. DKC2's head has "DIDDY" and "DIDDY KONG", while DKC3's has "DIXIE" and a blank space.

- Same notes as DKC2/DKC3 regarding the level data, except they're uncompressed in this game.

- There are 3 unused songs in the ROM, specifically an early version of Bad Boss Boogie, the title screen music, and Credits Concerto. All 3 have bad instrument pointers so they sound messed up to varying degrees:

- I found evidence to suggest that the oil drums were originally meant to be picked up. Their sprite ID is grouped in the middle of every other throwable object and there are unused animations for picking up and throwing one (which use the steel keg sprites, aside from the idle animation). Perhaps the steel keg was implemented when they decided to make the oil drums a hazard instead?

- There are around 30 unused sounds in the game. Besides the ones mentioned on TCRF, one sounds like a TNT fuse followed by an explosion and a few are the Rambi stomp sounds of progressively higher pitch followed by a duplicate of the 1up sound. That latter one is interesting, because you do get a 1up if you bounce on enough enemies without touching the ground, but there is no sound progression like in SMW.

- I found code remnants at $BFB7D1 that would display 3 unused animations when the Kongs are pushing against a wall (you can activate them by NOPing out the RTS 1 byte before). This is where the unused pushing frames would have displayed, but it seems the idea was abandoned before those pushing frames were fully implemented since DK won't actually show them. Diddy Kong's version of this is even less finished, as his copy of these animations just show DK's frames.

- That bug where you can enter the corners in the path between some levels in World 1 are simply a result of those corners being assigned dummy level IDs that correspond to bonus rooms in Orang-utan Gang/Ropey Rampage. These IDs have special handling on the overworld to make you auto-move off them, but the devs failed to add a check to prevent entering them, thinking the auto-movement would be enough.

- Mini neckies aren't the only thing with a questionable hitbox:

- Every level warp, using camera boundary edits to show the barrels when necessary. The Vulture Culture one only shows up if you speed run the level as DK.

- Behold one of DKC1's most obscure secrets! Jump off of Rambi at the peak of your jump at the end of the 1st level and you'll land on this off screen tire. Bounce off of it to gain 6 lives.

Regarding my personal experience:
- I had this game growing up, but it ended up being one of the few SNES games I lost my copy of. I have no clue how either, although I did eventually replace it.

- This originally was going to be the first DKC game I disassembled, but my previous laptop broke its hinge and I couldn't work on this disassembly for a while. I decided to work on DKC2 on my older laptop instead and by the time I got a new laptop to replace the broken one, my DKC2 disassembly had progressed further than the DKC1 disassembly.

- Unlike the other 2 DKC games, this one was a lot less annoying to get edit friendly. There also weren't that many funny glitches I encountered other than one where a Necky was attempting No Nut November:

-----------------------------------------------------------------------

Donkey Kong Country Style Text System

Additional Info: Show/Hide

This is some UberASM code that gives you a DKC1 style text system I made for anonimzwx for his hack, where the text fades in and out using color math and HDMA.

Insert it using UberASM on game mode 14. Adding your own text is self explanatory, as the example messages will show certain elements of this message system. To call a message, store the 16-bit message ID to !RAM_SMW_Level_CurrentLevelMessageLo, then write #$01 to !RAM_SMW_Level_CurrentTextProcess. You can have as many messages as you want per sublevel.

It's very basic in terms of features, but it does have a couple extra features compared to DKC, such as a command code that lets you JSL to a routine.

-----------------------------------------------------------------------

Enemy Rollcall Sprite Editor patch

Additional Info: Show/Hide

This is a small patch I made for someone on Discord that moves the enemy rollcall sprite and text data to the expanded part of the ROM. This makes it easier to edit it without worrying about trying to fit that data in the original location.
As this is mostly copy/pasted from my SMW disassembly, you also have the ability to display the Japanese enemy names if you prefer.

-----------------------------------------------------------------------

And that's about it. As always, I hope you guys liked what I had to show!

My Hacks:
Mario's Strange Quest V1.6
Yoshi's Strange Quest V1.3 / V1.3.1 Beta 4.6
Mario & Yoshi's Strange Quests (2/10/2023 Build)

Other stuff:
My SMW/SMAS/SMAS+W disassembly
Yoshifanatic's Discord Server: A place for fans of my stuff and/or Yoshi to chat with others.

Thanks for these interesting facts about the DKCs! These games are still my favorites from all time.

Originally posted by yoshifanatic

Creepy

Originally posted by yoshifanatic

- Meet Boris, the only wooden box in all of DKC3:

Always found this interesting, certainly a fun fact.

Originally posted by yoshifanatic

- You can't skip transforming into Ellie in Stampede Sprint. If you somehow get past the barrel, then the camera won't scroll much further beyond it.

My 13 years old was really curious about if it was possible or not, to the point I actually managed to do it in my real SNES back then (it's really easy to, you just need to do a stairs with Squitter's webs before passing through the sign that removes him), but got disapointed when the camera stopped. Though, I wonder if Rare managed to do it themselves in order to do this preventive mechanism, or if they just did without testing just in case.

On a side note, I've always wished these games were so easily editable the way SMW is, but even if the proper tools were made editing them will be always more difficult because these games are just built different. Fortunately there's still mad people that have actually done complete hacks so at least we can try these.

Layout made by MaxodeX
2021 TRENO vibe check thread

Man, DKC3 doesn't get enough love. I thought its soundtrack (and graphics) were just as good as 1 and 2, and it did some kind of interesting new things. I also prefer the SNES version of the soundtrack to the GBA version (especially for Frosty Frolics and Treetop Tumble). I'll agree that Kiddy was kind of a waste of space, though.

How hard would it be to remove all the copy protection, anyway?

I thought the Nintendo logo used mode 5, not 1.

I didn't realize that DKC3 only had one crate. Actually, I'm not sure if I realized that it had any of them; they're definitely a DKC2 thing. I also didn't realize that wooden barrels in DKC3 don't roll while they do in the other games, though. Weird.

From what I'm seeing of the scripting language stuff, it reminds me of the VWF dialogues patch. I've wondered for a while if I could implement something like that in SMW, maybe for complex sprites like bosses. I did use it for something at one point, but now I forgot what.

The DKC text system and enemy roll call patch seem like they could be useful, though they could use some documentation.

----------------

I'm working on a hack! Check it out here. Progress: 64/95 levels.

I've quite enjoyed reading about all the DKC related stuff and all the little tidbits of trivia you've showcased. I never knew about that secret at the end of Jungle Hijinks.
It's always interesting seeing what the original designers did to overcome certain tasks and what quick fixes they made to save time.

The DKC styled text in SMW looks really slick as well.

Nice Work YoshiFanatic. I always find your C3 threads rather interesting to go through and read about various documentation you have had to offer.

Yoshifanatic, i think you deserve a little more credit than you get.
especially since disassembly can take quite a bit of time to work through, it's great that you finished this in a quality state.

I'm Japanese, so if I'm not speaking well, sorry!

I'm always really eager to read through these, and it's great to have someone elucidate on some interesting snippets of game code. Is there any rhyme or reason behind what you choose to disassemble beyond "I liked it as a kid, so there?" Or are there some games you attempt to gum through and just don't really find anything worth talking about?

Other Submissions of mine!

What has been your favorite game to disassemble so far?

----------------

I'm working on a hack! Check it out here. Progress: 64/95 levels.

Originally posted by Ayami

Thanks for these interesting facts about the DKCs! These games are still my favorites from all time.

You're welcome!

Originally posted by Ayami

My 13 years old was really curious about if it was possible or not, to the point I actually managed to do it in my real SNES back then (it's really easy to, you just need to do a stairs with Squitter's webs before passing through the sign that removes him), but got disapointed when the camera stopped. Though, I wonder if Rare managed to do it themselves in order to do this preventive mechanism, or if they just did without testing just in case.

I had no idea it was possible to avoid entering the barrel. I just modified my X position with the BSNES Plus memory editor to avoid the barrel.

Originally posted by Ayami

On a side note, I've always wished these games were so easily editable the way SMW is, but even if the proper tools were made editing them will be always more difficult because these games are just built different. Fortunately there's still mad people that have actually done complete hacks so at least we can try these.

Yeah, the DKC games are quite complicated in some ways, especially DKC2 and DKC3 which both add extra complexity to the overall engine, which makes it harder to make a full fledged hack of them. The engine of these games does have some interesting capabilities if you can handle the complexity, like the fact that the sprites are designed to be customizable (think of it like custom SMW sprites with a lot of extra bytes) and that animation/hitbox data is separate from sprite programming.

Originally posted by imamelia

How hard would it be to remove all the copy protection, anyway?

In my disassemblies, it's as easy as changing a define in the ROM Map file. That one define will remove all the copy detection code at startup and all the traps that would otherwise trigger when removing the former. It does not remove the region check though.

Originally posted by imamelia

From what I'm seeing of the scripting language stuff, it reminds me of the VWF dialogues patch. I've wondered for a while if I could implement something like that in SMW, maybe for complex sprites like bosses. I did use it for something at one point, but now I forgot what.

Yeah, it's basically like the VWF dialogues patch but for a non-text purpose. Also, some of the bosses in these games use a scripting language for their AI, but unlike the main scripting languages, I didn't look too deeply into them.

Originally posted by imamelia

The DKC text system and enemy roll call patch seem like they could be useful, though they could use some documentation.

I'm not sure what more documentation these two patches need, unless I forgot something.

Originally posted by imamelia

What has been your favorite game to disassemble so far?

It's hard to say since each one has had its ups and downs, but I guess Jurassic Park was my overall favorite.

Originally posted by 1UPdudes

I've quite enjoyed reading about all the DKC related stuff and all the little tidbits of trivia you've showcased. I never knew about that secret at the end of Jungle Hijinks.

I never knew about this secret either. The only reason I know about some of these secrets is because I was looking at these maps while working on the DKC disassemblies.

Originally posted by 1UPdudes

Nice Work YoshiFanatic. I always find your C3 threads rather interesting to go through and read about various documentation you have had to offer.

I'm glad to hear that! ^_^

Originally posted by Francium

Yoshifanatic, i think you deserve a little more credit than you get.
especially since disassembly can take quite a bit of time to work through, it's great that you finished this in a quality state.

That's something I have noticed to some degree, since I oftentimes can't even tell how much of an impact some of the things I do are having. Although, whenever I do see someone expanding upon my work for something I attempted a while ago or someone making use of one of my bigger projects for their own, it means a lot to me.

Originally posted by Deeke

Is there any rhyme or reason behind what you choose to disassemble beyond "I liked it as a kid, so there?" Or are there some games you attempt to gum through and just don't really find anything worth talking about?

Most of the disassemblies I've done are games that I owned as a kid and thought would be interesting to disassemble. Of the 26 disassembles I've done so far, exactly 6 are games that I never had as a kid (Plok, SimCity, BS Zelda, EarthBound, Mega Man 7, and DKC3) with the former 3 being games I've nevered owned at some point. For the most part, the games I choose to disassemble are ones that have some interesting things going for them. It could be that the game does some cool technical trick that I want to learn more about, a game I consider underrated, the game is one of the best or worst of the SNES, the game is quirky in some way, or other reasons.

My Hacks:
Mario's Strange Quest V1.6
Yoshi's Strange Quest V1.3 / V1.3.1 Beta 4.6
Mario & Yoshi's Strange Quests (2/10/2023 Build)

Other stuff:
My SMW/SMAS/SMAS+W disassembly
Yoshifanatic's Discord Server: A place for fans of my stuff and/or Yoshi to chat with others.