Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1017
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).
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1017
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.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1017
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).
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1017
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.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1017
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.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1017
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.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1017
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.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1017
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?
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1017
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.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1017
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.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1017
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.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1017
Location: US
c-square wrote:
I think a good general rule is, stick with the default speed unless there are exceptional circumstances. Doing otherwise opens the runner up to extra scrutiny over the chosen speed, and potential rejection.
Sounds good to me; with one follow up question....
In the CD-Man run, I had to defend using the default speed, showing that it matched CPU speeds of the computers at the time of the game's release.
If the default JPC-rr clock rate is slower than that rate of common processors at the time of a specific game's release, would we be justified to increase the speed setting?
(Note the default JPC-rr setting results in a roughly 20MHz emulated system. which is accurate for SQ3, so it's not an issue with this particular game.)
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1017
Location: US
And what about games run on other emulators...should a run done with default settings of JPC-rr obsolete a run that used another emulator simply because the older run ran at a lower CPU frequency?
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1017
Location: US
c-square wrote:
Speeding up preset cpu speed my be venturing into dangerous territory, as it opens the run up to arguments that the added cpu speed unfairly influenced the run time. We’d need to be able to prove that wasn’t the case.
On the other hand, slowing down the cpu speed might add some intrigue and interest to the run as it’s counterintuitive that a slower cpu would produce a faster run. :)
I agree that it's potentially dangerous territory...but it is a setting in the assembly emulator screen just like initial RTC time.
We're theoretically already presented with the possibility that someone could argue against our current run claiming that the default setting is too fast for the game. Again, who decides, and where does the line get drawn?
Further, we changed the initial RTC time in the same assembly settings for our SQ1 run....If we're allowed to change some settings here, why not others? The emulator coders allowed it.
Should games be limited to to the max speed commonly available at the time of game release? If so, our current publications were probably produced at inaccurate CPU speeds.
If we're not allowed to mess with default CPU speeds, why were we allowed to mess with initial RTC time?
It also makes me wonder how many of the current DOS runs could be obsoleted simply by redoing the exact current paths with higher CPU speeds. Which then further begs the question, were all the currently published DOS games run at the same CPU speeds.
So many questions, that I don't even know who would be best to ask for guidance.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1017
Location: US
So....I was curious....
I tweaked the CPU speed settings in JPC-rr to run at 1GHz with 1GB memory. I then assembled with SQ1 and frame advanced my way through the start of the game. When I push left to move Roger after he leaves the closet, He's by the elevator two screens left with the first frame of movement, completely skipping walking through the Data Archive room.
Oh and this happened at 928ms of time. For comparison, with slowest CPU frequency settings, the emulator is at 6000+ms before reaching "Press F12 for boot menu."
...So I've proven that we can indeed speed up the runs by messing with CPU speed, but at a loss of control at least with the first 2 SQ games.
My question is now, how can dos games be compared for obsoleting old ones if different CPU frequencies are used?
Though I don't think a run at 1GHz speed would be possible, I'm pretty sure I could do a run that moves at lease at twice the CPU frequency speed as the current publication.
What is the limit then? As fast of CPU speed as possible given that the run can actually be accomplished?
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1017
Location: US
c-square wrote:
All this seems moot, though, if JPC-rr doesn't support Turbo-button functionality. Do you guys know if that's the case?
I can't find anything on it, but I did read here that we can set the CPU speed to just about anything between 3.9MHz and 1GHz.
This warrants two questions....
A) Should we run this game at a lower/higher than default JPC-rr settings?
B) If changing it from the default is ok, should we revisit the previous two Space Quest games with different JPC-rr settings?
And furthermore, that site also says we can turn off the input/output delays. Though it may not affect speed of a run, it may make direct editing of a savestate file easier.
Specifically I'm curious if changing this setting may make typed commands faster for the earlier SQ games. EDIT: Never mind...it's off by default.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1017
Location: US
Radiant wrote:
But it is a remote possibility that starting the game in slow mode (of 4.7 MHz) then switching to turbo after this check will set global124 to zero and lead to a faster run.
If we find this indeed sets the global124 to zero, do we know what the results will be? Does it result in slower/faster animations?
If we find that having the global124 set to zero would a beneficial means of shortening the run, would it be possible to start in turbo mode then to the slower setting just for the frame or two that the game checks the speed, then switch back to the turbo mode?
I'm thinking this might be significantly faster than starting up in slow mode.
Again all that only matters if global124 set to 0 yields changes that will speed up the run.
Could we isolate the address for global 124 and try to poke it to zero?
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1017
Location: US
I can confirm that skipping the blue screen with <Enter> is faster than an F9 reset.
EDIT: Nope I lied. I found a faster way to get the F9 input in. (This is not using the glitch at the beginning.)
EDIT #2: ...and if we are able to use the glitched 'reset' beginning, it is the fastest.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1017
Location: US
If it's the fastest way to get to a place of controlling Roger, I'm all for using it.
My fear is that it may invalidate the run and cause a rejection due to improper emulation.
EDIT: For what it's worth, either method of starting up the game, yields mouse control. So the glitched beginning doesn't invalidate the loading of the mouse function.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1017
Location: US
c-square wrote:
DrD2k9 wrote:
I may have already found a glitch...
When starting up JPC-rr using ctmouse command before the game.
If I enter all the dos commands as quickly as possible, I get this as the first thing showing in the game....not the blue sierra screen.
You should get that if you hit F9 to restart the game. It may be faster to restart the game right at the beginning than get the blue Sierra screen, though it should be tested.
Right, but I didn't hit F9. It happened automatically instead of going to the blue screen as a normal start of the game would.
EDIT: Ok a delay of 2 frames between the 'ctmouse /r32 <Enter>' and 'c: <Enter>'
commands results in a normal startup of the game, but there is a longer delay in the DOS screen (while the mouse is loading?) before the game begins.
I'm guessing doing all three commands (to load the mouse and start the game) on the same frame somehow results in the mouse still loading while the game is trying to start loading as well. This then results in the "restart" dialogue box popping up instead of the sierra screen.
Do you think this would be deemed as an emulator problem and negate a run utilizing it (assuming it's a faster way to the beginning of gameplay)?
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1017
Location: US
I may have already found a glitch...
When starting up JPC-rr using ctmouse command before the game.
If I enter all the dos commands as quickly as possible, I get this as the first thing showing in the game....not the blue sierra screen.
If I just set the emulator to run before entering the dos commands, the game starts normally.
I'm wondering if something with the mouse installation process is triggering this. If so, it's probably an emulation error.
If I just set the emulator to run before entering the dos commands, the game starts normally.
I'm wondering if something with the mouse installation process is triggering this. If so, it's probably an emulation error.