Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
Nalonk wrote:
This is for more casual play. I realize this is the TASVideos board, and this isn't the usual sort of question, but this IS also forum for Bizhawk specifically right?
Yes this was probably as good place to ask as any.
Someone with more specific knowledge of the technical differences between the cores will have to answer this for you though.
I wasn't trying to brush off your question, just trying to help with pointers if it was for TASing purposes.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
slamo wrote:
If nobody can find the disk image you're using then that's still a problem, however.
Yea, I understand.
At least the actual gameplay inputs appear to sync on other images of the game. In the meantime, I'll see if I can find a different disk image that can be matched by others and re-sync.
EDIT:User movie #53667010499459408 Here's a new .bk2 using a different game disk image. The only re-sync necessary was moving the input for the run command and adjusting the first button press to start the game.
Added bonus, this version is 134 frames faster than the original submission.
The 'ROM Filename' for this version is "Rat_The_1983_Cymbal_Software.d64"
I'll update that part of the submission notes myself if possible.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
slamo wrote:
Is there any evidence that this game was ever released on a disk? Information for this game is extremely limited, there aren't even any pictures of it, but people who collect these games only have it on tape.
I emailed the developer to check if the game was officially released on Disk or not. I'll let you know as soon as I get a response.
I did have this game on disk when I was a child, but it was not an original (thus the copy I had may have been a program extracted from a tape).
I don't remember where I acquired the disk image I used for this run.
If I hear back that there was no official disk release, I don't mind trying to resync this run using a tape image (assuming I can find one of those in .tap format). While the .t64 format is recognized by BizHawk (can be opened in the "open rom" menu), it's not usable--See here for more details on that problem. Conversion programs exist to convert between .t64 and .tap formats (which are both tape images), but this is a grey area.
Also, after the program is loaded, the run idles at the prompt for over a second before running the program. This isn't evident in the temp encode because the loading section is omitted. I tried removing a bunch of the idling frames and the run still synced.
Regarding the "Run" command idling on screen, I don't understand why that would be the case.
When you say idling, is the cursor flashing? If not, the C64 has accepted the "run" command and is in the process of running the program even if the text is displayed for a brief time before the screen changes to the game's title screen.
In this example, the "Run" command is displayed immediately upon the "Ready" prompt. The inputs for the "Run" command can be done on any non-lag frames during the loading sequence prior to the "Ready" prompt showing up. Doing so typically allows for a VERY slightly faster start to C64 games. These inputs can also affect the sequence of subsequent lag frames.
Regarding idling, it doesn't have a flashing cursor on mine. Here's an encode of the loading sequence from power-on through the first stage of this run. The "run" command is seen around 1:13ish.
Link to video
Are we using the same version of BizHawk?
Have we just discovered a loading inconsistency in BizHawk for C64Hawk core?
EDIT: We should probably set the judgement decision to "Delayed" until we get some of these questions answered.
UPDATE/EDIT 2: Received an email back from the developer. (Screenshot)
I don't really know if or how much that helps us.
For those curious, the PC Museum Rick's referring to is this one; whose primary curator/operator passed away last June at the young age of 46.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
If you're looking at making a TAS for submission to TASvideos, stick with the NESHawk core as it's generally accepted here as more accurate than the QuickNES core and is the preferred core for TASing.
As I understand it, QuickNES is still present for more casual play situations.
Also be aware that for submissions, ROM hacks require additional qualifications to be met for runs of them to be accepted on the site.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
Cancelling: I was able to manipulate RNG in Level 1 and get a 19 frame improvement. Looks like this was a premature submission. Sorry everyone.
EDIT: And to confirm the speculation in my submission notes, it does require complete re-do of subsequent levels, not just re-syncing.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
feos wrote:
What about "sniped"? This would showcase the dramatic effect. Overall I like this idea.
I like "Sniped" or "Sniped Runs." It's, at least, some degree of official recognition/archival of the accomplishments that would otherwise have been published.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
feos wrote:
DrD2k9 wrote:
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.
I don't understand what you're saying at all.
I'll try to reply to the actual post when I see the relation between reality and your feelings about it.
Thank you for at least reading and considering the post.
Here's what I'm trying to get at regarding publication order and maintaining a valid "obsoleted by" flag while still being able to publish both runs.
Alex_ik's run un-accepted and sits in gruefood due to the arrival of Mars608, et.al.'s run
Mars608's run sits on the workbench.
Step 1 - Assuming Mars608's run is accepted, publish it. It then gets a movie page designation/number of XXXXM.html.
Step 2 - After Mars608's run has been published, then publish Alex_ik's run. Since Mars608's run has already been published and has it's movie number designation, the "obsoleted by" flag can be set in alex_ik's publication pointing to Mars608's run.
This allows both runs to be published without arbitrarily obsoleting alex_ik's run in a vacuum.
In other words, when this type of rare situation happens. Simply publish the faster run first and set "obsoleted by" ID accordingly when publishing the slower run.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
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
(2057)
Joined: 8/21/2016
Posts: 1011
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
(2057)
Joined: 8/21/2016
Posts: 1011
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
(2057)
Joined: 8/21/2016
Posts: 1011
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
(2057)
Joined: 8/21/2016
Posts: 1011
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
(2057)
Joined: 8/21/2016
Posts: 1011
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
(2057)
Joined: 8/21/2016
Posts: 1011
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
(2057)
Joined: 8/21/2016
Posts: 1011
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
(2057)
Joined: 8/21/2016
Posts: 1011
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
(2057)
Joined: 8/21/2016
Posts: 1011
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
(2057)
Joined: 8/21/2016
Posts: 1011
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
(2057)
Joined: 8/21/2016
Posts: 1011
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.
