TASVideos

Posted: 12/23/2017 11:33 PM

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2300)

Joined: 8/21/2016
Posts: 1133
Location: US

c-square wrote:

I wonder if the wait for the surveyors to leave is random.

Perhaps. I tried a few different paths to the site, but all my attempts resulted in them leaving at roughly the same time. Perhaps no random calls on Ortega happen before then so RNG would need to be manipulated earlier if they are indeed random. I'm really hoping I don't have to re-run this game.

I’m guessing the Two Guys’ text bubbles can’t be skipped.

Nope. I think it's around 45 seconds from leaving Pestulon before the warning for the battle with the space bandits.

Are you thinking of hitting the KQ series next?

I will probably look into it eventually. I'll likely attempt to finish out the SQ series first though. I'm also considering some Lucas Arts games (Indy and the Fate of Atlantis for one).

Posted: 12/23/2017 11:01 PM

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2300)

Joined: 8/21/2016
Posts: 1133
Location: US

Submission

Posted: 12/23/2017 9:16 PM

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2300)

Joined: 8/21/2016
Posts: 1133
Location: US

Link to video Temp Encode The last input happens at the text flash just before the black hole of the endgame cut-scene.

Posted: 12/23/2017 8:56 PM

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2300)

Joined: 8/21/2016
Posts: 1133
Location: US

Radiant wrote:

By reading the source code of the engine, not of the game. I can find out as needed when it becomes relevant for other SCI games.

So the calculation we used for SQ1 should be accurate for the first 3 KQ game as well?

Posted: 12/23/2017 8:44 AM

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2300)

Joined: 8/21/2016
Posts: 1133
Location: US

...and done. I'll upload the temp encode and submit the run tomorrow. Temp encode runs 16:38. Final input is much earlier as there is quite a bit of endgame cut-scene and credits.

Posted: 12/22/2017 10:54 PM

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2300)

Joined: 8/21/2016
Posts: 1133
Location: US

AAAAARGH, I did the whole trash zapping sequence typing 'zap' each time instead of using F3. Crud...that was a bunch of wasted time....oh well, going back and redoing. As far as Arnoid is concerned. The scorpazoid showed up a few times in my trials which changed RNG in some paths. I did use one extra screen transition to get the RNG to make him spawn very quickly, but it also yielded him arriving from the top of the screen and getting to the pods faster than other directions. This was the fastest way I could find from the different permutations of paths to kill him with the pods.

Posted: 12/21/2017 5:46 PM

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2300)

Joined: 8/21/2016
Posts: 1133
Location: US

Update: I've gotten Arnoid to appear at the pod screen by doing a couple extra screen transitions. I'm going to play around some more and try to minimize this until we can find a more controllable method of manipulating the RNG.

Posted: 12/21/2017 5:24 PM

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2300)

Joined: 8/21/2016
Posts: 1133
Location: US

Radiant wrote:

Of course, the initial random seed is going to depend on the system timer again.

But how did we know the calculation? I've been looking everywhere i can think of and searching online and can't find anything. How did you find it for SQ1?

Posted: 12/21/2017 5:17 PM

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2300)

Joined: 8/21/2016
Posts: 1133
Location: US

Interesting (and completely off-topic) theory: Roger Wilco is a Time-Lord. His pockets are bigger on the inside. And he travels through time.

Posted: 12/21/2017 5:06 PM

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2300)

Joined: 8/21/2016
Posts: 1133
Location: US

c-square wrote:

Looks like what you want to do is get rng numbers set up so that he appears, and it's after only two seconds before he starts coming for you. Looks like we might want to go hunting for that rng again. Unfortunately, this is SCI not AGI, so it may be a different calculation.

If it takes much RNG manipulation (other than altering the initial RTC time) it probably isn't worth it. I.E. changing screens a few extra times may negate the savings in time for the arrival delay.

Posted: 12/21/2017 3:44 PM

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2300)

Joined: 8/21/2016
Posts: 1133
Location: US

Thanks! I will try some different directions and see what results. At least I know I only have to wait about 10 seconds to know if he's going to show or not. Other potential uses of RNG manipulation (depending on game code): Shortening the wait for the space pirates to leave the survey site on Ortega. Preventing Attacks/blocks in the Robot Fight. Speeding up the arrival of enemy ships in the space battle at the end of the game, and/or changing the pattern of ships in front/back (though I don't think I've ever seen this as anything but alternating front/back).

Posted: 12/20/2017 7:05 PM

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2300)

Joined: 8/21/2016
Posts: 1133
Location: US

Ok, challenge. Can someone figure out if the time Roger has to wait on Phleebhut for the terminator is RNG dependent or a set amount? EDIT: I've been trying to compare the gear method vs. the pod method of killing Arnoid. I can't get him to show up on the pod screen even after waiting over a minute (in game). I think I'm missing some trigger that causes him to appear on the pod screen. Going upstairs in the World 'O Wonders will immediately spawn him coming up the elevator as soon as Roger reaches the upper scaffold level with the motor. As of right now, this is the faster of the two methods for this TAS even with some extra commands. This method is rarely seen in normal speedruns. Likely because it take more time with the text input and extra screens than simply luring Arnoid to the pods. Unless we can determine how to trigger Arnoid faster for the pod screen, I don't see how that method is going to be faster.

Posted: 12/20/2017 2:38 PM

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2300)

Joined: 8/21/2016
Posts: 1133
Location: US

c-square wrote:

Yeah, it can be tedious to do this.

It makes me miss the piano-roll input method of bizhawk/FCEUX.

Posted: 12/19/2017 11:46 PM

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2300)

Joined: 8/21/2016
Posts: 1133
Location: US

Link to video Current WIP. Using default JPC-rr settings. TASing this has been tedious. I've discovered that the mouse is not always the fastest input method for movement (keyboard is often used at screen transitions).

Posted: 12/18/2017 6:20 PM

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2300)

Joined: 8/21/2016
Posts: 1133
Location: US

Glitches I've discovered. Some of these games had other previously known glitches as well. C64 Congo Bongo - Found an out method of jumping to briefly reach an out-of-bounds area in the first of the 2 screens. This drastically reduces the time needed to complete that screen as well as makes difficulty changes moot for that screen. This could theoretically be used in a live run with appropriate positioning. C64 Double Dragon - Directional inputs can be used during a 13 frame window to control the flight direction of Abobo during his damage animation. Very useful for re-positioning Abobo to attack again. Could be useful in real-time. C64 Jungle Hunt - Opposite directional inputs on the same frame can sometimes glitch the character's position to the canopy in the latter two stages. It's not useful for anything other than possible addition of entertainment value. (Probably) Impossible in real play due to inability to input opposite directions with most stock C64 joysticks. DOS Space Quest 1 - Setting the game to fastest speed as soon as possible and moving Roger out of the first screen quickly enough will prevent the intro text box from appearing. Saves time in TAS and could theoretically in real-time also if the inputs can be done fast enough. NES Beetlejuice - Opposite directional inputs on the same frame can instantly glitch the character's X/Y coordinate position in the top-down levels. This is useful in bypassing doors or simply reaching other parts of the level faster. Only possible in a real-time run if a controller designed to allow opposite directional inputs is used. Not possible on stock controller. NES Beauty And The Beast - A glitch that I don't understand allows a double hit on the first griffon boss in stage 1-2. It's exhibited in the current publication. I could not reproduce this glitch after a minor movement improvement on the stairs leading to the fight, and the double hit saved more time than the movement improvement. I'm assuming that this glitch relies on both perfect timing and position. NES Bible Adventures - A minor glitch when throwing objects during a couple frame window of a jump results in a few pixels of additional jump height allowing the character to land on platforms that would normally be to high to reach with a normal jump. Used to improve route planning. Theoretically possible in a real-time run. Rotating the objects on Noah's head can sometimes prevent dropping heavy objects that would normally fall during jumps. Theoretically usable in real-time runs. Frame-perfect use of the slingshot during David & Goliath prevents taking damage from falling boulders. Theoretically usable in real-time runs. NES Circus Caper - Discovered a glitch where a one-frame window exists in which the jump button can be pressed at the end of the damage animation to allow for jumping in air. Speeds up the final boss fight. Could be used in real time with frame-perfect inputs. NES Track & Field II - Purely visual glitch: During the Hurdle (Steeplechase) event, running fast enough can sometimes cause the CPU players to simply run straight through the hurdles without jumping or falling.

Posted: 12/18/2017 5:02 PM

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2300)

Joined: 8/21/2016
Posts: 1133
Location: US

c-square wrote:

So, we know SQ 1 and 2 are not bound by frame rate. Is SQ3? If so, then it sounds like it could be done at a CPU frequency divider of 1. I just checked and the boot up is now insanely fast! It shouldn't have an impact of gameplay though (if it did, it wouldn't be allowed).

I did a quick comparison using real-time needed from the door of the escape pod shutting to the interior light turning off using CPU dividers of 50 (default) and 256. The light turned off faster with the CPU divider set at 50, so it does appear that SQ3 is also not bound by frame rate. EDIT: At least for animations. :END EDIT I think keeping the default settings will be best for this game.

Posted: 12/14/2017 4:38 PM

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2300)

Joined: 8/21/2016
Posts: 1133
Location: US

Radiant wrote:

...you might want to try crossposting or getting the topic moved to this one.

As crossposting can be looked down upon, how do I go about having the topic moved?

Posted: 12/14/2017 2:24 AM

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2300)

Joined: 8/21/2016
Posts: 1133
Location: US

There hasn't been much response on the CPU speed topic. I think the best course of action is to go ahead and run this game at default speed (which is comparable to real-world systems at the date of release for SQ3). If conversation does still happen that yields a rule generalization/decision different from my proposed rules in the other topic, I will either restart this run at the higher speed option or consider re-running to obsolete an already submitted/published SQ3 run.

Posted: 12/12/2017 11:28 PM

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2300)

Joined: 8/21/2016
Posts: 1133
Location: US

Would the secret moves be considered cheats?

Posted: 12/12/2017 10:06 PM

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2300)

Joined: 8/21/2016
Posts: 1133
Location: US

Well done. I was anticipating running this game at some point, but after watching this, I'm kinda glad you beat me to it. The run is borderline Meh/Yes for me. It's not as exciting as I had imagined, but still somewhat entertaining.

Posted: 12/12/2017 9:53 PM

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2300)

Joined: 8/21/2016
Posts: 1133
Location: US

Radiant wrote:

...almost all PC games from the nineties link the game speed either to real-world time or to the monitor refresh rate. This was basically required because in the early nineties, CPU speed varied a lot between PCs. As a result, these games will not go faster if the CPU is set arbitrarily high. However they will go slower if the CPU is set very low (e.g. at 20 MHz), because of lag... So arguably it makes sense to have a 20 MHz cap for games that run arbitrarily fast without a cap, and probably all those games are old enough that they run fine on a 20 MHz CPU. Conversely, games that cap themselves (e.g. by monitor rate) arguably do not need a 20 MHz cap, and many of these games simply cannot run on a 20 MHz CPU anyway.

Would it then be a valid option to max out the CPU speed in JPC-rr to 1 GHz for games that tie to real-world time or screen refresh rate? If so, would the following generalized rules be acceptable: 1)Games with speeds restricted to real-world time or screen refresh rate can be run at maximum CPU speed in JPC-rr (setting the CPU frequency divider to 1) as it should theoretically only impact the startup time (and possibly load-screen times), not game-play itself. 2)Games with speeds only limited by CPU frequency are limited to the default JPC-rr (20 Hz) unless it can be proven by the runner that the game was released for faster systems. The CPU frequency setting can then be modified to mimic an appropriate era real-world system. If these rules or any derivation thereof is generally accepted, should we add them to the 'Console Specific ' section of the movie rules page on the main site?

Posted: 12/12/2017 6:23 PM

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2300)

Joined: 8/21/2016
Posts: 1133
Location: US

Fog wrote:

According to this submission, JPC-RR shouldn't exceed the default speed of 50. In this case it was referencing specifically to CD-Man, but I think it should be the general guideline as well.

I understand that perspective, but what about games that were released after processor speeds in excess of 20MHz were available. Leaving a default setting of 50 would essentially be playing one of those games on a system slower than what it was intended to be run. Basically any game released after 1989 could have been run on a real system of 33MHz or faster. The default setting of 50 is the divider value (1GHz/X=CPU speed). So the default setting yields a 20MHz system.

Posted: 12/12/2017 6:18 PM
(Edited: 12/12/2017 10:00 PM)

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2300)

Joined: 8/21/2016
Posts: 1133
Location: US

Here's another option, though it's not my preference... Accept any CPU speed settings with which the game can actually be completed. (Some games would simply move too fast to be completed at high speed settings.) EDIT: My preference has changed slightly, see later post on proposed rules.

Posted: 12/12/2017 6:14 PM

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2300)

Joined: 8/21/2016
Posts: 1133
Location: US

I started a thread to get some judges' perspectives on this CPU speed situation.

Posted: 12/12/2017 6:13 PM

Post subject: JPC-rr CPU speed settings - I need some judges perspectives.

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2300)

Joined: 8/21/2016
Posts: 1133
Location: US

JPC-rr contains an option to alter the emulated CPU frequency. According to this, the range of clock values runs from approximately 3.9MHz to 1.0 GHz depending on the value used for 'CPU freq. divider' in the assembly settings. The default value is 50 which yields an emulated CPU speed of 20MHz. This setting allows for games to be played on much faster (or theoretically slower) systems than what they were designed. I therefore have two questions: 1)Should this value be altered to yield an emulated environment comparable with actual systems from when the game was released? 2)Should a game run at higher CPU clock obsolete a game run at a lower clock rate simply due to the improvement from better processor speeds? --------------------------------------------------------------------------------------------- For what it's worth, my opinion is that settings should be altered to match real-world systems of the time. This site is a resource that could be used to aid in determining appropriate clock speeds. Discussion in this thread prompted these questions to the judges.

Posts for DrD2k9