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

Submission #4749: Arc, Kyman, Alyosha's NES Super Pitfall in 06:10.51

Console: Nintendo Entertainment System
Game name: Super Pitfall
Game version: USA
ROM filename: Super Pitfall (USA).nes
Emulator: FCEUX 2.2.2
Movie length: 06:10.51
FrameCount: 22267
Re-record count: 2443
Author's real name: David M
Author's nickname: Arc, Kyman, Alyosha
Submitter: Alyosha
Submitted at: 2015-07-05 13:15:23
Text last edited at: 2015-07-12 19:24:27
Text last edited by: Alyosha
Download: Download (2862 bytes)
Status: decision: cancelled
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:
Super Pitfall is a platforming game well known for glitchiness and overall poor programming.

Game objectives

  • Emulator used: FCEUX 2.2.2
  • Beats the game as fast as possible
  • Abuses programming errors

(Link to video)


This game is pretty poorly programmed, as anyone who has tried to play the game casually can attest.

'Wall Clip': This glitch occurs because a particular memory address ($00D5) is reused for multiple purposes in a frame. One of those purposes is for collision detection. Normally, this byte fails a check that prevents the player from moving forward when walking against a wall. However, it turns out that $00D5 is also changed at an interrupt of some sort. If the interrupt timing is just right, the value will be modified and not changed back before the collision detection check. When this happens the character moves one step into the wall. This is quite random, and I have found no way to consistently make it happen. Only a brute force search could really find the best case as far as I could tell. But it happens often enough to make it a time saver.

This run features several new clips, allowing slow deaths to be avoided.

Other comments

This is my first attempt at using automated re-recording to make a run, and I must say I am pretty happy with the results. This run probably contains more re-records then all my other runs combined, simply because of the blind brute forcing I did to make the clips as fast as possible.

There are a couple of other possible clips as illustrated by Arc, but I have not managed to make them save time over the current ones. Of course, I only tested a small fraction of the incredible number of potential combinations, so maybe if enough cpu time is devoted to the problem more improvements are still possible.

There is also a glitch (presented at a recent AGDQ but known for several years), that warps to the ending screen much faster, however it turns out the true ending state is not obtained this way, since it doesn't start the second world, and therefore not included in this submission.

Similar submissions (by title and categories where applicable):