Welcome to Door... a text adventure title by Richard Otter created within ADRIFT a modern way to play Command-Line only games.
This title was made for the InsideADRIFT Summer Comp 2008... That's the only other information I have about it.
So I literally stumbled on it, as the ScummVM Wiki is like "Door" and I was just sitting here going "the hell you mean 'DOOR'?" and well here we are today... with Door... and ScummVM.
What's with the final time of 00:00.00? You say you're using the 9999FPS because that's the fastest libTAS will allow for ScummVM, but benefit does that have for this TAS? Is this using the 9999FPS for a similar "key queuing trick" as this tas of Mari0 to pack all the inputs in a fraction of a second (where I assume the game responds to each input one at a time at a more leisurely pace)? If so I find it less entertaining, as that would allow any TAS for an ADRIFT game to have an arbitrarily short time-of-final-input using the exact same method.
Joined: 10/12/2011
Posts: 6409
Location: The land down under.
OnehundredthCoin wrote:
You say you're using the 9999FPS because that's the fastest libTAS will allow for ScummVM, but benefit does that have for this TAS?
It allows the 5 lines to be inputted faster. ¯\_(ツ)_/¯
You're not going to get a technical explanation from me about any of this, since it all amounts to "oh heck", "welp" and "oops".
Like the most information about frame rates is me asking for a Judge on what a maximum fps limit is allowed and this is the response I got:
feos wrote:
we don't have a hard limit. also need more context
And then some kind of discussion occurred after the submission.
I guess you could say it's me screwing around and trying to break (and get fixed) the rules again because that's more of my interest.
WebNations/Sabih wrote:
+fsvgm777 never censoring anything.
Disables Comments and Ratings for the YouTube account.Something better for yourself and also others.
#9075: Mikewillplays's Flash The Impossible Quiz Book: Chapter 1 in 01:04.84 highlighted a sensible reason to use high framerate for Flash: routing. Another reason we used to have for DOS was overclocking games that work on independent framerate, to help them lag less. Overclocking for the sake of getting lower realtime duration doesn't look like a good reason, especially because we'd have to slow down the encode if we want to let users know what actually happened.
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.
For computer games, environment settings explicitly supported by the game or its documentation are allowed.
If a setting is not mentioned in any way, it's allowed if it doesn't cause significant glitches.
But in most scummvm games, there's no setting for framerate. At max it has vsync, but framerate used in this movie doesn't tie into highest possible refresh rates of actualexisting monitors.
Based on iffy technical nature of increased framerate in this movie, lack of gameplay benefit from it, and presentation issues coming from unwatchable speed, I think it's not justified in this case to deviate from default framerate of this 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.
My thoughts as concisely as possible:
If we allow TASing with arbitrarily high framerates (that affect actual gameplay speed) in order to yield a faster run, we should also allow arbitrarily high emulated CPU speeds that affect actual gameplay speed.
I personally don’t care if we do or don’t decide to allow the arbitrary high settings (though I lean toward not allowing). I just think the concept needs to remain consistent across all PC emulation.
Allowing arbitrary framerate in libtas to affect gameplay but not allowing arbitrary CPU emulation in other emulators (i.e. JPC-rr) creates an uneven playfield for authors by giving an advantage to one emulator over the other, and it also makes judging a greater challenge.
Whatever decision is made will impact https://tasvideos.org/9181S as it also uses an arbitrary high framerate in libTAS/ScummVM.
I know little to nothing about FLASH TASing and framerates, but perhaps that should also follow similar rules.
The hard part is TAS tools don't have a way to distinguish input poll rate from video refresh rate, and we can't send inputs at maximum rate the game is able to process them, without also forcing it to render at that rate, which may in theory break things.
But even if it doesn't break things... if we try to artificially speedup the movie by enforcing higher framerate when nothing else changes, that feels like an unfair advantage that may lead competing in setting unreasonably high framerates. The main purpose of a TAS is optimizing gameplay, not reducing real-time duration at any cost. So if some specific faster framrate helps optimize gameplay, it feels reasonable, otherwise it doesn't.
Now, if gameplay is affected at 100k% FPS and becomes quicker, but the game itself speeds up by 100k%, does it sound fine? I don't know. And even having a community discussion on this matter is hard because it depends on deeply technical issues that not everyone may even understand. We've been discussing Flash rules for a couple years now and there's still no clear cut.
Maybe it should all be decided on a case-by-case basis depending on how reasonable it feels to change framerate?
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.
The hard part is TAS tools don't have a way to distinguish input poll rate from video refresh rate, and we can't send inputs at maximum rate the game is able to process them, without also forcing it to render at that rate, which may in theory break things.
Asi understand it: because JPC-rr processes inputs based on time passed and not based on frame number, it does process inputs as fast as the emulated hardware/software can process irrespective of framerate. It’s just the graphical rendering of that processing that that is limited by the frame rate.
In other words: yes we can send inputs at maximum rate the game is able to process them, without also forcing it to render at that rate.
The main purpose of a TAS is optimizing gameplay, not reducing real-time duration at any cost. So if some specific faster framrate helps optimize gameplay, it feels reasonable, otherwise it doesn't.
If speeding up CPU clock allows for speeding up a character movement due to faster processing, that’s a type of time optimization, even if it doesn’t change gameplay otherwise.
More importantly, there are situations where increased CPU allows for faster movement but also necessitates a different approach to optimization because the movement speed increase affects where/when inputs need to take effect to yield an optimized run. Any DOS game made by Sierra using the AGI interpreter would be an example of this type of change (Kings Quest, Space Quest, etc.)
Interestingly, there could potentially be a CPU speed and thus character movement speed that became so fast that optimized movement of the character would require unoptimized input from a timing perspective; because the characters movements would have to be tweaked so much that it takes longer to properly control where the character actually goes.
Now, if gameplay is affected at 100k% FPS and becomes quicker, but the game itself speeds up by 100k%, does it sound fine? I don't know. And even having a community discussion on this matter is hard because it depends on deeply technical issues that not everyone may even understand. We've been discussing Flash rules for a couple years now and there's still no clear cut.
Maybe it should all be decided on a case-by-case basis depending on how reasonable it feels to change framerate?
while case-by-case may indeed be the best way to approach such situations, that makes judging harder because there’s no standard to judge by. It also opens up the possibility of two different judges having opposite perspectives that would impact obsoletion chains over time.
Asi understand it: because JPC-rr processes inputs based on time passed and not based on frame number, it does process inputs as fast as the emulated hardware/software can process irrespective of framerate. It’s just the graphical rendering of that processing that that is limited by the frame rate.
In other words: yes we can send inputs at maximum rate the game is able to process them, without also forcing it to render at that rate.
True, though JPC is the only exception IIRC.
DrD2k9 wrote:
If speeding up CPU clock allows for speeding up a character movement due to faster processing, that’s a type of time optimization, even if it doesn’t change gameplay otherwise.
It doesn't feel legit to me. If the goal is now to have all movies last 00:00.000 realtime seconds by forcing framerates that cap out integer size for numerator and denominator, then why not also overclock all consoles to run as fast as possible?
DrD2k9 wrote:
More importantly, there are situations where increased CPU allows for faster movement but also necessitates a different approach to optimization because the movement speed increase affects where/when inputs need to take effect to yield an optimized run. Any DOS game made by Sierra using the AGI interpreter would be an example of this type of change (Kings Quest, Space Quest, etc.)
Interestingly, there could potentially be a CPU speed and thus character movement speed that became so fast that optimized movement of the character would require unoptimized input from a timing perspective; because the characters movements would have to be tweaked so much that it takes longer to properly control where the character actually goes.
Now, if gameplay is affected at 100k% FPS and becomes quicker, but the game itself speeds up by 100k%, does it sound fine? I don't know. And even having a community discussion on this matter is hard because it depends on deeply technical issues that not everyone may even understand. We've been discussing Flash rules for a couple years now and there's still no clear cut.
Maybe it should all be decided on a case-by-case basis depending on how reasonable it feels to change framerate?
while case-by-case may indeed be the best way to approach such situations, that makes judging harder because there’s no standard to judge by. It also opens up the possibility of two different judges having opposite perspectives that would impact obsoletion chains over time.
Pre-rewrite rules solved this by splitting unintended environment runs into a different goal that was Moons only. We tried to keep the rewritten rules generic enough to cover more cases by broader wording, but it looks like we'll need to reintroduce some of those pre-rewrite rules, to allow things to not get mixed up completely.
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.
