Editor, Experienced Forum User, Judge, Published Author, Expert player
(2094)
Joined: 8/21/2016
Posts: 1029
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
(2094)
Joined: 8/21/2016
Posts: 1029
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
(2094)
Joined: 8/21/2016
Posts: 1029
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
(2094)
Joined: 8/21/2016
Posts: 1029
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
(2094)
Joined: 8/21/2016
Posts: 1029
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
(2094)
Joined: 8/21/2016
Posts: 1029
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
(2094)
Joined: 8/21/2016
Posts: 1029
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
(2094)
Joined: 8/21/2016
Posts: 1029
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
(2094)
Joined: 8/21/2016
Posts: 1029
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
(2094)
Joined: 8/21/2016
Posts: 1029
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
(2094)
Joined: 8/21/2016
Posts: 1029
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
(2094)
Joined: 8/21/2016
Posts: 1029
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
(2094)
Joined: 8/21/2016
Posts: 1029
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
(2094)
Joined: 8/21/2016
Posts: 1029
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
(2094)
Joined: 8/21/2016
Posts: 1029
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.)
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2094)
Joined: 8/21/2016
Posts: 1029
Location: US
feos wrote:
The question is, do you count the scenario where things you haven't obtained during normal gameplay, magically appear from the outside, as an any% category?
If it's intended to magically appear from the outside, yes.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2094)
Joined: 8/21/2016
Posts: 1029
Location: US
feos wrote:
Saved game is not related either. Saved game won't help us get rid of the additional image requirement if we want new monsters.
The question is, why do you think we should judge 2 similar scenarios differently:
1) using SRAM to unlock new content not available from scratch, and
2) using additional image to unlock new content not available from scratch?
How does the latter magically make it any%? Especially given how strict some people are about any% in general, the purpose of Vault is to never have to explain anyone that "well, this particular not-quite-any% is still considered any% by some people, therefore we consider it absolutely objectively clear cut, and therefore vaultable". Do excuses like this really sound sensible to anyone?
Firstly, I don't know how much of the following is appropriate to this particular submission vs. my opinions as general concepts.
I understand that my personal opinions aren't always going to be the most ideal/practical for the site's policies. For what my opinion is worth though:
Saved game or not, I don't feel the use of the arbitrary image/SRAM/memory card data should automatically negate a run from being vaultable.
For the same reason, I don't think these two scenarios shouldn't be judged differently.
If the game is started from scratch and new content is then obtained through the course of normal gameplay as intended by the publishers using any of the above methods, it is still a valid any% run in my opinion. I realize this may not mesh with everyone else's perspectives. The key to me is that the game is started from scratch.
If the game is designed to read data from a source other than the original game disc/image, the console hardware, or the controller; how the data got on that additional source shouldn't matter. The game doesn't care how the data was developed, only that the data is present where it's being sought by the game.
As long as getting the data where it needs to be for the game to read it is done via a reproducible method, I think the game started from scratch should still be vaultable. Even if this means the additional source (SRAM, memory card, or disc image) was custom made in a hex editor.
TL:DR I don't feel that a game's publisher intended use of data from an outside source not created by the game itself should automatically make the game ineligible for vault.
ALL THAT SAID, if the site wants to negate vault eligibility for the use of any additional data not shipped with/contained in/created by the game itself, then I support that decision.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2094)
Joined: 8/21/2016
Posts: 1029
Location: US
Ok, I skimmed through things again.
I didn't realize before that all of the above discussion regarding secondary images was only considering a starting point from a saved game (NG+) standpoint.
I was thinking as if the run were started from scratch and utilized the secondary image to obtain the desired outcome.
As far as a game starting in an NG+ state, I agree it shouldn't be able to make vault.
If a game is started from scratch, then the secondary image is used in the course of the from-scratch game to obtain whatever outcome, I think that should be acceptable to vault.
Sorry if I made this discussion more confusing.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2094)
Joined: 8/21/2016
Posts: 1029
Location: US
I agree with a lot of it, including potentially avoiding copy-written discs/images as the secondary image.
The only questions I have are regarding vaultibility.
feos wrote:
Vaultable?
Should we allow movies using images, that don't belong to the original game, for Vault? The Vault is designed to only allow things that can be easily, clearly, and unambiguously defined. While some of the Vault rues are still quite complicated in their wording (like those for sports games, or for full completion), the spirit behind them is still simple: we want clear cuts and meaningful speed competition records.
In that sense, due to all the complexity of this case-by-case exception, I do not think that we should allow use of unintended images for Vault. And the definition of intended image is the same: either the game explicitly asks for some particular image, or the publisher encourages using it, like it happens with Sonic & Knuckles and Sonic 3 (or modern DLCs maybe).
If we are requiring a custom optimal image for the secondary disk to be shared/reproduced with the publication, then this aspect for any future submissions should be considered clearly and unambiguously defined as long as the secondary image accompanies the submission (either directly attached, or complete directions on how to reproduce).
As far as using publisher intended images, the publishers explicitly say to use any CD's you have. Therefore no discs/images should be considered unintended.
Also considering the following:
Starting a game as it is and playing it from scratch is a vaultable concept. Using an external resource to boost your stats is not.
This game however isn't the same situation as using an unintended external source (such as a game-genie) to boost the stats. Game modifiers (game genie, etc) introduce different than standard gameplay.
The key with this game is that the use of an external resource (different discs) to boost stats is expected and encouraged. Therefore using additional discs/images is considered by the publishers as part of standard gameplay.
For these reasons, I feel that submissions should still be vault eligible.
EDIT:
Regarding my earlier comment. I was just suggesting that those types of data would be valid in a real-life situation....not suggesting we accept them here.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2094)
Joined: 8/21/2016
Posts: 1029
Location: US
As far as self-created images:
Assuming someone knew exactly where the game looked for data on the target image/disc, couldn't someone create a image to yield the desired data then burn it to a practical CD and use it on a real system?
If that's the case, then any CD data or image that could be burned to real media should be considered valid as it would be theoretically usable on a real machine as well.
I agree and fully support MESHUGGAH's reasons for restricting the data of that image for publication on the site. From a data standpoint though, the examples suggested -- (nudes, virus, justin beiber albums) -- would still probably be valid data sources.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2094)
Joined: 8/21/2016
Posts: 1029
Location: US
xxNKxx wrote:
here's explain
If not do red line then green line will not work
If do glitch then don't need do red line, judt need do green line
If this's ok then I can remake for select last level and done around a minute
The above in better English:
To use the cheat normally, you have to input a special password, then use an additional input combination (code) to access the cheat menu/cheats.
The glitch bypasses the password requirement. It does not bypass the input combination (code) to access the cheats.
My opinion:
As the glitch only skips the first of two requirements to access the cheats, the second requirement is still unacceptable cheat code use, based on our current rules.
If a way could be found to glitch past both requirements, it would be acceptable.
If not do red line then green line will not work If do glitch then don't need do red line, judt need do green line If this's ok then I can remake for select last level and done around a minute