Editor, Experienced Forum User, Judge, Published Author, Expert player
(2120)
Joined: 8/21/2016
Posts: 1032
Location: US
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
(2120)
Joined: 8/21/2016
Posts: 1032
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
(2120)
Joined: 8/21/2016
Posts: 1032
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
(2120)
Joined: 8/21/2016
Posts: 1032
Location: US
Sounds good to me; with one follow up question....
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
(2120)
Joined: 8/21/2016
Posts: 1032
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
(2120)
Joined: 8/21/2016
Posts: 1032
Location: US
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
(2120)
Joined: 8/21/2016
Posts: 1032
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
(2120)
Joined: 8/21/2016
Posts: 1032
Location: US
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
(2120)
Joined: 8/21/2016
Posts: 1032
Location: US
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
(2120)
Joined: 8/21/2016
Posts: 1032
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
(2120)
Joined: 8/21/2016
Posts: 1032
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
(2120)
Joined: 8/21/2016
Posts: 1032
Location: US
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
(2120)
Joined: 8/21/2016
Posts: 1032
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.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2120)
Joined: 8/21/2016
Posts: 1032
Location: US
c-square wrote:
I see. You bypassed autoexec.bat so you never installed the mouse driver.
Just run "ctmouse /r32" before starting the game.
Yay, a simple solution...thanks.
EDIT: I'm trying to run the game in JPC-rr, but it won't run for me. It's saying "Couldn't install video driver". Was there some kind of setup you had to do?
I didn't have any video issues. But the first thing that comes to my mind is the resource.cfg file. Try making an image without it and see if that works (so the game uses default.cfg instead). Otherwise open the resource.cfg file and check the driver setting listed therein.
If you don't want to see this in the vault, it may be worth seeing if we can find something that will make it stand out.
My opinion on vault is that the vault tier is just as important for archiving TAS runs as any other tier. It would of course be great to achieve a higher tier through any appropriate means, but I have no problem with my runs ending up in the Vault.
Hopefully we can figure something out a major skip with the potential glitch in the tube.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2120)
Joined: 8/21/2016
Posts: 1032
Location: US
So I did a quick test dump of the first few screens of the game. It's nowhere near as zippy as the QFG runs....I'm not sure why it's seems so much slower.
No "high-speed hero" setting maybe?
https://filebin.net/bzl6l7zc60bej8m3/sq3test.mkv
Anyway, I'm fearful that the final run won't look that much different from a human speedrun.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2120)
Joined: 8/21/2016
Posts: 1032
Location: US
C-square, I can't seem to get the mouse to respond in-game.
I've tried to I drag and click then advance the frame.
I've also tried drag-advance frame-click-advance frame.
The game doesn't seem to recognize it.
Ideas?
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2120)
Joined: 8/21/2016
Posts: 1032
Location: US
FractalFusion wrote:
By the way, SCICompanion isn't able to decompile the scripts, at least on Version 1.018. The disassembly still helps though.
I have version 3.0.1.7 and it still won't decompile, but does disassemble. The vocabulary files are also visible. They're not quite as 1:1 as with AGI Studio's words.tok editor, but SCI recognizes MANY more words than the older AGI systems.
If anyone knows that one of these is specific to the GOG version and unnecessary please let me know so I can create a new image that will be more universally functional.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2120)
Joined: 8/21/2016
Posts: 1032
Location: US
Radiant wrote:
This page outlines an easy AI exploit in the fighting robots minigame.
The robots were what I was most worried about as far as RNG.
After reading the above article, I think I'll try both that method as well as actually fighting him to see which is fastest. Truthfully, with save states, outright fighting him may be fairly simple.