Posts for DrD2k9


DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2036)
Joined: 8/21/2016
Posts: 1009
Location: US
Would the secret moves be considered cheats?
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2036)
Joined: 8/21/2016
Posts: 1009
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.
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2036)
Joined: 8/21/2016
Posts: 1009
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?
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2036)
Joined: 8/21/2016
Posts: 1009
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.
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2036)
Joined: 8/21/2016
Posts: 1009
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.
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2036)
Joined: 8/21/2016
Posts: 1009
Location: US
I started a thread to get some judges' perspectives on this CPU speed situation.
Post subject: JPC-rr CPU speed settings - I need some judges perspectives.
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2036)
Joined: 8/21/2016
Posts: 1009
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.
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2036)
Joined: 8/21/2016
Posts: 1009
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.)
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2036)
Joined: 8/21/2016
Posts: 1009
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?
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2036)
Joined: 8/21/2016
Posts: 1009
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.
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2036)
Joined: 8/21/2016
Posts: 1009
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?
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2036)
Joined: 8/21/2016
Posts: 1009
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.
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2036)
Joined: 8/21/2016
Posts: 1009
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?
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2036)
Joined: 8/21/2016
Posts: 1009
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.
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2036)
Joined: 8/21/2016
Posts: 1009
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.
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2036)
Joined: 8/21/2016
Posts: 1009
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)?
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2036)
Joined: 8/21/2016
Posts: 1009
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.
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2036)
Joined: 8/21/2016
Posts: 1009
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.
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2036)
Joined: 8/21/2016
Posts: 1009
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.
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2036)
Joined: 8/21/2016
Posts: 1009
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?
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2036)
Joined: 8/21/2016
Posts: 1009
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.
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2036)
Joined: 8/21/2016
Posts: 1009
Location: US
I'm going to be using the GOG version of the game. Here's my preliminary file list from the image:
!BEGIN diskinfo-cb9ebc776794cbde4c2224acd9cd106a
+TYPE HDD
+ID cb9ebc776794cbde4c2224acd9cd106a
+TRACKS 16
+SIDES 16
+SECTORS 63
+TOTALSECTORS 16128
+IMAGEMD5 e7a05003b4df20232e2ec82b239bd267
+COMMENT(Entry: N/A            N/A                                      18 /)
+COMMENT(Entry: 19900101000000 e022fac068d78e62b21a1cc938a2f450       9778 /ADL.DRV)
+COMMENT(Entry: 19900101000000 53f823d23484325ea25d8d1ba01f3505       5825 /CMS.DRV)
+COMMENT(Entry: 19900101000000 ed4fb7b3973f4ec008701bbbe227b683        219 /DEFAULT.CFG)
+COMMENT(Entry: 19900101000000 d2f9e9ea730745558926518c930e7375       1952 /EGA320.DRV)
+COMMENT(Entry: 19900101000000 ab91b093a010aeb63866f71bc491110e        446 /IBMKBD.DRV)
+COMMENT(Entry: 19900101000000 c1a273f3ac6f9e39ae14b1399f0b26a7        541 /JOYSTICK.DRV)
+COMMENT(Entry: 19900101000000 7ced0fc0a7cc5395a1e4321250fcd943       1626 /MCGA320.DRV)
+COMMENT(Entry: 19900101000000 c465a944ca233b5fe97d5e19dea097c8       3179 /MT32.DRV)
+COMMENT(Entry: 19900101000000 60118bdc3e57076dc2d3d909730ff4af     490247 /RESOURCE.001)
+COMMENT(Entry: 19900101000000 c1526bd99391b674f0d68347f78b0fd2     715777 /RESOURCE.002)
+COMMENT(Entry: 19900101000000 69d74c5056144e09c6fdac85cc357cb3     703370 /RESOURCE.003)
+COMMENT(Entry: 19900101000000 634128488166ddb6e799b86bc5cfab00        215 /RESOURCE.CFG)
+COMMENT(Entry: 19900101000000 6509ea8a27cca3503aa2e18672c5d604       5730 /RESOURCE.MAP)
+COMMENT(Entry: 19900101000000 21f53b56b4bea50a28acbeeb0de37ade      76609 /SCIV.EXE)
+COMMENT(Entry: 19900101000000 48e6faeb6af8e540fed0523f17ec4c0d        538 /SIERRA.COM)
+COMMENT(Entry: 19900101000000 e022fac068d78e62b21a1cc938a2f450       9778 /SNDBLAST.DRV)
+COMMENT(Entry: 19900101000000 53f67f80f57577c0ef2e8bf897f45b4c       2466 /STD.DRV)
+COMMENT(Entry: 19900101000000 4f1243083efe33a01144eacc94fc84c6          7 /VERSION)
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.
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2036)
Joined: 8/21/2016
Posts: 1009
Location: US
As far as skips....I was wondering about skipping Monolith Burger, but it seems that may not be an option.
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2036)
Joined: 8/21/2016
Posts: 1009
Location: US
This should help in minimizing keyboard inputs.
Post subject: Re: Space Quest 3
DrD2k9
He/Him
Editor, Experienced Forum User, Expert player, Judge, Published Author (2036)
Joined: 8/21/2016
Posts: 1009
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.