Editor, Experienced Forum User, Judge, Published Author, Expert player
(2094)
Joined: 8/21/2016
Posts: 1029
Location: US
GJTASer2018 wrote:
DrD2k9 wrote:
Curiosity...wouldn't a mode B run be faster?
The problem with that is that each mode behaves differently when you reach Level 100 - AFAIK only Mode A has the killscreen, while Modes B and C rollover back to 1. This would essentially mean each mode could potentially have its own branch, given a high enough entertainment rating, and obsoletion of an existing submission could become problematic.
If there's a kill-screen in mode A then completion of that mode is reaching the kill screen.
For Modes B & C though; if nothing new occurs after the roll-back to level 1, the game can be considered endless. thus rules for endless games come into play (at least for vault purposes).
Therefore a completion point must then be defined.
I see basically two options for an end-point:
1) Finishing the 1st 100 levels until the level # rolls over.
OR
2)Finishing just the first 25 levels.
According to this data it appears that difficulty stops increasing after level 25. Therefore, it could be argued that only the first 25 levels need to be completed to reach a point where no new content is introduced to the endless gameplay.
If the first option is used, the completion of a Mode B run would be roughly half the length of this submission.
If the latter option is used the completion of a Mode B run would be even shorter...somewhere approximately 1/8 the time of this run (9-11 minutes).
I don't know how mode C would be affected as I haven't come across difficulty data for the clay pigeons. Thought I would assume if there is a difficulty ramp in that mode it would mimic the difficult ramp of the other modes.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2094)
Joined: 8/21/2016
Posts: 1029
Location: US
Curiosity...wouldn't a mode B run be faster? While there are a few frames between ducks, the dog would hold up 2 ducks at once instead of just 1, thus halving the wait time within a round. This could significantly lower the overall run time.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2094)
Joined: 8/21/2016
Posts: 1029
Location: US
link_7777 wrote:
PikachuMan wrote:
If we're going to do a TAS of this and Gyromite with R.O.B., we need a CRT TV connected to the computer with either a VGA to Composite adapter. on an HDMI to Composite adapter. With that said I'll have to vote no.
There is already a TAS of Gyromite.
I don't think a TAS with a real R.O.B. is very viable. Technically it should be possible if you build in some margin and everything happened to work as expected during playback, but there are a lot of factors. Also this category would be very long with a real R.O.B. (though perhaps 99 phases would be shorter).
If you were interested in making more of an attempt to play the game as intended I would suggest a "virtual R.O.B." category where you would send the correct commands, but just show the R.O.B. activities as an animation (imagine if R.O.B. was also tool assisted and performed activities quickly and accurately). This category would also be a bit long with a "virtual R.O.B.", I would argue that in a lot of ways the R.O.B.-less category in this submission is a more interesting TAS.
A TAS using a virtual ROB may be interesting. Unfortunately, the result may not meet moon level entertainment value. And as the shortest way to beat the game (due to the honor system) is by just hitting the start button as seen in this submission, a TAS using a virtual ROB would likely not be vault eligible.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2094)
Joined: 8/21/2016
Posts: 1029
Location: US
Niamek wrote:
I didn't mean it exactly like this. I mean removing the rerecord field from the site so it can't be seen by everyone, but the admins (and judges if needed).
Some additional thoughts stemmed from the above.
Is displaying rerecord count necessary once a run is published? If the run is accepted as worthy of publication, does anyone need to know the re-record count beyond that point? If someone wants to try and beat a current publication, whether they do so with more or less rerecords isn't really important so long as they succeed in actually beating the active publication.
I don't personally care if they are present or not in a publication (as I tend to completely ignore the rerecord count when watching already published runs anyway), I just had the above curiosities.
I realize that some may use a published rerecord number as an indicator of how much work went into the published TAS, and thus, use that information to sway their decision on if they want to try and beat the run; but I personally don't think someone else's rerecord count should be a factor in choosing a specific game. I feel that if someone wants to TAS a specific game they should, regardless of how much/little work someone else has put into that game in the past.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2094)
Joined: 8/21/2016
Posts: 1029
Location: US
While re-record count can be a very good indicator of how much work went into a TAS; it's unfortunately not a metric that really tells us anything about the quality or entertainment value of the final TAS movie itself.
I'm sure there are published runs with very high re-record counts, that I personally would find boring. Also, there are likely some with low re-record counts that I would find rather entertaining.
Similarly, a high re-record count doesn't guarantee a quality run from a technical aspect; just as a low re-record count doesn't guarantee a poor quality run.
Re-record count may be a useful metric as a tool for helping with the judging process (for example, in helping a judge determine how much effort to put into finding potential improvements before accepting/rejecting a run). It is, however, not a metric that I feel should alone sway a judgement one direction or another; I don't expect this has happened much if ever (I have pretty good faith in our judges).
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2094)
Joined: 8/21/2016
Posts: 1029
Location: US
Radiant wrote:
I suggest Eindeloos. It's a very technically advanced game (for the C64, that is) and offers a huge maze. At the time of release, it was rumored to be impossible; the name literally means "Endless", suggesting there is no end to the game. There actually is, but it took players several years to reach it. It would probably make a good dynamic TAS.
I'll look into it.
EDIT: Looked into it. Have roughly translated the in-game story as well as the instructions and story presented on the game packaging.
Tinkering with controls at the moment. Not a very easily controlled game. Joystick input is only read every 8 frames or so....shooting is even worse....roughly every 16. Lots of lag that varies depending on movement and screen activity.
Interesting note...Radarsoft offered a contest right on the game's packaging offering some nice sounding prizes for whoever could map the game. Unfortunately....I have been unable to find ANY maps of this game.
Thankfully there is a longplay on youtube I can use as a base guide for doing a TAS.
MAYBE if I get REALLY ambitious....I'll map this whole thing!
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2094)
Joined: 8/21/2016
Posts: 1029
Location: US
Sometimes (if not most of the time) glitches are found by accident; either through casual gameplay or via the course of testing normal mechanics/parameters for a game.
Once a glitch is discovered, then it must be determined whether or not that glitch is useful, or can be made useful.
One glitch that occurs in multiple games results from pressing both U & D or R & L together. Doing these inputs together isn't commonly possible with most hardware (gamepads/joysticks) but the game code itself will still try and process it if they are done together. This can sometimes allow for unusual/glitched results.
Just play around and see if things happen that you don't think the game's developers intended. If you find something that looks odd....congrats you've found a glitch! Now try and make it useful.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2094)
Joined: 8/21/2016
Posts: 1029
Location: US
EZGames69 wrote:
Not a judge, but I’m pretty sure that rule is saying a movie cant start from something like a savestate. Starting from “power on” would usually mean when the game actually boots up, which can include the BIOS (if the emulator allows it to play)
Hmmmm...
If this is the case, then perhaps we need to consider a new way of timing DOS/C64/etc runs for publication when they require longer booting/loading sequences.
It would be nice and better reflect the actual speed achievement of these runs to have just the time from when the game is executed to the final input instead of from power-on w/ boot and loading.
As examples:
While it would take more detailed analysis of the run, C64 games could be timed starting when return is pressed to send the "RUN" command to the CPU.
DOS games could similarly be timed from when enter is pressed to send the executable command to the CPU. This timing method for DOS would solve the issue of timing DOS in libTAS vs. jpc-rr (though it still doesn't solve CPU clock speed discrepancies...but that's another issue altogether and off topic)
This isn't perfect as a good number of C64 games continue to have further loading after the "RUN" command, but it would still be better than current methods for expressing accurate gameplay timing. It would also allow publications of C64 games to include only video from the execution of the program by the "RUN" command onward eliminating long boring loading screens from the published videos.
However
Due to the way times are automatically calculated, however, this all would definitely throw a wrench into the automated submission system. Then again we could always just go with the automated time while the run sits on the workbench and have the publications show the actual game-time. This would unfortunately require more working steps by the publishers.
c-squares points/concerns are legitimate.
We may not need to change anything regarding how submissions or publications are handled. This might be able to be cleared up by a rewording of the rules; perhaps adding something regarding "deterministic vs variable boot/loading sequences" simply for clarification.
This situation is probably best addressed/discussed by feos (as the senior judge) and other site administrative staff.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2094)
Joined: 8/21/2016
Posts: 1029
Location: US
With our current methods of emulation, DOS (via jpc-rr) and C64 timing should be guaranteed consistent from power-on and through loading; so long as the same disk images are used.
While I acknowledge that inclusion of these loading/boot sequences causes the published time of runs using those systems/emulators to be somewhat inflated in relation to actual gameplay, it's a minor issue because of the consistency.
For games using a program like libTAS (as opposed to a true emulator like jpc-rr), where boot-up can vary so drastically, I think it makes more sense not to include boot-up sequence in the timing. The only way to effectively compare runs using libTAS/Windows is starting from a point where consistency should be guaranteed which may be game-start instead of power-on.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2094)
Joined: 8/21/2016
Posts: 1029
Location: US
Something was nagging at me and I just felt the need to run through this one more time...
I saved even more frames mostly through slightly better movement optimization of a few screens.
Here's an updated .bk2 of this run.
As of this file, the BizHawk version is now faster than the current published run. Therefore I've not redone the inputs in FCEUX opting instead to stick with the more accurate emulator.
If I need to cancel this submission and make a new one with this userfile, please let me know.
I'll be editing the submission notes and adding an encode as I am able.
EDIT: Submission notes updated and Encode added. Once someone with the power to do so replaces the submission file with the above userfile, the emulator used will also need updated to avoid confusion.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2094)
Joined: 8/21/2016
Posts: 1029
Location: US
Well I feel stupid for not trying this before now....
It's possible to use the Magnet scroll before Mordamir taunts the player about not having any more defenses. Doing so negates the need to hold A/B through his taunting monologue and doing the spell afterwards. This shaves a bunch more frames from the end of the game.
Can someone with power replace the movie file with the following User movie #53712640492961666?
This does alter the end game making the above encode SLIGHTLY off. Essentially, Mordamir's monologue text will display slower, but the game will still finish as before.
Assuming acceptance: if whoever encodes/publishes the run wants an input file that uses A/B inputs to display the text faster, I can provide that. But this new .bk2 is the earliest I could get a final input to beat the game.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2094)
Joined: 8/21/2016
Posts: 1029
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
(2094)
Joined: 8/21/2016
Posts: 1029
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
(2094)
Joined: 8/21/2016
Posts: 1029
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
(2094)
Joined: 8/21/2016
Posts: 1029
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
(2094)
Joined: 8/21/2016
Posts: 1029
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.
