Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
Location: US
Not trying to anger/frustrate anyone. Trying to ask questions/present ideas that I feel need deeper consideration. If we are never willing to question the way things are done, we don't really know if they are actually being done the best they can be.
feos wrote:
Where are you even seeing disrespect?
...
Publishing as obsoleted makes no sense, because what would the actual record be? Technically obsoletion works by setting the "obsoleted by" movie ID, it can't be "spherical obsoletion in vacuum" if there's nothing to obsolete it.
Overall, it's undeniable that this movie has been proven to be sub-optimal. Usually we publish improvable movies if the improvement is hard to implement, but it has been properly bested now, from start to finish, with the improvement that MESHUGGAH posted, and with lots of other timesaves.
Regarding Disrespect
I see disrespect in not officially recognizing (through publication) that alex_ik's run was (at least for a time) the fastest officially accepted Contra record. More specifically, I see further issue in only a pseudo-acknowledgement of that record only to have the official archive (our sequence of publications of Contra) be lacking that run simply due to the timing circumstances of the next submitted run.
I'm not trying to claim anyone is intentionally trying to show personal disrespect toward the author. Perhaps "disrespect" isn't the right term to begin with, but I can't currently think of another term that would fit.
As an analogy, consider Track & Field records:
If an athlete breaks a world record for an event during a heat-race, then a different athlete breaks the record again in the very next heat-race; the first athlete still officially held the world record for a period of time (however brief it was). History officially recognizes the first athlete as having been a past world record holder, and that individual's name would be immortalized in a list of past record holders even though his/her record was beaten only minutes later. The honor of the first athlete would still be published in an official document listing the series of world record holders even if that document couldn't be published before the second athlete re-broke the record.
The way I compare our situation to this Track analogy:
--Two un-judged runs on the workbench that both beat the current publication are 'in the same heat-race' and only the faster wins the award of being named the record holder. This is how it would work in Track & Field: even if two athletes beat the current world record in the same heat-race, only the faster gets the official recognition of being the new record holder.
--An already judged and accepted run that is simply awaiting publication has 'already won its race and broken the record' and thus has already earned its position in a published list/series as being a past world record holder; regardless of whether or not that publication itself was able to be created before the record was subsequently re-broken. If an even faster submission arrives, while the first is awaiting publication, the newer run (assuming its own acceptance) becomes the new world record holder for winning its own heat-race and re-breaking the recently broken record. For our site (as with Track), BOTH of the runs/authors (athletes) deserve published recognition of their accomplishments. How long it takes for that publication to happen (whether the publication itself is a simple text listing of athletic records, or a series of movie pages on our site), should not be allowed to alter the archived history of the series of record holders.
At the absolute bare minimum, alex_ik's run should not have been un-accepted until the present submission was fully accepted itself. If for some reason, it does get rejected, then alex_ik's run would still be the record holder of accepted runs.
Regarding Publishing
I'm going to preface the following thoughts/questions with this: I don't fully understand all the various site mechanics of publication.
I'm not denying that alex_ik's movie is subopitmal based on current knowledge. I'm arguing that it was the most optimal known run at the time of its acceptance.
Is it not possible to make a movie page of a run that is slower than another run of the same game on our site? Wouldn't it be possible to directly mark the later publication as slower/already obsoleted by the earlier faster run? If these aren't possible, what would it take to make them possible so that we can officially and duly honor the line of record holders?
As far as publishing an 'already obsoleted' run, the current record would be the faster run sitting on the workbench. If the faster run is published first, the true record is maintained in a published state and there's no weird discrepancy of having a known non-record holder as the current fastest publication. By publishing the slower run second, the 'obsoleted by' ID could be set to the appropriate movie page of the faster run, and there'd be no obsoleting in a vacuum.
That said, every time ANY run is accepted as better than a current publication, the current publication stays on our site as the fastest published run even though it's not technically the record holder anymore....but that's probably getting overly nitpicky.
This is a speed competition after all, one should always expect to be bested and work hard in order to win.
Speed competition and expectations of others potentially beating you does drive us to do our best. But neither of those things should give our site the right to write-off the accomplishments that are made. A world record being re-broken almost immediately after it was first broken doesn't mean the custodians of record keeping should simply write-off the the first of those two record-breaking accomplishments.
Two simple YES/NO questions.
1)Do we care about maintaining an archive of record breaking runs/techniques/progressions for history's sake?
2)Do we ONLY care about maintaining publications of the fastest known runs?
If the answers are YES to both....there's an inherent problem with our site, as doing both isn't possible.
If the answers are NO/YES respectively, there is no reason to maintain any obsoleted movie pages. And the argument that 'there is valuable information in those obsoleted runs' only supports including a publication of this submission.
If the answers are YES/NO respectively, then my proposal is valid.
For completeness sake: If the answers are NO to both, then entertainment is the ONLY arguable purpose for the site IMO. Which then begs the question: why do we even care so much about rules and consistency if we're only archiving/documenting entertainment? We should then just become a 'YouTube of TASes' and not care about the competition/record side of this hobby.
EDIT: I'm willing to accept that my perspectives may not change things. But I feel the perspectives still need shared.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
Location: US
Spikestuff wrote:
And you didn't have anything for this then?
Spikestuff wrote:
If you're placing an argument for that you might as well place an argument for this then.
Assuming that is the same situation, I feel that the run that was un-accepted should be published 'as already obsoleted' just like I'm arguing for this submission.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
Location: US
At the time of this runs acceptance, it met all the rules. It's not the author's fault, nor the run's that prevented it from becoming published before the subsequent faster run was submitted. We should not strip the author of the honor of having a run accepted because of publication delay (however long or short that delay may be).
I agree with feos.feos wrote:
Publishing a run that's already been properly obsoleted by a new submission, and claiming "that's the current Contra TAS record", doesn't feel perfectly right either.
But I'm not proposing this run be published as the current Contra TAS record. I'm proposing that it be published as already obsoleted to honor its accomplishment and original official acceptance as an improvement to the current publication. If the newer run must be published first for this to take place, fine. But give credit where it's due.
I also agree with Mothrayas that this situation is unfortunate.Mothrayas wrote:
Not only does it not feel right, it's a blatant violation of the requirement that publications must beat existing records. If the site publishes a movie knowing that a faster movie already exists (and is on the submission queue), it's violating its own rule.
It's unfortunate whenever this happens to an already-accepted submission, but this is not the first time it has happened. No movie is confirmed for publication until it has reached the movie publication list. Accepted movies can still be rejected in light of new evidence.
It's only a violation of our own rules, however, if it's published (as feos said) as the "current Contra TAS record." Again, that's not what I'm proposing.
If 'accepted' movies can still be rejected, then perhaps we should change the judgment of 'accepted' to 'provisionally accepted pending publication' as that's more accurate and less disrespectful toward authors to whom this situation has already occurred and to those whom it will happen to in the future.
Your own statement speaks to how infrequently this occurs.Spikestuff wrote:
This situation has also occurred in the past where the movie that become obsolete sitting ready for Publication was Rejected due to the improvement that showed up on the Submission bench.
(At least twice to my current knowledge, but I can only track down one example of it... should make a page dedicated to this.)
Edit: And now that has been unfortunately done to alex_ik's submission.
Would a page to identify these occurrences be nice? Yes it would. Is it necessary? Perhaps for showing some degree of credit to those who've been unfortunately snubbed in the publication realm.
Still, the proposal to publish 'as obsoleted' would add minimal stress/work to the site staff, maintain honor toward the author, and improve the accuracy of archival for the game's history on the site.
Thank you for your perspective as a member of site staff. I'd like to hear more from other staff members in light of my thoughts.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
Location: US
Personman wrote:
Since we keep obsolete publication pages around, and frequently refer to them as valuable history, it seems really weird that the previous run won't get one just because publication was slow. I understand that this is how site policy currently is, but I think it's worth considering a policy change that allows for creating a publication page that is already marked obsolete at the time of creation.
This would create a more accurate record of the history of the run for future historians, and would also give the obsoleted runner the credit & respect they deserve for their efforts.
I second this proposal.
While it didn't necessarily happen due to publication effort being slow, the previous run was unfortunately un-accepted and retroactively rejected simply due to the arrival of this current submission on the workbench.
The authors of the previous run (that was otherwise accepted and would have been published) deserve credit for beating the previously published run. At minimum they deserve to be listed in the historical line of the game's runs.
If the previous run had not yet been accepted, I would have no problem with it being rejected due to the arrival of the current submission on the workbench. However, that wasn't sequence of events.
Because it had already been accepted, I believe it deserves its publication. While it is one more game's worth of publication labor for a publisher, I see no harm to the site in publishing the previously accepted run as already obsoleted and honoring it's place in the historical sequence of the game.
To put it simply: the arrival of a new run on the workbench should always be able to cause rejection of a slower run of the same game that is currently awaiting judgement. It should, however, never be able to cause un-acceptance of an already accepted run.
Once a run is accepted to obsolete the current publication (or as a new game), it should be honored for its place in the history of the game/site. The run that is awaiting publication should be considered 'as good as published' from an obsoleting standpoint. It should be considered as having earned its publication regardless of whether or not it has actually been published yet; or whether or not a new faster run happens to show up on the workbench.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
Location: US
I googled around to see if I could find data on market share of various microprocessors, but couldn't find anything older than about 2008. What I found was pretty much dominated by Intel and AMD.
I'm sure the information is out there somewhere, but I've got no other ideas on how to find it.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
Location: US
The poll does seem to show YT as an overwhelming preference by voters. And while some members may prefer to use the other methods for various reasons, I'd be surprised if many guests/visitors to the site watch runs using any method other than YT (whether that be embedded or on YT site).
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
Location: US
Nach wrote:
The MP4 Compatibility option can also be watched directly in the browser, and it doesn't require downloading a file.
I just fixed some bugs with it from preventing it from being seen in certain browsers, specifically some mobile devices. You might need to force refresh a movie page before the changes take effect for you.
...
Try Archive.org (MP4 Compatibility) streaming (from our movie pages), and let me know what you think. (Be sure to force refresh to get the latest version)
Thanks. I tried it on a couple publications, and it seems to work well in-browser on my laptop. I've never watched on my phone, so I can't comment on that at this point.
MP4 may now usurp YT as my preferred method of watching.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
Location: US
c-square wrote:
I'm much more interested in having a list of one CPU divider per year to keep the choice simple without needing extensive research or fear of rejection due to someone digging up a specs doc after submission.
I think a list of one CPU Divider per year is a very good idea as a resource for new DOS TASers. It would give them a quick reference to know how to setup JPC-rr and know their run is 'safe' from being rejected for the reason of bad emulator settings.
However, I don't think all DOS TASes should be concretely limited to that list; simply because there was variability in real systems, and utilizing variability (within reason) that still yields a valid system environment should be acceptable for the site.
EDIT: Side note regarding SQ1. The published run uses version 2.2 which was released in 1987. Therefore it's not overclocked, and could theoretically be run even faster than what it is.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
Location: US
c-square wrote:
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 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.
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)
Regardless of the answers to the above questions: I'd be willing to eventually re-do SQ1 at an appropriate CPU divider setting, if the resulting video has the opportunity to obsolete the current publication even though it may be a slower overall run due to the slower CPU setting.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
Location: US
I primarily watch in-browser using YouTube (via link from the publication page direct to the YouTube video page) for two reasons:
1) I'm usually just interested in what the run looks like.
2) It doesn't require downloading a file.
My secondary method is 'Movie file in Emulator' when I'm specifically interested in the input side of how some strategy was performed.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
Location: US
feos wrote:
How incompatible does the old divider have to be to require this clause in the first place? If a compatible machine was available back then, it's a pro. If the gameplay doesn't change, it's a pro.
It'd probably be game dependent, but it's theoretically possible that changing the CPU divider by as little as 1 could completely invalidate a .jrsr input file.
EDIT: I have to admit that c-squares chart of average clock speeds is definitely a more simplified resource than the big chart I did. I'd suggest either as being valid values for jpc-rr TASes.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
Location: US
Quick note on the CPU clock settings table: I'm still working on it as I'm able.
CPU Divider can be concretely calculated.
Unfortunately, DOSBox cycles can't be well calculated.
First, the formula I provided earlier in this thread is itself only an approximation for converting clock speed to cycles. Second, its accuracy fails toward the upper and lower ends.
This could likely be improved with some better/more accurate curve-fitting than what I did to get that formula in the first place.
That, however, may be a mostly pointless endeavor. As I've been looking more into this situation, I have found that the DOSBox cycle number isn't directly convertible to CPU clock speed. Emulated clock speed is dependent on both DOSBox cycle setting and host system specifications.
In other words, my understanding is that two PC's with different specifications will yield different emulated clock speed even when set at the same DOSBox cycle number.
I'll continue to fill out the table, but it will be limited to CPU Divider settings for JPC-rr.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
Location: US
It's a bit of a stretch, but based on this page, the OCEAN port (released on tape in the UK), potentially had two cassettes for the game....at least there are two cassette slots in the packaging suggesting there may have been two cassettes.
I've sent a message to the runner of that site asking if he knew how the episodes were distributed on the game media. I'm not holding my breath for a response, but who knows....maybe I'll be surprised.
EDIT with more info that mostly negates the above two statements:
I found a website that has photos of various releases of the game. All the variations only show one piece of media (either a tape or a disk).
Also, the site offers an image of the "original" tape version of the game (which is why I haven't linked the page in this edit).
The image is actually 2 images, one for 'Side 1' of the tape and one for 'Side 2' of the tape. I tested both using PAL settings in BizHawk (the US release was the disk release, tape releases were Europe). Using 'Side 1' loads Part 1 (Penguin); using 'Side 2' loads Part 2 (Joker).
I have no way to confirm if this truly is an uncracked original version or not, but there was no 'cracked by' screen during loading, and the true title screen was displayed for each side of the game. There was no "choose your mission" screen displayed using either side of the tape.
If we are willing to accept the authenticity claim by the webpage, we at least know that for tape versions, the two parts of the game were simply opposite sides of the tape media. Either could be played independently of the other side.
So we have a bit more information, but are still left with a dilemma due to the image feos posted above. We could either:
A) assume that the disk versions of the game mimic the tape version and have separate unconnected episodes on either side of the media that load directly to their appropriate part as the tape images do.
This however means that the above image may not be from an original disk and could possibly be from a cracked and/or compilation image that requires selecting which mission so the multi-disk image knows which section to load.
B) assume that the disk version doesn't split part 1/2 by which side of the disk is loaded from and the above image is the way the C64 knows which section of data to run.
Personally, I feel the later of those options would require more coding than necessary on the part of the developers than simply coding one part on either side of the disk. Essentially, they would have had to code a loader to select the mission option in addition to simply coding the two missions. Using opposite sides of the media eliminates the need for a mission selector/loader.
If it was done that way effectively on the tape, why would they feel the need to add the selection option for the disk release when they could utilize the same concept to separate the parts?
Other than finding someone with an actual C64 and original release version of this game, I don't know if we can confirm things any further regarding authenticity of how data storage for the two episodes was done.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
Location: US
I would guess that the reason for two separate disk images results from the original having one episode on one side of the disk and the other episode on the flip side of the disk.
C64 disk drives couldn't read both sides of the disk, so to access the other side, the disk would need flipped over. Sometimes these flips happen mid-game.
I would guess if the above screenshot is from an uncracked original disk or uncracked image, selecting one of the options will simply load that option, while selecting the other option would tell the user to flip the disk over and then it would load.
EDIT: so we need to decide if we
A) want to require combining the two images into one game for publication.
B) want to consider the two episodes distinct enough to published separately (similar to serial episodic games like DOS Crystal Caves or any other episodic Apogee game for that matter).
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
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.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
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.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
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.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
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.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
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.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2088)
Joined: 8/21/2016
Posts: 1026
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.
