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.
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.
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)?
I don't think so, as it's very possible that would happen in a real system if you entered commands in that fast. In the end, you can achieve the exact same result by hitting F9, so it gives no advantage, and you may want to restart anyway to avoid the Sierra screen, so I see no issue with it.
On a separate note, there's an interesting bit of code on startup:
I'm not sure what "u<" does, but I'm guessing this is checking the speed of your computer. Later in the code it disables some animations and changes the terminator introduction slightly if global124 is set to zero. I can't see any gain in trying to manipulate the value, but maybe you guys might?
Finally, congrats on the acceptance of the SQ1 run! We've now got three SQ runs accepted, with a fourth in the works!
Unsigned comparison, so instead of the regular scale of -32768 to 32767 it considers all integers to be on the scale of 0 to 65535.
The apparent point of this code is to remove certain slow operations, like big animations, on slower systems. Of course lowering the CPU speed will make the run longer, but there is one trick that may make it worth manipulating, and that is the turbo button.
In the mid '80s, many PCs had a button on the box that switched between full clock rate and a lower clock rate (generally either half the full rate, or 4.7 MHz). The intent of this was compatibility with older games, since some games have an uncoupled framerate (meaning they'll simply run as fast as the system allows, or way too fast on newer systems). Of course, many other games couple their framerate either to the system clock or the monitor vsync rate, so this doesn't always apply; turbo buttons were phased out in the late '80s when most or all games had figured out system-independent timing. Dosbox supports this feature, I'm not sure if JPC-RR does.
Sierra games actually have a coupled framerate, which is 12 FPS in AGI games. I think it's the same for SCI although I haven't found specifics on that. This means that the only thing a slow processor can do is cause lag frames. I find this unlikely because Sierra games newer were very graphically intensive in the first place. 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.
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?
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?
An easy way to poke it mid-game is to use the SCI debugger. Open it by pressing both shift keys and the minus key over by the num pad on the same frame. Once the debugger opens, type 'g' and a popup will appear. Type 124 into the popup, hit enter, then type the value you want to set for the variable. Finally, press both shift keys and the letter 'd' to drop out of debug mode.
Once you've set the value to what you want to test, type "pump shark<enter>" to enter SQ3 debug mode, followed by "tp<enter>" to choose a room and enter "40<enter>" to go to the appearance of the terminator. You can then see which version is faster. Make sure the game animation is on the same value for both tests (hitting the minus key earlier may have slowed it down one).
All this seems moot, though, if JPC-rr doesn't support Turbo-button functionality. Do you guys know if that's the case?
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.
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.
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. :)
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?
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.
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?
There is a bit of a precedent when it comes to using faster CPU speeds on a game that is heavily influenced by CPU speed. I didn't immediately find any other examples though, and there's no mention of it in the rules. So a judge probably should weigh in.
I'm not sure where I remember hearing this, but if I remember correctly, fastest mode in AGI games lets many things run as fast as the CPU is able to run it. A quick Google search seems to corroborate this, but I didn't immediately find a definitive source.
<ccfreak2k> There is no 'ctrl' button on DeHackEd's computer. DeHackEd is always in control.
We have strong precedent that switching from an English ROM to a Japanese one for the sole purpose of text speed does not count towards obsoletion. That is, if the J-ROM is five seconds faster but this is because showing the text takes six seconds less, then the overall run is counted as one second slower than the current run.
It stands to reason, then, that switching to a faster (virtual) machine for the sole purpose of speed should likewise be discounted for the purpose of obsoletion. Clearly redoing the exact same run with a faster CPU should not count as an improvement.
Agreed with everything said here. CPU speed can be changed, but there needs to be a valid reason why its changed, and then every run after must run at the same CPU speed as the original. 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.
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.
As for the question about other emulators, to my knowledge, JPC-rr is the only approved DOS emulator for TASvideos, so at the moment it's not an issue.
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.)
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.
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.
I agree, the game goes fast enough at default speed (not as fast as the others), and it removes one point of contention that may arise otherwise.
I haven't had much time to dig into the code recently, and may not get a chance in the next few days either. If there's something in particular that would be worth looking at at this stage, I can check it out, though.
There hasn't been much response on the CPU speed topic.
That's possibly because nobody much ever reads or posts in the "computer emulators" subforum; you might want to try crossposting or getting the topic moved to this one.
That said, I agree that for SQ3 in particular, keeping the 20 MHz speed setting is a good choice.
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).
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.
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).
