Super Metroid - the only game where half a dozen people will yell at you for posting an improvement :D
it may only be two frames, but it still looks incredibly smooth. Good job!
because there's no rerecording Amiga-Emulator. Unfortunately, it's currently technically impossible to create one that'll play most uncracked games.
feel free to use the sub-par snes ports, but prepare for less colors, inferior sound and lag.
edit: didn't know about a genesis port, but apparently that's not a real option either.
"This important looking notice was in a park in the zoo." If you ever wondered what it says, it's roughly:
Bomb craters
The zoo Schönbrunn was bombarded during the last days of the second world war, at the 19. and especially the 21. february 1945. To this very day there are three bomb craters in the woods connecting the areal Tirolergarten and the historic part of the zoo.
These sad relicts of the past are now valuable retreat areas for endangered amphibians.
One of these small, artificial craters can be seen here.
Isn't this the game where the game clock can be abused by pausing every second or so?
nope, see:
http://tasvideos.org/SuperMetroidTricks.html#MechanicsOfTheInGameTimer
you can avoid death by frequent pausing though (you cannot die while entering / exiting the pause screen, even if your energy is zero). That could lower your ingame-time by delaying e-tanks or doing more damage-boosts or skipping health refills.
If you can pause during MBs gay-rainbow-attack it'd allow skipping e-tanks altogether, but I doubt that's possible.
edit: you can't pause during the attack, so you'll die.
it doesn't matter if JXQs torizo fight was good or not, since we're calculating improvements over JXQs run.
of course you might label those 21 seconds as "1 second: better torizo fight. 20 seconds: torizo skip", if you really want to. ;)
sorry, you're right. Yesterday I did a rough estimation using the avi and my watch and got around 25 seconds.
time spent in the torizo-room itself is this:
JXQ 100% v2: 24374 - 26212 = 1838 frames
cpadolf v4: 24301 - 24844 = 543 frames
~21.5 seconds saved (small differences in the pre-torizo-room not accounted for)
also, despite being ingame-oriented, 73 realtime-frames were saved in zebes until the torizo-room by minor optimisations and CWJs alone.
guess this topic is more fitting for a reply.
Cpadolf wrote:
I will use a realtime oriented route (though the route might be the fasters ingame route too, but I'm not 100% sure on that) but I might end up optimizing door-entries for ingame time (not sure yet) since 00:36 is very tantalizing
don't forget that you'll get around 25 seconds just by skipping the torizo, so you'll need only ~30 seconds of gameplay improvements. Since JXQ didn't use many CWJs, you'll get a lot from that. Then there are all the newer room strategies that have been found. I'm just guessing here, but are you sure 0:36 is impossible when going strictly for real-time? Just look at the amount of time you managed to save on your old run, or hero saved on his.
There's also been talk a couple of pages back about a route change, delaying Kraid until you have PBs, thus doing the first norfair part suitless. IIRC there was no conclusion if it's feasible / faster, but maybe it'll turn out to save you another couple of seconds.
just finished watching. This was thoroughly entertaining and I'll make sure to watch it another couple of times when there's time to kill :)
While I still prefer real-time-runs, this is just 5 real-time seconds slower than hero's old run, and it incorporates so many new tricks and shortcuts that I consider it truly superior.
Thus voting yes for publication and obsoletion of hero's run.
Well, you could have used the turnaround-cancel-thingy a bit less often, but it's no big deal. ;)
..so, what's this thing I hear about a 100% run? do you plan to aim for ingame-time again?
Wow, very nice job guys! Although you had alot of benefits from my demo, and very likely wouldn't match my Zebes times without studying it carefully
just like they had to closely study your escape demo to barely match your time. right.
edit: oh, I wouldn't mind anyone doing a 49"22 in a realtime-oriented run, but that's the author's decision, either way is fine with me :)
looking forward to your run hero. still can't believe you've been working on this all along without telling us, but it was probably the best choice.
well, they should be if rerecording is supposed to work, but not every emulator does it that way.
for example pcsx2 is multithreaded and does not have full synchronisation (for speed reasons), UAE offers a disk mode that'll pass the data as fast as possible (because no Amiga program should expect certain disk speeds anyway, it's a heterogeneous platform) etc.
so while rerecording requires the emulator to be completely deterministic and not affected by host-based timings, that can't be taken for granted. There are valid different design decisions when writing an emulator.
Anyways, if you want, I'll work out a formula for arm-pumpability on slopes when I get the time. But really, I'm pretty sure it's about what you'd expect it to be - slopes are approximated by pixelized paths rather than a strict slope, and Samus can only armpump when the path is two horizontal pixels in a row. Which would depend virtually entirely on Samus's pixel position (i.e. ignoring block and sub-pixel position).
so it's just about figuring out the proper shape of the slope, then applying the well-known movement formulas and you're done?
how many different slopes are there actually? I haven't worked much with SMILE, but unless each slope piece has a different shape it shouldn't be a huge deal to code a brute-forcing application.
that leaves the options:
- do it manually like before
- try DeHackEd's LUA-Scripting
- sacrifice a goat to the almighty Kejardon so he might bless us with disassembled knowledge ;)
there is more than just one slope in the game.
Could it be useful to make a mathematical model and write a brute-force-program that'll output the fastest way / optimal subpixel position, or would that just be a waste of time?
the first is easy. take any two integer coordinates, then calculate the position of the third. There are two possible positions, but both of them can't be integers because sin(60°) is not rational.
the tetrahedron can be constructed by placing any cube on integer coordinates, then using one of the two touching tetrahedrons inside.
