Editor, Experienced Forum User, Judge, Published Author, Expert player
(2056)
Joined: 8/21/2016
Posts: 1011
Location: US
Mothrayas wrote:
This looks like it will be a very interesting matchup between the classic DOS side (represented by slamo) and the new Linux side (represented by keylie). Curious to see where it'll go.
This brings up a good question. For future years (assuming there are enough TASes of the various PC operating systems), would it be appropriate to have separate awards for each separate OS (linux, DOS, windows, etc.) instead of a single PC award?
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2056)
Joined: 8/21/2016
Posts: 1011
Location: US
In (minor) defense of my own King's Quest run: It's true that CPU speed settings affect how quickly the character is able to move. However with the increase of speed, there is a degree of control sacrificed.
Movement changes are only possible approximately every 3 frames (using any CPU speed settings I tried). How far the character travels within each frame is what changes with CPU settings. In other words, King Graham moves farther in 1 frame at 20mhz than he does at 10mhz CPU speed. With the opportunity to change direction still mostly limited to every 3 frames, faster CPU speeds actually introduce a greater degree of TASing difficulty due to lost movement precision.
So for this particular run, a degree of precision is lost to attain the speed it achieves. It's theoretically possible that faster (or possible even slower) CPU settings would yield a faster total run.
A faster CPU speed may allow for even faster character movement, but further precision would be lost. This would however break the rule of using default JPC-rr settings unless documentation could be provided to show the game was designed for faster than default settings.
A slower CPU speed may actually allow a faster total run as some movement precision would be gained by the slower CPU speed settings. If this gained precision allowed for fewer awkward movements through the run, the overall run may be shorter. Testing this could be quite tedious as it would likely require complete redos of the run to determine which is truly faster. (I'm somewhat open to this possibility, but have many other things on my plate at the moment).
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2056)
Joined: 8/21/2016
Posts: 1011
Location: US
Those are interesting (and rather strange) results of your testing. It makes me wonder what else may be affected in the run.
Unfortunately, this likely isn't something than can be generalized across all DOS games simply due to the insane variety of programs for DOS.
Thanks!
By the way, do you know why running fdconfig.sys saves 55 frames? Is it something that can be applied to other DOS games?
I don't know the exact reason, but fdconfig.sys contains a number of lines that mostly deal with memory usage. It's likely that processing fdconfig.sys allows the PC to use memory more efficiently thus minimizing the loading times later on in the run.
Another possibility is the FILES=40 line. This allows DOS to utilize 40 files at once. I don't know how many it would be able to use without this line. (I have read that 30 is actually a more efficient number than 40 for this line).
For reference, here are the contents of the fdconfig.sys file in the freeDOS floppy image.
shell=cmd80x86.com command.com /k autoexec.bat
dos=high
device=himem.exe
lastdrive=z
buffers=20
files=40
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2056)
Joined: 8/21/2016
Posts: 1011
Location: US
Personman wrote:
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."
WARNING: this is going to be a long post.
c-square, yourself, and I are all correct...we're just discussing subtly different aspects of input.
I'll try to explain with some hypothetical examples (not ones from this particular game).
If you want to move the character in a circle by going north, east, south, and then west; there are multiple ways to type the commands to do so.
Option 1: n<enter><enter>e<enter><enter>s<enter><enter>w<enter>
The way to read this input stream is as follows:
press 'n'
press <enter>
release <enter>
press 'e'
press <enter>
release <enter>
press 's'
press <enter>
release <enter>
press 'w'
press <enter>
In other words, 11 key press/release events.
This is the absolute fastest way to begin the screen scroll upon moving north.
This option assumes that not releasing the pressed down keys won't add additional letters to the text command and screw up the input. If it would, then the keys pressed down must also be released and result in more frames required to type both commands; this is because it takes the same amount of time to release a key as it does to press it down.
If it would work without releasing the letters pressed down, those keys would still need released at some point before they could be typed again. And as already mentioned, the key releases takes time.
Option 2: n..e..s..w<enter>
With this input stream, periods replace the first 3 enter presses. While it's equal at 11 inputs, the first <enter> press occurs 9 inputs later which may delay the start of screen scroll a fraction of a second. (This is what c-square was referring to by a later enter press having a delaying impact even though it's the same frame.)
Now let's say you wanted to move north and then pick up a ham.
Option 1: n<enter><enter> wait for output scroll until next prompted for a command then type get ham<enter>
This gets the screen scroll for moving north as fast as possible but delays inputting the next command.
Option 2: n<enter><enter>get ham<enter>
This gets the screen scrolling just as quickly as Option 1, but essentially pre-types the next command to pick up the ham before the screen scroll has completed. This allows for the output of picking up the ham to occur earlier than Option 1 and is thus more optimal. (This is what I meant by the extra key presses within the frame after the first enter press won't delay the start of the screen scrolling).
So finally let's discuss what I think you were wondering about:
You want to go north into an armory and pick up a shotgun from a selection of multiple weapons.
Option 1: n<enter><enter>get alll<enter>
This is the shortest possible input stream to get the earliest scroll and acquire the shotgun. It's 12 inputs long and thus would require at least two frames to do, but would likely all be processed before the screen stopped scrolling.
Unfortunately, it's also likely the character would pick up other unnecessary items which may later need dropped. This would require typing additional commands to drop those items resulting in a longer overall run.
It may also try to pick up unobtainable items resulting in extra output text that is useless but takes even more time.
Therefore it's likely suboptimal.
Option 2: n<enter><enter>get shottggunn<enter>
Though this input stream is longer, it is still less than 23 inputs and still only takes 2 frames to type. As with the above, it's likely that the processing of this input stream will occur before the screen is done scrolling.
This results in a longer command that yields a better outcome and shorter overall run, because nothing extra was obtained that would later require extra commands to drop.
Again, I think this was how you were asking about optimization. Sorry for all the confusion with goof-off input discussion (it is still good information, even if not necessarily on-topic).
I hope all that makes sense and helps consolidate all the previous explanations.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2056)
Joined: 8/21/2016
Posts: 1011
Location: US
Curiosity and potential feature request:
What would be required to implement sub-frame inputs in BizHawk?
My (possibly unrealistic) thought process on this would be to have an option for the piano roll of TAStudio to have lines labeled by input opportunities instead of frames, and thus have a new line whenever a change of input would be recognized by the game.
Using the NES as a specific example: Have TAStudio piano roll update with a new line every time the latch pin on the controller port is pulsed. This would essentially provide opportunity to change input every time the NES 'looks' for different input, not just changing input once per frame.
I'm guessing this would take modification of TAStudios programming if not the system cores themselves.
If this sub-frame input were available in an accepted emulator, we could potentially see more runs like the 3-second SMB3 run that was demonstrated at GDQ.
EDIT: Not sure why this posted twice...I'll delete the repeated post.
EDIT 2: Another option for piano roll would be to combine my idea with the current Piano roll. Have the roll still broken down by frame, but have additional indented lines (perhaps a different color like yellow?) for each latch pulse within a frame.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2056)
Joined: 8/21/2016
Posts: 1011
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.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2056)
Joined: 8/21/2016
Posts: 1011
Location: US
Hey, can you quit obsoleting my runs?
All joking aside, great work on the improvements. A 50 second improvement on this game is awesome!
I figured my run would be beaten at some point, as I assumed someone would eventually figure out better lag management. I didn't expect much in terms of route improvements.
Now I'm curious about implementing your improvements (aside from the hitbox thing) into the NA version to see how they would affect that run.
For the judge: Is this a situation where the hitbox issue yields enough difference to warrant separate version publications? If so, I'll revisit the NA version using ktwo's improvements and update it.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2056)
Joined: 8/21/2016
Posts: 1011
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.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2056)
Joined: 8/21/2016
Posts: 1011
Location: US
MUGG wrote:
And lag can be reduced by 1-3 frames on loading screens by button presses.
There's a looped instruction that can be interrupted via these button presses. -7 found the loop and made a lua to show which frames needed altered to minimize the lag by forcibly breaking out of the loop.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2056)
Joined: 8/21/2016
Posts: 1011
Location: US
TiKevin83 wrote:
I'd love to see a TAS of the DOS game Daleks:
I may look into this.
EDIT: Unfortunately Daleks does not display properly in JPC-rr. There is one primary issue, and one secondary (solvable).
1) JPC-rr does not use a correct resolution to display the entire game. I don't know how to correct this, but others more familiar with jpc-rr may. The game works fine in DOSbox.
2) The standard VGABIOS bundled with jpc-rr does not display the fonts properly to show the game characters. This issue is purely graphical and can be corrected with the ELPIN VGA BIOS that has been used with a couple other DOS games. The downside of this switch is a longer boot time. Switching the bios unfortunately does not fix the display resolution issue.
Sorry, TIKevin83. I tried. This one might have to go through a libTAS/dosbox method unless someone can figure out the resolution issue with JPC-rr.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2056)
Joined: 8/21/2016
Posts: 1011
Location: US
Welcome to the community!
For future reference, don't submit stuff you don't expect to be accepted. Use the userfiles to share those runs instead.
If you are expecting your run to be published, then officially submit that run.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2056)
Joined: 8/21/2016
Posts: 1011
Location: US
Some questions after watching the encode and reading through the game manual for the Atari 2600 version:
1) Is this run using the easy or expert game setting? (changed using the 'game select' switch)
2) The manual specifically mentions 14 crocodiles (which is exactly how many your run encounters), could the river portion be completed faster by killing all the crocs as soon as possible instead of letting some go by?
3) The manual states that the game becomes increasingly difficulty after each round of the 4 stages. (I don't know what changes with the difficulty curve.) Is one series of stages enough for completion? (this is probably best answered by a judge)
Side Note: To be fair, #3 made me question my own published TAS of Jungle Hunt for the C64. For reference, that publication starts at the hardest difficulty setting; and in the manual for the C64 version, there's no indication that difficulty increases beyond this point. (Looking back, I probably should have researched that aspect more myself to confirm that it didn't increase).
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2056)
Joined: 8/21/2016
Posts: 1011
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.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2056)
Joined: 8/21/2016
Posts: 1011
Location: US
Regarding 3D Battles of World Runner: I actually like the 2D version better. There's too many weird visuals after the 3D conversion.
For example, the pole hopping just looks like he's crashing straight through them instead of hopping off the tops of the poles. The boss fights are also wonky with background sometimes appearing in front of the boss/player sprites.
To put it simply, it's actually harder to follow what's going on in the 3D conversion.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2056)
Joined: 8/21/2016
Posts: 1011
Location: US
I'm not assuming anything regarding RTA rules. The examples I gave were just options.
I'm open to other sources for defining the RTA rules. I already also mentioned speeddemosarchive.com for example. Other options are always possible.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2056)
Joined: 8/21/2016
Posts: 1011
Location: US
Archanfel wrote:
...But i highly doubt that TAS rules regarding timing will be changed, after so many years of using it.
I haven't suggested this page as a reason to try an alter our rules...nor do I think our rules need altered.
It's just intended to be a page for reference and comparison.
ais523 wrote:
For high-profile runs, we sometimes write the time using other timing methods in the movie description. That seems like a better place to put it than having a centralised page listing every run.
Bear in mind that you have to specify the exact timing method used, because timing methods vary among the unassisted speedrunning community...Other timing methods used for unassisted running, such as SDA real-time timing and in-game timing, can give different results.)
While having a note in the publications themselves would be nice, having a consolidated list in a centralized location would also benefit those trying to quickly find published TAS runs that may have been beaten by RTA methods (kinda what EZGames69 is talking about).
Regarding exact timing rules: if the page is created, a link to the timing rules for each game would be included with the time differences. In the event that we use an atypical TAS timing method for a game's publication itself, a note would also be included for those games.
Archanfel wrote:
As variant we can keep both timing in title, something like:
[TAS] NNN - any% by NNN in 18:05 (17:58 RTA).
But we have thousands TASes... so it will be enormous work to correctly measure all published TASes with RTA timing.
And also as mentioned abow by ais523 in some cases RTA timing methods vary among.
While it may be a daunting task to start with, I'm willing to work through the current publications and curate the list as I am able. I've already got a jump on this from looking into post-completion input stuff.
Variation in RTA timing method is addressed by linking to the game-specific rules.
EZGames69 wrote:
I also want to point out that not all games with movies have RTA runs for them. for example: [3700] A2600 Crazy Balloon by EZGames69 in 04:02.13
So we cant exactly reference the RTA rules for that game if those rules dont yet exist.
True. For those games, we could just have a note that the RTA time is Not Applicable, and/or that specific rules haven't been established.
For games that do have RTA runs but the rules aren't written, we'd have to make some sort of estimate on when the RTA runs start and stop based on the videos of those runs.
