Am I allowed to disagree with what you deem to be the endpoint? I think unlocking the ending is pretty clearly the end of the game. There isn't any gameplay after that either. It seems pointless to go back and skip through the cutscene
The movie must be complete Your submission must play the game from the beginning, and must finish the game, or reach the most suitable endpoint the game allows. [...] Examples of suitable endpoints are:
- A definitive ending, such as a credits sequence.
These messages tell you that you've actually played the game "til the end" and "finished" it. Showing them subjectively feels appropriate for a game titled Unlock Everything.
While the credits don't automatically start, I think a perfect way to end the movie in a climactic (and definitive) way is to manually launch them at the end.
If showing the ending dialogs is valuable as opposed to skipping them, we can have an alternate movie for encoding that doesn't skip anything but slowly goes through those dialogs.
Go for an "as pure as possible" approach, removing savestating, slowdown and/or RNG pathcing
or take the opportunity of being allowed to modify the game and make a pleasant TASing experience?
The game also uses multiple rng variables:The world RNG is somewhat tricky as you have to watch out to not disturb world generation, but make block RNG deterministic... But the main thing I am getting is that I should rethink my RNG patching, which I will gladly do...
- Each entity has their own RNG that they call
- A "World" RNG that is responsible for chunk generation as well as block RNG
That was it - I had foreground_sleep_ms 2, while you had foreground_sleep_ms 5.
CD loading times in particular seem to present a difficult hazard for TASing, as loading earlier savestates after PCem has started reading from the CD image seems to cause desyncs, and even strange errors from XP itself on some occasions:Running the movie from the very start seems to give consistent timings without errors, but combined with XP's strange lag inconsistencies, it seems game installation in particular is likely to be a pain to optimise.
Plus, besides that, I can't even tell what form your optimization is supposed to be taking just in general from watching the video; I would appreciate a hint, because I can't tell if you somehow managed to cut your jumps earlier or something.
feos: does Adobe Flash Player process user input at its own rate independent of the game's video rendering rate? in the tas world we're used to thinking input polling is connected to video rendering because old consoles were emulated that way, but with PC applications it doesn't look related anymore? context: using autoclickers on pico's school to shoot at 5000fps seems to work fine in FP (but it would need to be verified in some way), so I wonder how FP actually works with this, and is it entirely on games to limit input polling rate in some way? Dinnerbone: I haven't looked into this to give a definitive answer, but in 'modern'-ish software (like FP), input is generally given separately to graphics. You click a hundred times, and the operating system sends one hundred "click" events to the software (ie flash), and that software handles it how it wishes (either by queueing up "I've been clicked" for one big update loop, or more likely in this case, sending each click event to actionscript) Consider a text editor, whether as native software or something written in flash (lol): you type really fast, sometimes repeat keystrokes within a very very short span of time. If input is fixed to graphics, typing becomes "lossy" - you'll randomly lose keystrokes as they happened too fast for it to realize it has them feos: is there theoretically any reason to suspect ruffle is doing anything inaccurate if we crank up libtas to 5000fps and send inputs at that rate, and the game handles it just fine? like if the game has a slower loop for input polling, only some of our inputs would make an effect, but if it's not limited, then all inputs would go through, right? Dinnerbone: I have no reason to suspect anything wrong here. That matches my instincts of what should happen. It would be up to the game in question to be programmed to receive such rapid events, I don't think many flash developers gave it much thought, but there'd be two general groups of games:To my knowledge, we match flash in that we'll send all the events, and what happens next is kinda up to the specific game
- fixed loop games, they have a single "on frame" function that runs once per frame, and in that loop they're asking "is my mouse button down". That'd only handle input as fast as the graphics rendered.
- immediate event callback games, they'd have an "on click" event and they're doing whatever ("shoot bullet") in that method. It can be called infinite times between frames.
That said, I think there are some folks in the HK TAS community who'd be more interested in getting verified in some way, but I definitely don't think the traditional method of TAS verification would work for HK without fundamentally new PC TASing technology (even if it were more reliably deterministic, the slow encode speed is still quite onerous.)
and you need to jump on a high platform, to jump up from it again ASAP. For regular play it feels natural to do regular jumps, and if their height is not enough, do double and triple jumps. But in a speedrun, you end up having too many slow periods in your jumps, because they get slower after the first 3 frames (in our imaginary case), and even slower after the next 4 frames. For that reason, for all the multiple jumps you have to do, you need to test if you can get on the needed platform by only using the fastest segment of each jump (3 pixels per frame), meaning you hit the jump button every 3 frames. If that's not enough, start adding the second fastest segments to each jump until you've exhausted both speeds (3ppf and 2 ppf), hitting the jump button every 7 frames. Only then start adding the 8th frame to each jump (1ppf), and so on.
I haven't done this in my test, because it takes time to figure things out and to test them, while I only needed to try my most basic thoughts on each level, to see how easy it is to improve.
User movie #638328711837129400
Link to video
I ended up saving 00:04.08 seconds, but the jumps are absolutely still improvable. Since most of the game consists of jumping and running, I think the opportunities missed in this submission are significant, and I'd like to see a better movie instead. Ideally one that's faster than mine, even if it's only a couple frames saved in each room.