(Link to video)
Submission Text Full Submission Page Publication Page

King's Quest: Quest for the Crown

This game is the first in Sierra's King's Quest series.
See previous submissions #7105: DrD2k9's DOS King's Quest: Quest for the Crown in 00:15.85 and #6096: DrD2k9's DOS King's Quest: Quest for the Crown in 00:18.30 for more info on the game.

1/5 Speed Temp Encode (so a viewer might actually be able to follow what's happening)

General Info

  • Goal: Aims for fastest time
  • Emulator used: c-square's modified JPC-rr 11.2 with TASScript
  • Game Version: 2.0F

Run Info

This is an improvement to the currently published run using a completely new route: using glitches and abuse of the game's coding for an in-game timer.
Differences:
  • Route changes (taking the back entrance to the underground) eliminated the need to pick up a treasure to give to the rat.
  • The clover is no longer obtained for protection against the leprechauns as movement can be used to avoid contact.
  • Sky walking off the beanstalk: There is a small gap in the death trigger on the beanstalk that allows graham to 'climb' off into the clouds to get to the final screen. This saves a brief amount of time by eliminating some maneuvering.

Potential Improvements

  • Even with TAS control, moving at the 'Fast' game speed can prove rather difficult to have Graham end up where you want him to go. There may be better movement patterns or route which I have not found.
  • RNG improvements are absolutely possible in this route. There are multiple RNG events in this run that could theoretically be eliminated by starting with a different RTC time. Unfortunately, changing the initial RTC time will typically cause a desync on this set of inputs within the first few screens of play. Eliminating the following would prevent the corresponding text boxes from showing up and thus eliminate the delay in play at those moments.
    • The Ogre Shows up
    • The Condor Shows up
In the process of eliminating these two, one would have to also make sure that the RNG changes don't cause the dwarf to show up the 2 times crossing its screen.
If I get ambitious, I may redo the run once again to negate all RNG encounters and hopefully save a bit more time. But right now, I have other projects to work on of which I'm more interested.

Files

These are extracted from the GOG release of the game with all the unnecessary GOG files removed. This run uses the same disk image as the current publication; so if anyone created a disk image for that run, it should also work for this submission.
HDD TRACKS 16 - SIDES 16 - SECTORS 63
TimestampMD5SizeFilename
199001010000004771062c7f64bf64c185178613fd665a39424AGI
19900101000000d83459a8643dfc67b4629ec4afe64e138192AGIDATA.OVL
19900101000000e34849e963efdcc942b67ee9bf5c15331024CGA_GRAF.OVL
19900101000000714c88fa15b8327c585b86f3e619b0681024EGA_GRAF.OVL
19900101000000f3d4c66e195491aa759b7c5ef996488b3072HGC_FONT
199001010000008eb68e541e8ea93da96c7fc4cfde7f3f1536HGC_GRAF.OVL
19900101000000a8f5aabf72ed3d4165038275faf8b5271024HGC_OBJS.OVL
19900101000000119949f12a5fc14a082794350c19118b512IBM_OBJS.OVL
199001010000004488067df5a7201e34ee3b01252e9860512JR_GRAF.OVL
19900101000000f579e8fb39209a321d575ebdc5f790143121KQ1.COM
1990010100000010ad66e2ecbd66951534a50aedcd0128315LOGDIR
199001010000006eca02fa540337308529ff13e9e764aa331OBJECT
19900101000000d468936618bed024ea453a315aba1958255PICDIR
19900101000000cf37ab2f6af09afee3598b92c9a42983144SNDDIR
19900101000000df5f5263d61e250495c249002c6210a1512VG_GRAF.OVL
19900101000000ac7048eceb628c07f452ecd1662d7b3d432VIEWDIR
199001010000008ec91effac02ba476f823f065ca1017248472VOL.0
1990010100000077c3be070fc9bf9c69952ed56821efe1200630VOL.1
19900101000000b33d0a9938c095da1a69b5ee3c9209d490891VOL.2
1990010100000050e00d15fa3e25b512c19608119111cf3144WORDS.TOK
ThunderAxe31: Claiming for judging.
DrD2k9: The BIOS image I used doesn't seem to be readily available, so I updated the movie file with a version that uses the BIOS mentioned in this post. Nothing changes in the timing of inputs or the run, so the encode is the same.
ThunderAxe31: Thank you to eien86 for his review. Accepting as improvement of the current publication.
fsvgm777: Processing. Holding off until an issue with the JRSR parser is fixed.
fsvgm777: Changed the framerate, so that the run time is correct now. Note that the issue in the JRSR parser hasn't been fixed yet, as the framerate had to be manually added.
And with that, processing for real.

Show more

Hide
Posted: 8/1/2023 7:33 PM
Quote
TASVideoAgent
They/Them
Moderator
Joined: 8/3/2004
Posts: 14882
Location: 127.0.0.1
This topic is for the purpose of discussing #8484: DrD2k9's DOS King's Quest: Quest for the Crown in 00:14.29
Posted: 8/1/2023 8:44 PM
Quote
eien86
He/Him
Judge, Skilled player (1699)
Joined: 3/21/2021
Posts: 174
Location: Switzerland
NES TASer of 2023 PC TASer of 2023 NES TAS of 2023 PC TASer of 2021
Awesome work. Lol'd at the yolo climb out of the beanstalk.
Posted: 8/6/2023 6:14 AM
Post subject: Priority screen for beanstalk clip
Quote
Sand
He/Him
Player (125)
Joined: 6/26/2018
Posts: 154
Here's a look at the priority screens to see what makes the beanstalk clip work. In room 71 there's just a big gap in the control lines (green lines) that define the edges of the beanstalk.
RoomPicturePriority
72
71
70
I made the images using agi-upscale, modified with a patch from my Mixed-Up Mother Goose repository to save the picture data rather than render it, and the renderer derived from ScummVM that is also in my repository. 
git clone https://www.bamsoftware.com/git/mumg.git
git clone https://github.com/eviltrout/agi-upscale
cd agi-upscale
git apply ../mumg/agi-upscale-write-agipic.patch
mkdir -p agipic xpm png
ruby pic.rb ~/KQ1 all agipic
make -C ../mumg/scummvm-pic
for fn in agipic/*.agipic; do N="$(basename "$fn" .agipic)"; ../mumg/scummvm-pic/scummvm-pic "$fn" "xpm/$N.pic.xpm" "xpm/$N.pri.xpm"; done
for fn in xpm/*.xpm; do convert "$fn" "png/$(basename "$fn" .xpm).png"; done
Posted: 8/6/2023 7:40 AM
Quote
DrD2k9
He/Him
Editor, Judge, Expert player (2070)
Joined: 8/21/2016
Posts: 1012
Location: US
Arcade TAS of 2023 Exotic platforms TASer of 2020 First edition TAS of 2020 Gameboy TAS of 2020 Exotic platforms TASer of 2019 Computer TASer of 2017
Yea. While the yolo jump off the beanstalk was new to me, it’s apparently been known for a while in the RTA community. I just hadn’t seen it myself until recently. So i implemented it. On another note, there are potentially further improvements to this run coming in the future: 1) the beanstalk can be planted elsewhere to shorten the route. 2) i need to investigate a different route altogether that may be faster. But I’m not sure how soon i can get to implementing these; so I’d like this run judged as-is.
Posted: 8/6/2023 1:41 PM
Post subject: Help finding emu
Quote
eien86
He/Him
Judge, Skilled player (1699)
Joined: 3/21/2021
Posts: 174
Location: Switzerland
NES TASer of 2023 PC TASer of 2023 NES TAS of 2023 PC TASer of 2021
Hi DrD2k9, I've tried to reproduce the movie but ran into a problem. I got the right game and FREEDOS images, but the BIOS, VGABIOS, and version of the emulator I downloaded (JPC-rr 11.2 w/ TASScript 2.01) are incorrect. I cannot seem to find the one you used anywhere. Can you please give me a pointer as to where to find it? Thanks
Posted: 8/8/2023 6:21 PM
(Edited: 8/8/2023 6:37 PM)
Post subject: Review
Quote
eien86
He/Him
Judge, Skilled player (1699)
Joined: 3/21/2021
Posts: 174
Location: Switzerland
NES TASer of 2023 PC TASer of 2023 NES TAS of 2023 PC TASer of 2021
Ok, adding my review: * Sync: Yes. Tested on c-square's modified JPC-rr 11.2 with TASScript Making it sync was a bit of a research task. (EDIT: which would have been much easier, had I read : feos' post, smh) This movie uses a different machine BIOS' than the ones provided in c-square's JPC-rr 11.2 redistributable. You have to download them from the Bochs repository and import them into JPC manually: https://github.com/ipxe/bochs/blob/master/bios/BIOS-bochs-latest You need to modify the movie file with this line, if you want it to reproduce with this BIOS: BIOS 740f01be58103af0996220bdeb7c4d12 -> BIOS 21fa468b969329b6ac3571ead5b181e3 Similarly, a different VGA bios is used (Elpin) to properly display the game's text and prevent a desync. https://github.com/ipxe/bochs/blob/master/bios/VGABIOS-elpin-2.40 As for the DOS disk, the standard FreeDOS image that comes with JPC-RR works just fine. For the game image, I used GoG's source removing the unnecessary files, according to the submission notes. * Previous Work: DrD2k9's own previous movie (Movie #4447M) played on a similar setting. This movie improves it by almost 2 seconds. * General Optimization: I really recommend OneShortEye's documentary on this game's WR history and read previous submission notes to know the level of trickery that goes into beating this game fast. The TAS, of course, takes this to an extreme. The level of optimization is clearly visible and there's nothing I can add to it. I'm mindblown by the new tricks, especially the beanstalk yolo skip. * Entertainment: Watching this movie at different speeds (see provided encodes) provide totally different experiences. However, as with any TAS, it takes some knowledge to truly appreciate the level of trickery. I would love to watch a TAS-specific documentary to dissect every step of the movie.
Posted: 8/8/2023 6:35 PM
(Edited: 8/8/2023 7:41 PM)
Quote
DrD2k9
He/Him
Editor, Judge, Expert player (2070)
Joined: 8/21/2016
Posts: 1012
Location: US
Arcade TAS of 2023 Exotic platforms TASer of 2020 First edition TAS of 2020 Gameboy TAS of 2020 Exotic platforms TASer of 2019 Computer TASer of 2017
eien86 wrote:
Ok, adding my review: * Sync: Yes. Tested on c-square's modified JPC-rr 11.2 with TASScript Making it sync was a bit of a research task. This movie uses a different machine BIOS' than the ones provided in c-square's JPC-rr 11.2 redistributable. You have to download them from the Bochs repository and import them into JPC manually: https://github.com/ipxe/bochs/blob/master/bios/BIOS-bochs-latest You need to modify the movie file with this line, if you want it to reproduce with this BIOS: BIOS 740f01be58103af0996220bdeb7c4d12 -> BIOS 21fa468b969329b6ac3571ead5b181e3 Similarly, a different VGA bios is used (Elpin) to properly display the game's text and prevent a desync. https://github.com/ipxe/bochs/blob/master/bios/VGABIOS-elpin-2.40 As for the DOS disk, the standard FreeDOS image that comes with JPC-RR works just fine. For the game image, I used GoG's source removing the unnecessary files, according to the submission notes. * Previous Work: DrD2k9's own previous movie (Movie #4447M) played on a similar setting. This movie improves it by almost 2 seconds. * General Optimization: I really recommend OneShortEye's documentary on this game's WR history and read previous submission notes to know the level of trickery that goes into beating this game fast. The TAS, of course, takes this to an extreme. The level of optimization is clearly visible and there's nothing I can add to it. I'm mindblown by the new tricks, especially the beanstalk yolo skip. * Entertainment: Watching this movie at different speeds (see provided encodes) provide totally different experiences. However, as with any TAS, it takes some knowledge to truly appreciate the level of trickery. I would love to watch a TAS-specific documentary to dissect every step of the movie.
I'm going to make sure my future DOS TASes don't use the BIOS that I originally used in this run. (If I can before judging happens, I'll re-sync on a more available BIOS and update the submission.) Done. FWIW, The linked World Record progression video is significantly outdated. The current RTA record for KQ1 is 42.20 seconds and was set within the past couple days. Also FWIW, the different route that I need to investigate which I mentioned in an earlier post may eliminate the YOLO jump from the beanstalk if it ends up being faster.
Posted: 8/10/2023 7:19 PM
Quote
fsvgm777
She/Her
Senior Publisher, Player (221)
Joined: 5/28/2009
Posts: 1185
Location: Luxembourg
So I've noticed a weird discrepancy between the time reported by JPC-RR and the time given by the site. The site claims it's 14.05 seconds long, but JPC-RR claims it's 14.294 seconds long. Not sure what's up with that.
Steam Community page - Cohost profile Oh, I'm just a concerned observer.
Posted: 8/10/2023 9:55 PM
(Edited: 8/11/2023 3:25 AM)
Post subject: Frame rate
Quote
Sand
He/Him
Player (125)
Joined: 6/26/2018
Posts: 154
fsvgm777 wrote:
So I've noticed a weird discrepancy between the time reported by JPC-RR and the time given by the site. The site claims it's 14.05 seconds long, but JPC-RR claims it's 14.294 seconds long.
It should be 14.294 s. That's what you get if you add up all the relative event timestamps to the final KEYEDGE 28, 14294723718 ns. My best guess is that the 14.05 s comes from frame count and frame rate on the submission page:
Frame Count 857 Frame Rate 61
857 / 61 = 14.049. Compare that to the previous submission:
Frame Count 951 Frame Rate 60.018933417481854
I wrote the current JRSR parser, but the frame rate formulas are just copied from what was there before: 
Language: csharp
// int Frames;
// double FrameRateOverride;
// long lastNonSpecialTimestamp = 0L;
result.Frames = (int)(lastNonSpecialTimestamp / 16666667);
result.FrameRateOverride = result.Frames / (lastNonSpecialTimestamp / 1000000000L);
Substituting 14294723718 for lastNonSpecialTimestamp yields Frames = 857 and FrameRateOverride = 61.0, as on the submission page. I don't fully understand how FrameRateOverride is meant to be used, but the formula looks wrong. It looks like the intention is that Frames / FrameRateOverride should be equal to lastNonSpecialTimestamp / 1000000000, under the constraint that Frames has to be an integer. But as it is, it's impossible for FrameRateOverride to have a non-zero fractional part. It should at least be casting lastNonSpecialTimestamp to double before doing the division. Intermediate integer truncation is what's leading to the mismatched results. It must have worked differently in the past. Looking at other recent JPC-RR publications, they all have an integer Frame Rate as well: In fact, the most recent JPC-RR publication that has a non-integer Frame Rate is the previous King's Quest publication from 2021-05-08, which predates the new site.
Posted: 8/11/2023 3:42 AM
Post subject: Re: Frame rate
Quote
Sand
He/Him
Player (125)
Joined: 6/26/2018
Posts: 154
Sand wrote:
I don't fully understand how FrameRateOverride is meant to be used, but the formula looks wrong. It looks like the intention is that Frames / FrameRateOverride should be equal to lastNonSpecialTimestamp / 1000000000, under the constraint that Frames has to be an integer. But as it is, it's impossible for FrameRateOverride to have a non-zero fractional part. It should at least be casting lastNonSpecialTimestamp to double before doing the division. Intermediate integer truncation is what's leading to the mismatched results.
I opened an issue for this. #1638 Fix calculation of frame rate in JRSR parser
Posted: 8/19/2023 7:43 PM
Post subject: Movie published
Quote
TASVideoAgent
They/Them
Moderator
Joined: 8/3/2004
Posts: 14882
Location: 127.0.0.1
This movie has been published. The posts before this message apply to the submission, and posts after this message apply to the published movie. ---- [5505] DOS King's Quest: Quest for the Crown by DrD2k9 in 00:14.29