(Link to video)
Submission Text Full Submission Page
TAS of Loom EGA on ScummVM on 1000FPS and really REALLY fast mode enabled. Hopefully submission part 1 of 3

Game objectives

  • Emulator used: ScummVM 2.8.1, within LibTAS 1.4.5, within Ubuntu 22.04.4 LTS, within WSL 2, within Win 11
  • Learn all notes
  • Defeat Chaos
  • Save (a fraction of) the universe

Technical Preliminaries

This is (possibly) one of three TAS' for Loom EGA I wish to make, with three different speed settings. These settings arise from arbitrary default limitations on ScummVM and LibTAS which are either active or passive in those three runs. This run has both set to fastest.
I made a sneak preview here: https://youtu.be/3z9Lf3r01gU which discusses the possibilities and limitations, inquiring feedback which was positive.
I then made a proof of concept here: https://youtu.be/Lm1cQ_mQTYg
The two speedsettings are:
Limited framerate + Vsync (60 FPS + On vs. 1000 FPS + Off) and really REALLY fast mode (Ctrl + G in game, see https://wiki.scummvm.org/index.php/Loom#Default_controls )
neither of which are permissible for the current categories on speedrun.com, but can be played at the very same speed manually if desired.
The setting 1000 FPS was an estimate about an order of magnitude higher than 60 FPS. See here https://youtu.be/VNhlWpIJJb4 for why this is an underestimation.
To run this movie, make sure Loom is the only game added to scummvm, and the Command-line argument is "--random-seed=0" (so no game, scummvm launcher will boot) this is required to turn off Vsync. If all goes well, the game begins with Boppin racing to the main tent to get his distaff

Comments

We follow the route of the WR submission by Non-Slim Jim
Note that there is a difference in RNG behviour between the VGA and the EGA verison. In VGA, one of 4 draft lists is randomly selected. In EGA, each draft is sampled for one of three possible patterns (except open and transcendence, which are always fixed)

Stage by stage comments

Main Island

Pretty much identical to Any% other than the speed of course. Any% is limited to 60 FPS and we run at 1000 FPS. This leads to a desynch of video and audio when spells are cast, as the animations are measured in frames, and the sounds are measured in seconds. Also, certian sounds cannot be skipped, in particular the "learning a new note" sound. First observed at the 5 second mark. These cause a pause of about 3 seconds, and constitute almost half of the entire run.

Glassblowers and Shepards

Directly begins with learing G and waiting another 3 seconds. Then the route follows the regular Any%, so Shepards, Scrying sphere, Shepards, Lamb, Herd, Dragon

Dragon and Maze

Both turning the gold to straw and learning "A" cause another long wait in the dragon's cave. Upon entering the maze, the light draft is cast, costing another good 2 seconds. At about 27 seconds into the run we see the first actual difference between the TAS route and the Any%. In Any%, we let two drops fall from the stalactites into the water to infer the correct spell for "reflection". This is not required for the TAS, so all we do is immediately skip the stalactite drops and we see a total of 3 frames of falling drops. This is because of the set seed (but would work without as well), we already know the pattern through the magic of rewinding.

Rusty and the Nailbenders

Other than some hardly necessary pixel perfect positioning when listening to the Bishop, this is identical to Any%. Swap clothes, go in, get scolded, hex a sword, get kidnapped.

Chapel and Backside of the Universe

Identical to Any%

Showdown

Here, three more drafts need to be learned or guessed. Or in our case, rewound.

Other comments

- If it were to happen, viewers might enjoy the other 2 versions I have planned, which are slower but easier on the eyes.
- mikeSpeedyAdventures mentioned snap scroll (alt + i) which might save a couple of frames in the maze.
- I'll do screenshots soon

Acknowledgements

- Thanks to mikeSpeedyAdventures for the tech suggestions - Thanks to Non-Slim Jim whose run I followed.
eien86: Claiming for judging.
eien86: Unclaiming since I've been informed this game is under consideration for potential policy changes.
feos: Yeah sorry I forgot that I'd rather claim it to potentially set a precedent.
feos: Sorry again, this is taking a while, setting to Delayed to indicate it.

Show more

Hide
Posted: 7/13/2024 8:46 PM
Quote
TASVideoAgent
They/Them
Moderator
Joined: 8/3/2004
Posts: 15577
Location: 127.0.0.1
This topic is for the purpose of discussing #9181: darkshoxx's Linux Loom in 00:43.76
Posted: 7/14/2024 6:26 AM
Quote
Spikestuff
They/Them
Editor, Publisher, Expert player (2642)
Joined: 10/12/2011
Posts: 6438
Location: The land down under.
Flash TASer of 2022 PSX TASer of 2016
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. The only reason I bring this up is because the author provided a showcase on Discord about what they're doing, and the input still matches from back then in the game menuing. As a comparison the Riven submission does something similar, but it runs out of the gate without messing with ScummVM in the input. Instead it requests the Judge/Publisher to make sure to adjust their keybindings to add two key strokes. I don't make that as part of the input. And as a bit of a nitpick. You should've done Global Options > Graphics > V-sync Off. You added extra steps that you didn't need. For future reference in regards to the splash: Game executable: /usr/games/scummvm Command-line options: loom-ega My vote is Abstained. But I disagree with messing with ScummVM as it can lead to other systems that it supports with a major advantage that it should not have. That cap was intentional. Personally I believe you should've actually messed with JPC-rr instead.
WebNations/Sabih wrote:
+fsvgm777 never censoring anything.
Disables Comments and Ratings for the YouTube account. Something better for yourself and also others.
Posted: 7/14/2024 10:55 AM
(Edited: 7/14/2024 10:57 AM)
Quote
darkshoxx
He/Him
Player (65)
Joined: 4/30/2023
Posts: 30
Location: Glasgow
Hi Spikestuff, thank you for your detailed response.
I can't tell if you followed the guide to running ScummVM titles or not.
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 https://imgur.com/a/MWff3CZ
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.
Yes, precisely, because to the best of my knowledge that's the only way to disable vsync on a clean install.
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.
Well, it's a clean install of the scummvm version I specified on a clean install of ubuntu. Have I not provided all detail for reproduction with that? It was sufficient for my submission of Phantasmagoria https://tasvideos.org/8249S NINJA EDIT: I understand that the situation is different, as a submission that starts on the splash screen is independent of the layout of scummvm. Apologies.
And as a bit of a nitpick. You should've done Global Options > Graphics > V-sync Off.
Fair, didn't think it would make a big difference
For future reference in regards to the splash: Game executable: /usr/games/scummvm Command-line options: loom-ega
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?
Instead it requests the Judge/Publisher to make sure to adjust their keybindings to add two key strokes.
To me that is "messing with ScummVM" to the same degree as I do, in both cases the original configuration is changed. 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. I feel like a lot of this could've been avoided if I had gotten feedback to the discord post mentioned above. I'm happy to apply changes that makes it consistent with the rules. The rules were unclear. Kindly advise.
Personally I believe you should've actually messed with JPC-rr instead.
I had not heard of this. I'm quite comfortable with ScummVM at this point, I'd rather not change to a different setup if this one works. Happy to look into it for another project.
Posted: 7/14/2024 11:07 AM
(Edited: 7/14/2024 11:09 AM)
Quote
feos
Site Admin, Skilled player (1254)
Joined: 4/17/2010
Posts: 11475
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
NES TAS of 2011
darkshoxx wrote:
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
Wiki: MovieRules wrote:
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.
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).
Yes, precisely, because to the best of my knowledge that's the only way to disable vsync on a clean install.
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).
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.
Posted: 7/14/2024 11:53 AM
Quote
darkshoxx
He/Him
Player (65)
Joined: 4/30/2023
Posts: 30
Location: Glasgow
Hi feos, thanks for the quick response
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).
Yeah that makes sense. I reckoned it would be fine to just have a submission as a point of conversation. I'll know for next time.
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).
For my submission for Phantasmagoria I was given to understand that initial tweaks are not an option, and I had to do a lot of workaround to avoid a specific crash because of that. To be honest I did not check the running ScummVM titles specifically this time around mainly because I could not find the page. I wasn't sure where those rules were set, googled a bit and gave up, because I didn't even know what I was looking for. That's when I made the post in discord. I'm very open to suggestions on how to fix this in the best way possible. Is there a way to start this with a preset of initial tweaks that help? For example, will scummVM remember if you start it with Vsync disabled in the global options, then close and run the game with the command line setting of the game?
Posted: 7/14/2024 11:56 AM
(Edited: 7/14/2024 11:57 AM)
Quote
Spikestuff
They/Them
Editor, Publisher, Expert player (2642)
Joined: 10/12/2011
Posts: 6438
Location: The land down under.
Flash TASer of 2022 PSX TASer of 2016
darkshoxx wrote:
To me that is "messing with ScummVM" to the same degree as I do, in both cases the original configuration is changed.
This is my fault of short-handing the explanation. What I did actually matches the official Steam release of Riven. With one slight difference. I changed it to be usable for people with 10-keyless systems, as they were bound to Num 7 and 9. To essentially open up the-- if needed --future reencodes/publications of that title. So your example and reasoning is a bit more of an Apples to Oranges comparison.
darkshoxx wrote:
Well, it's a clean install of the scummvm version I specified on a clean install of ubuntu.
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.
darkshoxx wrote:
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?
That might be a bit of misunderstanding. If you're doing the settings within an instance of libTAS it will not save. You would have to do (within libTAS) Settings > Runtime disable "Prevent writing to disk" (then reenable). Modify the settings, then should be golden. Alternatively do it outside the instance of libTAS and have it pre-configured. After all with my example it was pre-configured outside of libTAS. Riven never had that issue when reinstating two keys.
The comments that were related to Vsync off and JPC-RR is mashed here with only one bit highlighted. Because I didn't know how to separate them as they all essentially related as a single point for me.
darkshoxx wrote:
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.
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. Again. 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. That cap was intentional.
WebNations/Sabih wrote:
+fsvgm777 never censoring anything.
Disables Comments and Ratings for the YouTube account. Something better for yourself and also others.
Posted: 7/14/2024 1:22 PM
Quote
darkshoxx
He/Him
Player (65)
Joined: 4/30/2023
Posts: 30
Location: Glasgow
So your example and reasoning is a bit more of an Apples to Oranges comparison.
they're still both fruit. And neither runs are without setup. "With one slight difference." In the fruit basket it goes. See my reasoning above as to why I had to make the assumptions that I did. We can continue to argue whose runs violate which rules, but I'd appreciate if we move towards getting the run into a shape that makes everyone happy. Again I had struggled to find the rules, and an early response on discord could've avoided this as well.
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.
That's fine. Let's focus on what to change.
You would have to do (within libTAS) Settings > Runtime disable "Prevent writing to disk" (then reenable). Modify the settings, then should be golden.
Great I'll try that.
The comments that were related to Vsync off and JPC-RR is mashed here with only one bit highlighted.
Sorry, didn't mean to misconstrue anything. I'll avoid talking about JPC-RR altogether.
It doesn't though. "Fast Machines" would only get this performance if the CPU was overclocked.
Apologies, this is due to knowledge gap in my understanding of the tech. The choice of 1000 was indeed arbitrary, I wouldn't know if that can only be achieved through overclocking. I didn't overclock my current or previous machine. But I very much can run Loom essentially uncapped. I just went for "a good order of magnitude above 60" The way it plays on my machines with vsync off is (to be best of my understanding, but I've not measured) the same as in the video I've provided.
If this used JPC-rr then you're essentially using a validateable and provable system that is essentially using an actual powerful DOS system.
Again, I see no point in switching entire systems mid submission.
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.
Could you please elaborate what you mean by that? I do not understand that at all. This is a very specific setting to highlight a mode of gameplay that is available out of the box. And it is replicable, so how does anyone have an advantage over another? As mentioned in the submission, I intended to do 3 runs, one on regular (SRC leaderboard compliant), one with capped framerate and speedhack (not leaderboard compliant), and this one (obviously not leaderboard compliant), uncapped speedhack. I obviously started with this one, because speed go zoom. These three "categories" are obviously not in direct competition with each other.
Posted: 7/16/2024 9:40 PM
Quote
PLANET
He/Him
Joined: 1/3/2018
Posts: 73
Hmm, bit mixed opinions on this one. I definitely love the fact you picked up this very title! 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. Also, your "Hopefully submission part 1 of 3" made me smile with a little sadness inside - unsure if that was intentional ; Loom was supposed to be the first chapter of a trilogy (or not ; Brian Moriarty himself seemed to speak in a different tone about it in different interviews), later parts telling of the Forge, and the Fold (with respectively Rusty and Fleece being their main characters). On the other hand, I would love to see the VGA version instead (even if it's longer indeed) and a slower rendition of this TAS rather than this, well, madness ; ) Watched on 0,25x it's tolerable somehow, but still is too fast : p Nevertheless, a Yes vote for encouragement : )
Posted: 7/16/2024 10:31 PM
Quote
darkshoxx
He/Him
Player (65)
Joined: 4/30/2023
Posts: 30
Location: Glasgow
Hi PLANET, thanks for the kind words.
Hmm, bit mixed opinions on this one.
yeah you're not alone with that, :) but I still don't quite know why?
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
oh man, that kinda makes me want to "hack in" all notes from the beginning and see if you can unmake the loom from the get-go. Probably not because I think Boppin has to see the drafts before he can play them. Otherwise we could skip the forest at the start.................?
Also, your "Hopefully submission part 1 of 3" made me smile with a little sadness inside
Oh no that was not intentional. I just wanted to demonstrate all three ways you can play loom out of the box in Scummvm as a TAS. I am very aware of the planned trilogy, and it fills me with sadness too when I think about it. Have you seen the fan-made version of the forge? it's really good, Moriarty approved of it in his keynote speech at GDC.
I would love to see the VGA version instead
Bit unsure about that one. First time playing it in VGA after playing EGA for so long felt amazing, but my pure nostalgia lies with the EGA version, the dithering that was basically invented for this game and the more crude midi soundtrack. Maybe after I'm done with EGA?
and a slower rendition of this TAS rather than this, well, madness ; )
I was rather surprised by the contrast in feedback for this one compared to the Phantasmagoria one. Watch both next to each other and what you'll learn about each game is almost net zero due to the chaos, essentially a spoiler-free TAS.
but still is too fast : p
Is going fast not the point of speedruns? How can a TAS be too fast? Well I can guarantee the other two versions will be more digestible. But I probably wouldn't have started the TAS of Loom if I hadn't managed to get this fast version working, because I was looking for an experience similar to Phantas.
Posted: 7/17/2024 2:44 PM
Quote
darkshoxx
He/Him
Player (65)
Joined: 4/30/2023
Posts: 30
Location: Glasgow
This is not addressed an any singe person in particular, it is a general rebuttal of my settings of 1000 FPS, I'm happy for any and all responses and constructive criticism. I've done some tests and did some maths to find out what the actual framerate is that loom is playing when with vsync off. It is far larger than my estimate of 1000 FPS. The first thing I did was start my scummvm EGA Loom in regular Win11, with vsync off, started a game, hit ctrl g, and found a spot with a long tunnel, to be able to count out a long sequence of animation frames. I choose the path back from the Loom to the entrance of the tent. I used an autoclicker to make sure Boppin moves as continuously as possible. That footage is here: https://youtu.be/6MNSlHUpRMc I then cherrypicked (not afraid to admit that, but the error from that hardly hurts my argument) a sequence of 4 frames (with a difference of 3 frames) and counted the animation frames to get the same distance in the TAS, which has 1 animation frame per frame, the entire point of the thing. That analysis is here: https://youtu.be/VNhlWpIJJb4 I do some maths in that video, but let me expand on that here: First frame: 2635 Final Frame: 2819 difference of 184 frames in the animation. Arguments can be made for counting that as 4 or 3 frames, doesn't matter for the argument. Let's play the devil's advocate and be strict, 4 frames: First Method: FPS Conversion Factor Then conversion from Video to Windows gameplay framerate is a factor of 184/4 = 46 Therefore the effective framerate is 46*60 FPS = 2760 FPS , twice as fast as the capped FPS of 1000 Second Method: Frames divided by seconds Video has 4 frames, which is a time of (4 frames)/(60 frames per second) = (1/15) seconds = 0.066666666 seconds Then animation has 184 frames, leading to a framerate of (184 frames) / (1/15 seconds) = (184 frames) / (0.06666666 seconds) = 2760 FPS The result is the same, as it should. If you want to be more lenient, you count that as a difference of 3 frames, leading to 184/(1/20) FPS = 3680 FPS If you have doubts that my video runs at 60 FPS, divide it by 2 to get 1380 FPS, still above 1000 FPS. If you say it comes from cherry picking, run the tests yourself it won't make much difference. With worse frames I'm sure you can get that another good 20% lower, but 1380FPS*0.8 = 1104 FPS Even if you did get it to dip slightly below 1000 FPS, It would still be near it and doesn't invalidate the fact that 1000 FPS is a reasonable framerate for this exact playmode. If anything it could be higher. No Chiptuning, nothing. Please understand that all I'm doing is defending my position. And I'm happy to be wrong and corrected. But so far I have seen no argument on why this shouldn't be a valid movie at 1000 FPS. As explained multiple times, this playmode does not compete against a mode with Vsync and a mode capped at 60 FPS. These are different modes and I intend to make a TAS for those as well. But this is a legitimate way of playing the game. Sure it's effectively humanly unplayable, but so is every other TAS here. Is it the word "speedhack" that people take offense with? I really don't know. Kindly try to understand my point of view when responding, thank you.
Posted: 7/17/2024 9:04 PM
(Edited: 7/17/2024 9:18 PM)
Quote
DrD2k9
He/Him
Editor, Judge, Expert player (2213)
Joined: 8/21/2016
Posts: 1090
Location: US
Arcade TAS of 2023 Exotic platforms TASer of 2020 First edition TAS of 2020 Gameboy TAS of 2020 Exotic platforms TASer of 2019 Computer TASer of 2017
@darkshoxx To hopefully clear up some potential confusion: 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. There are differences of opinion on whether this restriction should be lifted or not. For example: one argument against maintaining this restriction is that it may force a TAS to use settings slower than what real humans may be actively playing the game at on modern systems, and that kinda undermines the ‘superhuman’ aspect for a TAS. 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. If this occurs, how do we as a site decided when one TAS is better than another? What if one run plays through a game with perfect precision of movement, but has a longer time than a different run using sloppy unoptimized moment that manages to have a shorter overall time due to using a higher emulated framerate/CPU clock speed; which one should be published? It’s these kind of concerns that are part of considering whether or not your submission is acceptable. If we do consider this basic restriction mentioned above, one question for this submission is: While a modern system that disables v-sync in ScummVM can play the game at the speeds/FPS this submission demonstrates, would a PC around the time that Loom was released be able to match this kind of speed running the game natively in DOS (not in a ScummVM emulator)? Was disabling v-sync even possible in the original game, or is that a functionality only introduced through use of ScummVM? I can understand arguments from both perspectives on whether or not arbitrary CPU/Framerate should or shouldn’t be allowable for publications on our site, and i think this submission is at least partially spurring the discussion on which way we need to go as a site. For that reason alone; this submission has value, even if it’s ultimately deemed unpublishable. Even if not accepted for publication, this run could likely reside in Playground instead of being outright rejected. I personally would like to be able to TAS things with unrestricted settings, but I also understand the logistical issues regarding the work of publication that arise with lifting the restrictions. Because of this, I’m not even sure which side i would officially take on the policy. EDIT: For what it’s worth, I actually enjoyed watching this run. And i even have some published runs that visually look similar (Space Quest, Kings Quest). Those were TASed using JPC-rr at CPU speed settings based on the release date of the AGI interpreter version used in the games.
Posted: 7/18/2024 11:18 AM
(Edited: 7/18/2024 11:24 AM)
Quote
darkshoxx
He/Him
Player (65)
Joined: 4/30/2023
Posts: 30
Location: Glasgow
Hi @DrD2k9, thanks, I think I'm getting a better overview of the problem. If we're allowing any uncapped run, we won't have clearly defined categories to directly compare them to each other. I'm very much in favour of having those, and want to make a Loom run in them as well, as mentioned multiple times. But, is having an uncapped "all goes" category really that bad?
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?"
so fast that little to nothing of the game is even seen
An additional point to that is the current runs of things like OOT, https://tasvideos.org/4324M MegaMan https://tasvideos.org/2601M or SMW https://tasvideos.org/3989M where you also learn net zero about the game. So that in and of itself shouldn't be an argument against my run, right? 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. I am obviously heavily biased, I put in work I don't want it to go to waste. I hope I could make a couple of good arguments towards having such categories. To answer some of the technical questions:
Was disabling v-sync even possible in the original game
The original vsync library was released in 2010, before that there was no vsync. So technically, "enabling" vsync is what wasn't possible.
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" To the best of my knowledge neither the box of the original game https://www.mobygames.com/game/176/loom/cover/group-41455/cover-111569/ nor the manual https://mocagh.org/lucasfilm/loom-manual.pdf mention technical details. But they obviously didn't imagine you to run it with an i9-14900K. The ScummVM documentation however specifically mentions the "really REALLY fast mode" you get by pressing "Ctrl + g"
would a PC around the time that Loom was released be able to match this kind of speed running the game natively in DOS
of course not. Even if your PC had a Turbo button ;-) My whole point is that it doesn't have to.
EDIT: For what it’s worth, I actually enjoyed watching this run.
Yes that is worth a lot. 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."?
Posted: 8/5/2024 6:03 PM
Quote
feos
Site Admin, Skilled player (1254)
Joined: 4/17/2010
Posts: 11475
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
NES TAS of 2011
I wanted to reply much earlier but got super busy...
darkshoxx wrote:
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?"
Olympics on drugs would still use the same "game engine" (physics of the currently available universe), so it'd look vastly different from regular Olympics. If the only difference is speed, that's much less unique because one could speed up the video and get a similar result.
darkshoxx wrote:
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.
Improvements that don't come from better optimization of gameplay (or menuing if it's all that's left to improve) traditionally don't result in obsoletion. If someone switches from one version of the game to another that has faster loading times or shorter dialog, that alone was never considered enough to count the new run as a proper improvement. Better optimization always needed to be applied. Sometimes new tricks saved so much time that overall duration was shorter despite weaker optimization in other parts, but we still counted that. Obviously if gameplay improvements are found, then one could add version switch to the mix to be even quicker in the end. When comparing the 2 submissions, we explicitly discount "automatic" difference such as different framerate or loading times, and only compare sections with actual gameplay (I personally adjust game speeds to match in a video and then make a comparison encode). If new timesaves can be applied to old runs and make them quicker, that 100% counts. If the previously used version of the game made some improvements impossible, and the new version allows them, that still works as an overall improvement, because directly reproducing the old movie on the new version would not be optimal anymore - it'd need that new timesave. When framerate is controlled by the user and directly affects game speed, we traditionally limited that to something that the game expects (old rules wording versus current wording), but the current wording is not as strict, because we don't have a lot of tech experts among staff, and tricky PC setups don't appear often in submissions. To be continued...
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.
Posted: 8/5/2024 6:31 PM
(Edited: 8/5/2024 6:37 PM)
Quote
feos
Site Admin, Skilled player (1254)
Joined: 4/17/2010
Posts: 11475
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
NES TAS of 2011
darkshoxx wrote:
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"
That's the right link, it contains our best attempt at reducing the insane size of the old rules while maintaining the main principles, some of which also evolved since then.
darkshoxx wrote:
The ScummVM documentation however specifically mentions the "really REALLY fast mode" you get by pressing "Ctrl + g"
Do you have a link? I see. 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.
darkshoxx wrote:
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."?
Figuring out something we're conceptually not ready for is the hardest part. It involves a lot of technicality, and not only the forum is almost dead these days, but we only have like 2 people in staff who understand this technicality, very few people available who control the global site vision and trends, and there's very little match between those 2 groups. Things related to the community in the general sense we can resolve easily because we've been part of it all for years. Insane wizardry related to edge cases with game code or sensible limits to arbitrary-in-nature reality is almost impossible to solve in a future-proof way. So we have to rely on whatever we've always been sure about, and on things we've agreed on going forward. On one hand we have Judge Guidelines that tell us to evolve along with the community, and on the other hand we have all the previous decisions by staff and community. It's hard to keep the balance, especially when everyone is busy with real life. 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.
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.
Posted: 8/6/2024 1:50 PM
Quote
darkshoxx
He/Him
Player (65)
Joined: 4/30/2023
Posts: 30
Location: Glasgow
Hi feos, thank you for your response, I was somewhat afraid the post is abandoned and that being a kind of ruling on it's own. Thank you very much for elaborating.
If that mode exists in the original game then it feels legit.
I agree, and it doesn't seem to be the case. It doesn't work on Dosbox or Dreamm engine, and the manual as a section on "function keys", it's not mentioned in there either.
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.
I think my point was that they didn't vote despite watching it, but it doesn't matter now.
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.
Totally understand. I was rather surprised that the other submission is from Spikestuff themself :) . I'll be patient on this then, no point making the "Ctrl + g" only mode right now if that's equally controversial. And the Vanilla game without those speedsettings is just going to be a very slow walking simulator. I feel it only makes sense to make it if I can contrast it with one of the other two.
Posted: 8/16/2024 7:08 PM
(Edited: 8/16/2024 9:19 PM)
Post subject: Too fast.
Quote
eien86
He/Him
Judge, Skilled player (1873)
Joined: 3/21/2021
Posts: 262
Location: Switzerland
NES TASer of 2023 PC TASer of 2023 NES TAS of 2023 PC TASer of 2021
Hi darkshoxx, I was pleasantly surprised when somebody decided to TAS this beautiful game. Those of us contemporaneous to the release of this game know how much art (visual and musical) it holds. For this very reason, I must say I was disappointed to see you've decided to run this in the fastest possible FPS. When we TAS, we look for ways to break the game within the game's rule. Increasing the emulation speed does not mean you solved the game faster, but rather that your solution simply plays faster. From my own experience (https://tasvideos.org/Forum/Topics/23316) this only obscures the game's own quality and makes for a dull experience for the viewer. For this reason, I cannot accept this movie in the present conditions. As judge for this movie I can only give three options: 1) Take the time to re-formulate this movie in a correct speed (i.e., that expected of systems of the era in which the game was released). If you go this route, I'll put this submission in 'Delayed' and you can take your time to do this refactoring. 2) Cancel the submission 3) Appeal to a Senior Judge to reconsider this decision Hope you take (1) and we get to see your mastery of this game in all its (slower) spendlor.
EDIT: unclaiming since the this submission is under consideration for possible policy changes. I sustain my opinion, that the movie is not in a satisfactory form, and will be much better if it's played in the original developer's intended speed. I hope we can make policies clearer towards this point and authors won't have to go through this in the future.
Posted: 8/17/2024 8:08 PM
Quote
darkshoxx
He/Him
Player (65)
Joined: 4/30/2023
Posts: 30
Location: Glasgow
Hi eien86, sorry if this is impolite, but you've clearly not read the above discussion. You saw the movie, got angry and jumped down here. if you had followed the discussion above you'd have noticed that 1. This was intended to be a part of three submissions, one of which would be the "regular" version, and I therefore won't "resubmit" that in your desired context. 2. The discussion is ongoing on the details. I'll add, just for you, one more time, that I did for Loom the very same thing that I did for Phantasmagoria. Both runs look very similar, and the Phantas one was very popular. Furthermore, if you have seen any regular Speedruns of Loom, a "normal" TAS of Loom will look pretty much identical to it and therefore to me has very little value other than to server as a comparison to a sped-up version. No "speedstrats" or anything has been found that I know of. Again apologies for my tone and assumptions, it's just a bit frustrating, I have made peace with the current state of the discussion, and then the next person comes in and says the equivalent of "YOU'RE RUINING THE GAME!!11!!" If you want to still remove the submission, go ahead.
Posted: 8/30/2024 10:06 AM
Quote
darkshoxx
He/Him
Player (65)
Joined: 4/30/2023
Posts: 30
Location: Glasgow
@PLANET
PLANET wrote:
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.
Inspired by the quote and a discussion on discord, there is a way to do that in theory. There's a scummvm debug command "learn drafts" that gives you all notes and drafts. You can then cast "unmake" on the loom (which can only be BAAB ABBA BCCB in the EGA version and BCCB in VGA) without ever leaving the main island and go straight to the end of the game. So if we had an ACE that set the flags for that draft and the required note(s) we'd have our own little credits warp. Sadly I don't know of any crashes on the main island.
Posted: 23 days ago
Quote
PLANET
He/Him
Joined: 1/3/2018
Posts: 73
Hey man, late to the answer, but wanted to thank you for the info! : ) Never knew about such a possibility in ScummVM. Would like you like to showcase this, in case you'd want to? : ) With "learn draft", of course. That would be swell to watch. Likely the whole game would be finished... below a minute? : D Good luck with the runs, be it Loom or anything else, mate!