Language…
19 users online:  Atari2.0, DanMario24YT, Dennsen86, deported, derv82, drkrdnk, eltiolavara9, h.carrell, Isikoro, krizeth, masl, MorrieTheMagpie, Serena, Shomi, sinseiga, sparksplit-smw, StarWolf3000, steelsburg, trihex - Guests: 291 - Bots: 312
Users: 64,795 (2,375 active)
Latest user: mathew

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

Super Mario WorldNon-Super Mario WorldPatchToolWork in ProgressResource ReleaseScreenshots

  • Pages:
  • 1
  • 2
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*.




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

Experimental Revamped SMW Sprite Draw Engine patch (WIP)


I can't believe it's not MaxTile!



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

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*



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

Donkey Kong Country 3 Disassembly
GitHub Link


Yoshifanatic's DKC disassembly double trouble!



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

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!


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

Donkey Kong Country Style Text System





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

Enemy Rollcall Sprite Editor patch



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

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. #smrpg{mlem}#smrpg{cool}
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.#thp{=D}
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. #smrpg{mlem}#smrpg{cool}


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.#thp{=D}


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.
  • Pages:
  • 1
  • 2

Super Mario WorldNon-Super Mario WorldPatchToolWork in ProgressResource ReleaseScreenshots