Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
How will this affect the completion times of currently published runs?
For example, Circus Caper requires a few inputs to progress through the end-game story after beating the final boss.
If the completion point is considered to be the last input needed to beat the final boss and start the end-game sequence, the completion time listed is incorrect.
If the completion point is considered to be the last input needed to finish the post-game story, the time is correct.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
Not yet...I have one other idea to test. If it doesn't work, then I'm going to give up on syncing this particular submission.
EDIT: As with ThunderAxe, I was able to create from scratch images that acquired the correct monster...however the run desyncs.
Here is the from-scratch image I created if anyone else wants to try re-syncing the inputs.
https://www.dropbox.com/s/u362n94dry060xx/TEST-CD.zip?dl=0
I may attempt to re-sync myself at some point in the future, but that's pretty low on my priority list at this point.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
I was invited via pm to join Truncated's team.
While I had originally planned to not join any specific team and instead just see who I would randomly be grouped with...seeing as I'm the only individual currently signed up and not yet on a team, I have changed my mind and have accepted the invitation.
So this serves as my confirmation of joining that team.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
The biggest problem I see is this: If someone uses a legit copy of the game and someone else uses a pirated/DRM-free copy of the game, how do you compare the resulting TAS? Especially if the DRM-containing run is longer only due to the DRM being present (loading times, etc).
The recent discussion about format conversions for C64 might be slightly applicable in this context too. Namely, that discussion resulted in the rules being clarified to only allow using formats of the game know to have been legally released unless those original formats cannot be obtained. This added to the previously existing rule that disallowed cracked versions of games unless no un-cracked version is obtainable.
For my opinions specifically on using pirated versions of games:
If the game was legally released in both DRM-free (GOG, Steam, etc) and DRM-containing (Disc, Floppy, etc) versions; either version is fair game for TASing and either can obsolete the other.
If the game was never released in a DRM-free version, a pirated/hacked version is only allowable if the original version containing the DRM isn't obtainable. (This is based on currently established rules regarding cracked/hacked games for other systems.)
If the un-pirated game is obtainable, pirated versions shouldn't be allowed simply to save time and/or increase compatibility due to a lack of otherwise intended DRM.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
I'm in for participating, don't have a team yet.
For anyone who ends up on my team...I'm unfortunately limited to 32-bit versions of BizHawk (namely 1.13.2 as of this message).
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
I apologize if using the different FreeDOS and BIOS images made/make things difficult.
I had done a bunch of testing a while back while trying to get CD based games working on JPC-rr.
Some of that testing I held over, as I felt it was better to use an updated BIOS and FreeDOS image with linear mouse function (from a TASing perspective).
If these new(er) images need to be provided somewhere (assuming it's legal to do so). I can get them to whoever wants to post/host them.
Specifically for the FreeDOS image; I can't imagine trying to TAS anything (at least in c-square's click/drag modified JPC-RR 11.2) using accelerated mouse movement when linear is an option and the mouse pointer can typically cover the entire screen in any given frame. Even TASing in a different version of JPC-rr that doesn't have the click/drag support, moving a mouse pointer the same distance using linear vs. accelerated would simply require inputting a different (often larger) number into the mouse movement box for linear than it does for accelerated; but this wouldn't change the frame count that it took to move the mouse (at least in any game I've tried in JPC-rr).
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
Radiant wrote:
I suppose you've tried this; just to check: killing the giant with the sling may be faster than waiting for him to fall asleep? And climbing down the beanstalk may be faster than using the stairs. An odd detail in the run is that the screen shaking (when you fall) is so slow; I suppose that's because it waits for vsync whereas nothing else in the engine does.
I eliminated killing the giant from my routing plans simply because of all the extra screen transitions it requires. Specifically going out of the way to get the pebbles by the beach, then out of the way again to to get the sling before returning to the giant to kill him. I did not test this option, as I felt all the extra travel would add time (perhaps I should have tested it).
Routing was also the reason I went up the beanstalk instead of the cave climb. There are simply more screen transitions to use the cave going upward (and more distance traveled on those screens for the cave as well).
As far as coming down the beanstalk...from the giant, the cave is closer than the top of the beanstalk; and the bottom of the cave is much closer to the castle. So while the beanstalk is faster routing going up, it's slower routing going down.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
fsvgm777 wrote:
Can you tell us where you got your FreeDOS image from? Its ID doesn't match with the imported image that came with the JPC source (yours is 45c3f118cbca79f176307142c73f780c, the imported one from the JPC source is f334bc4d5dc5f393feb0ca2d1e1cdc25 (which you have used in the past, mind you)). In fact, it doesn't even match with the imported 1.2 image (b47e30f0d3574d8be004742104ada494).
The only thing I can think of is that my FreeDOS is a slightly modified version of the one with the JPC source. I edited the autoexec.bat to automatically load the mouse into linear mode instead of accelerated (this makes TASing mouse based games much easier). I then extracted the resulting drive to a new image.
I can get you a copy of the image if you like.
Side note: The input event stream syncs with both of these version of FreeDOS.
Dacicus wrote:
Some questions that didn't affect my vote:
Does the ending song freeze or something? It's a well-known tune that I'm too lazy to look up, but it doesn't seem to actually reach the end.
Is the RNG in the cave for a dwarf or an elf?
I have no idea why the ending music froze. Bad movie dump maybe? I'll re-dump to see if this is the case.
I had done a quick TAS using debug mode as joke for the RTA community. The end music played fine on that one.
According to the game logic files, it's a dwarf in the cave.
£e Nécroyeur wrote:
The music does freeze. The song is "Greensleeves".
DrD2k9, does the game freeze at this point, or is it only the music? Is it still possible to clear the credits dialog box after the music has frozen?
If a new dump doesn't clear the problem, I'll have to do some checking on whether or not the credits can be cleared after the music freeze.
As a side note: The credit's message can be cleared immediately upon showing up....however this results in just seeing the newly crowned King Graham sitting on his throne while the music plays.
In my opinion, the TAS should end on the last input to get to the credits message, not on the input to clear those credits.
MAJOR EDIT:
I realized that typing "fast" to change the game-speed is actually faster than using the menu. Unfortunately this happens at the very beginning of the run. This required a complete redo of the run.
Here is a link to the new movie file. Someone with the power, please update the submission.
Notes on the new run:
As the mouse isn't needed, I used the stock FreeDos image instead of the modified one. I also bypassed the Autoexec.bat and fdconfig.sys files on boot.
The submission text has been updated to detail changes.
Regarding the concerns addressed earlier in this post:
The game did indeed freeze on a re-dump of the original submission. Clearing the credits wasn't possible.
I've confirmed that this new movie does have normal music through the end, and the credits could be cleared after the music ended.
Though I did not test the event stream of the new run on both FreeDOS images, I'm guessing it would sync on either as it did before.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
Radiant wrote:
For this game in particular, please consider a 100% run as well because (unlike most of their later games) KQ1 is pretty elaborate in allowing multiple different solutions on most puzzles.
I'm all for doing the 100% run. That said....I could really use some help with routing it.
RNG may not be quite as easy to manipulate on this one. Unlike SQ1, this game doesn't have the option to type "Y" to advance the random seed. Screen scrolling would work, but would be a slightly slower than "Y" was in SQ.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
feos wrote:
Requiring devices that don't normally come with the console or the computer in question, nor with their games, and aren't even among common peripherals for casual use, sounds like using a devkit version of the system or the game: arbitrary requirement that one is not supposed to have to simply play those games. It's a shaky ground, and it might sound simple for simple systems, but with modern ones that support tons of peripheral types and approaches, it will drive us crazy if we allow arbitrary addons.
This perspective makes sense. Also, I had a brief, but good discussion with someone on discord who was concerned that this approach may set a bad precedent for other systems.
To paraphrase that discussion, the concern was that finding a way to alter loading times on some systems can affect gameplay timing/strategy because gameplay occurs simultaneously with loading times.
The example used was loading a Wii game from a USB instead of a disc, which might cause some rooms/map areas to load faster and alter whether or not certain glitches/strategies could (or couldn't) be utilized when they are for the standard/original media.
While I'm unaware of any C64 games that have such loading periods simultaneous with gameplay, there may be a few out there that do. So, as much as I'd like to see the shorter loading times accepted for C64, I don't want to set a bad precedent for other systems.
Unless the staff feels that there is still potential for this method to be accepted (via whatever rule/guideline updates may be necessary), I am willing to cancel this submission.
If an official ruling would be better so as to set a precedent in the other direction--preventing such media conversions--I am also willing to let it stand and be 'judged' officially.
Either way the decision ultimately goes, I feel the site stands to gain a more concrete approach to TASing across all systems.
Thank you all for your perspectives and consideration.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
ThunderAxe31 wrote:
feos wrote:
So for this submission, it'd have to be tweaked to use a non-arbitrary extra image that meets the requirements, it can even work the same as the image used here. Then we'll judge the actual movie finally.
...I'll try to make a handcrafted image that syncs for this movie, as resyncing the movie would basically mean to re-do everything fron scratch.
If a different image would result in a more optimal monster...it's worth redoing anyway.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
Memory wrote:
From what I see...
DrD2k9 wrote:
One last thought that may or may not mean anything for whether or not this is acceptable for the site: These types of conversions are actually possible on real hardware. If I had the EasyFlash cartridge to do this on my own C64 (or something similar for my Vic-20 for that matter), I would do it in a heartbeat.
Contradicts
I do not know what it would have taken to convert a game to cartridge format on the system itself (if this was even possible).
What do you mean?
I was saying that I'd gladly use an EasyFlash cartridge on my C64. As the disk2easyflash program is a PC program for converting from disk image to crt image format, the conversion wouldn't take place on the C64 itself.
Regarding the part about converting from disk to cartridge on the system itself: I don't know what all would be required to create a classic cartridge. At minimum, you'd need all the cartidge hardware and an EPROM programmer to program the cartridge from the C64.
It does appear that it's possible to create a .crt image on the C64 itself from data on other C64 media and then copy that .crt image to the EasyFlash cartridge. see here. http://skoe.de/easyflash/doku.php?id=writecrt I don't know how/if disk2easyflash is better/worse/equivalent to doing so in this manner....but it's a heck of a lot easier in my opinion.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
Some further thoughts from me on this whole concept:
The C64 could copy between Tape and Disk formats using commands within the system itself.
Much of the copy protection of the era was based on specific data positioning on whatever format was used for the game (which is why so many game versions currently available are cracked to begin with--to bypass this type of copy protection).
I do not know what it would have taken to convert a game to cartridge format on the system itself (if this was even possible).
The way I understand the Disk2EasyFlash program is that the C64 reads the .crt image as it would any other cartridge. The conversion basically makes the original disk-based game code run from the EasyFlash cartridge as if it's reading from a disk drive (only a much faster disk drive than the 1541).
Basically, I see the conversion somewhat akin to reading the game information from a 48x speed rom vs a 2x speed CD rom. Or reading data from a USB drive instead of an old floppy drive.
The game data remains effectively the same. It's just where the C64 looks for that information is changed from the 1541 Disk Drive to the cartridge slot. Then the converted .crt image mimics the disk drive to provide the C64 with the game data. It's why there is still a loading screen when using the converted image.
The reason the converted image has faster loading is because data transfer from the cartridge slot was much faster on the C64 than data transfer from a 1541 disk drive--which itself had a known issue that made loading from the 1541 slower than it even needed to be (fastload carts were made to help this particular issue, thought that might be off topic a bit).
So to answer feos' question about what is lost/missing...other than for games that won't convert in the first place, nothing from a game itself should be lost by the conversion. The only thing lost/missing is waiting periods for loading.
As far as the C64 system itself is concerned...how long a game takes to load isn't important to the C64; only that the data is present in memory when it's time to actually run the program.
Further, I can't imagine a programmer specifically tying whether or not a game works properly to how long it takes to load the game's information from a disk/tape; because that timeframe can vary slightly in a real-life situations from one C64 system setup to another.
As far as load time affecting the game itself, the conversion shouldn't affect how the game plays aside from possible RNG effects as described below.
There are two possibilities where a game's RNG may be affected using this conversion method:
1) Situations where a game bases its RNG on the C64's internal time value--how many jiffies (1/60th of a second) from 'power on'. Games using this RNG approach are equally affected by sitting idle on the boot screen before loading a game for any number of frames as they are by loading times.
2) Situations where games require multiple loading sequences during the course of gameplay. If these secondary loading sequences affect frame/time based RNG, it could potentially affect the RNG outcome of the game. If the loading sequences do not affect the frame based RNG, this is not an issue.
So loading faster should only change RNG values, not the how the C64 runs the loaded game code itself. In either of the above RNG situations, the game should still play as it always would, just with different RNG.
One last thought that may or may not mean anything for whether or not this is acceptable for the site: These types of conversions are actually possible on real hardware. If I had the EasyFlash cartridge to do this on my own C64 (or something similar for my Vic-20 for that matter), I would do it in a heartbeat.
EDIT: For this specific submission, the RNG wasn't affected at all by the difference in loading time/system time. RNG is therefore affected only by in-game actions or by the time since the game-code was 'run' (which is equal between the submission and the published run).
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
EZGames69 wrote:
DrD2k9 wrote:
The whole point of this submission is to get feedback from the community's perspective.
You could have easily did that if you made a topic about it in one of the other form threads. You didn’t have to make a submission just to ask the community what they thought of the idea.
I did it as a submission on adelikat's suggestion.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
fsvgm777 wrote:
TASVideoAgent wrote:
This submission's 'ROM' is a unique cartridge image file that I created. As it was created from the same disk image that adelikat used in his run, I assume anyone else using Disk2EasyFlash on that disk image should be able to create an equivalent cartridge format image to verify this submission.
Yeah....no. For one, the game was never released on a cartridge. So, we're limited to either the tape version (and deal with absurdly long load times) or the disk version (which is often a cracked release, which adelikat used in his TAS), not a cartridge image you created yourself with some tool.
Thanks for your input. The whole point of this submission is to get feedback from the community's perspective.
Also for clarification, most of the tape releases out there are cracked versions also.
Memory wrote:
Just because we're unfortunately limited to illegitimate images, doesn't mean we should be modifying them further to be even more illegitimate...
Thanks for your input as well.
For the sake of debate and trying to consider all perspectives: What makes one illegitimate image any more/less valid than another illegitimate image?
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
feos wrote:
Solution
When the game asks you to insert a certain specific image (in-game or through the manual), it is considered a part of the game. And it can only be inserted when the game explicitly prompts for that. Inserting disks that weren't asked by the game is not allowed.
When a game asks you to insert an arbitrary image, you need to have an image that's been generated exactly for this movie, you need to have instructions how to recreate it, and you need it to serve the goals of your movie as optimally as reasonably practicable. Only such "arbitrary" images are allowed, and only when the game duly prompts for inserting them.
This was approved by Nach and liked by judges. Opinions, suggestions, complaints? Also maybe I forgot something?
So am I'm reading this correctly...
The "arbitrary" disc image being generated specifically for the movie submitted, in effect, is being made non-arbitrary due to the nature of it's creation. Thus it's going to be allowed for vault?
Or is this just a site standard for any run of these types of game that utilize additional 'arbitrary' CD data, and they still aren't vault eligible?
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
Omnigamer wrote:
...but in my opinion makes any disc-less submissions far less interesting/entertaining to perform or watch.
As much as I like your concept of the extra CD being simply another form of input similar to controller input...this particular statement unfortunately does nothing to support allowing the extra CDs for vault runs, because the vault doesn't care about entertainment.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
feos wrote:
You said it yourself. Catching them all is not any% for pokemon games, it's full completion.
But trading can still be done to get better/different monsters that would otherwise be unobtainable in a run not using the link. If the goal is to beat the game fastest and it can be done by trading for a specific pokemon, that's the best method regardless of how many pokemon are caught otherwise.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
ThunderAxe31 wrote:
DrD2k9, in this post I brought up why I consider obtaining monsters with this feature to result in a non-Vaultable movie; I'd like to hear opinions and thoughts about it.
Since it's in the previous thread page, allow me to copy-paste:
ThunderAxe31 wrote:
The usage of arbitrary images introduces the same problem of secret passwords, codes, and input sequences: these rely on a knowledge external to the game and its official manual, and thus giving an unfair advantage to the player. So a movie that makes use of an arbitrary image should be allowed only if it introduces gameplay that results enough different from the Vaultable branches, as well as meeting the entertainment requirements of Moons tier.
Below I show the relative text in the Movie Rules page (bold mine):
We allow playing unlockable content using in-game passwords
Using in-game codes[1] or passwords at the start of a game is allowed if it makes the game harder or if it makes cosmetic changes to the game, as long as parts of the game are not skipped.
Using in-game codes or passwords at the start of a game to unlock a special game mode, character, level sets, or otherwise play the game in some unusual way is allowed. However movies of this nature are not considered to be one of the primary branches for the game.
Please tell me if you agree with my interpretation.
Putting a different CD into the PSX is not relying on knowledge external to the game, just data external to the game.
A player who inputs a code must know the specific code before inputting it to yield it's result (and it can be generally assumed that the player knows what that result will be before using the code).
A player sticking a different CD into the PSX doesn't have to have a specific CD nor does the player need to know the result of the CD used to continue with the game.
Further, the use of the CD is intended as part of normal play, not play enhanced/altered by a secret code/input sequence. I generally look at codes/passwords/etc. as things that either intentionally make the game easier/harder. The CD swap with the MR games is not a guaranteed result of easier or harder (it could in fact yield a neutral result).
The fact that someone at some point in history figured out how the game uses the other CD's data (which then allows us to pre-define that CD) doesn't change the fact that the game is still using the information as if it's a normal unenhanced playthrough.
The CD swap is a 'luck' situation. Getting the best possible monster from the swap is like getting lucky in picking the right disc when playing on actual hardware. We just manipulate the luck to yield the best outcome.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1011
Location: US
Required, No. But they are intended/expected to be used as a resource to beat the game.
It's kind of like Generation 1 pokemon games. Through normal gameplay (not using glitches) it's impossible to catch all the pokemon without trading with another player via a link cable attached to another gameboy (an outside source of data). Doing so isn't necessary to beat the game, but it can be used as a resource to yield different/stronger pokemon that may allow for beating the game faster than playing through without trading. (yes I realize the presence of glitches makes this moot for pokemon games specifically, but the concept of the outside resource is sound.)
