With the recent development in the any% category (the first TAS was published last year and the RTA time has been pushed down earlier this year), I've finally gotten around to update the any% section (as well as giving the game mechanics section a minor facelift) of the SDA guide (linked in the guide section).

It's worth mentioning that there are some small, but easy/free time saves that were not used in the currently fastest run at the time of writing, threecreepio's 6m27s from "two months ago". The guide should however include all of the fastest routes that are currently considered for RTA-runs (that I'm aware of).

The SDA guide can be edited by anyone, but you're also welcome to contact me directly or post in this thread in case you would like to contribute in sharing knowledge about this game.

The best ending section is currently out of date, but my intention is to eventually update it as well. I can't give a timeline for it though.

Edit (091124): I have now updated the best ending section. Unless something new is found, I don't plan on making any other updates.

lackattack, thanks for sharing. That's a really cool find!

I've never seen or heard about this before, so my feeling at first was that it was either a "get the stars to align" thing or there is a special setup for it that I never tried. I tested your idea just now and managed to get the warp to appear several times pretty easily by tugging the fuel cell through the warp just like you did. So I think your theory is right about that action triggering something in the code.

Without having timed anything, but just judging the path lengths, this looks in my eyes clearly slower than the route "collect shield and then go to the warp". But it also clearly looks a lot faster than the route "shoot warp, collect shield, go to warp".

If someone is making attempts, it would be interesting to see the average time difference and the success rate. Maybe it will become the preferable strat for new people to the game before learning the shield first route?

On the topic of odd things in this game, I came across something I haven't seen before a few months ago. Unfortunately, the highlight has been corrupted ( - a good reminder to not rely blindly on twitch...), so there is no evidence of what happened. But from memory, I got a double-warp on planet 1 that moved away towards the fuel cell. I don't remember if it stayed there or exactly what happened, but I remember I entered it. It just took me to planet 7 and not planet 8, as I otherwise would have expected. My memory is failing me a bit on this one, so I might be wrong on some of the details. This was clearly not directly useful for speedruns though, so I didn't bother to document it better than the twitch highlight.

RAM addresses of interest: $460 - warp object on planet 1 (0 - despawned; non-0 - the warp is still there) $5E/$5D - Big/Small "section" timer $439/$43A (and maybe more?) - warp timers

The "section timer" starts at 0 when a level begins and increases every frame. It's reset when e.g. delivering an item to the mothership (maybe it's related to the game loading a new "section", hence my tentative name). I haven't tried to look at the exact criteria for this, but for the purpose of planet 1, this should be enough information.

From a quick glance at the "warp timers", they seem to initialize when you get "close enough" to the warp and increase every second frame. If you trigger a timer and then move away from the warp, the timer will stop.

There are at least two ways to despawn the warp object. a) The big "section timer" reaches 5 b ) One of the "warp timers" reaches 0x40. (I can't rule out that there aren't any other despawn triggers - this was just from a quick check)

The critical one on planet 1 is 'a'. You need to collect the shield and get back to the ship within 5x256 frames ~ 21s. This is pretty tight, no matter how you look at it. You need to get a good bounce after collecting the shield and then you need to practice how to deliver the shield as efficiently as possible.

I didn't see this thread until now, but felt that I'd like to add a few details.

I think it's worth mentioning in the first post that the three runs by me were done on the PAL-version of the game. As far as I know, there are no gameplay differences between PAL and NTSC (although PAL probably has a small relative advantage by getting less lag, due to the slower framerate).

While I don't think converting PAL to NTSC for leaderboard purposes is a good idea, it could still be noted that 13:48 PAL "corresponds" to 11:28 NTSC. At least such a conversion gives an idea of what the known strats back then could produce.

I don't have a habit of saving my intermediate pbs, so the two first listed runs were deleted a long time ago. I checked the SDA-thread again to see what I wrote. I think you got the dates wrong. I edited the same post in that thread for updates. The post was from the 11th of August 2009, but the 14:10 was from an edit on the 280809 and the 14:02 from the day after.

zakky's 10:58 was the first time the ship glitch was done in a new record run.

And thanks for making the overview!

I've gotten the warp to 8 at least once more (probably twice) with my Powerpak. Good to hear that it has also been produced elsewhere.

I'm now focusing on producing it on emulator. My first attempts were to come up with theories (e.g. what happens if a random enemy spawns in the same location as the original warp). They have not resulted in anything of use though. While this has been far from exhaustive, I don't think that's the most efficient way forward for me. I'm now going to focus on recording attempts on emu and hope that I will randomly get it. Having an emulator movie to analyze would open up for better possibilities to understand the mechanics.

I'll let you know if I find anything of use. Likewise, if you find or hear credible accounts of other game-breaking tricks or glitches, I hope you will consider publishing them.

Cross-posting here for knowledge sharing. https://forum.speeddemosarchive.com/post/solar_jetman_nes_7.html

In short, I managed to warp from planet 1 to planet 8 by spawning a second warp. It was done on console with a powerpak. I've only been able to do it once and I don't know what caused it, even though I'm guessing a spawning enemy somehow got the warp value written to the RAM-address determining the enemy type. Considering the mechanics behind the eye despawn of the final boss, lag/overflow could also be involved. I've also posted in the tasvideos topic to see if it sparks some interest in understanding what happened.

I've watched yogi's 12:40 run. It's a very good time and it will not be easy to produce a faster run. However, I decided to look at the run in some detail and comment on where I see there is still room for improvement. I'm mostly focusing on the room solutions and not so much on the execution mistakes. While some of the comments are already well known, it might still be of use if someone shows up here in the future, once the dust has settled.

I found a faster way to clear this room: By dropping the goblin on the right side, the lag is not slowing down the sparkballs as much and you don't have to wait for the one on the left side. I think you can potentially save close to half a second in this room. The downside is that the jump past the sparkballs on the right side is tighter than in the 12:40 run.

One of the Saramandors dropped an "upgrade jar". It's a random drop for which I don't know of any manipulation in this room. This drop can be manipulated in some other rooms though, so it's possible that something could be found here as well. Either way, I'm guessing it's still a 50% chance or so even without any manipulation. If the jar drops, it's tricky to collect it with the solution yogi used, but there are other solutions to make it easier. See https://kb.speeddemosarchive.com/Solomon%27s_Key_(NES)/normal_ending#Room_22 The fireball that transforms into a super fireball can be used to save time in room 37, but at the same time requires room 31 to be cleared without using any fireballs.

This solution looks slightly slower than optimal. The additional block created before jumping to the key comes at a fix cost of 17-18 frames (block creation seems to vary a bit). That's quite a bit more than what's needed to avoid jumping into the gargoyle. You can also make a quick pause of a few frames, but less than what it costs to create a block, before jumping to the key and it should still be safe.

If the upgrade jar was collected in room 22, you could take out all the demon heads and get a more direct route to the exit. Time save a little under a second.

There is a safety block on the left side of the start row that can be left out. Obviously risky though as it requires two additional corridor jumps.

With pixel-perfect positioning (so frame perfect), you can drop the last blue flame without getting hit by the demon head. This saves a little under a second.

Another possibility is to use a fireball on the last demon head (assuming you didn't use one in room 31 or 37), which should be possible to convert into a half second time gain or so.

You should be able to save ~5 frames by destroying the lower block to begin with instead of the block in front of you.

I'm a little in doubt whether the fourth block at the start is better to destroy before dropping down or while dropping down. The former requires ducking, while the latter will block Dana for a few frames while dropping down. I'm uncertain because it depends on how well you execute ducking and how early you're able to destroy the block during the drop. By comparing mine and yogi's runs, it seems like yogi gained a few frames from destroying the block before dropping down.

Destroying the block on the other side of the shaft with the key requires running the length of two more blocks (and ducking). That corresponds to 40 frames (plus likely a few frames from ducking). The purpose of this is to transform the key drop into a 3-frame (iso 2-frame) window when exiting the shaft.

However, I found a way so exiting the shaft with the key becomes a 3-frame trick even without destroying this block. Consider the following RAM-addresses: 589 - x 588 - x-sub 586 - y Normally, Dana is restricted in the x-position between 84 and 92 during the drop and with no x-sub. However, if you press against the wall and hold right as Dana grabs the key, you'll get another frame of movement (=192 sub-pixels) and slightly clip into the right wall. If you now release right, you'll keep the new x-position (so x=92 and x-sub=192/-64). Breaking the block on the right can now be done when y=101, 103 or 105. If you make any movement after collecting the key or if you didn't get the correct x-position when grabbing the key in the first place, only y=101 or 103 will allow you to break the block and exit the shaft.

When creating the block under the demon mirror, you can arrange the blocks differently to make it slightly more efficient. It's described here: https://kb.speeddemosarchive.com/Solomon%27s_Key_(NES)/normal_ending#Room_48

You should be able to save a tenth of a second or so at around 8700.

• First create the block to the right
• Turn around to destroy the block to the left
• Jump and turn right up to the edge of the block on the right This sequence allows you to use the jump time for turning around, instead of turning around on the ground (which will always be associated with a small time loss).

Using the block magic costs more time than an additional jump. So creating a block before jumping to the demon mirror is a time loss.

There is also the TAS-strat, which manages to use the block magic on the demon mirror and then get into the room with the book without having to make an extra jump. Pretty difficult for only a small time gain though.

I've noticed that both yogi and metroidmcfly often have a slightly different method when creating a staircase and climbing it than myself. I have the habit of creating the block before landing on the block above and then jumping again, while yogi and mcfly often start the next jump before creating the block. It turns out that it's one frame faster to wait with the block creation until after you've initiated the next jump.