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.
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.
All the new little tricks and improvements.. obvious yes vote.
Both runs had their unique strong points, but I'm still with the realtime-crowd.
edit:
freezing metroids, they can't be killed otherwise. (well, power bombs work, but that's really really slow)
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.
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?
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.
It's called Swarm, it's installed on my Linux machine, probably part of KDE 3.x.
edit: the about box says
so it's likely there are other versions around. Maybe those names will turn up some starting points on google.
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.
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.