Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
DrD2k9 wrote:
Curiosity on SQ1, does the year (1986) consider the game/interpreter version?
For that matter how should we consider game versions released in later years than the original game? (sorry if this was already answered somewhere else)
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
Hi feos,
I'm not certain this is what you're asking, but there are three published runs that are considered "overclocked" by the table I posted last, and by the current rules would require being recreated from scratch to improve them:
Castle Adventure (1984) by Ilari & Truncated
Run's CPU Divider: 50 (20 MHz)
CPU Divider of that Year: 90 (11 MHz)
Hitchhiker's Guide to the Galaxy (1984) by c-square
Run's CPU Divider: 50 (20 MHz)
CPU Divider of that Year: 90 (11 MHz)
Space Quest 1 (1986) by DrD2k9, c-square & Radiant
Run's CPU Divider: 50 (20 MHz)
CPU Divider of that Year: 55 (18 MHz)
All other DOS runs are actually considered "underclocked", which is allowed by the new rules.
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
DrD2k9 wrote:
Ok. Here is the table of CPU Dividers for JPC-rr.
Thanks for this list. I've looked over it and something just doesn't feel quite right about it. For example, I doubt the 40MHz 386 in 1985 was over 1.5 times faster than the 25 MHz 486 that came out four years later in 1989. I think basing this just on clock speed leaves out all the architectural improvements, as well as the ability to access things like faster RAM and more efficient CPU coding.
If we do want to use clock speed, I recommend we take a simplified approach. As I usually don't have the intended CPU specs for any given game I run, and the values in the list vary wildly even within the same year, I propose we use a trend average for each year by default. I plotted all the clock speeds from the link you referenced and took a trend line (.ods file).
(Processors with multiple values were averaged)
Of course, if someone wants to dig up the original game specs and choose a specifically supported CPU from your list, they'd still be more than welcome to.
feos wrote:
What's the grandfather clause again?
I'd like the option to be able to submit an improvement to a run using the same CPU Divider setting as the currently published run, even if it is higher than the game was intended to run on. Otherwise, none of the work done previously would be reusable, and all work would have to be done from scratch.
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
feos wrote:
I improved the wording. As written in the edit note: "We can't draw the line based on amount of variations of some option. Really wide ranges may be explicitly supported. And non-arbitrary modes may be unintended. So instead, make sure the option is intended for normal play." Now this is in line with the rule about in-game codes BTW.
http://tasvideos.org/MovieRules.html#PcGameEnvironmentMustBeLegitimate
I like it; it's now clear that any supported settings are allowed. Thanks for clearing that up.
I'm still concerned about the new DOS TASser who picks up JPC-rr for the first time and does a run with it, just to find out after submitting that the default CPUDivider value is too high and all her work is lost. It is a particular issue because the emulator instructions explicitly state:
Do not touch the other fields unless you know what they do, they are for advanced users.
Replacing this instruction with the list of speeds by year that DrD2k9 is coming up with would fix this. Or we could leave the instruction and always allow the default value as acceptable, with those who want to go higher bearing the onus of proving their case.
Finally, I'm still hopeful for a grandfather clause for improvements on existng runs, however the fact that underclocking a game is now allowed makes this less pressing.
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
Pokota wrote:
feos wrote:
To answer your megapost, it seems I should make it "and don't belong to point 1 or 2". If a game explicitly tells you to set whatever value you want, any value is supported. If it tells you to set up to 125% and beyond that you're on your own and no guarantees are made, it's not explicitly supported.
Space Quest is covered by this expansion. I believe CDMan is as well (as long as it doesn't warn you when passing a certain threshold that unexpected effects might happen)
I may be missing something, but I don't see know adding the line "and don't below to point 1 or 2" solves the issue.
Point 1 is limited to options that can be changed "without affecting the gameplay". Point 2 is limited to "limited non-arbitrary options". The sliders above affect gameplay and are considered arbitrary, so they don't belong to points 1 or 2, and thus fall to point 3 which says they need to be kept at their default values.
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
feos wrote:
So you can't obsolete a run by changing the environment, even if you change it to be more accurate. You can only obsolete it with new tricks or optimization, with gameplay improvements.
I'm glad to hear that. That certainly alleviates some of my concerns.
feos wrote:
How many of your projects depend on CPU speed that hard?
All of them. As soon as you change the CPU divider, or practically any other setting in JPC-rr, the entire run will desync requiring it to be remade from scratch.
feos wrote:
your problem should only be with games whose gameplay is affected by CPU speed AND default jpc-rr speed is too high for them.
Yes and no. First, all my published DOS runs (and many others' as well) have gameplay that is affected by CPU speed. But furthermore, the rule is:
If changing the CPU frequency introduces gameplay differences ... set the CPU frequency divider to emulate the CPU speed intended for this game
Submitting an improvement of a run using the default slow CPU for a game that was written for a fast CPU is as much in violation of the current rule as vice versa. Thus, unless the default 20 mHz just happened to match the intended CPU of the game, no improvements are possible until the CPU divider is updated which, as mentioned above, would then force me to start over from scratch.
If a runner wants to improve a run using a more accurate CPU setting, that's fine. However, I would at least like to have the option of improving a run using the same CPUDivider settings as the published run. In the end, it increases the quality of the publications on the site, while leaving the authenticity no worse than it originally was.
feos wrote:
Non-arbitrary explicit options presented as modes:
Choose game speed:
50%
100%
150%
So, for example:
This makes total sense to me why this would be allowed.
feos wrote:
Arbitrary setting:
Choose game speed:
50% - 150% slider
An example:
It doesn't make sense to me why we'd be forced to keep this speed setting at the default value.
Then there's this:
It has explicit options presented as modes, but is on a slider, but the slider has 100 distinct non-arbitrary values. I'm not sure how to classify this one, but again, I can't see why we wouldn't allow a runner to use the value that results in the fastest run.
DrD2k9 wrote:
If it helps, I can make a list of valid CPU dividers based on CPU speeds available sorted by year.
That would be wonderful. Could you make it so it has both CPU Dividers and DOSBox settings?
Many thanks, DrD2k9.
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
feos wrote:
c-square wrote:
1) Currently published TASses and all obsoletion attempts of those TASses are granted an exemption
I'm sure no one intended these rules to suddenly invalidate any existing publications, but I think it would be good to be explicit about it. But furthermore, in order to be able do a fair comparison, any future runs attempting to obsolete a published TAS must be done at the same CPU settings as the published TAS, regardless of whether or not it adheres to the new rules.
Where are you getting this from?
I wasn't clear; the above is what I want to add. Once a speedrun is published, it should set the bar for that game for three reasons:
1) It allows for a clean way of comparing a run against its predecessor to know which one is faster.
2) It means I can still use the same save states and TASScripts if I ever want to try and improve one of my runs. Switching CPUdivider settings would force me to have to start my existing runs from scratch, and I would lose all the work I did. It certainly would make me think twice about making improvements.
3) It means someone else can't come along later and obsolete an existing run simply because they've uncovered an old document saying that the game supported a faster CPU and upped the CPU settings with no other changes.
feos wrote:
Why are you skipping the part that addresses explicit in-game options directly?
I think this is where I'm getting confused. Both the second point and the third point talk about "in-game settings", the difference seeming to be whether the settings are "arbitrary" or "non-arbitrary". Would you explain what is the difference between limited arbitrary settings and limited non-arbitrary settings, preferably with some examples?
feos wrote:
c-square wrote:
Finally, because refactoring in JPC-rr is such a pain, it would be good to provide authors with an official list of accepted CPUDivider settings for each year, so TASsers can refer to it and know that they're safe to choose that setting before starting. It would also help judges to know if submissions meet the guidelines. I'd be very happy to submit a list for review and official adoption.
This would help a lot, but being released the year when some CPU was available doesn't automatically mean it was supported. But for cases when no info about explicit support is known at all, this will help.
I wrote earlier about my concern that the new rules would create an extra process for those making PC runs, and could dissuade people from taking up a PC run for the first time. I still have those concerns about the new rules. In my mind, it's not a far stretch to have a pre-approved list of mid-range CPU settings for each given year that we can reasonably expect the majority of games released then would have supported. An author then has the choice to either pick the pre-approved value based on the game's release date and not worry about having to hunt for documented game specs, or can choose to pick a higher value by doing the research legwork to defend the decision. I think we can strike a good balance that provides reasonable authenticity while still giving runners the option of a quick confirmation of their system setup.
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
Although I'm okay with the rule for authenticity, there are a couple things I'd like added/changed:
1) Currently published TASses and all obsoletion attempts of those TASses are granted an exemption
I'm sure no one intended these rules to suddenly invalidate any existing publications, but I think it would be good to be explicit about it. But furthermore, in order to be able do a fair comparison, any future runs attempting to obsolete a published TAS must be done at the same CPU settings as the published TAS, regardless of whether or not it adheres to the new rules.
2) I feel as though I must be misunderstanding the following rule:
In-game settings and environment parameters that have arbitrary nature and don't belong to point 1 should be left at default values. Deviations from those are disallowed from Vault.
For example, if the game allows to set arbitrary speed factor (even limited to some range), picking arbitrary values can only belong to side branches, not to fastest completion (and%) or full completion (100%).
There are many games with in-game speed settings, allowing the player to adjust the speed of gameplay. Often times, setting these to the highest speed increases the difficulty of the game, and so acts both as way to make a faster speedrun and at the same time results in a more impressive accomplishment. Examples from my own runs include the Sierra games, Sid Meier's Railroad Tycoon and, of course, the CD Man game. All of these would have suffered in both entertainment and quality if they were forced to keep to the default in-game speed settings.
I don't see why PC games should have a special rule forbidding the use of in-game options that affect gameplay that other platforms don't have to follow.
Finally, because refactoring in JPC-rr is such a pain, it would be good to provide authors with an official list of accepted CPUDivider settings for each year, so TASsers can refer to it and know that they're safe to choose that setting before starting. It would also help judges to know if submissions meet the guidelines. I'd be very happy to submit a list for review and official adoption.
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
btl wrote:
Can the sound issues be the cause of the desync?
Practically any settings change will make a desync happen in JPC-rr, which is why it's very important to get your settings finalized before starting to make your movie. That said, last year I created an improvement to the emulator to make recovering from a desync a lot less tedious. It also contains the ability to drag the mouse pointer which I think would be useful in making your run. I highly recommend checking it out!
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
Warp wrote:
In my opinion, if a clear-cut fair system cannot be established due to practical reasons (after all, who gets to decide what speed the original developers "intended" the game to run at?), then these early DOS games that run faster on faster PCs should be excluded from anything where completion time matters (including awards and, perhaps, Vault? Because Vault is all about completion time, and when the completion time can be semi-"cheated" by emulating a faster PC, it kind of makes it pointless. Who gets to decide what the "correct" speed is?)
This is one of my big concerns with this whole conversation, that DOS TASes will somehow end up being treated differently than runs from other platforms. If they are explicitly excluded from things like awards or the vault category, then DOS TASses effectively become a lower-class type of run. We currently have rules that establish a fair and balanced playing-field, and DrD2k9 has proposed some others that would also be fair and balanced, so I don't see any reason why we'd ever have to consider getting to the point of limiting the runs from any kind of standing or category.
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
There are a number of things that would have to happen to see this through:
- First, we'd need to define a list of CPUDividers that map to calendar years, matching the specs for what was a "high-end" system for that year.
- Next, we'd need to have rules defining how we determine what year (and thus what CPUDivider) should be used for any particular game. Is it by initial release date? By version release date?
- We'd also have to come up with a way to compare existing runs with ones created under the new rules, to be able to tell if the old run should be obsoleted.
- Finally, the same three things would need to be done for DOSBox, to give us a way to compare a run done in JPC-rr against a run done in libTAS.
From a personal perspective, I can understand the value of trying to get some authenticity in the speed settings used for the games. 20 mHz is an arbitrary number, and there's really no rationale for using that over any other number except that it happens to be the default value for the emulator.
That said, I'm hesitant to add another rule or complication to making DOS TASses. The DOS platform has far and away the largest TASsable library of any platform we support here, and yet at the same time it has one of the smallest sets of TASsers. People have been discouraged from trying out DOS TASsing because of both real and perceived barriers, and while I'm trying my best to slowly make it easier for people to get into making DOS runs, I would hate to add one more hoop people have to jump through to make a DOS TAS.
And so, in the end I'm torn. I like the simplicity now that people can just pick up the tool and start TASsing without having to worry about CPU settings. At the same time, I can see the argument that the oldest DOS games will get inaccurately skewed by the default setting. I don't know if there's an easy solution that addresses both concerns here.
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
Mothrayas wrote:
We've concluded that [3793] DOS King's Quest: Quest for the Crown by DrD2k9 in 00:18.30 was excluded by mistake in judging Speedy TAS nomination entries. As such, it has now been added to the poll. As a consequence, the poll has been reset.
Apologies for the inconvenience.
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
Nach wrote:
c-square wrote:
I completely missed this, as there was no question in my mind that the KQ TAS qualifies. On high-end systems of its era, the KQ1 game was literally uncontrollable at the fastest game setting.
I don't know what you're talking about.
The KQ TAS is based on version 2.0F which was released in May 1987. In February 1987, 20 Mhz 386 computers were first coming on to the market, and JPC-rr at default settings runs at 20 Mhz. That's what I mean by high-end systems at that time making the game uncontrollable at the fastest setting.
Mothrayas wrote:
I'd like to point out that the point of requiring nominations to be justified is precisely to weed out nominations that were added in previous years but were not actually considered proper candidates (as Nach pointed out last year). So, the fact that these sort of movies were nominated in previous years does not mean anything.
Space Quest I was released in 1986-87 and Hero's Quest was released in 1989, the former when machines comparable to JPC-rr's performance were coming out, and the latter when they were very common. To me, they're both proper candidates, so I feel they are valid comparisons.
Even if you disagree with everything I've said above, it would be helpful to change the wording around the link to the list of "eligible TASes" in the original post. It's confusing to me to have nominated a run from the list of eligible TASes to then find out it's not actually eligible.
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
Nach wrote:
I was considering this, but I need more convincing that this is eligible.
The bulk of the speed that allows it anywhere near 18 seconds comes from running the game on a system much faster than it was designed for. The overall game-time is also not relevant for this award.
If we factored out the speed from overclocking the game, would you still consider the character movement to be insanely fast enough that you'd consider it for a speedy award?
I completely missed this, as there was no question in my mind that the KQ TAS qualifies. On high-end systems of its era, the KQ1 game was literally uncontrollable at the fastest game setting. The setting was there just so that low-end systems wouldn't be unbearably slow.
Furthermore, there's a lot of precedent for this, as Space Quest 1 was nominated in 2017, Hero's Quest was nominated in 2016, and CD-Man won in 2015. The same argument you made to keep KQ1 out could have been made for any of those, yet they qualified.
I kindly request you reconsider your decision, as I think it truly deserves to be on the list, and is arguably more deserving than either of the other two Quest games that did get nominated.
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
feos wrote:
Thanks. I don't think "full completion" goal is possible for this game, you just play the fastest route and end up getting full score because you simply do things right. Specifically, you have to do extra actions to lose score, while common understanding of "full completion" is doing extra actions to gain more points. For this reason, I think 400 points are inherent to fastest completion of this game, and the branch label is unnecessary.
Yeah, that makes sense. This really is just a fastest completion run.
P.S. Love the acceptance text. 😀
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
feos wrote:
c-square wrote:
Yes. Although getting all 400 points is mandatory, there are three ways to lose points in the game, and it's possible to end the game with fewer than 400 points.
Would that be faster than your movie?
No, as you'd have to spend time entering commands to eat the cheese sandwich, drink the ATS or turn on the spare drive before you need it. Each of these deducts 30 points from your score.
feos wrote:
c-square wrote:
- Using single-letter shortcuts where possible ("l" for look, "z" for wait)
- Using acronyms ("ATS" for "Advanced Tea Substitute")
List all of these please. I could assume what things mean, but I want to be sure.
n = north
s = south
e = east
w = west
sw = southwest
d = down
u = up
l = look
z = wait
g = repeat last command
ats = advanced tea substitute
Also forgot to mention the shortcuts of using just "no" for "no tea" and manipulating the shortest password to get the plotter.
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
feos wrote:
Phew, finally I've read it. It was constantly oscillating between horrendously boring and funny, and in the end I didn't like the experience I've had.
Yeah, I can understand that, as game is really just a set of in-jokes for people who have read the book.
feos wrote:
Questions.
What word shortcuts are you using throughout the run?
Efficiencies include:
- Using only verbs when nouns can be implied
- Finding the absolute shortest words ("rise" instead of "get up", "sip" instead of "drink")
- Using single-letter shortcuts where possible ("l" for look, "z" for wait)
- Chaining nouns (you can use "it" to refer to the previous noun you used)
- Using acronyms ("ATS" for "Advanced Tea Substitute")
- Referring to people by their real names ("Tricia" for Trillian and "Mr" for Prosser)
- Forcing the awl to be the tool chosen by Marvin
Other ones I liked are using "frisk" instead of "search" and "doff" instead of "take off"
feos wrote:
You mark this as 100%, are there ways to beat it with lower completion?
Yes. Although getting all 400 points is mandatory, there are three ways to lose points in the game, and it's possible to end the game with fewer than 400 points.
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
[3793] DOS King's Quest: Quest for the Crown by DrD2k9 in 00:18.30
18 seconds to finish this game is insanely fast, and the blur on the screen shows it. Also, that climb up the beanstalk is so hard that real-time runners refuse to take that route, even though it's faster.
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
Mothrayas wrote:
Personally, I actually like the water strategies. It adds a different element to routing, and even if it's not "perfect" in score, I don't see it as any different than taking damage or deaths to save time in other games. It adds a little unique flair to this particular golf game.
Yeah, I came to the same conclusion when I was watching the encode. It's the difference between a fastest time vs. a no-damage fastest time run.
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
That was fun to watch. Voted yes. I do think the timing should start from power on, as per the rules, and if a future TAS can save time by avoiding exiting and reentering the course, it should obsolete this run.
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
Some additional input:
DrD2k9 wrote:
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).
Unfortunately, in this game no text input is processed while the screen is scrolling. Text scrolling and input processing are mutually exclusive activities. Only once the game has stopped scrolling and opened itself up for input will it take in that input from the keyboard buffer, one key every 1.3 ms. That leads us to...
Option 3: n..get ham<enter>
This takes longer to get the screen scrolling than either Options #1 or #2, however keeps the parser from stopping after heading north to get the next command. Instead, the game fires both commands off back-to-back, which makes this the overall fastest result of all three options.
In reality, there's no such thing as a frame in DOS. DOS is running all the time, and JPC-rr just lets you get a peek at the current state every 14 ms. Luckily, although it restricts its video output to snapshots every 14 ms, it doesn't restrict your input, and you can fine-tune your input to the 1/1000ths of a millisecond if you really wanted to. What makes it variable (and where something like a frame-rule would come into play) is how often a game is programmed to poll for input. Quest For Glory takes 100 ms to poll for a single letter. CD-Man polls at least every 2 ms, probably less. (My apologies if I’m saying something that’s already been said. It’s late and I’m tired.) HHGG polls one letter every 1.3 ms but only when it’s waiting for a command. If it’s outputting text, it doesn’t poll.
Due to the different polling rates between games, each game will have a bit of a different strategy when it comes to optimizing a TAS, which is one of the things that makes DOS TASsing interesting.
Experienced Forum User, Published Author, Active player
(372)
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.
Experienced Forum User, Published Author, Active player
(372)
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)
(Processors with multiple values were averaged)
Of course, if someone wants to dig up the original game specs and choose a specifically supported CPU from your list, they'd still be more than welcome to.
This makes total sense to me why this would be allowed.
It doesn't make sense to me why we'd be forced to keep this speed setting at the default value.
Then there's this:
It has explicit options presented as modes, but is on a slider, but the slider has 100 distinct non-arbitrary values. I'm not sure how to classify this one, but again, I can't see why we wouldn't allow a runner to use the value that results in the fastest run.