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.
ikuyo: I like taking on headache inducing submissions, it looks like.
Alright, so the issue here turned out to be surprisingly simple. The movie as originally submitted would sync in its expected framerate (estimated by feos to be 100fps) with the same framecount and inputs. However, since both the original environment and the emulator used for it technically work under arbitrarily high clockspeeds, the movie was submitted with the highest possible framerate the emulator would support.
This poses an interesting question for us: for as much as this is the game running on an unintended setup, it also is not abusing any "errors". The game works exactly like it would, just in a much faster way. Is this acceptable?
And you know, I'm making it sound like it is legitimate, but... no. This is silly.
If the only reason the movie is being created at the highest possible framerate is because that makes each frame have a shorter timespan and nothing else, then there's no reason to actually do this. In prior submissions (such as Towerfall) the reason to aim for such a high framerate was gameplay-based: it allowed for extremely granular control and exploited the game's physics in unique ways not achievable without it.
We as judges understand that we know less about any given game than whoever is submitting those games to us. This is natural: when one makes a movie, they obtain a familiarity with the game that not all judges will have. As such, we expect you as the author to be able to justify any creative choices made in the production of your movie. And while we can agree or at least concede most decisions, this is one where a line is drawn. If a movie file with identical frames and inputs would sync at the most natural framerate instead of the submitted one, and the high framerate is providing no unique gameplay advantage, it will not be accepted as a valid reason to bump up the framerate.
With that in mind, this movie is still valid as a proper movie for the game, and as such we think it best to accept it... with its correct framerate set. I've already gone ahead and replaced it.
I'm happy to close the Door on this submission. Accepting the replaced movie.
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: 6493
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.
Joined: 4/17/2010
Posts: 11591
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
#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.
Joined: 4/17/2010
Posts: 11591
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
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.
Joined: 4/17/2010
Posts: 11591
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
DrD2k9 wrote:
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.
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.
run500.exe!ADRIFT.frmRunner.SubmitCommand() Line 1626 C#
run500.exe!ADRIFT.frmRunner.txtInput_KeyDown(object sender = {Text = "Ø 6utfuyk"}, System.Windows.Forms.KeyEventArgs e = {KeyData = Enter}) Line 1549 C#
System.Windows.Forms.dll!System.Windows.Forms.Control.OnKeyDown(System.Windows.Forms.KeyEventArgs e) Line 12223 C#
System.Windows.Forms.dll!System.Windows.Forms.Control.ProcessKeyEventArgs(ref System.Windows.Forms.Message m = {System.Windows.Forms.Message}) Line 13238 C#
System.Windows.Forms.dll!System.Windows.Forms.Control.WndProc(ref System.Windows.Forms.Message m = {System.Windows.Forms.Message}) Line 16006 C#
System.Windows.Forms.dll!System.Windows.Forms.RichTextBox.WndProc(ref System.Windows.Forms.Message m) Line 3867 C#
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.DebuggableCallback(System.IntPtr hWnd, int msg = 256, System.IntPtr wparam, System.IntPtr lparam) Line 761 C#
[Native to Managed Transition]
[Managed to Native Transition]
System.Windows.Forms.dll!System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(System.IntPtr dwComponentID, int reason = -1, int pvLoopData = 0) Line 305 C#
System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(int reason = -1, System.Windows.Forms.ApplicationContext context = {System.Windows.Forms.ApplicationContext}) Line 1236 C#
System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.RunMessageLoop(int reason, System.Windows.Forms.ApplicationContext context) Line 1152 C#
run500.exe!ADRIFT.frmRunner.Main() Line 552 C#
Just like with Flash, this implies that input rate is not tied to rendering rate, and input polling happens as usual when the OS decides to do it inside the message loop. So technically entering commands to ADRIFT at high framerate is legitimate. However that does not solve the problem of when it makes sense to do so. I still believe that if there's no gameplay advantage, one should stick to default rate.
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.
Joined: 10/12/2011
Posts: 6493
Location: The land down under.
feos wrote:
one should stick to default rate.
Default being 60 right?
Regardless this is a shitpost to screw around with the rules, and without any corrections by me it should be fine to force it to that rate without fear of desync. From memory when I did screw with it a year ago.
WebNations/Sabih wrote:
+fsvgm777 never censoring anything.
Disables Comments and Ratings for the YouTube account.Something better for yourself and also others.
There's a somewhat large genre of "inherently uncapped games" which (assuming lag isn't a problem) can process commands as fast as the player can enter them, because there's no timing dependency in the game logic itself.
In such cases, I think it doesn't really make sense to use time as a method for determining how optimised a TAS is – the time of a run is something that the game doesn't care about and doesn't affect the gameplay. (For a non-TAS run, it would measure a skill – the skill of entering input quickly and precisely. But in a TAS we assume that that skill is already at ideal/super-human values, so it isn't a meaningful thing for TASes to compete on.) With this sort of game under TAS conditions, you'll always be able to get a faster time by running on a faster computer and connecting it to a faster keyboard, so optimisations that make the run go faster in realtime don't really make sense. Instead, the goal should be to minimize something else – maybe fewest lines of input, or fewest keystrokes, might make sense.
(For example, in the NetHack TAS that dwangoAC and I've been working on, the main optimisation goal is in-game turncount, because realtime is mostly a factor of how fast the computer runs and how fast the keyboard runs; the game is designed to let you think as long as you like about each move and has no time limits, which also means that it lets you think as short as you like, too. To nonetheless come up with some meaningful realtime measurement, we have a rule to not send input any faster than a typical physical keyboard of the time would be able to send it, which is often a tighter limiting factor than lag is – but that basically only affects tiebreakers. We may in fact slow some of the input down for the final submission to make it more viewable, and if we don't, would at least slow down the encode.)
Joined: 4/17/2010
Posts: 11591
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
ais523 wrote:
In such cases, I think it doesn't really make sense to use time as a method for determining how optimised a TAS is – the time of a run is something that the game doesn't care about and doesn't affect the gameplay. (For a non-TAS run, it would measure a skill – the skill of entering input quickly and precisely. But in a TAS we assume that that skill is already at ideal/super-human values, so it isn't a meaningful thing for TASes to compete on.) With this sort of game under TAS conditions, you'll always be able to get a faster time by running on a faster computer and connecting it to a faster keyboard, so optimisations that make the run go faster in realtime don't really make sense. Instead, the goal should be to minimize something else – maybe fewest lines of input, or fewest keystrokes, might make sense.
Agreed. Normally it's frames, but for some non-conventional game where frames don't matter it could be something else.
ais523 wrote:
(For example, in the NetHack TAS that dwangoAC and I've been working on, the main optimisation goal is in-game turncount, because realtime is mostly a factor of how fast the computer runs and how fast the keyboard runs; the game is designed to let you think as long as you like about each move and has no time limits, which also means that it lets you think as short as you like, too. To nonetheless come up with some meaningful realtime measurement, we have a rule to not send input any faster than a typical physical keyboard of the time would be able to send it, which is often a tighter limiting factor than lag is – but that basically only affects tiebreakers. We may in fact slow some of the input down for the final submission to make it more viewable, and if we don't, would at least slow down the encode.)
How does nethack work in relation to video frames and input polls? Normally in a tas environment frames and polls are turned into the same thing, even if it reduces accuracy to the original device. How does jpc-rr work with those?
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.
Joined: 4/17/2010
Posts: 11591
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Spikestuff wrote:
feos wrote:
one should stick to default rate.
Default being 60 right?
This turned out to be completely impossible to determine from looking at or even debugging scummvm code. If I move mouse in adrift on every frame at 100fps (vsync off), libtas shows no lag frames, meaning the game renders every frame there's different mouse input. Running it at 200fps results in lag on every other frame. If I don't move mouse at all, it's all lag, so no rendering is done. And how fast letters appear on the screen is also different: 50fps- they appear every frame, 51fps+ they appear on every Nth frame. I recommend 50 and vsync off.
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.
JPC-rr uses time for inputs. Each keypress/key release/mouse click/mouse movement takes a certain amount of time (in the sub milliseconds range…can’t remember the exact value off the top of my head). How quickly keys can be pressed for a given game is dependent on how the game itself processes the inputs. Some games may only process a keypress every few frames, other games can process many many keypresses within a single frame. Some games are weird combinations of those possibilities, where multiple inputs can be given all within one frame but the game won’t process that series of inputs for a few frames.
So strictly speaking for the emulator itself, input can be completely separate from video frames.
For NetHack, I’m guessing multiple inputs can be entered and processed within a given frame, so the run could be extremely fast based strictly on time. FWIW, finding the shortest sequence of necessary inputs would most likely also be the fastest way to progress through the game time-wise. But a slowed down version would likely be necessary for a viewer to follow what’s happening; because it may be theoretically possible to beat the game in a single frame once the game has actually loaded/started after bootup.
Joined: 4/17/2010
Posts: 11591
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Interesting. IIRC jpc-rr writes final time into the movie after it's done, and frames are not very relevant because framerates are not constant.
Since jpc-rr emulates timings with decent accuracy and you can't arbitrarily speed it up beyond caps of original devices, overall movie duration in human time seems to be the only technically valid metric. I can't find a reason to disregard it in favor of anything comparably correct. There will always be upper bound on how fast inputs can be entered, and then they can be processed by the game after the movie is already over (that happens in this submission too BTW).
But for systems without a theoretical upped bound not even final duration in human time is a meaningful metric anymore, so IMO it makes the most sense to stick to defaults.
This little aspect adds important details to the new post about PC framerates that I plan to make to discuss future proof rules for it.
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.
What were the settings used for running the movie file? I cannot get it to sync and no annotations were provided (libTAS 1.4.5 and ScummVM 2.9.0 cannot sync it).
