NES versions - bugs, unused content, beta stuff, revisional differences

I just came across this thread on a polish forums: https://forum.pegasus-gry.com/index.php/topic,2479.msg30636.html#msg30636 (well, I have seen it years ago as evidenced by my posts there, but completely forgot about it)

Two people there state that there's a bug in the game, where after collecting all 100 stars some of them might re-appear (particularly in the cave under the cemetery). Collecting them causes the star count to underflow, so that the game thinks you have 255 stars to collect - the game glitches out trying to display that number, showing only "5" (not "05"). Obviously, that makes the game unwinnable (Zaks' magical stargate door gets re-locked). Has anyone experienced such issue? I haven't played the Blue version that much myself.

There were two other interesting glitches mentioned in that thread, which I assume apply to the Blue revision as well:
- apparently, after a long playtime some of the actions you've done are reverted - wooden plank goes missing, the bridge near the mine repairs itself, the treasure chest on the beach loses collision, etc. (could that be related to the extra stars phenomenon perhaps?)
- someone stated that when trying to catch Pogie near Dizzy's hut, the game might actually activate the extra life puzzle that's present in the Yolkfolk Village. I haven't been able to reproduce that, so (assuming it's true) there might be other factors involved, or it was a random (possibly emulation) error, or...?

[quote data-userid="2495" data-postid="55856"]

Two people there state that there’s a bug in the game, where after collecting all 100 stars some of them might re-appear (particularly in the cave under the cemetery). Collecting them causes the star count to underflow, so that the game thinks you have 255 stars to collect – the game glitches out trying to display that number, showing only “5” (not “05”). Obviously, that makes the game unwinnable (Zaks’ magical stargate door gets re-locked). Has anyone experienced such issue? I haven’t played the Blue version that much myself.

[/quote]

I haven't caught it happening in my game, but I have seen more than one playthrough on YouTube where either the last star or the next-to-last star reappeared after being collected, though the players didn't go back to collect them because they either didn't notice or didn't want to risk breaking their games. And I don't think all of them were the first version, either! So maybe the "Stargate is open" message was always bugged to skip flipping the bit that remembers that a star was collected when an area is reloaded.

And that reminds me of a topic here where someone warned against collecting your last star in the graveyard cave because the final star sets a new respawn point for Dizzy (unless it's in a minigame), and they didn't know how to use the trampette to escape in the Blue version without taking a death to respawn with it at the entrance. It occurs to me that the bottom of the sea cave costs you a life to respawn at the top if you don't bring flippers to swim back out, but if you were to collect your final star down there without the flippers, then you really could be stuck there no matter how many lives you lose!
apparently, after a long playtime some of the actions you've done are reverted - wooden plank goes missing, the bridge near the mine repairs itself, the treasure chest on the beach loses collision, etc. (could that be related to the extra stars phenomenon perhaps?)

I hadn't seen anything like that until a clip in a recent review where the reviewer mentioned that the Snappy Weed came back to life after returning from Zaks' castle. You can tell the weed should have already died because the weedkiller is sitting in a place where it would have sprayed it. And he was playing a Red version! Now I wonder what could be overwriting the few bytes of information the game needs to keep track of changes to the game world...
someone stated that when trying to catch Pogie near Dizzy's hut, the game might actually activate the extra life puzzle that's present in the Yolkfolk Village. I haven't been able to reproduce that, so (assuming it's true) there might be other factors involved, or it was a random (possibly emulation) error, or...?

I've never heard of that, but I know that, like the match on the straw, the cage will not catch Pogie if you use it on the very highest stair you can stand on before entering the next screen up, no matter how you time dropping it. Maybe the puzzle glitch could be height-based, too!

Well, last month I tried one run through the game where after I collected the final star in front of the stargate, I searched around to see if a star regenerated, but I couldn't find one. I also went out all the way to Dizzy's home and saw that, while the Snappy Weed was still dead, it was also still retracting upward, a process it should have finished long ago, so maybe something about its state did get overwritten!

Now here's something that might be more interesting. I tried playing the first version to get to the town castle, probably abusing the desynched damage meter at the time, and when I was doing the first rope swing on the pirate ship to go toward the winch wheel, I discovered that if Dizzy got killed by a bird while swinging, the whole game would crash! Luckily I was using an emulator with "rewind" to retry this and make a savestate you can experiment with in Mesen with the "Blue" version. https://app.box.com/s/q5joshuuggkl6otg02ubopgtmb8lqip8

You might be able to make different things happen by getting Dizzy killed at different times, like how one time it was only a partial crash that left a strange pattern over the whole screen. I have found that if you wander away and come back, the danger of this crash may be gone, and Dizzy just falls down and dies normally if you get him killed by that bird then.

Sounds very interesting, might play around with it later. Thanks!

As for the plant, I've been told by Dizzy9 that (IIRC) the plant "state" reuses the same memory variable that Zaks' stargate door uses, and there's a very low random chance of such things occuring after it's been opened.

[quote data-userid="348" data-postid="89492"]

Now here's something that might be more interesting. I tried playing the first version to get to the town castle, probably abusing the desynched damage meter at the time, and when I was doing the first rope swing on the pirate ship to go toward the winch wheel, I discovered that if Dizzy got killed by a bird while swinging, the whole game would crash! Luckily I was using an emulator with "rewind" to retry this and make a savestate you can experiment with in Mesen with the "Blue" version. https://app.box.com/s/q5joshuuggkl6otg02ubopgtmb8lqip8

You might be able to make different things happen by getting Dizzy killed at different times, like how one time it was only a partial crash that left a strange pattern over the whole screen. I have found that if you wander away and come back, the danger of this crash may be gone, and Dizzy just falls down and dies normally if you get him killed by that bird then.

[/quote]

I NEVER had this happen to me, its so weird.

I'll make sure to investigate when I can find some time, many thanks for providing the save file!

Regarding the Killer Plant:
The magic stargate in Zaks castle and the Plant uses same RAM memory at 0x748.

The stargate uses it for its animation counter while the plant uses it as a counter for retracting back after you use the weed killer.

It is important to note that this ram is being used as a flag whenever the plant is still alive. (non zero means its dead).

Whenever the stargate is on screen, it will increase the ram value by 1 each frame, thus altering plants state. When stagate is out of sight, the animation is no longer played, leaving value at 0x748 at whatever it was set by the stargate. If it happens to land on non zero value, the plant will do its retracting animation. If it lands on 0, though, the plant will be revived completely. This is rather small chance: 1 out of 32.

Speaking of weird crashes, on one of my speedrun attempts this happened: (excuse the profane language)

https://www.twitch.tv/yojec/clip/CuteAuspiciousCroquetteOptimizePrime-p5DnQg7iVuWgLQhM

I've assumed that this was a hardware error (the cartridge might not make a proper contact with the console, all of my Famicoms suffer from that unfortunately). But who knows?

[quote data-userid="2495" data-postid="89514"]

Speaking of weird crashes, on one of my speedrun attempts this happened: (excuse the profane language)

https://www.twitch.tv/yojec/clip/CuteAuspiciousCroquetteOptimizePrime-p5DnQg7iVuWgLQhM

I've assumed that this was a hardware error (the cartridge might not make a proper contact with the console, all of my Famicoms suffer from that unfortunately). But who knows?

[/quote]

I probably would spend half of my day writting why I think its a hardware error while also advocating for software glitch but I only have 5 minutes.

I think Its hardware error mostly because of background is using sprite graphics instead of background set. Interestingly, seems like graphics for Rapids minigame get loaded as well as some kind of map. The map reminds me of Rapids minigame, but not all tiles make sense. Palette loaded seems to be one from Rapids minigame, though.

Well, its possible the cartridge connection failed for a bit and game transported you to Rapids minigame and crashed afterwards.

Sometimes these things can be used to speedrun certain games.

I've renamed this thread so that it covers a more broad range of topics - hopefully no one minds.

Here's a link containing Dizzy9's findings (copied from the Speedrun thread): https://docs.google.com/document/d/1d4LLZFSbfNglcQ0lBhUCdGXbKHEnvP_sfVVCQ7-y1q4/edit?usp=sharing

And there's another curiousity that I came across recently...

As some of you might know, in the Aladdin version manual (and on some game boxes) there's a beta version screenshot with several differences:

Yesterday, I've been to a gaming-themed pub that had a Polish Famiclone on display (Pegasus IQ-502). Out of curiousity I was checking out the box of this console, which had screenshots of five Codemasters games (the ones from Pegasus Golden Five multicart). One of the screenshots caught my interest:

It's the same exact screenshot, but... recreated in the retail Blue version!

Regarding the Screenshot on Pegasus box:

Excellent find, I never really noticed it myself...although, I never really had a proper Pegasus myself, only cheap knockoffs

Regarding the glitch of game crashing while dizzy swinging with a rope dies:

I actually looked into the code. The function that handles rope swing has a sub function that handles Dizzy getting off the rope.

The sub funciton takes X register as an argument for which animation should be played when Dizzy gets off the rope.

There are three cases in total:

-Getting off when rope swings down.

    This will always play walking animation and passes correct value in the X register.

-Getting off when rope swings up.

   This will play jumping animation and also is correct.

-Getting off the rope when Dizzy dies.

    This should play....no idea which animation because X is not being set in here AT ALL.

Since X is not being set, game uses whatever it was in it before...and uses it to start a new animation!

So, depending on X contents, an animation code can and will pull data from outside of what was intended.

If a sprite in animation doesnt exist, a lot of...things will happen in the code and game will crash.

You may ask about the rope ending its swing, but when that happens, code is redirected to function that handles first case.

Aside from blatant game crash, the game can just soft lock instead:

This glitch doesnt always result in crashes and softlocks, some animations can have a correct ending, allowing for normal death.

This glitch was fixed in both RED and PAL versions.

Regarding the crash on yojc stream:

It indeed seems like you got teleported to a Rapids minigame.

By changing some RAM values, I crashed the game at start of Rapids. It looks quite familiar.

The real difference being the background color is black in your crash...which gives me a hint: game replaces background color for status bar, which means that game must have crashed after that(but before bottom of the screen, where game returns map colors back). It would be immensly interesting if this crash was, in fact, done in software and not in hardware. Just imagine speerdunning the game with ability to warp to minigames directly, haha.

Also this:

Yeah, the games checkpoint system aint that great...

Good job with the research!

That last gif made me chuckle. I wonder if that's the reason for this trap being removed in the Red versions?

I was looking through your Google doc again and it just struck me, that the ceiling clip you've shown might actually be a decent speedrun strat - this might make killing the plant unnecessary. Not a huge timesave by any means, but that's 10-20s saved right there at first glance. I'd have to test it more thoroughly to be sure 🤔

Heh, I had already discovered in one of the first two versions a long time ago that the score wraps around from 9999 to 0000, but I never thought to test that in the final version. And what you said about filling the bucket is interesting in that speedrunners should take care to spend more than half a second in the water or risk it not being filled. But I don't expect the jump-off-air/through-walls cheat will be allowed in the main speedrun category. :smile:

EDIT: Oops, I misread the clipping tricks that came after the cheat code as being uses of the cheat code, but no, they're just ordinary jumps you can do! I believe I even got stuck on that mine blockage rock when I tested the game a decade ago, but I forgot all about it by the time I saw we were cataloguing bugs.

[quote data-userid="2495" data-postid="89540"]

It’s the same exact screenshot, but… recreated in the retail Blue version!

[/quote]

Heheh, it would be funny if they somehow had the original screenshot that Codemasters then mocked up more things onto for their 1993 manuals, but the score and lives are different, so probably not.

[quote data-userid="2495" data-postid="89544"]

That last gif made me chuckle. I wonder if that’s the reason for this trap being removed in the Red versions?

[/quote]

Maybe, huh... I remember when I had a respawn point directly over the cloud castle's spike trap, it actually gave me the chance to jump away from it, but this trap doesn't.

[quote data-userid="2495" data-postid="89544"]

I was looking through your Google doc again and it just struck me, that the ceiling clip you’ve shown might actually be a decent speedrun strat – this might make killing the plant unnecessary. Not a huge timesave by any means, but that’s 10-20s saved right there at first glance. I’d have to test it more thoroughly to be sure

[/quote]

Okay, good idea. I'm just scared to find out how the plant reacts if Dizzy is already to the right of it or passes over the top of it! :x_x:  

[quote data-userid="348" data-postid="89545"]

And what you said about filling the bucket is interesting in that speedrunners should take care to spend more than half a second in the water or risk it not being filled

[/quote]

Yes, that is so very true. Ask me how I know. :P

[quote data-userid="348" data-postid="89545"]

But I don’t expect the jump-off-air/through-walls cheat will be allowed in the main speedrun category. :smile:

[/quote]

Yeah, it'd definitely need to be its own category if this cheat was to be allowed. Technically it negates the need to collect stars, since you can clip through Zaks' stargate door. The game would take just a few minutes to complete. With that said... I'm not sure if that's what the speedrun site is about; completing the game with this cheat doesn't really show off the runner's skill, it looks kinda unimpressive.

[quote data-userid="348" data-postid="89545"]

Heheh, it would be funny if they somehow had the original screenshot that Codemasters then mocked up more things onto for their 1993 manuals, but the score and lives are different, so probably not.

[/quote]

I think Dizzy's placement is also a few pixels off. I just find it a bit funny that they went to the trouble of recreating that screenshot - it can't be a coincidence it's taken in the same place with the same items in the inventory. It's even more surprising that the retail version screenshot appears on a semi-bootleg console (there are rumors that Pegasus famiclone importer might have licensed Codemasters games somehow, but it's disputed).

[quote data-userid="2495" data-postid="89547"]

Yeah, it’d definitely need to be its own category if this cheat was to be allowed. Technically it negates the need to collect stars, since you can clip through Zaks’ stargate door. The game would take just a few minutes to complete. With that said… I’m not sure if that’s what the speedrun site is about; completing the game with this cheat doesn’t really show off the runner’s skill, it looks kinda unimpressive.

[/quote]

"I'll just float on over to Zaks's key, and then I'll float on up to the top of his castle!" :lol: Well, you might also need to float on down to the cymbals in the first version...

I've just recalled a quite peculiar bug - which admittedly is only partially related to Dizzy, but interesting nonetheless (I think).

When playing on FCEUX, you can crash the game so bad it actually corrupts the emulator somehow... Every state loaded will be glitchy, and even a soft/hard reset won't help - you'll need to reload the ROM to fix it.

I've written some more details (along with the video presentation) in the bug report there: https://github.com/TASVideos/fceux/issues/389

This is only the second time I recall a situation, where a game crash could actually affect the emulator. I'm not really surprised that the other game was... Fantastic Dizzy on the Master System - when played on PSP via Picodrive emulator, it would sometimes actually lock up the whole console IIRC. Of course, this is a bug in the emulator and not the game itself, but still - what a coincidence. :P

That sounds like what happened in Mesen when I overwrote a few text characters in the intro to display the unused ones: I thought I was only editing the part of RAM copied from the ROM, but then it still had those edits when I reset the game, as if that made the emulator write the same changes back to the ROM. Although I edited it back manually just in case, Windows didn't report a new Last Modified date for the ROM image, so I guess that was a temporary change that's supposed to be undone by the Reload ROM option or something.

Seems like the rope glitch just happened to the Kinaman

I was playing around with the NES Red/Aladdin version, and somehow managed to accidentally light up the straw just outside Denzil's hut.

I know it's not supposed to happen - in the Red versions, the straw can only catch fire inside Denzil's hut. So... how could it happen? This was an one time fluke, I couldn't reproduce this at all.

@yojc 

I actually was not aware of this.

I looked into the code and seem to understand whats going on.

The burning of the straw can be triggered in two ways:

1: by dropping a match on top of the straw.

2: by dropping a match in close proximity of the straw.

Yes, in code, these are very different things.

The first method was patched in RED version to work only when player is in Denzils hut.

The second, however was not changed from the original(BLUE version) and still can be performed in both RED as well as PAL version.

The reason why you may have had problems with recreating it may be because the proximity check is not very well done.

In theory, it should check 10 pixels to the left and 10 to the right of the straw object when you drop match....

However, the collisions for the items have an origin point on the left side of the item. Since items are 16 pixels wide, proximity of 10px will be eaten up byt item pickup collision test.

All this means, you can light the straw by placing the match within 10px on the left side of the straw. This will work on any map.

Side note:

All items in the game have a specific pointer\action thats executed when given item is dropped. This is the source of the second method of burning the straw. Since match is linked to that, we can conclude that burning of the straw anywhere in the BLUE version was intentional by the authors and not a glitch or side effect of something.

Edit:

The proximity check for the burning straw is actually 20 pixels in both axis, not 10.

10px is for checking for Denzil thawning spot.

@dizzy9 

Thanks for the thorough explanation!

From my brief testing, it looks like the collision area is anchored to the top left corner of the item, and it also extends vertically. What I mean is that I could light the fire while standing above the straw (within some distance), but not below it. Is my observation correct?

Also, are there any other items where the same method of activation (by placing the items 10px to the left) applies? Maybe the cage to catch Pogie with?

@yojc 

The proximity check tests a requested amount of pixels in both sides from a given xy coordinate.

Since items have origin point on top left, it means the collision checks to the left of the origin and above as well in a significant manner. It still check to the right, and below the point, don't get me wrong. Its just its more noticeable to the left and above.

Long time ago, I've written a lua script to visualize checks. Heres how check for burning the straw looks like:

As for you question about pogie:
Yes, it also has a top left origin point, making it easier to grab him on the left side rather than the right side:

https://i.ibb.co/sshZSyG/Fantred-031.png

Each item has a pointer. Some items such as aqualung or flippers have a pointer to no operation since these items are not "used".

Apologies, but I dont really have the time to go through code of each item to see if there are any gimmicks.