I can't tell if you followed the guide to running ScummVM titles or not.

Part of the reason I bring this up is because you have ScummVM's menus visible for a frame of that provided encode and not the splash.

ScummVM itself can have different layouts and I know that as my Linux distro does not have your layout, my options are at the bottom, not the side.

And as a bit of a nitpick. You should've done Global Options > Graphics > V-sync Off.

For future reference in regards to the splash: Game executable: /usr/games/scummvm Command-line options: loom-ega

Instead it requests the Judge/Publisher to make sure to adjust their keybindings to add two key strokes.

Personally I believe you should've actually messed with JPC-rr instead.

I specifically asked in the discord if what I'm doing follows the Rules or not, but I sadly didn't get a single response after several days and decided to go ahead

If you have any questions that this page does not answer, or if you are unsure about the presence or absence of a rule, ask a Judge on the forums or reach out to us on our Discord server.

Yes, precisely, because to the best of my knowledge that's the only way to disable vsync on a clean install.

Now obviously Discord is mentioned there, but only as a secondary resource, due to its live chat nature, which makes it impossible to use as a general future reference, so forum is preferred (and more visible to judges).

We don't count prior configuration as having played the game, because sometimes it's impossible to TAS it without initial tweaks (and because you haven't played the game).

To me that is "messing with ScummVM" to the same degree as I do, in both cases the original configuration is changed.

Well, it's a clean install of the scummvm version I specified on a clean install of ubuntu.

that's precisely what I CANNOT do, because it doesn't turn off vsync. Unless I'm misunderstanding. If there's a way to disable Vsync on startup without messing with configs?

The reason I upped the framerate is because you can actually play the game like this, that's the whole point. This is what it looks like when you play the game on a fast machine with vsync off.

So your example and reasoning is a bit more of an Apples to Oranges comparison.

The difference as well is more in line with what you did won't cross sync. My bottom layout of ScummVM's settings is actually from a clean install and that's how it basically arrived for me. The other part about a fresh install of Linux/Ubuntu really doesn't matter. We've been publishing Linux TASes for a few years now, the thing that matters most is going to be the System Time and matching versions.

You would have to do (within libTAS) Settings > Runtime disable "Prevent writing to disk" (then reenable). Modify the settings, then should be golden.

The comments that were related to Vsync off and JPC-RR is mashed here with only one bit highlighted.

It doesn't though. "Fast Machines" would only get this performance if the CPU was overclocked.

If this used JPC-rr then you're essentially using a validateable and provable system that is essentially using an actual powerful DOS system.

Disabling ScummVM's Vsync leads to future issues where it can lead to other systems that it supports with a major advantage that it should not have.

Yet, one argument for keeping the restriction is that allowing things to be TASed at whatever settings an emulator is capable of producing could someday lead to runs that are simply so fast that little to nothing of the game is even seen at all in the resulting run/video.

so fast that little to nothing of the game is even seen

Was disabling v-sync even possible in the original game

In the past, we have basically required DOS games to be TASed using settings for the emulated PC that would have been roughly equivalent to real systems around the time a game was released.

would a PC around the time that Loom was released be able to match this kind of speed running the game natively in DOS

EDIT: For what it’s worth, I actually enjoyed watching this run.

Yet, one argument for keeping the restriction is that allowing things to be TASed at whatever settings an emulator is capable of producing could someday lead to runs that are simply so fast that little to nothing of the game is even seen at all in the resulting run/video.

and wouldn't that be hecking amazing? Wouldn't that look so cool? Imagine having a second version of the Olympics where doping is not only allowed, but all kinds of drugs actively encouraged, taking off all guardrails to find out "okay, but how fast can we REALLY go?"

Regarding the concerns about comparing these to each other, I agree that if the framerate is choosable, the "number of frames" is no longer a good measure of the length of a TAS, but the length in seconds, calculated as (chosen framerate)*(number of frames) is now a metric that can be measured to arbitrary precision and used as a comparison in a potential "choosable framerate" category. So you could try to get a better run on 2000 FPS because it reduces the animation time, or on 500 FPS because the mutliple-second-waiting-sessions will have fewer frames.

In the past, we have basically required DOS games to be TASed using settings for the emulated PC that would have been roughly equivalent to real systems around the time a game was released.

Is that written somewhere? It has been very tedious to find exactly which sets of rules apply to your run and where to find them. Can you kindly provide a link to that? All I found was https://tasvideos.org/MovieRules#GameplayMustBeAccurateToHardware Which states that "environment settings explicitly supported by the game or its documentation are allowed"

The ScummVM documentation however specifically mentions the "really REALLY fast mode" you get by pressing "Ctrl + g"

This makes it the second piece of positive feedback, together with 1 negative vote and 78 views on my unlisted video of people who watched it but didn't dare to vote at all.

I'm a bit afraid this means we have reached everyone who had an opinion and was willing to share it. If this is the last voice before a judgement on whether I'm allowed to continue on this or not, any chance that, even if not allowed in general, we make this a test case and see how it goes? And to avoid opening floodgates, a restriction like "if you submit an uncapped run, you must ALSO submit a capped run."?

If that mode exists in the original game then it feels legit.

darkshoxx wrote: This makes it the second piece of positive feedback, together with 1 negative vote and 78 views on my unlisted video of people who watched it but didn't dare to vote at all.

Forum is not very active lately.

But in any case, we can't rush this, and we don't want to act in a "deal with it" manner, so we're going to need more time on this and the other submission before anything can be decided.

At first I thought there's some C' f g c sorcery going on here, going straight to the Loom and somehow bypassing all of the game ; ), but it wasn't that.