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.
Can a TAS of a simulated pinball table be considered an actual TAS of the game itself for cataloging purposes, or is it only a TAS of that particular simulated table? If a TAS of a simulated table is considered a "real" TAS of the actual game, should different versions of the reproduced table be considered different game versions?
What is considered "accurate emulation" for a simulated pinball table? (In this case the Baby Pac-Man table is accurate in physics as far as I can tell, but that might not be the case for all tables).
How do deal with the difficult reproduction/syncing workflow? To elaborate: files required for pinball simulators and VPinMAME cannot be found in the same places as ordinary ROM and emulator resources. The tables themselves are particularly problematic, as in addition to containing the original manufacturer's copyrighted cabinet artwork and thus being unlinkable, they also contain the original work in physics parameters and scripting by the person who performed the recreation effort. As such, rehosting these tables is not allowed, and the original sites that host them require registration in order to download files. Basically, finding the required files independent of any direct aid (which would be prohibited by site rules) is a hell of an adventure, to say the least.
Hardest cycle: In Baby Pac-Man, there are only 3 unique mazes; however, at a certain point some of the inner maze walls become invisible, and then eventually they all become invisible, thus defining the point at which the game has reached its hardest difficulty and exhausted all (maze-related) content. However, this goal is not preferable, as it means that time saved by acquiring energizer pellets in the pinball portion becomes highly tenuous, if it saves any time at all, and if the pinball portion is never entered then that means there's no point in not just emulating this via MAME or PinMAME running standalone.
Score attack: In Baby Pac-Man, the score counter can reach up to 10,000,000 points before rolling over. This offers some interesting TASing potential, allowing for more time spent in the pinball portion for acquiring energizers and advancing the fruit. However, it also risks meeting the goal before all unique content has been exhausted, as the fastest way to reach high-score could potentially entail not reaching the final, all invisible walls maze.
"100%"/All bonuses: There are three types of bonuses in Baby Pac-Man; up to 4 Energizers per stage, the Banana as the top-tier fruit (requiring advancing the fruit 7 times), and a maximum tunnel speed of 8 (also requiring advancing the speed 7 times). As such, it is possible to construct a goal of reaching the hardest stage while maxing tunnel speed, acquiring all energizers, maxing out the fruit type, and finally collecting at least one fruit per stage, thus offering a balanced combination of pinball play and maze play. This is the option I'm currently leaning towards, but it also could potentially be considered arbitrary, hence asking for judge input.
