Submission #6089: EZGames69 & Memory's GB Mickey's Dangerous Chase in 11:37.07

(Link to video)
Game Boy
baseline
BizHawk 2.3.0
41634
59.7275005696058
57692
Unknown
Mickey's Chase (Japan).gb
Submitted by Memory on 9/2/2018 12:34:33 PM
Submission Comments
Mickey's Dangerous Chase is a simple platformer for the GameBoy. You can play as either Mickey or Minnie and the goal is to get back a present that Pete stole. The character can walk, jump and pickup blocks and throw them. It heavily resembles Chip n Dale Rescue Rangers for the NES except with some autoscrollers with vehicles.

Game objectives

  • Emulator used: Bizhawk 2.3 (GBHawk core)
  • Takes damage to save time

Comments

Memory: I decided to investigate EZGames69's last submission while judging and I found plenty of improvements. I decided to look into more improvements and so I decided to work on it myself.
I used EZ's input as a base and most of my strategies are the same as his, with the exception of lag reduction and some minor movement changes here and there.

Techniques

Memory: Jumping a certain amount of frames before a lag frame may cancel it. This is the most common method I implement to reduce lag in the game. Other methods include reducing sprites... including Mickey himself by jumping offscreen.
Another improvement was the usage of clipping corners to get pushed forwards. You move forward 2 pixels instead of 1 on a single frame if you do it. It was thought this would cause lag but I discovered that this was not always the case and implemented it where I could.

Emulator differences

EZGames69: When I started working on this game, I noticed that the Screen transitions for GBHawk are noticeably faster compared to Gambette. in Gambette, the transitions take 11 lag frames while in GBHawk it's only 1 lag frame. So this is movie is about 84 frames faster than if it was done on Gambette.
what's interesting is even when the movie files were done on either core to playback on a GBP, it would still make it to the first level just fine, even though the differences occur during the screen transitions. Hopefully this movie can help determine if anything needs to be fixed in the GBHawk core.

Table of improvements from Published movie

LevelFrames saved
1-133
1-215
1-323
2-129
2-218
2-337
3-147
3-247
3-314
4-184
4-224
4-333
5-142
5-213
5-311
Total470

1-1

Memory: I first started to save frames here by experimenting with the jumps. I found that I actually saved frames by moving the second jump earlier, which ultimately pushed me to look further into improvements for this game. Experimenting with the block toss timing also saved some time.
Whenever I jump seemingly randomly, the point is to reduce lag.
I changed the exact timing when Mickey got hit by the enemy to control lag.

1-2

Memory: Mostly additional jumps and experimented with timings to reduce lag.

1-3

Memory: A ton of time was saved here and on most the autoscrollers through lag. In this case it was mostly just the jump a certain number of frames before certain lag frames method.

2-1

Memory: When you throw the blocks is crucial to determining the amount of lag you get.

2-2

Memory: I managed to get past a bouncing rock two frames faster than EZ by holding right instead of left for one frame when trying to jump past. Otherwise more of the same lag reduction techniques.

2-3

Memory: Picked up 3 of the orbs to reduce lag. Also picked up an invincibility to remove enemies and reduce lag. Collecting the stars might sometimes cause lag so I avoided it when it would. Some levels you want to collect the stars, others you want to avoid.

3-1

Memory: Jumping in the spikes at the beginning causes a little less lag than jumping into the bird.
Power-ups that come from the Question Mark blocks cause a lot of lag when they appear so you want to collect them ASAP.
Often you can fall slightly faster by jumping and hitting the ceiling with 2 frames of A-input instead of 1 or walking off the edge.

3-2

Memory: Jumping before getting hit by the bat at the start helps reduce lag for some reason.
At 5:21 in the encode is the first instance in which I knowingly used the corner clipping technique.

3-3

Memory: Jumping off screen frequently reduced lag so I implement it whenever possible. Ultimately lag comes down to trial and error.
Lag can also be caused by holding directions at certain periods so I'm sorry if the entertainment on the autoscrollers isn't quite as good.

4-1

Memory: Managed to save a lot of time here. A lot of it was lag reduction, but I also implemented a cleaner strategy picking up the block with the spike ball on top of it.
I timed collecting the star thing that appears from the ? block but it wasn't worth waiting for. It ultimately just creates a 1-up sprite which might cause lag anyways. I still managed to reduce lag from it by jumping repeatedly, however.

4-2

Memory: Some lag and movement optimizations.

4-3

Memory: I picked up the star at the beginning as soon as possible to minimize lag. I also grabbed an additional orb.

5-1

Memory: Experimenting with when and where you get hit was key to determing lag.
Jumping from the higher platform at the end also reduced lag.

5-2

Memory: Lag reduction picking up more orbs and staying off-screen. You want to jump a lot earlier here to avoid lag than most other stages.

5-3

Memory: A lot of the lag here I couldn't do much about but I took what I could. Collecting stars helped with lag here.
There is one block where I landed on the corner and it looks like I lose time but delaying the jump causes more lag anyways so it doesn't actually matter.

Other comments

Memory: I wouldn't be surprised if there is more time to save through lag and maybe some more minor optimizations. However, this TAS is much harder to improve on than earlier iterations, which was ultimately the point of me working on the project.

ThunderAxe31: Judging.
ThunderAxe31: Solid improvement. Accepting for obsoleting the current publication.
feos: Pub.
Last Edited by adelikat on 10/27/2023 2:00 PM
Page History Latest diff List referrers