ROOM
You see a nondescript table. On it rests a book. 

> look at table
I said the table is nondescript!

> look at book
It is an electronic book. "Don't Panic!" is written in large, friendly letters
on the cover.

> read book
You don't have it.

> get book
Taken.

> read it
It is the Hitchhiker's Guide to the Galaxy, is an electronic guidebook to the 
entire universe.

> read about hitchhikers guide
Which do you mean: 
	1) The wholly remarkable guidebook published by Megadodo Publications, 
	   one of the great publishing houses of Ursa Minor Beta.
	2) The science fiction series written by Douglas Adams
	
> 2
The Hitchhiker's Guide to the Galaxy is a comedy science fiction series 
created by Douglas Adams of Earth (see: Mostly Harmless). The broad narrative 
of Hitchhiker follows the misadventures of the last surviving man, Arthur 
Dent, following the demolition of the planet Earth by a Vogon constructor 
fleet to make way for a hyperspace bypass. Dent is rescued from Earth's 
destruction by Ford Prefect, a human-like alien writer for the eccentric, 
electronic travel guide The Hitchhiker's Guide to the Galaxy, by hitchhiking 
onto a passing Vogon spacecraft. Following his rescue, Dent explores the 
galaxy with Prefect and encounters Trillian, another human who had been taken 
from Earth prior to its destruction by the President of the Galaxy, the two-
headed Zaphod Beeblebrox, and the depressed Marvin, the Paranoid Android. 
Originally a radio comedy broadcast on BBC Radio 4 in 1978*, it was later 
adapted to other formats, including stage shows, novels, comic books, a 1981* 
TV series, a 1984* video game, and 2005* feature film.
(* all dates in Earth years)

> read about video game
An interactive fiction video game based on the comedic science fiction series 
of the same name. It was designed by series creator Douglas Adams and 
Infocom's Steve Meretzky, and was first released in 1984* for the Apple II, 
Macintosh, Commodore 64, CP/M, MS-DOS, Amiga, Atari 8-bit family and Atari ST.
The game loosely mirrors a portion of the series' plot, representing most of 
the events in the first book. As with other Infocom games (see: Zork series) 
the Hitchhiker's Guide is a text adventure game, where the player solves a 
number of puzzles to complete various objectives to win the game. The player 
has a limited variety of commands that they can enter to observe, move about, 
and interact with the game's world, such as "look", "inventory", "north" (to 
move north) "take screwdriver", or "put robe on hook". 

The Hitchhiker's Guide to the Galaxy gained a reputation for its difficult 
puzzles. The most notorious involved getting a Babel Fish out of a dispenser 
in the hold of the Vogon ship. This tricky puzzle appears early in the game 
and requires the player to use a variety of obscure items in a very specific 
fashion as to create a Rube Goldberg-like chain of events, and had to be 
"solved" within a limited number of turns. Failure to "solve" the Babel Fish 
puzzle did not kill the player, but rendered the remainder of the game 
unwinnable. That particular puzzle became so notorious for its difficulty that
Infocom wound up selling T-shirts bearing the legend, "I got the Babel Fish!".
Due to numerous other similar puzzles in the game, The Hitchhiker's Guide to 
the Galaxy ranks #1 on gamespot.com's list of games that can become 
unwinnable link.

Subsequent rereleases included a Solid Gold version, containing a built-in 
hint book, as well as 20th and 30th anniversary editions released by the BBC 
with augmented graphics (the interface remains text input) link. In
September 2018* an realtime speedrun was submitted to speedrun.com link and 
later that year a tool-assisted speedrun was submitted to TASVideos.org link.

> read about TAS
The tool-assisted speedrun was created by c-square using JPC-rr 11.2 augmented 
with TASScript link, on the Solid Gold version of the game (v.31). One goal 
of developing the JPC-rr TASScript improvement was to create a system that 
would make it much simpler to develop a text adventure TAS. To that end, 
c-square teamed up with DrD2k9 to tackle Zork I link. Unfortunately, it became 
quickly clear that significant luck manipulation would be required for that
TAS. In the meantime, c-square decided to run the simpler "Hitchhiker's Guide
to the Galaxy" game as a proof-of-concept and a learning exercise.

More information can be found under the following headings:
	- Objectives
	- Luck Manipulation
	- Strategies
	- Potential Improvements
	- Encodes
	- TASScript
	- Files
	- Color a Dinosaur
	
> read about objectives
The objectives of the run are:
	- 100% completion (400 points)
	- Beats current unassisted record by 9:46
	- Luck Manipulation
	- Finds and drinks a cup of tea

> read about luck
Although making the TAS was much easier with TASScript, there was still a lot 
of luck manipulation involved, including:
	1) Getting the shortest password for getting the plotter
	2) Always making sure the gift from the Aunt reappeared in the 
	   inventory when pulling the switch to avoid an additional text entry 
	3) Getting the desired destination to be the first destination that 
	   appears each time you go to the dark
	4) Getting the shortest path in the maze (3 steps)
	5) Getting the tool with the fewest letters (awl) as the tool to give 
	   to Marvin (you might say it was awl or nothing...)
	
> read about strategies
As with any text entry game, minimizing the number of letters typed is 
critical. Much of this run was finding smaller words for saying things (e.g. 
"don" and "doff" instead of "put on" and "take off", or using Mr. Prosser's 
first name) and when nouns could be omitted. This made it critical that the 
awl was the tool to be chosen at the end of the game, and the player had to 
visit the War Chamber last so that the awl was in the inventory. Each text 
entry was optimized to the millisecond.

> read about improvements
The TAS was made with shortest text input in mind. However, there are 
instances where a slightly longer text input results in one fewer line in the 
descriptive output, which may result in a savings. There were just too many of 
these situations to test out. 

> read about encodes

> slow it down
You don't want me to do that. It would spoil the entire game!

> slow it down
No! It will make the game no fun if you just see all the answers.

> slow it down
Fine, fine. Don't say I didn't warn you.
A few things to know about the slowed encode:
	1) The password to the plotter box is not manipulated to be the 
	   shortest like it is in the fast run
	2) Luck manipulation in the rest of the run is not optimized (as it is 
	   in the fast run)
	3) The fast run uses "Superbrief" descriptions which require an extra 
	   "look" command in the engine room. In the slow encode, the look 
	   becomes extraneous.

> read about TASScript 
The TASScript can be downloaded here link, where you can see all inputs.

> read about files
HDD, 16 tracks, 63 sectors, 16 sides.

Timestamp,MD5,Size,Filename
19900101000000,23abb66bad86a0fd8907a71705bca283,158413,HITCHHIK.DAT
19900101000000,173ff27e03b251e05b4cf46f362f192c,31924,HITCHHIK.EXE

> vote
Are you sure you don't want to see the "Color a Dinosaur" entry first?

> read about color a dinosaur
A dinosaur was not colored in this TAS

> vote
Go here to vote: link

> vote
No, seriously, you're going to have to click on the link above to vote

> click link
Listen, this is just stylized submission text. It's not actually text parser 
input. You'll have to click the link yourself.

> click link myself
Argh.. I give up.

> don't give up

> don't give up

> look

> inventory

> help

> quit

feos: No idea what this game is, but hopefully I'll figure it out. Or not. Judging...........
feos: Removing the branch label as explained here.
feos: Okay so I've read all the text in this movie, compared it to the RTA record, looked up what the points are gained for, and I think this is a good TAS, especially with all the shortcuts text input allows. The amount (and sometimes order) of proper actions doesn't allow for too much variety, so the speedrun boils down mostly to entering the commands, as explained in details in the thread.
Now, while a few people who are familiar with the game enjoyed it, the movie is completely unwatchable as it is. Even if you slow things down you still have to either magically know what's going on, or just read all the elaborate auteur eloquence, savoring the exquisite arthouse masterpiece that is being poured onto your bemused mind. Isn't that beautiful? Maybe it was, back when this game was released, when text quest genre was everything you needed to be entertained by a computer game. But overwhelming majority of games we TAS involves gameplay that can be actually seen, and if you don't have to read at all to understand the brilliance of the work in question, the better. I could have said millions of words describing why this game is so good or bad, and why the tier it gets fits it perfectly, but let's leave the rhetoric to true connoisseurs and simply accept this movie to Vault.
fsvgm777: Processing.


TASVideoAgent
They/Them
Moderator
Joined: 8/3/2004
Posts: 15628
Location: 127.0.0.1
Joined: 10/14/2013
Posts: 335
Location: Australia
Ah, memories. It might not be the most glamorous game, but the dialog is incredibly well-written. It's going to take a while to read it all and determine if it's a "yes" or "meh" from me, so stay tuned. Edit: I ended up deciding on "meh" for entertainment as a result of the text-based nature of the game limiting my potential enjoyment, but you've managed to trivialize months of my own frustration and that has still made me very happy.
I'm not as active as I once was, but I can be reached here if I should be needed.
Post subject: Re: #6162: c-square's DOS Hitchhiker's Guide to the Galaxy "100%" in 00:12.68
Player (26)
Joined: 8/29/2011
Posts: 1206
Location: Amsterdam
Forty-two yes votes!
fsvgm777
She/Her
Senior Publisher, Player (226)
Joined: 5/28/2009
Posts: 1217
Location: Luxembourg
Personally, I cannot find a game that's strictly text-based to be entertaining at all, be it at normal speed or slowed down. Voting no on entertainment.
Steam Community page - Bluesky profile Oh, I'm just a concerned observer.
Active player (378)
Joined: 9/25/2011
Posts: 652
Added a link to the TASScript for those who want to see the inputs. Thanks for the comments and votes, everyone!
DrD2k9
He/Him
Editor, Judge, Expert player (2221)
Joined: 8/21/2016
Posts: 1091
Location: US
fsvgm777 wrote:
Personally, I cannot find a game that's strictly text-based to be entertaining at all, be it at normal speed or slowed down.
This is likely a common (if not majority) perspective. For myself, this is one of those games where the bulk of the TAS's entertainment value is derived from an understanding/familiarity of the game outside of the TAS community. A TAS can be entertaining because it's simply fun to watch, or it can be entertaining due to a familiarity with the game being TASed even if the resulting movie isn't visually entertaining. There are many games with TASes which I find quite entertaining visually even though I've never played the game before. Having played this game (and others of its type) before, I find it quite entertaining. I probably wouldn't without this foreknowlege. Are TASes of text adventures entertaining to watch visually? Not in the least bit. Is this one entertaining from the perspective of seeing a familiar game/genre destroyed so quickly? Absolutely.
TiKevin83
He/Him
Ambassador, Moderator, Site Developer, Player (155)
Joined: 3/17/2018
Posts: 358
Location: Holland, MI
As someone familiar with the Hitchhiker's Guide books, watching the slowed down version is an interesting way to relive some of the source material while getting to enjoy speed tech at the same time. However, the final product is so fast that it loses the charm of both the novel and getting to see how the speed tech works. Feels like it would be appropriate for vault?
upthorn
He/Him
Emulator Coder, Active player (392)
Joined: 3/24/2006
Posts: 1802
I actually did enjoy the full fast version simply because I remember how long I spent playing the game as a kid without ever managing to complete it. (I did get past the babel fish, but I think I was on the version with a built in hint-book.)
How fleeting are all human passions compared with the massive continuity of ducks.
Hopper262
He/They
Joined: 3/22/2011
Posts: 55
In the versions I've played, including the online one, only the first six letters of a word are examined by the parser. This means you can type "satche" instead of "satchel", for instance. 11 keystrokes are used on words longer than this limit. EDIT: Nope, this trick doesn't work on this submission's executable. It does mean an earlier release might be faster, depending on luck manipulation. I'm curious about the time needed to type vs. waiting for lines. Playing along with the TAS, I notice you "get gown" instead of "get all" which spends one character to save several lines of output, so you presumably didn't go strictly for minimum character count. In the pub area, you could sacrifice two keystrokes to skip one wait turn, which might be worth it depending on the time and how luck manipulation works. (You can buy the sandwich instead of "z" before "sip", but you have to type "cheese" instead of "it" at the dog.) EDIT: If turns are instead faster than typing, you can wait twice to automatically ask Ford about your home. Perhaps these fall under "too many of these situations to test out", but I wonder what routing improvements may be lurking. I find text adventures to be an interesting optimization problem, even if nobody "watches" this TAS in the traditional sense. (Even in other genres, I often find the descriptions more entertaining than the videos.) Thanks for making and sharing this!
Active player (378)
Joined: 9/25/2011
Posts: 652
Hopper262 wrote:
In the versions I've played, including the online one, only the first six letters of a word are examined by the parser. This means you can type "satche" instead of "satchel", for instance. 11 keystrokes are used on words longer than this limit. EDIT: Nope, this trick doesn't work on this submission's executable. It does mean an earlier release might be faster, depending on luck manipulation.
Yup, you beat me to it. I tried that and it didn't work for the version I had, but someone could possibly obsolete this run using an earlier version. Also, at least one other version mixes up the second verse of the poem, making the shortest word "thou" instead of "Bleem", saving a keystroke there too.
Hopper262 wrote:
I'm curious about the time needed to type vs. waiting for lines. Playing along with the TAS, I notice you "get gown" instead of "get all" which spends one character to save several lines of output, so you presumably didn't go strictly for minimum character count.
Good catch. Yes, in this case it's clear it's worth spending the extra character to type "gown". Get all has you try to get the screwdriver, the toothbrush and the telephone, each with a description about how you can't get them.
Hopper262 wrote:
In the pub area, you could sacrifice two keystrokes to skip one wait turn, which might be worth it depending on the time and how luck manipulation works. (You can buy the sandwich instead of "z" before "sip", but you have to type "cheese" instead of "it" at the dog.)
That was a conscious choice to avoid having to type out "cheese" again, but I didn't take into account the extra two characters for the wait. You're right, it's possible typing the two extra characters may be faster than the extra turn waiting.
Hopper262 wrote:
EDIT: If turns are instead faster than typing, you can wait twice to automatically ask Ford about your home.
For this one, I think we can certainly say yours is faster. For some reason I was under the impression you got points for asking about your home, but it turns out that's not the case.
Hopper262 wrote:
Perhaps these fall under "too many of these situations to test out", but I wonder what routing improvements may be lurking.
I have a feeling there are a bunch of small improvements to be found in here. Unfortunately, I don't have time currently to hunt them out or make the updates. However, TASScript makes it pretty easy to make the updates, so you or anyone else is very welcome to take the existing script and make improvements! I'll be happy to give pointers.
Hopper262 wrote:
Thanks for making and sharing this!
You're quite welcome! I'm hoping this is just the first of more to come.
Hopper262
He/They
Joined: 3/22/2011
Posts: 55
c-square wrote:
However, TASScript makes it pretty easy to make the updates, so you or anyone else is very welcome to take the existing script and make improvements! I'll be happy to give pointers.
Thanks for the responses, and TASScript does look quite cool -- I wouldn't have even started digging into this run's details if the input weren't so legible. If I get away from my hundred other unfinished projects, I'll try not to overwhelm you with questions. ;) Best of luck on the Zork project!
Banned User
Joined: 3/10/2004
Posts: 7698
Location: Finland
If there was an award for the least entertaining TAS, this might be a major contender. (Of course it's not the author's fault. It's the game's fault. Text-based adventure games, with zero pictures, don't make for entertaining TASes.)
Active player (378)
Joined: 9/25/2011
Posts: 652
Warp wrote:
If there was an award for the least entertaining TAS, this might be a major contender. (Of course it's not the author's fault. It's the game's fault. Text-based adventure games, with zero pictures, don't make for entertaining TASes.)
I agree that, for those with no experience with the game, this has zero entertainment value (and I’ve been pleasantly surprised at how many yes votes this TAS has actually received). That said, there have been many submissions over the years that have had negative entertainment value, or have been painfully sub-optimal, and I think those would be better contenders for the award.
Editor, Expert player (2080)
Joined: 6/15/2005
Posts: 3284
Thanks for the TASScript; it really helped to see the exact inputs. That being said, the "slowed encode" seems pointless to me since it is not a slow video of the normal encode (which I thought it was at first), it doesn't even use the same commands, and I still can't read it. Personally, I'd just dump the contents of the entire console input/output as text. I can't really say that this was entertaining in any way (similarly for a number of hyperspeed DOS TASes). However, it is complex enough that I can admire the amount of work that went into optimizing this. It also helps that I like adventure games, which are known for this type of complexity. On the other hand, if we look at, say, CD-Man, I don't see this kind of complexity; the only thing I am left admiring is the author's apparent masochism. (Submission descriptions are very important in influencing opinion. This is true especially for hyperspeed DOS TASes.)
Active player (378)
Joined: 9/25/2011
Posts: 652
FractalFusion wrote:
Personally, I'd just dump the contents of the entire console input/output as text.
Is that doable? If someone tells me how, I'll export the console and post it.
On the other hand, if we look at, say, CD-Man, I don't see this kind of complexity; the only thing I am left admiring is the author's apparent masochism.
Ha ha ha! Yes, that was certainly a painful exercise. But even that would now be a lot easier with TASScript. :)
Personman
Other
Joined: 4/20/2008
Posts: 465
I am extremely entertained by this on many levels. Seeing the minutiae of the parser explored to this level is very interesting to me, and even watching the fast encode was neat in that it gave me a sense of the fundamental size of a solution to the game. One question I have is, what factors determine the speed of text output? Does it matter what CPU or display resources are available to the DOS VM? Given that tradeoffs are being made with input size, it would be nice to know the actual values too – how much time per input keystroke, and how much time per output character (or is it per output line?).
A warb degombs the brangy. Your gitch zanks and leils the warb.
Active player (378)
Joined: 9/25/2011
Posts: 652
Personman wrote:
I am extremely entertained by this on many levels. Seeing the minutiae of the parser explored to this level is very interesting to me, and even watching the fast encode was neat in that it gave me a sense of the fundamental size of a solution to the game.
Hurray! I'm always glad to know others find this kind of thing interesting.
Personman wrote:
One question I have is, what factors determine the speed of text output? Does it matter what CPU or display resources are available to the DOS VM? Given that tradeoffs are being made with input size, it would be nice to know the actual values too – how much time per input keystroke, and how much time per output character (or is it per output line?).
I'm sure changing the CPUDivider (increasing the CPU clock speed) would have a direct impact on the speed of entry and text display. I'm not quite sure what you mean by "display resources", but I doubt emulating a CGA monitor as opposed to a VGA monitor would make any difference. As for exact values, an input keystroke takes exactly 0.66666 ms to enter, or roughly 4.8% of a frame. Put another way, you can type a maximum of 21 keys per frame. Certain keystrokes (such as the arrow keys) take twice as long, so alternates should be used if possible when making a TAS. How long it takes for the game to register the keystroke depends on the game. In this game, each key takes 1.3 ms to register, meaning approximately 11 characters can be registered per frame. How fast the game outputs descriptions is variable. There seems to be a certain amount of time to process a command, followed by anywhere between 1 and 5 lines of output per frame. If you go past a full screen of descriptions, there's a one frame pause to clear the "[MORE]" message. Stopping to set up for the next input also takes up part of a frame. In the end, I can see an argument that saving a few lines of descriptions may be worth a few more input letters, but there doesn't seem to be an exact measurement as to where that boundary lies.
Personman
Other
Joined: 4/20/2008
Posts: 465
I'm not quite sure what you mean by "display resources"
I probably just don't know enough about how DOS works to be asking a reasonable question; I was kinda thinking in terms of unix terminal emulation layers. I have no idea what systems DOS has between a program attempting to output characters and those characters appearing on the screen, but it seemed possible that some of them might be emulation settings rather than core to the OS.
How long it takes for the game to register the keystroke depends on the game. In this game, each key takes 1.3 ms to register, meaning approximately 11 characters can be registered per frame.
Does this mean that there is essentially a frame rule? If a frame starts and you press "n<enter>", presumably the game can't start producing output until the next frame, right? So you could have typed 9 more characters with no time loss?
A warb degombs the brangy. Your gitch zanks and leils the warb.
DrD2k9
He/Him
Editor, Judge, Expert player (2221)
Joined: 8/21/2016
Posts: 1091
Location: US
Personman wrote:
Does this mean that there is essentially a frame rule? If a frame starts and you press "n<enter>", presumably the game can't start producing output until the next frame, right? So you could have typed 9 more characters with no time loss?
Frame Rules are more along the lines of 'X number of frames must pass from point A to point B in a game before the next game event occurs (assuming all other necessary requirements are met). What you're asking about is more about a limitation based on how quickly the inputs are processed by the game. This would be specific to the game, not the DOS operating system. The DOS/emulator limitation is the timing of the key presses. If the game can process and output all input within a single frame upon the very next frame, there could be as many as 21 key press inputs processed and output within that frame. There's not really such a thing as simultaneous inputs (as we would see in a Piano Roll like for TASStudio in BizHawk) as DOS processes each key press sequentially. Another part of the timing of key presses for DOS is timing both key-down and key-up aspect of the keypress. Pressing a key (key-down) takes .66666 ms. Then the key is then considered held down an indefinite number of frames (with no additional time cost) until a command to release the key (key-up). At that point it takes an additional .66666 ms to release the keypress. TL:DR So in brief, it's not a frame rule imposed by the game, it's a limitation of the 'hardware' and operating system.
Experienced player (940)
Joined: 7/18/2016
Posts: 107
Location: United States
I'm giving this a yes for the creative submission notes :))
Personman
Other
Joined: 4/20/2008
Posts: 465
DrD2k9 wrote:
words
That.. was a rather long-winded and condescending way of, I think, saying "yes" to my question? I know what a frame rule is, and I know that this isn't literally exactly the same as, say, the SMB1 21-frame rule, which is why I used the word "essentially" in my post. And it is really essentially the same principle – if you consider the DOS key polling time analogous to NES input frames, and HHGG frames analogous to the level end routine, the logic is exactly the same. HHGG won't process your inputs until 11 key polling intervals have passed, so, in the same way, you can "waste time" without actually wasting time. It seems like this could probably be profitably applied – 11 characters is a lot, so I bet there are some longer commands that would fit within the rule window while reducing text output.
A warb degombs the brangy. Your gitch zanks and leils the warb.
Active player (378)
Joined: 9/25/2011
Posts: 652
I like where you’re going with this. Unfortunately, there isn’t room for adding letters without impact. You can consider this game like an auto-scroller (of text) scrolling up. At regular intervals, the game stops scrolling until you input the next command and hit enter. We can minimize the stops by chaining as many commands as possible into one input. After that, it’s just a matter of getting to that enter key as fast as possible to get the scrolling started again. Since there is no frame rule on the start of scrolling (i.e. hitting enter on key input #1 starts scrolling faster than hitting it on key input #2) every additional command letter delays scrolling by 1.3 ms. (For what it’s worth, I thought DrD2k9’s explanation was pretty accurate, which is why I didn’t end up responding myself)
DrD2k9
He/Him
Editor, Judge, Expert player (2221)
Joined: 8/21/2016
Posts: 1091
Location: US
It was definitely not my intent to sound condescending. I actually thought it was a great question. I was simply doing the best I could to explain the timing. I tend to err toward being long-winded fearing I may leave out necessary information otherwise. I still personally don't equate this input situation to a frame-rule. My perspective: Frame rules restrict in-game events to occur only upon a certain frequency/cycle of output frames. This is a programming issue. The DOS/jpc-rr typing situation is more an issue of an input/output delay due to hardware, not a delay/restriction of event occurrence due to programming. Further (albeit slightly off-topic) thoughts on inputs: Emulation is the primary difference between inputs for DOS in jpc-rr and most other system emulators accepted on tasvideos.org (i.e. BizHawk/FCEUX for NES). JPC-rr is designed to process a certain number of sequential key presses (or releases) within one frame's worth of time. There's no such thing as instantaneously simultaneous input in jpc-rr, though the effect of simultaneous input can still result depending on the program being run. JPC-rr also allows for the same key to be pressed multiple times within a given output frame, something not emulated by many other accepted emulators. All key-presses are read by the hardware even if the game itself doesn't use all the sub-frame inputs. Using NES as a comparison, BizHawk and FCEUX only emulate whether or not a button is held down on a given frame. This is actually an emulator restriction, not a hardware restriction. The hardware of the NES and its game-pad is capable of processing multiple button presses (of the same or different buttons) within a frame. Multiple sub-frame inputs have been proven and used on actual NES hardware. Just as a DOS game's programming determines if the key-presses read by the hardware are used for output by the game, the NES cartridge programming does the same for the button presses read by the controller. In the situations where a game only polls input at certain intervals, "Goofing off" with extra inputs in the time between those intervals may be theoretically possible, but would go completely unnoticed by a viewer because there'd be no visual effect on the game/movie. So unless someone were to read the movie file itself, it's a waste of effort to have goof-off inputs in between processed inputs. Similar to how inputs during lag have no effect. So more specifically to your earlier question
So you could have typed 9 more characters with no time loss?
Yes having more inputs within the frame shouldn't lose any time before the impact of the 1st input is seen. However, it's possible (and the case in this game) that those extra inputs will still be processed by the game and have a resulting impact of their own, so they aren't necessarily lost/useless inputs simply because they're performed on the same frame before the output of the fist command is visualized. In some cases, these extra inputs can absolutely be used beneficially to 'pre-type' the next command before the screen displays that it's ready for the next command. In fact, this method is the fastest way to provide input for simply starting up a game in jpc-rr. This is what makes c-square's work on TASscript so beneficial. Inputs can be optimized to the sub millisecond, not just optimized based on frame timing. Even before TASscript was available, some DOS TASes on the site (Space Quest 1 & 2, Kings Quest 1) used multiple sub-frame inputs to affect/optimize character movement. There may even be slight improvements possible on those games now by using TASscript. For what it's worth, I think it would be amazing to have TASscript type editing ability for other systems besides DOS. Being able to affect games output with sub-frame input is a huge advantage in TASing. As a community, we could potentially find many more optimizations and or ACE opportunities (as has been demonstrated on SMB3) if this type of sub-frame input tool existed for other systems. I'm curious how much work it would take to implement sub-frame input into BizHawk/TAStudio or if the various emulation cores used would even allow for it....I'm going to ask this in the BizHawk topic.
Active player (378)
Joined: 9/25/2011
Posts: 652
TheWinslinator wrote:
I'm giving this a yes for the creative submission notes :))
Thanks! I was hoping people would enjoy them. I do have to credit Wikipedia for a lot of the content, which made it a lot easier. I also have to say that I did not expect this run to get over 50% yes votes, so I'm extremely pleased at the reception this run has had. Makes me feel the run was well worth the work put in.
Personman
Other
Joined: 4/20/2008
Posts: 465
Sorry DrD2k9, I maybe overreacted there. I appreciate you taking the time to respond in depth. I think part of why I felt like your original reply was talking past me is that I didn't (and I think still don't) understand the input model here correctly. You refer in your latest post to "goofing off", but that's not what I was suggesting — I was talking about optimizing speed by typing longer commands (at no cost) that result in less text output. I'm pretty confused now, though, about how to reconcile c-square's claim that this is impossible ("there is no frame rule on the start of scrolling (i.e. hitting enter on key input #1 starts scrolling faster than hitting it on key input #2)) with your claim that "having more inputs within the frame shouldn't lose any time before the impact of the 1st input is seen."
A warb degombs the brangy. Your gitch zanks and leils the warb.