Posts for DrD2k9


DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2037)
Joined: 8/21/2016
Posts: 1009
Location: US
Pokota wrote:
The purpose of removing arbitrary selections is to prevent playing at 199% if 200% is a valid, developer-supported option
But why should we prevent 199% simply because it's not the default or fastest setting? It's still a developer supported option While it typically makes characters move faster, increasing in-game speed settings also sometimes makes movement harder to optimize due to the balance between input processing and character movement within the game. It's therefore possible that the difference between 199% and 200% may actually make it harder to move the character efficiently at 200% and thus allow for the game to be completed in a shorter time using the 199% setting. In such cases, why should 199% be disallowed simply because it's not the maximum or default setting? What determines whether a given in-game speed setting should be allowed or not should only be limited to what the developers planned as options. In the cases where the developers provide a warning, as you mentioned above, I agree that those values would be arbitrary and unintended. EDIT: I should be able to start making that CPU Divider table sometime today/tonight. It might take a while to put together though. I'll see what I can do about including DOSBox cycles as well.
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2037)
Joined: 8/21/2016
Posts: 1009
Location: US
Sorry for two posts in a row, but they are completely separate thoughts.
feos wrote:
I'm not sure if we can swap the priorities that way, but in any case, first we'd need a timeline table.
If it helps, I can make a list of valid CPU dividers based on CPU speeds available sorted by year.
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2037)
Joined: 8/21/2016
Posts: 1009
Location: US
As a preface: I tried to quickly skim through the other topic on PC environment settings for this, but couldn't easily find an answer for the following. (This post may belong better in that topic also, but I'm not sure, so it's here.) When it comes to in-game speed settings, I don't understand why using a non-predefined value from within a limited range can't be allowed for vault. In-game settings and system environment configuration aren't the same thing. I understand the necessity for limiting/preventing inappropriate configurations in system environment, but I don't feel that in-game speed settings should be limited by the same rule. It's true that some in-game settings are exclusively used to coordinate with system environment/hardware (v-sync and FPS, for example), but in-game speed options aren't only for that purpose. Some people simply like playing games faster than other people, and developers sometimes allow for this with speed sliders instead of preset speed options. The Sierra adventure games are a good example: earlier AGI based games have limited set speed options, latter SCI games however often used speed sliders. In-game speed settings and vault eligibility standards. Why does a game that allows a preset speed option of 125% make it more eligible for vault compared to a game that allows for a speed of 125% on a slider? The 125% on the slider is no more arbitrary simply because it's on a slider; it's still 125% of the default speed. Why is one 125% choice more eligible than another simply because of the method by which the choice is made? If a system environment (hardware/emulated hardware) is controlled and a speed selector has defined upper and lower endpoints, there is a finite range limit of potential speeds at which the game can be played while still adhering to the appropriate environmental protocols. The fact that the range is finite should be enough of a limit to arbitrariness that these games should still be eligible for vault using any speed selection available within the game's options. At bare minimum, either of the endpoints of the slider should be allowed in addition to the default setting. The point of the 'appropriate environment' rule as I understood it was to prevent insane speeds/glitches achieved through use of inappropriate system (hardware) environment. To further limit already finite speed options just because they are on a slider instead of on preset bullet-point speed selections seems itself an unnecessary distinction. Making this distinction is effectively saying that it's ok to play one game faster than the default but not another simply because the game-provided method of choosing the selected speed differs. It's making a issue over selection method, not the fact that a different speed is being used. If an in-game speed setting is allowed by the game within an appropriately configured system environment, that in-game speed setting should be allowed for vault regardless of whether it was selected via slider or bullet-point. To put it simply; if the environmental (hardware) protocols are appropriate, I don't agree that any point on a finite speed selector within the game's options should be ineligible for vault. EDIT: added headers and slightly shuffled comments.
Post subject: Re: Capping off AGDQ 2019, looking to changes for future GDQ's
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2037)
Joined: 8/21/2016
Posts: 1009
Location: US
Warp wrote:
During the first years most people here were excited about the GDQ TASbot events, and were willing to participate and contribute. However, as the novelty has worn out, and the technical requirements and amount of work have increased year after year, it's no wonder that people are losing interest and getting tired of it. One has to wonder if this is really something worth doing forever. The amount of pressure, expectations, work, and even monetary cost, is getting out of hand, and people here are getting tired and disinterested.
While certainly contributing factors, fatigue and disinterest aren't the primary reasons preventing much of our community from interacting with GDQ planning/events in my opinion. I feel that the larger factors in the lack of participation lie in availability (time) and the technical aspects of what we're presenting (which Warp briefly touched on above). -Even if they'd be interested and otherwise capable, some of our members simply don't have the available time to get involved with helping create/present for GDQ events. This may be due to the amount of work that needs done for the event and/or due to the fact that the member has other priorities in their life that prevent them from having time to help. -While the majority of our community may be able to TAS inputs for any given game well enough to beat the game, there is a significantly smaller percentage of members that have the requisite knowledge for things like ACE and/or custom payload creation...and those are just on the software side of the equation. When the GDQ event planning for a TASBlock desires/requires specialized hardware modification/creation, the percentage of our members with the requisite knowledge to help decreases even further. Speaking for myself (though this is likely a shared perspective with other members), I don't often feel able to contribute much (if anything) to the GDQ presentations because I usually don't understand what's going on well enough myself to: A) contribute to the creation of said presentation B) offer commentary on what's happening in that presentation Though I have no proof on this, I believe that a large part of the hesitation from members of our community on getting involved with GDQ events revolves around this perspective that they have nothing to offer to the project. I am one of the few who have contributed in the past to GDQ events, but that contribution was only providing sound effects that someone else was required to insert into a custom payload. Other than this contribution (which was neither a typical nor intuitively expected need for GDQ events), I don't feel that I have the requisite abilities to be a productive member of GDQ planning. Looking back over the past few years of GDQ events, there is very little that has been presented in the TAS block that I feel I could have helped with even given my current knowledge of TASing. In past years, my knowledge was even less, and thus I would have been even less capable. Finally, to address the financial side of things: This is where I feel interest/disinterest may be playing the greater role. I expect this and a few other reasons for why our members don't contribute financial help specifically to the logistics of the TASBlock at GDQ events. 1) Disinterest - This is absolutely a factor here. Some of our members simply don't care enough about GDQ events and/or the TASBlock at those events to want to contribute financially to them. It may be members have lost interest, or never were interested to begin with. 2) Complete Financial Inability - Another key factor. Some of our members simply don't have available funds to contribute. As much as I would like to be able to offer financial help for these events, this is my personal situation. I simply don't have money available to offer. 3) Limited Financial Ablility - Somewhat tied to the previous reason. Some members may only have limited monies available and choose to donate to the GDQ charities via the event instead donating toward the logistics of making the TASBlock happen. 4) Some people are simply stingy with their money (and they have the right to be if they so choose )- Some with the means never give their money to anything they don't personally get something back from. For them, they don't personally get anything back from GDQ events or from getting the TAS presentations there; thus they will never contribute financially to either of those things. It's just their choice. What does all this mean? For DwangoAC (or future keepers of TASBot/organizers of TASBlock): DON'T stop asking for help! Those who would be willing/able to help financially may not offer money if they don't realize you need the help. Similarly, those who have the knowledge/abilities to help on the presentations may not offer help if they don't realize it's needed. Many people are willing to help when asked, but not the type of person to otherwise volunteer. For the rest of the community: Please proactively offer to contribute financially if you're able and so inclined. Also, if you'd be interested in helping with a GDQ presentation/idea (even if you don't feel you have the requisite knowledge), please let the TASBlock organizer know you're available. There may still be something you can do that doesn't seem obvious.
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2037)
Joined: 8/21/2016
Posts: 1009
Location: US
I like the conciseness of the newly revised rule for JPC-rr as well as the tie-in to the rule section on legitimate PC environment.
Post subject: Re: Rule review for DOS games (at least via JPC-rr)?
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2037)
Joined: 8/21/2016
Posts: 1009
Location: US
feos wrote:
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.
Post subject: Re: Rule review for DOS games (at least via JPC-rr)?
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2037)
Joined: 8/21/2016
Posts: 1009
Location: US
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
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2037)
Joined: 8/21/2016
Posts: 1009
Location: US
HappyLee wrote:
The only victim has been our hard work.
Your work has not suffered in any way. Nothing anyone has already said or will ever say about that particular run can change the actual work you accomplished. Further, what others THINK about your work still does not change the work itself or the intrinsic value of that work for the site and TAS community. People are entitled to their own opinions whether or not you like, agree, or care about their opinions. From how this whole situation has transpired, it appears that you only care about other people's opinions if those opinions coincide with your own. You are continuing to whine and complain ONLY because others haven't LIKED you and your run as much as you think they should. The only "victim" has been your ego. EDIT: The yearly awards are a POPULARITY contest. If you can't accept that you and your run aren't more (or the most) popular run/TASer in our community, then it is again an ego problem not a problem with the community or site staff.
Post subject: Re: Rule review for DOS games (at least via JPC-rr)?
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2037)
Joined: 8/21/2016
Posts: 1009
Location: US
Warp wrote:
Radiant wrote:
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.
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2037)
Joined: 8/21/2016
Posts: 1009
Location: US
total wrote:
I took some time and managed to convert the AGDQ2017 SMB3 ACE payload we used that does the DPCM glitching in 1-1 to lead into full total control. It's not the final version that was shown but it's mostly the same. Wasn't too easy to convert though since I had to first convert the inputs from the binary format used for the hardware replay and then go in and manually resync inputs for every lag frame and frame boundary that didn't match up, but finally it worked :) Here's the bk2: http://tasvideos.org/userfiles/info/52514549789799992 Pretty cool to see it working at least!
Encode (not as exciting without having actual music at the end, but here for those who want to watch). Link to video
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2037)
Joined: 8/21/2016
Posts: 1009
Location: US
Ferret Warlord wrote:
Archanfel wrote:
P.S. Little pigs transform to rugby balls!? This is something new.
American footballs are sometimes called "pigskins."
Which is still ironic considering they never have been commonly made from pig skin (pig bladder maybe, but not commonly the skin). They are now primarily rubber bladders inside cow leather.
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2037)
Joined: 8/21/2016
Posts: 1009
Location: US
Nicos wrote:
just watched the block and i think that the "lack of knowledge and interactivity" hurted the block pretty hard
Something else to consider for a GDQ audience: It's not a TAS audience, it's a speedrun audience. The majority of the attendees don't pay for passes to go to a GDQ to see what newfangled, fancy, or technically impressive stuff we TAS people come up with by using games as a launchpad. They go for the speedruns (and to support the cause). I'm not suggesting that the technical stuff we've done isn't interesting or noteworthy accomplishments. Yet, while our TAS community may find some of this technical stuff very interesting/creative/entertaining, the speedrun community may not share those perspectives because they look at gaming from a slightly different standpoint. In some cases they simply may not have the requisite background (or interest) to follow/enjoy all of what we are presenting. It doesn't mean that what we're doing isn't worthwhile. I'm suggesting that the GDQ audience isn't the appropriate audience for presenting this aspect of the TAS community. In other words, we may simply not be catering to the correct audience. While gaining complete control and doing arbitrary things can be very interesting; I'd dare to bet that many in attendance at these events would be perfectly thrilled by a TAS exhibition that simply beats games much faster than a human could ever hope to, instead of having ACE or extra non-game related stuff in the TAS Block that isn't actually playing a game. Again, being able to accomplish these non-game effects is awesome, but it's not the core of what GDQ is about. GDQ = Games done quick. If it's not game-related, does it really fit in with the concept? My personal perspective regarding ACE runs at a GDQ event is the following: -If the ACE is used to get to the endgame/credits faster, it's worthy of showing off at a GDQ. -If the ACE is only used as an entry to do something completely non-game related, it doesn't fit in with the concept of games being beaten quickly and thus doesn't really fit with the concept of GDQ in the first place. This doesn't mean that this type of ACE isn't interesting, just that it's not related to games being done quickly. Being technically impressive doesn't always equate to being entertaining. Perhaps we just need to simplify: stop worrying about showing the audience fancy new technical achievements and show them the speed-gaming they're there for anyway...just better than what they expect. If we do want to demonstrate something that's not strictly about beating a game quickly, we should strive to still offer a sense of speed-gaming in the presentation. For example Brain Age (while not a very fast completion) maintained that feel of speed-gaming while still demonstrating something unattainable by human standards. To reiterate...I suspect that the majority of GDQ attendees are there primarily for the speed gaming...not to see all the other non-game related stuff that just so happens to be doable using technology that is designed primarily for gaming (whether or not a game is used as the primary access point to achieve that other stuff).
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2037)
Joined: 8/21/2016
Posts: 1009
Location: US
Alyosha wrote:
If anyone is willing to re-test SMB3 I would appreciate it.
I can confirm that Masterjun's inputs still work (at least using copy/paste in TAStudio). Or did you need something different?
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2037)
Joined: 8/21/2016
Posts: 1009
Location: US
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.
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2037)
Joined: 8/21/2016
Posts: 1009
Location: US
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.
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2037)
Joined: 8/21/2016
Posts: 1009
Location: US
MESHUGGAH wrote:
Still can't see subframes.... 2. Can't see any "SUBNESHawk" checkbox under Core https://imgur.com/GFAKKgh
Use the Config>Cores>SUBNESHawk Not the NES>Core>xxxx
Post subject: Re: Rule review for DOS games (at least via JPC-rr)?
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2037)
Joined: 8/21/2016
Posts: 1009
Location: US
Radiant wrote:
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.
Post subject: Re: SMB3 DPCM
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2037)
Joined: 8/21/2016
Posts: 1009
Location: US
Masterjun wrote:
I had to adjust it a bit due to timing differences from FCEUX, but here it is: Super Mario Bros. 3 cleared in 126 polls by abusing the DPCM glitch workaround overflow. It might not be actually 126 polls on console, as I assume there are blank, emulator-only polls, existing as a video frame so BizHawk can draw them.
well...i guess that's at least one step closer to publication. I was hoping to help slightly more than just suggesting that I could help. EDIT: Here's an encode of Masterjun's file. Link to video
Post subject: Rule review for DOS games (at least via JPC-rr)?
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2037)
Joined: 8/21/2016
Posts: 1009
Location: US
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.
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2037)
Joined: 8/21/2016
Posts: 1009
Location: US
nymx wrote:
Edit: I was also surprised to see a conveyor belt level for the C-64. I remember seeing something like that, but wasn't sure what system it came from. I wonder if I saw it on the version that Adam released.
IIRC all three Donkey Kong ports on C64 have all four sub-stage.
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2037)
Joined: 8/21/2016
Posts: 1009
Location: US
feos wrote:
This game has an ending guys.
Are you referring to the bit with Mario and Pauline up top at the end of the Rivet stage? If that qualifies as an ending, then simply playing through level 1 would be the absolute fastest way to complete the run. (And I'll gladly do it if that's all it will take!) I didn't expect that brief scene to be considered enough of an ending to not consider this an endless game. If only level 1 were played, there'd be potential future unseen content (conveyor and elevator stages) that would arise if the game was continued further. I always took that scene as a 'fooled you' by the developers, and didn't consider it a 'clear ending'. If for no other reason, because the happy music in that scene becomes suddenly foreboding over the last 3-4 notes suggesting that things aren't over yet. But hey, you're the senior judge, so I'll defer to you on when this game actually ends.
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2037)
Joined: 8/21/2016
Posts: 1009
Location: US
Awesome! I love that you figured this out in less than a month after telling me "Subframe input on the piano roll isn’t happening." here. Even if it is only for 1 or 2 cores. This is essentially what I was suggesting/hoping for. WAY TO GO! FWIW, I'm willing to help work on getting the SMB3 run re-done to see if it will work.
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2037)
Joined: 8/21/2016
Posts: 1009
Location: US
Spikestuff wrote:
I'm personally not a fan of TASes that jump to a set level and not complete the loop that's in the game which you happily pointed out. Much like this Submission which got rejected last year for well the reason I just wrote: #5950: Quibus's Coleco Galaxian in 00:22.97
Thanks for your opinion, but please specify exactly what pathway you feel would be required for completion. Which of the following would you require? -Starting and completing just Level 5 -Starting from Level 1 and completing level 5 -Starting from Level 1 and completing all 100 levels to return to level 1 -Something else? The problem I have with any of those specific options is that none of them offer any additional unique visual content or harder difficulty compared to the current submission (unless you count the order of sub-stages as visual content). Adding a sub-stage doesn't make a game harder from a TAS perspective. Truly it doesn't make the game harder for a human player....it just offers more opportunities for a human to screw up before reaching a higher level. Thus the difficulty hasn't increased, it's just prolonged. It's true that the sequence of sub-stages varies between the current submission and level 5+ but there's no gameplay differences or difficulty variation within those sub-stages. These are my opinions. Thank you for yours. I fully expected the community's perspectives to be a bit split on this submission, which is why I noted that I have a completed run which begins at level 5 ready to go. I do not have a level 1-5 run prepared, but would be willing to make it if necessary (as boring as it would be to watch the various stages repeated 20 times). EDIT: I'm not interested in doing a level 1-100 run.
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2037)
Joined: 8/21/2016
Posts: 1009
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?
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2037)
Joined: 8/21/2016
Posts: 1009
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).