Submission #9501: eien86's NES Lunar Pool "no friction" in 31:58.29

Nintendo Entertainment System
(Submitted: Lunar Ball)
no friction
(Submitted: no friction)
(Submitted: Lunar Ball (J) [!].nes )
Bizhawk 2.10 (Core: QuickerNES)
115287
60.0988138974405
6038
PowerOn
aa5c574a4743991a3523dfd78a39d782bede262a
Submitted by eien86 on 1/26/2025 11:26 AM
Submission Comments

Introduction

See #9499: eien86's NES Lunar Pool in 22:53.62 for a detailed explanation.
This movie goes for the "frictionless" category, where the friction factor is set to zero, making it a fun challenge. In terms of botting, the lack of friction made it easier. The reason is that the possible outcomes of any given shot are much more limited -- typically all balls except for one or two go into the pockets. Therefore, the exploration blows out much slowlier than otherwise.
Contrary to the any% movie, it is faster here to sink the cue ball into the pocket to reduce the score rate. There is no other way to reduce the rate since, given the nature of frictionless, at least one ball needs to enter a pocket (or the game enters an infinite loop)
To prevent infinite loops or very long sequences, I use a hash function to detect repetitions. Funnily enough, there are finite shorts that can reach almost half a million frames before stopping. Crazy.
Again, it's my privilege to bring obsoletion to this 15 year movie.

Comparison Video

The old movie is able to finish certain stages faster because the initial conditions carried on from the previous stage has an effect on the best possible solution. Also emulation differences make it so that executing a shot under the same conditions (angle, position, power, power increase/decrease direction) would result in different outcomes.

Software + Hardware

Rom Information

  • Name: Lunar Ball
  • ROM: Lunar Ball (J) [!].nes
  • SHA1: AA5C574A4743991A3523DFD78A39D782BEDE262A
  • MD5: 26F1B77980A216767EA63C41397476E5

Emulator

  • EmuHawk 2.10 (Core: QuickerNES)
Note on accuracy: this game is very sensitive to a correct timing emulation. A console-reproducible solution won't be possible unless using a highly-accurate emulator like NesHawk. However, since 1500M was made with an emulator that's arguably less accurate than the one I'm using, I think we're taking a step forward on that regard.
Ideally, I would be able to use NesHawk or Mesen as routing core. However, using those will be so comparatively slow that I will have to take several months to even come close to the quality of this solution. So in this case I valued solution quality to accuracy.

Routing Bot

  • Bot: LunarBot
  • Routing Core: QuickerNES
  • Platform:
    • 2 x AMD Epyc 7763 (128 cores, 256 threads) + 512Gb RAM
    • Exploration Rate: ~8k shots/s

nymx: Claiming for judging.
Last Edited by nymx 11 hours ago
Page History Latest diff List referrers