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.
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.
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.
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.
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.
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.
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:
857 / 61 = 14.049.
Compare that to the previous submission:
I wrote the current JRSR parser, but the frame rate formulas are just copied from what was there before:
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: