This topic is for the purpose of discussing #8484: DrD2k9's DOS King's Quest: Quest for the Crown in 00:14.29

Awesome work. Lol'd at the yolo climb out of the beanstalk.

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.

Room	Picture	Priority
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

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.

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

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.

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.

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:

• #8079: davidtki's DOS Hero's Quest "maximum score" in 10:38.73
• #8033: SioN's DOS Duke Nukem: Episode 1 - Shrapnel City in 06:58.92
• #5893: c-square's DOS Mario Teaches Typing "maximum score" in 25:57.78

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.

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

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