Submission Text Full Submission Page
Mari0 is a 2012 PC mashup game of Super Mario Bros and Portal. It comes with two sets of levels, one the original levels from Super Mario Bros, and the other a completely new set of puzzle platforming levels inspired by Portal. This TAS takes on the latter set of levels using the "Gelcannon mode" cheat, a feat which has not been completed in the 12 years since the game's release until now.

Game objectives

  • Emulator used: libTAS 1.4.3
  • Aims to complete the Portal mappack with the gelcannon as fast as possible
  • Abuses programming bugs and oversights
  • Abused high frame rates to exploit the physics engine

Comments

The gelcannon mode is considered a cheat, and thus normally is only accessible after completing the game for the first time. However, the cheats can also be unlocked by performing the Konami code (↑↑↓↓←→←→BA) anywhere on the title screen, which is used in this run. (This is what causes the sound effect at the start.) This cheat replaces the portalgun with the gelcannon, an item which can spray gels which cause Mario to bounce or speed up when stood on. This comes at the cost of no longer being able to teleport Mario or other objects around, which has led to this challenge remaining unbeaten despite many attempts by community members and speedrunners.
Continuing on the work started in #8188: lexikiq & WilliamFrog's Linux Mari0 "level editor" in 00:00.01 and #8698: lexikiq & WilliamFrog's Linux Mari0 "level editor storage" in 00:00.01, this TAS is the first full-length Mari0 TAS to utilize high frame rate (500 FPS) abuse. This abuse was necessary to ultimately complete the challenge, however it was also used for smaller optimizations, namely tighter wall clips and faster gel spraying.
The game's physics is directly tied to the frame rate, which is not to say that "higher FPS = faster" (although this is sometimes the case, namely for gel spraying), but instead to say that the game has an update loop which consists of "measure duration of last loop, poll kb/mouse events, perform physics update based on duration, render screen, sleep for 0.001s". This means that, if the game has an FPS of 60, then the physics has a TPS of 60. 100 FPS = 100 TPS, 500 FPS = 500 TPS, etc. (The one caveat is that we can queue up a ton of kb/mouse events at "10bn FPS" in libTAS, although that does not come into play during this run.) The maximum FPS is theoretically 1000 thanks to the 0.001s sleep, although this version of libTAS was adding extra lag frames when I tried to go that high, so in this TAS I use 60 FPS for the "basic" movement and 500 FPS for the "tighter" movement and exploits.
The inputs in this TAS were written solely by lexikiq, however this TAS could not exist without WilliamFrog who developed most of the strats and techniques seen within the run, including the big final one which allowed this run to finally be finished. We were in close communication throughout the entire creation of the TAS bouncing ideas off each other. Shoutouts as well to Masterjun who did not have any involvement in this run but whose strategies continue to be relevant, or at least on my mind, to this day.

Stage by stage comments

Title Screen

To even begin the run, we first have to perform the Konami code! This is a bit slow, as while most menu inputs accept multiple keys ("w" and "↑" for up), there aren't exactly multiple A or B keys on a keyboard, and we can't interrupt the sequence with other button presses. Once the sequence is done, we quickly select the Portal mappack, manuever down into the options and select Gelcannon mode, then navigate back up to start the game.

1-1: Puzzle 00

The first level of our run starts off fittingly simple as we're introduced to the very basic mechanics of the gels. Holding left/right click on the mouse will spray blue/orange gel. Orange = fast, blue = bounce ... and also fast.
Orange gel is simple enough to explain: while on the ground and holding sprint, your acceleration rate and maximum horizontal velocity will be increased. Specifically, your normal velocity limit of 9 units/second while sprinting is increased all the way to 50u/s, although you will eventually run faster than you can place the gel, practically capping our speed at around ~30u/s for the run.
Blue gel on the other hand is a little more complicated. It's best known for inverting your vertical velocity when you land on it (so your 50u/s becomes -50u/s, flinging you away from the gel), however it also possesses some other more broken uses. We'll get to those as they become more relevant.
For now, let's actually tackle the puzzle 00 play-by-play: Mario accelerates at a rapid pace, then jumps and bonks his head so as to perfectly fall into the gap with enough downwards velocity to land on some blue gel then come ricocheting back towards the button with which he can place a cube to open the first door. Incredible!

1-1: Puzzle 01

And the first level of the run ends fittingly complex. The fact that the very first level of the mappack requires some precise glitches should start to illustrate why this challenge has never been completed before! (Though, to be clear, humans have performed everything up to the final level.)
The normal solution to this puzzle involves placing a cube on the top button and ourselves on the bottom button, opening both doors and allowing us to shoot a portal through them to teleport ourselves to the end. Unfortunately, we do not have a portal gun, so we must instead clip through the wall, which introduces quirk number 1 of blue gel.
When Mario collides horizontally with blue gel, it sets his horizontal speed to around 15 in the opposite horizontal direction (more on that later) and 20 going upwards, and then updates his position. This sounds fine, however the game has already taken Mario's speed from the beginning of the frame and used it to identify every possible tile he could collide with. Now that his speed has increased, it doesn't know that there are new tiles that he could collide with, meaning he can now freely move into tiles that were previously just out of his reach! This behavior has various ramifications, primarily for mods of the game with complex interactions, but in this case it allows us to clip into ceilings next to walls using blue gel.
Once inside the ceiling, we enter an Out of Bounds state (referred to by some in the community as "wall sliding"), in which Mario is allowed to have vertical control and momentum, but not horizontal. Instead, Mario is constantly pushed at a rate of 4 units per second in the direction opposite the way he's facing (i.e. moving away from the mouse), which one might expect would help to push him back in bounds. However, we simply look at away from the flag, so that Mario is pushed towards it. Genius. This allows us to skip past the impenetrable doors, and thus we finish our first full level.

1-2: Puzzle 02

Alright, let's speed things up a little bit! This puzzle is intended to be solved by climbing up to a button with a portalgun and a light bridge, however we still lack a portalgun, so we bounce up instead. The only notable new trick here is that we can pick up cubes through walls, ceilings, frankly just about anything (as long as you aren't standing in an Emancipation Grill, but that doesn't really come up in this run). The way this works is very simple, the game just does not check any of that stuff! All it does is project a square a short distance in the direction you're looking, and if a cube or a button is in that radius, it picks it up or presses it. Pictured below is a visualization of the grab radius.

1-2: Puzzle 03

The first part of this puzzle requires you to pick up a cube to protect you from the lazer, which we do as intended. We play around with the cube a little bit, demonstrating that its speed is preserved when picked up and dropped again. This trick is useful in the portalgun TAS as we can invert its momentum with a pair of portals and then fling it into our feet to jump in midair, however we have no such means of inverting the cube's momentum here.
The second part of the puzzle I believe is supposed to be solved by putting the cube atop the leftmost closed door and then standing on the button, however most people just solve it by dropping the cube as they jump into the button hallway. We choose the third option of just skipping all the fluff and bouncing right into the hallway.

1-3: Puzzle 04

Oh my, a real gel puzzle!? Yep, the Portal mappack does actually use some gel dispensers, which you can maneuver around with the portalgun. However, we are clearly superior as we can put our gel anywhere we want! Before we do that though, we first have to build up speed. And I mean a lot of speed. As promised, we're finally getting back to the last quirk of the gels. But first: can you spot the logic error in this code block!? This is the real code from the game, however it has been slightly cleaned up for brevity, and comments added for clarity.
-- From mario:leftcollide, Mario just collided with the left side of a tile.
-- Does it have gel on it, is he in the air, and does he have some speed built up?
if tile["gels"]["left"] and (self.falling or self.jumping) and self.speedx > horbounceminspeedx then
	-- Yes, yes, and yes! Let's update his speed!
	-- First let's set his speed to -15 or a factor based on his current speed, whichever is lesser.
	self.speedx = math.min(-horbouncemaxspeedx, -self.speedx*horbouncemul)
	-- Then let's ensure his upwards speed is at least 20.
	self.speedy = math.min(self.speedy, -horbouncespeedy)
end

-- From mario:rightcollide, Mario just collided with the right side of a tile.
-- Does it have gel on it, is he in the air, and does he have some speed built up?
if tile["gels"]["right"] and (self.falling or self.jumping) and self.speedx < -horbounceminspeedx then
	-- Yes, yes, and yes! Let's update his speed!
	-- First let's set his speed to 15 or a factor based on his current speed, whichever is lesser.
	self.speedx = math.min(horbouncemaxspeedx, -self.speedx*horbouncemul)
	-- Then let's ensure his upwards speed is at least 20.
	self.speedy = math.min(self.speedy, -horbouncespeedy)
end
If you said "the game attempts to set a maximum speed of 15, however the left-facing collision erroneously utilizes the math.min function which instead ensures a minimum speed of 15", you're a nerd! And you're right! In other words, if we're low on speed and next to a pair of walls, we can slam ourselves into the left-facing wall to immediately increase our speed to 15, then slam into the right-facing wall and perfectly preserve our speed going in the right (literally) direction.
That's everything you need to know about gels! Now onto the puzzle and... yeah after that it's as simple as bouncing off some blue gel over the pit. Okay, we're actually very carefully manipulating our speed to cross the gap without bonking into the random overhang in the ceiling. In fact we're actually starting to abuse high frame rates for the highest physics precision possible to ensure we don't hit the corner of the overhang (which would actually teleport us to the left as the game tries to help ensure we don't bonk our head, but we don't want that here) and even to barely sail past the corner of the floor before the overhang. All this was done to barely hit the first cube cycle in Puzzle 05...

1-3: Puzzle 05

...which we did not even wind up needing! Yep, turns out that turning around and losing all our speed falling back in the pit and pressing the button and waiting for the door to open (it's fully solid for the entire opening animation) is slower than just clipping into the wall, which was kinda a bummer after spending so long trying to hit the first cycle but hey we saved some frames anyway! At least we get to close out with another stylish double blue gel bounce, which is another instance of Mario instantly increasing to 15 speed.
It's also here that we begin a streak of finishing levels faster than the portalgun TAS, as we clock in a time of 5.95s (vs PG 7.32)!

1-4: Puzzle 06

You know almost all there is to know at this point so I won't belabor too much. This puzzle is intended to be solved through an elaborate series of portals, however once again we lack that, so instead we do a quick clip into the wall. We grab the cube for fun, although we don't end up needing it thanks to a new strategy unique to this run!

1-4: Puzzle 07

In skipping 06 we also skip 07. It's just another series of portals. Moving on!

1-4: Puzzle 08

In previous TASes, we would smuggle a cube through the Emancipation Grill by dropping it before it gets erased from Marios hands, but after Mario is far enough forwards that the cube simply gets placed beyond the grill's hitbox. However, doing this would inevitably require that we waste some time and speed running into the cube, which surely cost us hundredths of seconds, so we went back to the drawing board.
There's a somewhat rare mechanic in the original Super Mario Bros as well as Mari0 that allows Mario to run across small gaps by snapping him to the top of the block if he hits the side of the block with downwards velocity within 1.2 pixels of the top. This alone isn't quite useful, but if we combine it with our prior knowledge about how collisions aren't checked mid-frame, then we can find something special. Namely, if Mario is traveling at 15u/s or higher, then the snap will place Mario inside a door on top of the block! If you remember, that's exactly the speed we get from doing a double wall bounce! It's easier said than done though- we had to utilize high frame rates to perfectly release our jump so that we would be going downwards and collide perfectly with the tile, placing us into the door and sailing right on through.
Interestingly, clipping into objects does not exhibit the same "wall sliding" properties as clipping into tiles and I'm not especially sure why! I asked William and he said:
idk it's just not scripted to. It's not a universal behavior, Mario is written to do it specifically with tiles.

2-1: Puzzle 09, 10, & 11

Alright, I promised shorter explanations so here's a quick one. We finish all the puzzles in 2-1 just about as intended (at least, as intentional as we can get for the gelcannon), although we do utilize high frame rates to cut some close corners exiting puzzle 09 to carry through as much speed as possible.

2-2: Puzzle 12

Ah, an autoscroller! The least interesting level, or is it? There's actually a little bit to say here. We start out by increasing the frame rate to spray orange gel faster than we can run on it. We then clip into the wall, ignoring the moving platform down below. The speed of the moving platform is only 3.75u/s, which if you're great at remembering numbers you'll note that that's barely less than the 4u/s speed of wall sliding, hence why we opt to skip the platform. As we skipped it, we needed to perform a very very tight bounce off the walls coming out of OOB which is only barely possible thanks to briefly increasing the frame rate.
We then do some quick movement upwards with the blue gel, run forwards with more high FPS orange gel spraying, and finish off with one last wall clip to finish our autoscroller skip.

2-3: Puzzle 13

This puzzle is intended to be solved by dangerously opening the doors with some lasers. We have two main options for skipping past this puzzle, either clipping into the wall or into the doors. As mentioned earlier, the latter allows us to preserve our horizontal speed, so it was our prime choice.
If you look closely you'll notice I actually bounce around the doors 3 times, as I wasn't able to perform 2 clips back-to-back. However I believe I would have hit the wall if I did get the back-to-back clips, so it worked out.

2-3: Puzzle 14

We were somewhat close to organically triggering the gap snap code, however we fell a bit short (pun not intended). I did however stumble into a door clip that quite confused me, though William later explained:
The clip is [a] glitch resulting from collision priority; if you're going fast enough, you're able to hit the door instead of the block above the door, putting you inside the block [...]

It requires more than 15 speed but becomes increasingly precise the slower you're going

Notably the speed threshold is almost the same as the [gap snap] clip from earlier, except that one works with exactly 15, and doesn't change in difficulty past the threshold speed

Mechanically though they are very different
And later elaborated:
An interesting note on this door clip; the collision priority lets you into the wall, and then you slide into the door. An unusual detail of wall sliding is that it ignores edge collision, and will put you inside objects... but you won't slide once you're in. This is because mario has a flag to ensure he only wall slides once per frame, which curiously will be activated by being inside objects that don't cause him to slide, essentially nullifying it.
Fun trivia!

2-3: Puzzle 15

This puzzle involves some sort of shenanigans with portals and light bridges but we simply build up speed (yes, more high FPS spraying) and jump past it. From here we could either clip through the wall, or go for the much snazzier and slightly faster series of blue gel bounces off the walls.

2-4: Puzzle 16

Everything here should be somewhat familiar by now: blue gel bounces up the tower, clip into the wall to skip an impossible jump, build up speed, etc.
The pace slows down considerably at the upside-down-U room, as the transparent light bridge which allows the normal completion of the puzzle actually hinders us, as we are unable to spread blue gel on it to bounce off it. We thus slow all the way down to bounce off the left wall instead.
Disappointingly to me, we then perform another wall clip which wound up being slightly faster than bouncing out of the U, and then chain it into another clip past a door we cannot open (quickly).

3-1: Puzzle 17

Finally, we arrive at the final boss- oh, sorry, I forgot there's a short little puzzle at the start. Yeah it's supposed to be a timing challenge (the goomba opens the door to the lasers, allowing you to fling to your death) but you just hold Run+Right and bonk on the first door, since as mentioned earlier the door remains solid for its entire opening animation. Maybe the plan was to change this before release and it never happened? Not really sure why there's two doors at all quite frankly. Oh well.

3-1: Puzzle 18, as of October 19 2024

The following passage refers to an outdated version of the TAS and is left as it was written. See the following heading for current information.
Finally, we arrive at the final boss. Everything up to this point has been completed by a human in some form, but a solution to Puzzle 18 has eluded the community for the past 12 years. To our knowledge, there is no way for a human to bypass both the lasers that block the entry into the test chamber with only a gelcannon. However, it has been known since at least April 2023 that you could abuse collision priority to clip into this wall to bypass the first laser.
From here your options are slim. You can either clip through the door, and die to the second laser...
or clip into the middle of the entry room, and die to the second laser.
There's no way to clip past the lasers. The next logical option is to clip into the chamber underneath the goomba room, but unfortunately both the floor and the ceiling in the goomba room are only one tile thick, meaning the vertical speed from the blue gel clips will force us into and then on top of the goomba room instead of letting us into the test chamber. Besides, our odds of jumping across the left edge of the laser from 0 speed aren't very high. But surely once we're on the roof we can just fall through the "transparent" cube dispenser object, right? Nope, our gel may pass through it but Mario may not. And with not a single wall or truly anything else in sight- hell, we literally can't see anything without a camhack, it really does seem like we've come to the end of the road.
That is until June 2023 when I interrogated William on everything he knew, and he let loose one last crazy idea.
So [through] real time fps manipulation, you can gain height purely by bouncing on blue gel; doing this above the map would eventually give you enough speed to clip back in bounds
Bingo. So, the plan was simple. Clip on top of the map, then immediately toggle into 500 FPS, frame-perfectly switching to 60 FPS to increase our vertical... hm, well, I suppose the plan is not so simple. There's actually a decent range of frames in which we can toggle back the FPS. If we toggle at the beginning of the range, we'll get an increase to our height. If we toggle at the end of the range, we'll get an increase to our speed. Which do we optimize for? Well, here is when Masterjun would bust out some fancy graphs. Unfortunately, when asked for comment, Masterjun replied he was busy "watching tiktoks" and did not know who Mario is. Fortunately, I had William on call instead to calculate some numbers, to which he returned this:
Supposedly this proves that optimizing for speed is better in the short term, but optimizing for height is better in the long term, and boy howdy are we in it for the long term.
So, with all that sorted, I modded the game to move the camera just a bit upwards so I could see what I was doing (fun fact: the whole screen is rendered all the time, I just shifted the render down), and strapped in for the long haul. 46 frame perfect height increases later, we finally hit 78.1666667 speed approaching y=-2, at which point we could toggle our FPS back to 60 one last time to clip back into the map on top of the door to the finish. From here, there's a little bit more out-of-bounds movement to perfectly clip into the door, followed by a little splash of orange gel to quickly reach the flag, with input finishing at 3:58.12. (Technically input could've ended a little sooner but I didn't want Mario to slowly crawl into the finish after all that work okay!? We settled for earliest input end that achieves the fastest RTA time.)
It was later discovered that the 78.1666667 figure was erroneously accounting for gap snap code, which is disabled on the top row of blocks. The actual required speed was only 73.6666667, which may have saved a bounce or two, bringing the level time just under a minute.

A New Discovery

Remember "from here your options are slim"? It turns out there was a secret third option. Before we get to that though, we should explain how to even clip in the wall there.
Ironically from my earlier comments, the timing puzzle actually becomes a little relevant here, as we are once again abusing collision priority which requires the goomba's door to be closed. We use the Aerial Faith Plate to bring us up to clipping speed, then collide with the door to clip into the block the same way we did in Puzzle 14. To get the perfect trajectory into the intersection of the door and the tile, we jump at the same time that we get launched by the faith plate, and hold it for about 0.06s before releasing. As Mario experiences gravity >50% less while jumping, this increases our vertical momentum, allowing us to bonk the top of our head on the bottom of the light bridge, sending us downwards at the perfect angle to clip.
Now that we're in, we need to revisit a brief trick that was brushed over earlier:
we're actually starting to abuse high frame rates for the highest physics precision possible to ensure we don't hit the corner of the overhang (which would actually teleport us to the left as the game tries to help ensure we don't bonk our head, but we don't want that here)
It was somewhat known that you could use the narrow gap in the rightmost chamber of the puzzle to perform a clip into the wall separating you from the finish flag. However, it was believed that it was impossible to make any progress from this clip as there is only one tile you can bonk your head on, but at 60 FPS you won't get very far into the wall, and even if you do the game will just always assume you're trying to jump out from the wall and nudge you back in-bounds instead of bonking you. (You can see the nudge being used intentionally at various points in the run, namely to exit the wall quicker at the very end of the TAS.)
However, upon sending this submission draft to William to fact-check, he remembered this third option and started playing around with trying to clip in using FPS manipulation. At 4am EST on October 20th, he urgently texted me a video of himself using hacked speed and coordinates to clip into the rightmost wall and beat the level, theoretically saving a minute over the TAS.
So how exactly does this work? It's fairly simple in concept: he used 500 FPS to approach the right wall, then immediately after getting bounced by the right wall's blue gel he went up to 60 FPS to get the deepest possible bounce off the left wall's gel into the right wall's OOB, then went back up to 500 FPS so that the physics would be precise enough to not assume he wanted to nudge out of the wall and instead allowed him to bonk against the ceiling, keeping him in the wall and pushing him to the finish.
In practice, the trick was harder to execute, as there is a very small range of Y values from which the first bounce must be initiated to clip low enough into the wall and succeed, as well as a very small range of X values which can perform a deep enough clip and succeed. Regardless, after a few hours of attempts, I was able to score a 2:59.76, which I later micro-optimized down to 2:59.72 thanks to brute forcing some values within the tight X,Y range. As before, we optimized for RTA time first, input time second, for better aesthetics.

Author Comments

That's it! You now have a PhD in Gelcannons! I'm very happy to see this challenge finally be completed after it was debated in the community for so long. I (lexikiq) don't see much further to go with unique challenges in this base game, besides revisiting old TASes with new FPS manips and brand new tricks discovered by William. There's the other cheat modes like Minecraft mode but they aren't especially interesting. So, if this is the end of the road, I'd like to say I'm thankful to everyone who contributed to the Mari0 TASing journey from dwangoAC for kickstarting all this to kilaye fixing libTAS issues to Maurice supporting libTAS to Masterjun for truly innovating on the speedrunning scene to William for his unending research on the game to MM102 for the original tasb0t mod to everyone else who's had a helping hand. As Mario would put it, Thank you so much for to playing my game!
And now for some closing words from some others:
  • WilliamFrog: "It was a lot of fun working on this run! We got to show off many innovative techniques, and conquer a decade-old impossible challenge in the process. Even though the (far more theatrical) OOB bounce strategy didn't stay relevant long, it was worth it for the meaningless achievement of beating the portal tas in the end."
  • Masterjun was asked for further comment and said we could make up silly quotes asked if we've seen the latest "Super Moo Deng World" TikToks
  • Maurice, the developer, was unable to be reached prior to publication. I believe he no longer really wants to hear about this game which is totally fair, but we remain thankful for his work on making the game able to be TASed!

Comparison

Remember that winning streak against the singleplayer portalgun TAS I mentioned earlier? By the end we wound up with quite the winning streak, beating out the portalgun TAS overall! Of course this is a cheat so neither category could obsolete each other, and besides the singleplayer TAS has been obsoleted by the multiplayer TAS anyway, but it's still fun to compare.
Level3809M3894M9355S
1-12.32s2.08s5.91s
1-25.875.166.58
1-37.325.815.95
1-412.139.166.62
2-18.076.966.22
2-222.3520.9320.84
2-38.136.947.37
2-48.756.737.88
3-15.354.597.15
Total1m20.29s1m8.36s1m14.52s

Future Improvements

The quality standards of the run increased as it went on due to new techniques and strategies being tested, discovered, and shared. Thus, some earlier levels are known to have optimization opportunities from increased FPS, however they are on the span of hundredths of seconds. These include tighter wall clips, faster gel sprays, and faster menuing on the title screen. Due to RNG and floating point errors, adding these micro optimizations in late proved to be quite challenging, and thus has been left for a future exercise.

Regarding Emulator Choice

On my WSL2 machine, libTAS v1.4.1 experiences odd issues trying to render the game, and v1.4.2+ experience memory corruption issues when loading a savestate, so this TAS was created on an in-between commit 9d3a9b9f which was created after the rendering issues were fixed and just before the savestate issues were introduced. Fortunately, I have confirmed the TAS to sync on the stable release of v1.4.3 on Ubuntu 20.04 and 22.04. Earlier libTAS releases are incompatible with newer Ubuntu versions, and later releases desync (I'm guessing due to changes to variable framerates).
For more information on syncing, consult the Annotations!

Regarding Category Choice

Although this is a niche category, I believe it to be distinct enough to be worthy of publication as it is a full completion of the game using a novel cheat.
Frame 13232 is arguably the most important frame of the entire run but anything in 3-1 probably makes for a good screenshot.

feos: Claiming for judging.


TASVideoAgent
They/Them
Moderator
Joined: 8/3/2004
Posts: 15632
Location: 127.0.0.1
Patashu
He/Him
Joined: 10/2/2005
Posts: 4045
Love TASes of previously never completed categories, and some fun speedtech in this one. I do have one question. If a human wanted to replicate swapping between 60 and 500 FPS mid run like this TAS, what would they have to do? Or is this an artifact of libTAS letting you change it mid-run and not human-viable?
My Chiptune music, made in Famitracker: http://soundcloud.com/patashu My twitch. I stream mostly shmups & rhythm games http://twitch.tv/patashu My youtube, again shmups and rhythm games and misc stuff: http://youtube.com/user/patashu
lexikiq
She/Her
Active player (459)
Joined: 8/13/2018
Posts: 110
Location: United States of America
Great question! It's not totally impossible for a human. I made an update to the game earlier this year that allows you to run the game at a fixed dt, but this doesn't allow you to change the dt mid-run (maybe worth considering?). I believe in William's video at the bottom of the submission, you can see him pause the game and then use an external software like NVIDIA Control Panel to lower the FPS, which is a good option to use with pause buffering. If that's a bit cheaty for you then another method I know of is simply to wiggle around the game's window(!), which artificially delays the game's execution and triggers it to run a frame at the minimum dt, which I believe William used to demonstrate a proof of concept for the original 3-1 speed building strat! (Can't find that video now though, may have been in voice chat)
mohoc
He/Him
Reviewer, Active player (250)
Joined: 5/20/2018
Posts: 41
Location: France
Hi lexikiq. I was able to sync your movie on libTAS v1.4.3. To sync verify it, all I have to do now is determine the game version. Right now there are two versions with identical name, region and version number (see game page Mari0). Only their hashes differ. Do you know which version is correct and which file the hash refers to?
lexikiq
She/Her
Active player (459)
Joined: 8/13/2018
Posts: 110
Location: United States of America
Both of the hashes are for random compilations of the LÖVE game engine lol, apparently 11.2 according to the publications they're attached to. So not really sure which is more correct, probably both should be merged to the actual hash for the mari0-1.6.2.love game which would be 2f5105322ec98d2b3378867f46ebafd4 (found by downloading the archive zip from GitHub, unzipping it, then zipping the nested folder contents and hashing that). EDIT: Zipping will generally cause an unreproducible archive/hash; a more reliable method is to use a specific command, namely zip -oXrZ store ../mari0-1.6.2.love . which disables compression and most timestamps, producing a result of 9dd0d0f531d50bcec5059f9e8704a82f MD5 and 5fffef84419c17acfb6e691d6a739d2f3cff1a17 SHA1.
Site Admin, Skilled player (1255)
Joined: 4/17/2010
Posts: 11495
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
lexikiq wrote:
found by downloading the archive zip from GitHub, unzipping it, then zipping the nested folder contents and hashing that
Sounds like what we have a Notes field for on game versions, where we can list hashes of individual files constituting the game.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
lexikiq
She/Her
Active player (459)
Joined: 8/13/2018
Posts: 110
Location: United States of America
... is that something I can do? 😅 I don't believe I've seen any such option... EDIT: discussed in the Discord, seems like everything is resolved! Settled on just using hashes of GitHub's archive ZIPs as they are (admittedly reluctantly) stable for hashing.
Site Admin, Skilled player (1255)
Joined: 4/17/2010
Posts: 11495
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
This movie is another weird case we don't have a solution for, and I have doubts a proper solution is possible. If the game allowed changing framerate on the fly like HalfLife does via its console (which considered an intended tool for normal play), then it'd be perfectly acceptable. If unthrottled framerate was available with VSync off like in some other games, then it could be argued that the host can be configured in a way that makes this specific high framerate technically possible as it normally fluctuates. But for techniques only available by introducing external applications into the mix, it becomes much less clear.
  • libTAS has variable framerate functionality and it can enforce it upon a target program without asking questions: it kinda forces VSync to different rates that the user controls.
  • Doing something specific with NVIDIA control panel while the game is running can't be recorded into a libTAS movie (though it could be recorded in a theoretical QEMU movie when we're emulating the entire guest machine for our game), and it definitely sounds like something that's impossible for the original game to account for, making it an unintentional environment tweak.
  • Wiggling the game window around relies on event handling in a given window manager I guess, so again a dependency on a factor entirely external to the game.
Old movie rules allowed unintended environment settings only in entertainment-based categories, because for pure speed records those contain legitimacy concerns. Current rules don't have this distinction and ban unintended environment settings altogether, however that's not fully intentional in itself either: after the rules were completely rewritten, we tried to keep the wording compact and to not expand it without explicit need. So obviously there's room for rule changes or at least clarifications here. The problem is that it's hard to come up with a good compromise for this kinda thing. We've been discussing this issue for 6 years now, and it's always a battle between legitimacy and creative freedom. Banning such techniques from the Vault tier Standard class used to be a decent compromise not relying too much on technical differences but more on bookkeeping differences. Obviously it's still an option today. Another option is preserving this technique until the game officially supports variable framerate and only using the movie with constant framerate this time around. There can be other options, but this entire subject is so odd, technical, and obscure, that every time I brought it up with staff I got different opinions. And we have two more high-framerate movies waiting to be judged, because this is not resolved yet.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
lexikiq
She/Her
Active player (459)
Joined: 8/13/2018
Posts: 110
Location: United States of America
The frame rate discussion is one I foresaw and certainly a valuable one. I won't claim to have any solutions, but I do believe I have some things to add to the table:
feos wrote:
If unthrottled framerate was available with VSync off like in some other games, then it could be argued that the host can be configured in a way that makes this specific high framerate technically possible as it normally fluctuates.
This is in essence how the game is configured by default. It has a VSync setting which defaults to off, and allows essentially unthrottled FPS, aside from an engine limitation (and resource saver) that caps it around 500-1000 FPS as mentioned in the submission. (EDIT: it's also worth mentioning that the game enforces a minimum FPS/TPS of 60, to ensure the player does not fall through the floor when the game lags) There is additionally a VSync option you can use, which now that I've given more thought I've imagined a slightly more reasonable solution to than using the NVIDIA control panel: you could enable VSync, then simply pause the game and switch your monitor's FPS as necessary, then unpause and repeat. Much more system-agnostic, though your available FPS options may be limited? Of course this isn't directly related to the TAS but it would be one way to justify this as being a reasonable thing to use in a TAS, as it could conceivably be done RTA.
feos wrote:
If the game allowed changing framerate on the fly like HalfLife does via its console (which considered an intended tool for normal play), then it'd be perfectly acceptable.
In my last correspondence with the game developer, I discussed modifying the game to be more consistent for speedrunners, he seemed interested and suggested:
Maurice wrote:
feel like if you wanna make something for speedrunning, you should change the game to a fixed timestep
Which would pave the way towards modifying FPS- er, TPS- during the game, though this has not yet ultimately come to fruition as PRs are not currently being merged, though I could see this conceivably happening one day.

1734977120