Fairly recently (within the past couple years) our rules on CPU speed settings for DOS runs via JPC-rr were updated to their current state:
Movie Rules wrote:
CPU frequency restrictions
CPU frequency settings may be restricted or not, depending on the game.
-If a game's speed is limited to real-world time or screen refresh, CPU frequency may be maximized by setting CPU frequency divider to 1 (emulating a 1GHz CPU).
-If a game's speed is limited only by CPU frequency or clock speed, CPU frequency may be set no faster than JPC-rr's default of 50 (emulating a 20MHz CPU). In other words, the CPU frequency divider settings may not be set any lower than 50. This limit may be stretched if proof can be provided that the game was designed to run on faster systems than the 20MHz default.
In other words, if increasing the CPU clock speed affects and speeds up all normal gameplay, it must be capped at most to the emulator's default setting, or to a frequency the game is proven to be designed for. If increasing the CPU clock speed only affects lag or loading times and does not otherwise speed up gameplay to any significant extent, it may be set to the emulator's maximum.
In light of the recent Speedy TAS nominations/discussion I think we may need to reconsider these rules, yet again.
While I understand both sides of the argument for the Speedy TAS award, this topic is not meant to have any specific connection to that contest; the awards situation was only the prompt of me questioning the current rules/guidelines.
As it stands, our rules allow for runs of DOS games designed for faster systems to use CPU settings above the default CPU frequency if proof is provided. This allows for more authentic speeds of these newer games.
However, we do not require runs of games designed for systems significantly slower than the default 20mhz setting to reduce that CPU frequency setting to an appropriate value based on system speeds around the time when the game was released.
I think we need to consider making this a requirement for DOS runs created in JPC-rr (and require proof of slower than default settings as we do with games having faster than default settings). As much as it'd be a bit disappointing to have to slow things down compared to some of the lightning fast runs already published, it'd be more authentic representation of these games.
As the Speedy TAS award discussion pointed out, some of these DOS runs are artificially faster than they should be. We don't allow overclocking of any other system just to make the runs appear faster than they otherwise should; we probably shouldn't allow it on DOS either simply because the default settings of the emulator happen to be faster than the systems the game was designed for.
If this rule is implemented, I believe that a lengthier DOS run which uses a more authentic CPU setting should be capable of obsoleting a currently published shorter run that used artificially inflated speeds (just because they were the default setting).
Suggested wording of the rule if it is decided it needs updating. (unless someone comes up with a better way to phrase it).CPU frequency settings may be restricted or not, depending on the game.
-If a game's speed is limited to real-world time or screen refresh, CPU frequency may be increased anywhere up to the maximum (setting the CPU frequency divider to 1
thus emulating a 1GHz CPU).
-If a game's speed is limited only by CPU frequency or clock speed, CPU divider should be set to a value yielding CPU speeds authentic to systems around at the time when the game was released. In other words, the CPU frequency divider settings may be lowered for games designed for faster systems than the default 20mHz, and it must be increased for older games designed for systems slower than 20mHz. Supporting information for the chosen speed settings is required in submission notes.
In other words, if increasing the CPU clock speed affects and speeds up all normal gameplay, it must be set to emulate an authentic CPU frequency of which the game is proven to be designed. If increasing the CPU clock speed only affects lag or loading times and does not otherwise speed up gameplay to any significant extent, it may be increased up to the emulator's maximum.Side Note: Implementing this requirement would mitigate future situations similar to what happened with this years Speedy TAS nominations.
Side Note #2: A potential parallel could be argued for games run in DOSBox via libTAS (when that method of TASing DOS games get's the official green light). DOSbox allows for adjusting CPU cycles speed. Care should be taken to replicate authenticity in CPU speed there also.
I disagree. The situation in the nomination thread appears because some people mistakenly believe the KQ1 movie is overclocked. In the late 1980s, PCs running at 4.7 MHz and at 20 MHz were both available on the market, and are both part of the target platform despite one being over four times faster!
I disagree. The situation in the nomination thread appears because some people mistakenly believe the KQ1 movie is overclocked. In the late 1980s, PCs running at 4.7 MHz and at 20 MHz were both available on the market, and are both part of the target platform despite one being over four times faster!
That particular situation doesn't change the fact that the rule needs reviewed and possibly revised. And if it does need changed, it's a good thing that situation occurred to prompt the questioning of the rule.
Just to reiterate, the concern this topic attempts to address is the rule, not any one particular run.
Even if this doesn't apply to KQ1 (or any other sierra games mentioned in that particular thread), the rules as currently written still offer the potential for artificially faster runs due to the default CPU settings emulating systems significantly faster than what some games were designed for.
With as much as we desire accuracy with the emulators of other systems (i.e. preferring NESHawk core over QuickNES because it's more accurate...or considering console verification as a type of gold standard), we should also show the same concern for the accuracy of DOS TASing. To me, that means playing games at CPU speeds they were intended to be played regardless of whether it's faster or slower than the default setting in JPC-rr.
the rules as currently written still offer the potential for artificially faster runs due to the default CPU settings emulating systems significantly faster than what some games were designed for.
My point is that this is not true. Inherently, PC games have always been designed not for one particular system setup (or CPU speed) but for several. A game released in, say, 1988 might be specifically designed for a 80386 CPU, but those still come anywhere between 12 and 40 MHz. And games are frequently intended to still work on a slightly older system, such as a 6 MHz 286 CPU, as well as whatever faster system comes out next year.
Let me give a concrete example. This is the first Civilization game. It has a 2:30 intro sequence, to give the player something to watch during the calculation-intensive world building process (similar to how Castlevania and Metroid have those slow passage rooms to mask their loading process). If you press ESC, the game will abort the intro as soon as the world is built. On a slow computer, this would take minutes (because that's why the intro is there); on a fast computer, it takes about a second. The game is literally designed to account for anything between 10 and 200+ MHz, because that's how the PC market worked at the time.
So in the 1980s / 1990s, you could absolutely buy a faster PC specifically so that games would run faster. And since actual players could (and did) do that, why wouldn't a TAS'er be able to?
The rules haven's appeared out of nowhere. There was due thread that led to the current wording. If something from that thread doesn't hold water anymore (in your eyes) point that out. We can't revisit rules without understanding why they are there in the first place.
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.
Looking back over both this and the other thread linked; and considering the question I've asked above, I'm no longer sure where I stand on CPU divider settings. These are further thoughts/questions in my mind now.
How can we effectively set a cap on how fast any particular DOS game can be run?
If we're allowing 20 mHz settings for games designed for slower systems than that, why can't we run a game that was released only when 33 mHz systems were available at even higher speed settings like 100-300 mHz? (as the rule is currently written, we'd have to provide proof to even raise the setting to the 33 mHz range).
Considering how much of the DOS game library was released after systems beyond 20 mHz were available, the 20 mHz cap seems somewhat arbitrarily chosen simply because it's the default in the emulator.
Further, can we even argue that games run at speeds higher than what they were designed for are being run 'artificially' fast?
If we do want to cap the speeds of DOS runs, is the default 20 mHz cap SLOW enough that any game designed for even slower systems could be arguably run at that speed?
If we do want to cap the speeds of DOS runs, shouldn't the cap value be calculable for any given game and not based on any one arbitrary value?
...spends time thinking...
After further pondering (even without answers to all these questions), I believe I'm to the point where I feel future DOS TASing should go one of two ways:
1) Have no CPU speed restrictions on any game so long as it can effectively be run in JPC-rr (or DOSBox via libTAS when available).
2) For all games, cap CPU speeds in JPC-rr/DOSBox based on a value able to be substantiated and specifically calculable for each individual game (i.e. year of release)...not on an arbitrary value or default setting. We require a level of researching games for the optimization of TASes, looking up this type of information wouldn't be any more difficult.
SIDE NOTE: When the time comes to restrict DOSBox cycles for matching system speeds (if necessary), the formula to convert between CPU clock speed and cycles is approximately as follows.
DB Cycles = 7.45(CPU clock speed in mHz)^2
It's not a perfect formula, but it yields a close approximation
Therefore a 100 mhz cpu is approximately 74500 cycles
10,000 cycles would be roughly a 36mHz CPU
This formula was created by plotting some of the information found here and then finding the curve formula.
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.
I agree. It would take much more work to implement the suggestion of capping all runs based on some calculable value. And it may not be worthwhile anyway.
Personally, I'm leaning more and more toward the idea that the other option is best: outright elimination of the speed cap, and simply allowing any DOS run to be performed at the maximum settings with which the game can be effectively completed.
I find Radiant's statement, that real people could simply use a faster system (than it was designed for) to play a game at a higher rate, to be a very valid point.
TASing is about actually accomplishing what would be super-human. So reiterating what Radiant said; if real people could do it, why should we prevent a TAS from doing it? In essence, forcing a cap is like preventing a TAS from doing something a human actually could; making it not super-human, but sub-human. Much of what we already do in TASing is beyond what developers planned or expected. Why should we isolate DOS TASing to be bound to developer intent regarding system specs?
Would having insanely fast runs detract from their entertainment value?...possibly. But it's not uncommon to have speed/entertainment trade-offs on our site. Normally, these trade-offs sacrifice speed to add entertainment, but the trade should be allowed to go the other way also....sacrificing entertainment to add to speed. In a way we do this all the time anyway (by commonly skipping cutscenes, text dialogue, etc.).
Eliminating the cap would eliminate the extra work necessary to substantiate the used CPU settings. It would further push TASing into the level of super-human. It would also negate the need to calculate and compare CPU speed settings between JPC-rr CPU frequency and and DOSBox cycles. Given the differences in emulation, timing comparisons would still likely need to be adjusted somehow; perhaps start timing when the command to start the game is input instead of from system startup (but that's an off-topic discussion for the future).
So now, my proposal is to eliminate speed caps for DOS runs. If we want TASes to be super-human...let's allow TASes to be super-human.
TL:DR Setting a cap on CPU speeds prevents a TASer from doing something a human could; thus preventing a TAS from being super-human.
Something I learned while doing the Mega Man DOS TAS: that game is not really CPU-limited. It is refresh-limited in the sense that once the CPU is fast enough to run the game at 70.09 fps, a faster CPU won't make the game run any faster. You can check this in DOSBox by pressing Ctrl+F12 to increase the cycles: above a certain threshold, Mega Man's blink rate doesn't increase. A faster CPU wouldn't shorten the TAS (except for load times, those would be shorter).
You can look at it this way: the game is limited by both CPU and screen refresh. It seems to have been written with the assumption that the CPU would be the bottleneck; i.e., the game relies on there being constant lag to run at a playable speed.
I tried increasing the CPU divider up to the maximum of 256, but it wasn't enough to cause lag. Gameplay ran at an identical rate, with the only difference being longer load times. I also considered using the in-game speed controls. Pressing F2 inserts busy-waits into the main game loop, in effect creating its own lag. This does slow down the game without distorting the sound effects. You can only slow the game down by discrete multiples of 1/2, 1/3, 1/4, etc., because of the nature of lag. I decided against using the in-game controls because it would have been annoying to TAS when 1 frame ≠ 1 gameplay loop, and would have been harder to compare to the previous TAS.
A rule change (in any direction) wouldn't affect the speed of the Mega Man TAS other than load times, unless the CPU were made slower than JPC-RR currently supports. Maybe this is a minority case. I would guess that most games are properly refresh-limited at a reasonable speed, or else are not tied to refresh at all and therefore a faster CPU always makes the game faster.
In the late 1980s, PCs running at 4.7 MHz and at 20 MHz were both available on the market, and are both part of the target platform despite one being over four times faster!
I think you would agree that it feels cheating to use a faster computer than what the original developers of the game intended. Surely the developers didn't intend for the game to run 4 times faster depending on which kind of PC you have.
(The problem with the very early DOS games is that developers didn't realize that PCs would become faster in the near future, and assumed that all PCs are the same speed, just like the "8-bit home computers" and consoles of the time.)
There was a discussion quite recently about this, and I don't think any sort of conclusion or decisions were really reached.
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?)
In the late 1980s, PCs running at 4.7 MHz and at 20 MHz were both available on the market, and are both part of the target platform despite one being over four times faster!
I think you would agree that it feels cheating to use a faster computer than what the original developers of the game intended. Surely the developers didn't intend for the game to run 4 times faster depending on which kind of PC you have.
I don't agree at all that simply using a faster system feels like cheating.
Using faster technology is no more cheating than using any other type technological advancement is cheating. That includes all other types of TASing tools including frame advance, piano roll, and even savestates. These all could be considered as a form of cheating from a developer's perspective.
(The problem with the very early DOS games is that developers didn't realize that PCs would become faster in the near future, and assumed that all PCs are the same speed, just like the "8-bit home computers" and consoles of the time.)
Can you substantiate this claim?
Just in the '70s, microprocessor speeds climbed from as low as 375kHz all the way up to 8mHz. Developers in the '80s at least had enough historical information to anticipate that further speed increases could continue.
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?)
Developer intent is a sticky qualification.
If we're going to disqualify games from vault/awards/etc. simply because they are run on a faster system (something the developers didn't 'intended'), then we should disqualify any run that use glitches from vault/awards/etc. as well, because those runs also use situations that the developer didn't intend.
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.
Using faster technology is no more cheating than using any other type technological advancement is cheating. That includes all other types of TASing tools including frame advance, piano roll, and even savestates. These all could be considered as a form of cheating from a developer's perspective.
Those aren't the same thing at all.
Using a faster computer to make the game run faster than it should, when the game itself doesn't adjust for that increase in speed, feels as much cheating as making a NES emulator run faster than it should. You can't argue that the latter isn't cheating because "frame advance" and "savestates".
If someone makes a TAS of such a game by emulating a 20MHz PC, what stops someone else from just doing the same with an emulated 21MHz PC? And a third person from doing so with an emulated 22MHz PC?
We would never, in a million years, accept a TAS of a NES game running on an emulator that's running faster than it should to achieve a shorter wallclock time. Why should we do that with any MS-DOS game?
(The problem with the very early DOS games is that developers didn't realize that PCs would become faster in the near future, and assumed that all PCs are the same speed, just like the "8-bit home computers" and consoles of the time.)
Can you substantiate this claim?
Is that a claim that needs substantiating? The very fact that DOS games exist that assume a certain speed from the computer, and don't adjust for varying speed at all, making them run at ridiculous speeds with a much faster PC. Surely the developers didn't intend for the game to become unplayable because it's just running way too fast in a future PC.
But even if you could prove with absolute certainty that the developers of a particular game knew this perfectly well and simply didn't care because they were lazy, that doesn't really make much of a difference with respect to whether we should allow arbitrary emulation speeds when TASing those games. Allowing arbitrary emulation speeds just makes the TAS pointless, because the only upper limit is how fast you can emulate it in your modern PC.
If we're going to disqualify games from vault/awards/etc. simply because they are run on a faster system (something the developers didn't 'intended'), then we should disqualify any run that use glitches from vault/awards/etc. as well, because those runs also use situations that the developer didn't intend.
You seriously cannot understand the ridiculous idea of allowing any emulation speed you want for DOS games?
Once again: If someone decides to make a TAS of a DOS game by emulating a PC running at, let's say, 20MHz, what stops someone else from doing the same thing but emulating a PC at 30MHz? Or 100MHz? Or 1GHz? It becomes meaningless. Obsoleting the TAS becomes meaningless, when you can simply do so by adding another MHz to the emulation speed.
I'm not trying to anger/frustrate anyone with my perspectives or comments. I'm trying to improve our site.
Warp wrote:
If someone makes a TAS of such a game by emulating a 20MHz PC, what stops someone else from just doing the same with an emulated 21MHz PC? And a third person from doing so with an emulated 22MHz PC?
If a human speedruns a game on a 20MHz PC, what stops someone else from just doing the same with a 21MHz PC? And a third person from doing so with a 22MHz PC?
Humans CAN. Why cant a TAS?
Whether or not developers expected/foresaw/planned for people to do so doesn't matter.
Humans can run/speedrun old DOS games on more modern PC's with 1+ gHz CPUs, even without emulation. It just requires installing a DOS environment on a modern system; FreeDOS for example.
We would never, in a million years, accept a TAS of a NES game running on an emulator that's running faster than it should to achieve a shorter wallclock time. Why should we do that with any MS-DOS game?
I only partly agree. All NES systems are essentially uniform and don't have variable specs from system to system. So, no, we shouldn't accept overclocked NES runs.
However, PC's have (and always have had) variable specs. NOT allowing for variability in DOS TASing is arbitrarily disallowing something that can be done on actual systems.
You seriously cannot understand the ridiculous idea of allowing any emulation speed you want for DOS games?
Once again: If someone decides to make a TAS of a DOS game by emulating a PC running at, let's say, 20MHz, what stops someone else from doing the same thing but emulating a PC at 30MHz? Or 100MHz? Or 1GHz? It becomes meaningless. Obsoleting the TAS becomes meaningless, when you can simply do so by adding another MHz to the emulation speed.
I simply don't see this as ridiculous as you do.
If a particular TASer can only accomplish beating a game at a 30mHz or slower speed, yet another TASer is capable of beating that same game at at 60 mHz speed (thus yielding a faster run); I feel the second runner should be allowed to do so. It shows that the later TASer is the better TASer, and thus the run itself is better from a speed/vault perspective because the first TASer couldn't accomplish it at a speed above 30 mHz. It may be less entertaining, but that's beside the point.
I stand by my argument that if a human CAN do it for their speedrunning, why can't a TASer do it also?
Allowing arbitrary emulation speeds just makes the TAS pointless, because the only upper limit is how fast you can emulate it in your modern PC.
This is similar to the thought that stemmed this whole topic. The 20mHz default speed in JPC-rr is itself an arbitrary value.
If we're not going to allow arbitrarily increased speeds above the default, we should not allow the arbitrary value of the default either. Just because it's a default for the emulator doesn't make it any less arbitrary.
If we feel the need to eliminate arbitrariness, why should we allow the 20 mHz default SLOW arbitrary value as opposed to some other FAST arbitrary value, simply because it's slower and/or default? Eliminating arbitrariness requires that ALL runs be held to a standard based on the game being run...not the emulator it's being run on.
So as I've tried to already express; The only 'fair' options for DOS TASing are the following.
1) Force ALL future DOS runs to have their CPU speed settings substantiated/limited including those that use the default speed.
2) Allow ALL future DOS runs to be at any chosen speed, regardless of how fast that is, so long as the run can be completed.
It could be argued that limiting runs TO a specific arbitrary value (such as the emulator default) guarantees fairness between TASers, but it doesn't change the fact that the forced value chosen is still arbitrary. This only furthers the question of why a SLOW arbitrary is OK, but a FAST arbitrary value isn't.
As far as the site rules are concerned, I don't care which of these approaches is chosen. I feel either would be better than the current rules.
While I personally feel that allowing any speed is best, I'd be fine with the other option being implemented instead; because it not only limits games at higher performance speeds, it would also limit lower performance games. That is fair.
Our current rules only establish a limit on one end, not the other. That in itself is arbitrary and non-specific.
Either of my rule approaches would be a more specific/concrete approach than what is currently established, in my opinion.
DrD2k9, I want to ask you about yet another thread. Have you seen this post and any of its context?
Post #476703
The resulting Movie Rule:
http://tasvideos.org/MovieRules.html#PcGameEnvironmentMustBeLegitimate
It's kinda hard to talk about rule suggestions when you change your opinions so quickly, so I don't know which of yours I should be addressing, but it looks like you haven't seen that thread.
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.
If someone makes a TAS of such a game by emulating a 20MHz PC, what stops someone else from just doing the same with an emulated 21MHz PC? And a third person from doing so with an emulated 22MHz PC?
If a human speedruns a game on a 20MHz PC, what stops someone else from just doing the same with a 21MHz PC? And a third person from doing so with a 22MHz PC?
Humans CAN. Why cant a TAS?
Do you seriously not understand how ridiculous that is?
If any emulation speed can be chosen, TASing the game becomes completely meaningless. Why would you even TAS the game? You choose a particular emulation speed, and the next person simply chooses a speed that's higher and beats your run, even if the input is otherwise identical. Obsoleting someone's run becomes quite trivial.
And, on top of that, to the viewer there's absolutely nothing to see, because ostensibly a DOS game from the mid-80's can probably be completed in a second in a PC running at 100GHz, if that's the speed you choose.
Take a video of any existing speedrun, and speed it up a thousand-fold, so for example a 15-minute speedrun becomes 1 second long. Let's see how much you enjoy it.
Now do that, and declare that 1 second is now the official speedrun length for that game, rather than 15 minutes, and keep a straight face.
This is completely ridiculous.
DrD2k9, I want to ask you about yet another thread. Have you seen this post and any of its context?
Post #476703
The resulting Movie Rule:
http://tasvideos.org/MovieRules.html#PcGameEnvironmentMustBeLegitimate
It's kinda hard to talk about rule suggestions when you change your opinions so quickly, so I don't know which of yours I should be addressing, but it looks like you haven't seen that thread.
Thanks for the link. I had missed that post. After reading it, (and even though I may personally disagree) I better understand why the site can't allow for runs at any speed.
It doesn't change my personal opinion that ridiculously fast runs at elevated speeds are more impressive of an accomplishment than a slower run, but I can deal with having a personal preference that the site cannot support.
As far as my suggestions/opinion changing quickly: It's not that I'm drastically changing my opinion, I'm seeing aspects of things in ways that I hadn't considered before. New/different perspectives and knowledge should prompt reviewing of one's opinions.
Also, while my opinion on what I personally see as impressive DOS TASing may have changed some, my opinion on the problem with current rule hasn't really changed since the first post in this topic.
I still feel the current rule needs addressed for future DOS TASing.
The 20mHz default is itself arbitrary. If we want to strive for authenticity by attempting to eliminate arbitrariness in PC TASing, we need to clarify the rule so that future DOS runs can't be 'given a pass' for using the default setting just because it's the default setting.
I understand that requiring all future DOS TASers to justify their settings adds more work for the TASer (and potentially for the judge to verify those settings), but it's a necessity if we want authenticity.
I also understand c-square's concerns of how this added work may limit/deter others from DOS TASing in general. Unfortunately it may be a necessary evil for the platform even if it does scare some away.
To specifically address his concerns:
- 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.
https://en.wikipedia.org/wiki/Microprocessor_chronology offers CPU speeds by year. To get the CPU divider setting for JPC-rr, the formula is 1000/CPU speed in mHz.
I provided the approximation formula for DOSBox Cycle speed earlier in this thread.
- 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?
I like the idea of using game documentation if available to get the require system specs.
If that isn't available, I'd suggest using year of the game's publication (allowing for some variation based on different versions released in latter years).
- 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.
This one is tough for a couple reasons. For one, it is going to be an issue regardless of whether or not the rule is modified; system 'boot' times will be different between the emulators.
We could begin timing from the moment the command to start the game is received by the OS, but that would require significantly detailed evaluation of the movie files to know when exactly that occurred. I unfortunately don't have a better recommendation on timing comparison between different emulators.
- 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.
Addressed in the above 3.
So, the question that I feel the the site staff need to answer is, whether or not the arbitrariness of the default value in the current rule is grounds enough to consider further clarification of the rule.
Since my personal preference can't be allowed, I re-offer the following as a suggestion (similar to my original post, but slightly modified):
CPU frequency settings may or may not be restricted, depending on the game.
-If a game's speed is limited to real-world time or screen refresh, CPU frequency may be increased anywhere up to the maximum (CPU frequency divider = 1;
emulating a 1GHz CPU).
-If a game's speed is limited only by CPU frequency or clock speed, the CPU divider should be set to a value yielding CPU speeds authentic to recommended system specifications for which the game was designed. These specifications can usually be obtained from the game documentation (or may be based on year of release if documentation is unavailable). Justification for the chosen speed settings is required in submission notes.
In other words, if increasing the CPU clock speed affects and speeds up all normal gameplay, it must be set to emulate an authentic CPU frequency of which the game is proven to be designed. If increasing the CPU clock speed only affects lag or loading times and does not otherwise speed up gameplay, it may be increased up to the emulator's maximum.
Yes, I think as long as gameplay doesn't speed up or slow down, we should allow faster CPU emulation, and when gameplay does speed up or slow down regardless of the emulated CPU speed, we should require the rule I linked to be followed. Which means, try to provide proofs that the game was supposed to run on whatever you're emulating or simulating. And if your movie abuses unintended environment, it can't be any% or 100%.
With this in mind, the timelines of CPUs and games don't have to match exactly, but it's expected that intended environment is used. If that means reducing the CPU speed in JPCRR, it must be reduced.
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.
Yes, I think as long as gameplay doesn't speed up or slow down, we should allow faster CPU emulation
The thing I worry about this (which I stated in another thread) is that there might be a particular speed that causes glitches in the game that don't happen otherwise.
To be fair, this isn't unprecedented in (unassisted) console speedrunning. Ocarina of Time being, perhaps, one of the most prominent examples: The game works differently on the three major platforms it has been released, ie. the N64, iQue, GameCube and Wii. All the platforms are allowed by the OoT speedrunning community, and they are allowed as the one and same category (ie. all runs in all platforms go to the same list, and a run by one runner on one platform may obsolete a run by the same author on another platform, if it's faster.) For a short time the iQue version held the top positions because it was faster than the N64 version (until the Wii version obsoleted it because it allows a glitch that doesn't work in the other versions).
However, when we are talking about PCs, we aren't just talking about three or four different platforms that can run the same game. We are literally talking about hundreds or even thousands of different setups (since, after all, a PC can be built with components from a wild variety of manufacturers, with all kinds of differences between them). And emulating a PC opens up even more possibilities (because emulation can eg. choose CPU clockrates that have never been used in practice.)
Even if a more modern DOS game did take into account differences in speed of the hardware and future-proofed itself, it may still be possible that with some speeds and/or some combinations of hardware it will exhibit glitches that it doesn't otherwise.
I'm not sure how happy I would be if DOS game TASes started appearing that require a very specific setup, rather than the same run being possible with all PCs that the game supports.
Good point. I tried to formulate the rule I linked so that it talks about general things, not even just gameplay speed. In JPCRR, environment configuration is limited to CPU speed, so it was natural to only account for gameplay speed as the main factor. Now that we have clear rules on PC environments, the JPCRR rules do indeed need some rewording to match. Maybe they are obsolete altogether.
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.
You choose a particular emulation speed, and the next person simply chooses a speed that's higher and beats your run, even if the input is otherwise identical. [...] And, on top of that, to the viewer there's absolutely nothing to see, because ostensibly a DOS game from the mid-80's can probably be completed in a second in a PC running at 100GHz, if that's the speed you choose.
This doesn't apply to games that use vsync.
Warp wrote:
Even if a more modern DOS game did take into account differences in speed of the hardware and future-proofed itself, it may still be possible that with some speeds and/or some combinations of hardware it will exhibit glitches that it doesn't otherwise.
That's completely transparent to the viewer if they don't read the commentary text; it shouldn't affect their enjoyment of the actual run.
The games that did not adjust their own speed to compensate for the speed of the PC were quite obviously not using vsync (because that would have make them automatically adjust to it; their timing would be tied to the display refresh rate, not the speed of the CPU).
IIRC vsync didn't even become a thing until well into the 90's.
Maybe vsync wasn't an explicit user option, but it was clearly an option for a game developer. I've had a talk with Ilari back in the day about DOS games.
<feos> the fact that they go that high is more of a bug than a feature I guess?
<Ilari> Yes, the lack of vsync (or ridiculous vsync speed) in any realtime game is a bug..
<feos> but is it optional for them at least, or they completely fail to limit themselves in any sensible/useful/playable way?
<Ilari> There are games that completely fail to limit themselves, and the effective framerate goes to infinity as CPU speed goes to infinity. Then there are games that fail to sensibly limit themselves, and altough the effective framerate saturates at some point, that saturation point is unplayably fast.
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.
