Beautiful, I am definitely going to have to watch this again to pick out more of the detail of the speedrun. I've been hoping for a 3D sonic TAS like this for a while and this delivers everything I wanted. Yes vote.
Good luck with future SA:DX and SA2B TASes, to everyone who is planning them :)
Every time you hit an encounter, there are three possible ways you can deal with it - reset glitch, run from the battle and stutter just enough to skirt over it. So, you can branch execution and examine what results of each of those three branches:
1) Reset glitching it, adding the associated frame cost and continuing at the same danger level;
2) Accepting it, adding the associated frame cost and continuing at danger level 0;
3) Calculating how long ago you would have needed to start stuttering to baaarely miss it (only allowing you to stutter immediately after the last reset glitch/accepetd battle, or beginning of the graph, whichever comes first), adding the associated frame cost and continuing at the danger level that just mised the battle. However, if you can't go far back enough to stutter over it (for example, for your example graph, if reset glitch was chosen for the encounter at step 30, it can stutter as far back as immediately after the reset glitch, since stuttering further back than that is a different universe - and if stutter was chosen for the encounter at step 30, we could go all the way back to the last danger level 0 and attempt to stutter and still not make it) then this option is skipped.
In each of the possibilities we've picked, we wait until the next battle, and again try reset glitch/accept battle/stutter starting after last event, again adding the associated frame costs to the total frame cost spent manipulating so far. Finally, in each string of possibilities (how we dealt with each encounter), when it reachess the end of the graph, we note what we did and how low the frame cost. Once we're tried all strings of possibilities, we sort by frame cost and recall the cheapest.
This is a very dumb backtracking algorithm but it works in the case of few enouncters to deal with (For example, in your graph there are 19 encounters - at worst you'd try 3^19 universes, but most of the encounters won't be reache by most universes, and a lot of the time stuttering won't help, so in reality it's a lot lower). If you need it to be smarter and more efficient, maybe something like alpha-beta pruning could apply here? (Google it, but basically alpha-beta pruning is used for exploring trees of possible future moves and picking the best outcome - it's a rule that lets you ignore all branches if they can't possibly beat a prevously evaluated branch using perfect play.)
Errrr.......I don't think he did well
I TASd this game before and almost 1 minute faster than this ,but I do not use this version
so I think it can improve a lot
If you still have the input file, could you upload it?
It would be interesting to see an improvement of this run someday. For example, the Faerie Card alone can now be used to do the shopkeeper glitch, so you can get your mana prisms, duplicator, etc. earlier in the run. Plus, with a game as insanely complicated as SoTN there's undoubtedly a better way to collect all the rooms that just needs to be thought of.
As a matter of fact, a "better" or smarter way to collect rooms would be to clear the ennemy list, and while at it why not collect all items... its very ambitious but im having this in mind since quite some time now, it could be technically very interresting, probly less glitchy, less underfloor crazyness, less repeativness and more to explore, hopefully it would make a more balanced movie than current one.
A 'completionist' run would be absolutely insane. Good luck if you ever work on one!
If this run is published as a separate category, then why does it get the "Notable Improvement" lightning bolt?
The situation is as follows:
-The old definition of the previous TAS was 'beat julius mode as fast as possible'. By that definition it is a notable improvement.
-Because the previous TAS is worth watching and essentially fulfills a different category (I think you'd call it Julius Mode no OoB?) it has been rebranded so it can be published alongside.
Imo necroposting is only bad (should be discouraged) in situations like:
-The topic was about something very temporal (like a version of a piece of software that no one has any right to be on anymore) that is no longer relevant.
-There is a more up to date or relevant topic on the same subject that would be better to necrobump instead.
-The topic is strictly about discussing the OP, or another person, and the OP/person is no longer in need of discussion.
-The topic is chatroom style (like how the mspaintadventures forum has a stickied topic about discussing what's going on in the comic in chat room style, and every time it gets too long it's closed and a new one made, because they are intended to have merely temporal nature)
Otherwise, necrobumping keeps forums clean of duplicate, redundant and unncessary threads, and helps consolidate all information about a single thing into one thread.
Yeah, I'm currently editing the video. Sorry about this long time, but I had a lot of issues to encode it and I was busy with other things. But I'm uploading it in this week!
So there's this thing that's been annoying me during basic testing, and it would also annoy anyone trying to remotely optimize Galaxy TASes at all:
When I press Z, Mario crouches either 1 or 2 frames later. The problem is, I have no idea when it's 1 frame and when it's 2 frames. 2 frames is the more common case, but 1 frame would obviously be more useful. This affects the timing of inputs required to execute long jumps and backflips.
If anyone feels like helping out with Galaxy TASing/Dolphin testing, investigating this would be a big help.
Is it correlated with...
-Mario's position?
-The kind of surface Mario is on?
-What frame of animation Mario is currently in?
-Some global timer?
I think that a typical mouse can only move (signed byte) pixels in X and Y diections in a given message, if this protocol is still in use: http://en.wikipedia.org/wiki/Mouse_(computing)#PS.2F2_interface_and_protocol
Although, couldn't programatically moving the mouse around escape this limitation? I know that WM_MOUSEMOVE messages use two bytes and just say the final location of the mouse, so there's no 'one byte' limitation there. If you programatically move the mouse more than 128 pixels it would just create 'one mouse movement' not chunk it up, right?
Finally, my understanding is that a mice informing the computer about a mouse movement is interrupt based (so can happen as often as it wants, whenever it wants) - so any game that polls for mouse movement once per frame instead of learning about it via interrupts can have arbitrarily far mouse movements in one frame, regardless of above concerns.
I like how a few days after this topic was made, we have a spurt of 5 submissions over the course of 24-48 hours. I guess it's just the clumpiness of random distributions at work.
I think it's because the standard of quality in TASing has gone up. I know many TASes that will be extremely good are currently in development to ensure they'll be as good as possible (TTYD, Banjo Kazooie, Banjo-Tooie, DK64 some day?, Twilight Princess, etc).
We can also do a 2nd loop run with the bullet hell lua script.
I'm actually pretty interested in ridiculous difficulty level TASes of gradius games in general (I recall that all the arcade games had ridiculous loop 2s, for example, and all those are quite interesting to watch)
TASing Windows and DOS games can be done without needing ROMs (because the version of the game you would buy and play normally is the version of the game you TAS).
I already thought about a G/S/C run as well, since there seems to be no run of it (not counting the glitchless run), but I don't know much about the glitches in this generation, yet, and they are not as well explored as in Gen I afaik. Also, it appears to be harder to gather information about it (e.g. I wasn't able to find any reliable information on the glitch used in the video you linked). There will be a lot of research to do first, but I may be up for it in the near future.
Just as an update, werster and RingRush have been looking into glitch hunting/tweaking usage of glitches in Gen II:
twitch.tv/werster
So if you're still interested you could check that out, contact them and talk, etc
EDIT: Werster just beat the elite four using a glitched route + instant victory glitch and it didn't crash!! This means he should be able to go on and beat Red. This is a great proof of concept that means the game can be fully beaten like this.
Not completely true, Mitjitsu - TASes formally submitted to the site should use all TASing tools available, but TASes that simulate perfect real time play or have other restrictions or just show off glitches/tricks/techniques are very useful for study, analysis and improving real time speedruns, and are very welcome in the forums.
It's usually inspiration/serendipity/random chance/poking and prodding at everything you possibly can.
But you want to try and do things like
-use illegal items, abilities or combinations of items/abilities ('glitch' moves and pokemon that aren't assigned to real things in Pokemon, illegal combinations of beams in Super Metroid, attempting to stun an unstunnable sprite in Super Mario World)
-do illegal state changes, or an illegal state change + mode combo (turn into stone while entering water in Kirby's Adventure)
-...
But even knowing how memory corruption/arbitrary memory glitches happen can't tell you how to find one, you just have to learn as much as you can about the game and try everything you can and try harder at everything that looks promising.
It's sometimes said that the games with memory corruption glitches only have them because enough people looked at them to find one. Maybe almost every game has one and is waiting to be found.
