TASVideos

Tool-assisted game movies
When human skills are just not enough

Submission #6762: EZGames69 & Memory's GBC Mickey's Dangerous Chase in 11:41.78

Console: Game Boy Color
Game name: Mickey's Dangerous Chase
Game version: JPN
ROM filename: Mickey's Chase (Japan).gb
Branch:
Emulator: BizHawk 2.4.2
Movie length: 11:41.78
FrameCount: 41970
Re-record count: 62869
Author's real name:
Author's nickname: EZGames69 & Memory
Submitter: EZGames69
Submitted at: 2020-05-27 15:11:20
Text last edited at: 2020-06-13 09:03:37
Text last edited by: feos
Download: Download (10943 bytes)
Status: published
Click to view the actual publication
Submission instructions
Discuss this submission (also rating / voting)
List all submissions by this submitter
List pages on this site that refer to this submission
View submission text history
Back to the submission list
Author's comments and explanations:
Mickey's gift for Minnie was stolen by Pete, so now he must go and get it back from Pete in a very very very very dangerous chase.

Straight encode:


(Link to video)

Comparison Supercut Encode (removed loading screens):


(Link to video)

Game objectives

  • Emulator used: BizHawk 2.4.2
  • Takes damage to save time
  • Uses GBC BIOS

Comments

While the time looks to be longer compared to the previous publication, this is in fact an improvement of 174 frames. The reason why it appears longer is due to the old TAS using an earlier version of GBHawk (the one found in BizHawk 2.3 to be exact), which had 1 frame worth of loading time. This has since been changed in later versions of GBHawk. All that time lost from the 1 frame loading added up and managed to be longer than GBC mode (even with the GBC BIOS being significantly shorter than the GB one). Because of this, I have provided a super cut comparison encode that removes all the cutscenes with Goofy, so I only have to compare gameplay, rather than account for the inaccurate loading. I should note that I do not know if the use of EqualLengthFrames=False has any effect on the comparison encode, but if it does, I doubt it would have any significant differences.

However I should be addressing the bigger elephant in the room. This TAS is using GBC in GBA for the purpose of console verification. TiKevin83 has verified a modified version of the older movie on console, he is planning on testing this movie soon, so once that is up, I'll add it to the submission. A side effect of using GBC mode for this game is some of the lag is reduced compared to GB mode. However I can assure the judges that there are other gameplay improvements here, which I will get to in the level by level section.

One major change you might notice with this new movie is damage sounds are emulated this time, previously some sounds didnt play on either GB core, but now they have been added. I never mentioned it to the devs because I thought the damage noise was only exclusive to the USA release. It was only once I made the modified version of the old movie did I realize Gambatte was actually playing it back. So thank you to whoever fixed this.

Stage by stage comments

You are able to play as either Mickey or Minnie, however there are no notable differences between them. So Mickey is chosen as he's the first option. The gameplay is comparable to Chip 'n Dale for the NES, where you can pick up blocks and throw them at enemies, although being a much slower version.

Stage 1

If you couldn't tell, this game is laggy in some parts. One of the easist ways to reduce lag is to have less sprites visible on screen, you can do this by jumping high enough to force them off screen. The biggest part of optimizing this game is to reduce lag as much as possible, even with the amount of effort done to reduce it, the only way to truly optimize it fully is though method of botting.

We also take some damage boosts here and there, and we are able to refill our health in each of the x-3 stages. each x-3 stage with the exception of 5-3 is an autoscroller, which allows us to refill our health during the downtime.

Stage 2

For this stage, we avoid taking damage entirely because for 2-3, the rising speed of Mickey depends on your current health. So if we were down to one heart, we would only have one balloon, and we would rise at a slower speed. The invincibility powerup is grabbed for some stages to eliminate enemies that cause lag

Stage 3

This stage needs more damage boosts, so we have to grab health in places other than from the x-3 stages. I found that by getting a 1-up from collecting enough stars, it can cause more lag in areas that are laggy, so due to this, I get the 1 up at the end of 3-1 where no lag takes place.

3-3 is difficult to optimize for lag, as Mickey has to be off screen in order to reduce the majority of it.

Stage 4

4-1 has many blocks you have to throw, we try to throw them at the top of the screen to avoid any additional lag as possible. Although it was never proven that throwing them upwards avoids lag, we do it anyway since it wastes no time (better safe than sorry).

Stage 5

the hitboxes on the wheels in 5-1 are huge, which is why you see me wait a bit before walking past them. We also cannot refill our health after this stage so we must grab one before heading on to the next levels. We need health to get the quick kill on the final boss.

for 5-3, we damage boost past pete on the less laggy encounter of him. the first two encounters have him throwing one ball, where the other 2 encounters have him throwing 2. It would cause more lag to damage boost in the second 2 encounters, so it wouldnt be worth it. The quick kill involves damage boosting and using all the i-frames to continue to throw bricks at Pete.

Other comments

I'd like to thank MemoryTAS for kicking my butt in the previous submission, it really opened my eyes to how I can improve my TASing abilities in the long run.

I'd also like to thank the Alyosha and TiKevin83 for their work in making GB emulation console accurate, I'm glad to see one of my childhood games that no one knows about being used to help improve emulation.

I hope you enjoyed watching.


ThunderAxe31: Judging.

ThunderAxe31: I want to remind that when considering an improvement to a current record, difference in loading times due to different game mode or emulation accuracy are not taken in account. So even if a movie is overall shorter due to using GBC mode instead of GB mode, it will still need to be faster in actual gameplay execution.

This movie resulted overall longer due to improved emulation accuracy of loading times, and since during gameplay segments this movie is faster than its predecessor thanks to better optimization, it's considered a valid improvement. Thus, accepting this submission for obsoleting the current publication.

feos: Pub.


Similar submissions (by title and categories where applicable):