Community
General and Everything Else => The Games and other Sierra Adventure stuff => Topic started by: NewRisingSun on October 22, 2016, 09:17:12 PM
-
I have finished my small extractor and decompiler for the "Game Adaptation Language" logic resources used in the early King's Quest releases. I'm sharing my work-in-progress.
GALextract.exe requires a 360K disk image, its name specified as a command-line argument; all known versions of the game should be supported. If specifically the gnome/beanstalk messages are corrupt, then your disk image is the badly-cracked version of the game that is floating around the internet.
GALdecompile takes the name of the logic resource as a command-line argument and outputs the decompiled script to the standard output. WORDS.BIN must be in the current directory; this is the equivalent to AGIv2's WORDS.TOK, which in the case of GAL is hard-coded into the main executable file, like so many things.
Being a work-in-progress, it's far from perfect --- some opcode meanings are unknown, some may have their lengths misidentified, and I may have made an incorrect guess at what some of them mean. I'm also a bit stumped by the meaning of "FB FE 00 00" in the test command blocks. I have started filling in preliminary object and variable names; they are only valid for the "PCjr/Tandy 1000 disk" of the Sierra On-Line release; their names will be off for the IBM PCjr release. Still, it's not bad for a first effort, I would say.
-
I have not yet tried to image my IBM KQ1. It is the 2nd IBM release that had just the strip keyboard overlay. I'll have to try it in a few days when I get a day off.
-
Amazing what archive.org has archived for us:
http://web.archive.org/web/20090809121039/http://retrograde.trustno1.org/sierra.htm
The TANDY image seems to work with your tool. Trying the other two now...
-
The extractor is working for me on the KQ1.IMG and the KQ1TANDY.IMG. It seems to silently ignore the KQ1PCJR.IMG.
The decompiler is working on the LOGIC files from both the KQ1.IMG and KQ1TANDY.IMG. The source output is looking really good.
I've been thinking more about the syntax used in the Donald B. Trivette article from 1985. Someone must have given him that code snippet. It isn't something he would have come up with by himself. Although it seems quite straight forward to convert that primitive syntax from the article to the more familiar AGI syntax, my money would be on that more primitive syntax being what they started out with. I guess we'll never know for certain since no one seems to remember it. Clearly there was quite a bit of redesign of the engine when they moved on to KQ2, and another lesser redesign when moving to AGI v2 (where the test and action commands were reshuffled a bit).
-
and another lesser redesign when moving to AGI v2 (where the test and action commands were reshuffled a bit
It would be most interesting to look at the booter version of Donald Duck's Playground. It comes with interpreter version 2.001, supports EGA and text windows, draws background pictures to a shadow buffer rather than the screen, but still has the ANIOBJ structure on the disk that was dropped later. It's basically some kind of in-between between AGI 1 and AGI 2.
There is also an extremely rare actual PC version (1.50) using AGI v2.440, plus the Amiga (game version 1.0C) and Atari (game version 1.0A) versions of the game, which despite the version number come later than the actual booter PC version (1.0Q). (The version on Al Lowe's website is the Amiga version with a rather unsuitable PC interpreter executable added.)
Will look at KQ1PCJR.IMG later.
-
I haven't had a chance to look at them yet myself, but was wondering what those two versions of Donald Duck's Playground stored in the archive.org link above are?
-
KQ1PCJR.IMG from Retrograde Station does not work with GALextract because Demonlord removed the game's copy protection in such a way that the location of some things is not where it was on the original disk. While I hesitate to accomodate a "cracked" game in such a manner, I suppose since most people will be using that image, I better add support for it to GALextract.
what those two versions of Donald Duck's Playground stored in the archive.org link above are?
The Retrograde Station downloads of the game are the original self-booting PC version 1.0Q with AGI version 2.001. One is a disk image, the other is a "DOS conversion" (basically the self-booting disk image modified to run under DOS by way of a little launcher program). The disk image has been "cracked" again in a rather clumsy fashion that prevents it from working on a Tandy 1000, where the original copy-protected disk has no such problems.
-
I have not yet tried to image my IBM KQ1. It is the 2nd IBM release that had just the strip keyboard overlay. I'll have to try it in a few days when I get a day off.
There appears to be a copy of the IBM PCjr KQ1 game for sale on ebay at the moment.
Collector, would that be what you already have?
http://m.ebay.co.uk/itm/Original-Complete-Kings-Quest-1984-IBM-Computer-Game-Personal-Computer-Software-/201687504490?nav=SEARCH
-
Quick update: added support for the Retrograde station KQ1PCJR.IMG disk image. I have added another program:
GALsnd2vgm converts the sound resources to the .VGM format, which can be played back by many sound players with the right plugin (https://vgmrips.net/wiki/VGM_Players). I have made sure that all tracks that should loop do loop properly. The syntax is GALsnd2vgm infile outfile ["English track title"] ["Japanese track title"]. The track titles are optional. If at least an English track title was given and a GD3.INF file is found in the present directory, then the generated .VGM files will each have a GD3 tag as well. GALsnd2vgm_all.cmd does this already.
Doing this both to the Radio Shack and IBM releases indicates that the IBM release has a few sounds different, notably the witch sound. There are also several unused sound resources.
-
As far as I know the box and manual of the two IBM releases are identical. It is the overlay that is the best way to tell. That listing seems to be missing the overlay.
1st release:
(http://wiki.sierrahelp.com/images/9/91/KQ1IBMv1-Overlay.png)
2nd release:
(http://wiki.sierrahelp.com/images/2/21/KQ1IBMv2-Overlay.png)
-
Thanks for the tools NewRisingSun!
One question though:
(https://cdn.meme.am/instances/500x/72619715.jpg)
:D
-
"Github is like facebook for programmers" (http://kbroman.org/github_tutorial/pages/why.html). That's where they lost me.
-
"Github is like facebook for programmers" (http://kbroman.org/github_tutorial/pages/why.html). That's where they lost me.
But it isn't an official position statement.
-
I don't see how it compares to facebook at all really. To me it is more like the old Google code and sourceforge sites. It's just a place to create a repo that you can use and it gives others access to that code. I have an aversion to facebook (that incidentally I don't have to twitter or some of the others), so if I'd seen that statement before joining, I would probably have been hesitant as well. It's probably closer to LinkedIn I guess, as its more a reflection of your technical ability. Recruiters do sometimes look at people's github accounts, but if you use an unrecognisable account name, no one will know who it is.
The only drawback for some people might be that the free version of github doesn't let you create private repos. Whatever you put in to github, you have to be aware that the whole world can see it. In reality though, the whole world isn't going to be looking at it. The only people that would bother to look at my code on there are probably the ones that I wouldn't mind having a look at it.
Bitbucket lets you create private repos though. That's another alternative. Only 5 users in the free account but I guess it has to be quite a successful project to require more than 5 committers.
-
Bitbucket is what I have been using. I fail to see how any parallels can be drawn between social media and Bitbucket. It is just a repository that allows multiple developers to work on the same project. It allows you to track and approve commits as well as forks. It has an integrated bug tracker and Wiki. If it is public it allows others read only access to the code. I have a GitHub account but have not used it. However I assume that it is not that much different.
-
GALdecompile:
- Corrected the control flow regarding "else" statements.
- Action command definitions as well as variable and object names are now taken from a GAMEDEFS text file which %includes SYSDEFS. That will allow any user to adjust the output for different game versions, and contribute the meaning of the unknown action commands without having to recompile GALdecompile. GAMEDEFS.CGA-1984-08 is the definition file for the August 1984 PC CGA version, which must be renamed to GAMEDEFS to be used by GALdecompile.
GALextract:
- Now adds the proper two-byte header to GAL sound files. GALsnd2vgm modified to account for that.
- Now extracts the WORDS.BIN file from the disk image.
-
It is interesting to see just how similar the decompiled script from the original KQ1 version is to what was in Donald B. Trivette's February 1985 article.
This is from the article:
IF HAS-GOAT 0 AND OBJHIT-EDGE 14 AND EDGEOBJ-HIT 1 AND GOAT-GONE 0 AND SHOWCARROT 0 THEN ASSIGN GOAT-ROOM 11, ERASE 14.
This is from the decompilation of the original KQ1 versions:
PC JR:
if (v41==0 && objectHitEdge==14 && edgeObjectHit==2 && v121==0 && v50==0) {
assign(v51,11);
sound(0);
erase(o14);
}
IBM PC and TANDY:
if (v41==0 && objectHitEdge==14 && edgeObjectHit==2 && v122==0 && v52==0) {
assign(v53,11);
sound(0);
erase(o14);
}
So if we take the PC JR example:
v41 = HAS-GOAT
v121 = GOAT-GONE
v50 = SHOWCARROT
v51 = GOAT-ROOM
The edgeObjectHit value is different, and there is an extra sound command in there, but the rest seems to line up quite well. The AGIv2 version of KQ1 is quite different with regards to this particular piece of logic.
-
I've just used the GALtools decompiler with a RM.1 logic extracted from the Apple II version of KQ1 and I can confirm that it decompiled it without issue. There were a few differences in the logic of the script, and the word numbers have been rearranged a bit, but in general it was the same script, and the format was the same as supported by the GAL decompiler.
I find this interesting because Jeff Stephenson was the one that ported KQ1 to the Apple II. The data in the main part I would guess is very similar to the PCJR version of the KQ1 game, so Jeff would have simply been porting the interpreter to the Apple II. What I find interesting is that I'm currently imagining that Jeff was the one that brought about the rather dramatic changes to the interpreter that were introduced with King's Quest 2. NewRisingSun is quite right in that the original KQ1 interpreter is quite different from all other versions of the AGI interpreter that followed. I think we've already established that the interpreter was known as GAL or Game Adaptation Language prior to the release of King's Quest 2, so it seems reasonable that we call the KQ1 interpreter GAL, not only because we know it was called that, but also because of how different it is from the other AGI games. King's Quest 2 and all AGI games that followed were quite comparable to each other (ignoring the fact that in AGIv1 games, vars and flags were the same thing). - Jeff claims that he wasn't involved in writing the original interpreter used with KQ1, so in my mind I'm imagining Jeff porting it to the Apple II and thinking of all these ways in which he could improve the interpreter, and perhaps that was what we saw with KQ2, i.e. the incorporation of his improvements.
-
I was revisiting this topic again this evening and I discovered a very interesting thing. Someone added names of people to the end of the WORDS list. It contains the names of six people encoded within the WORDS data, with the first and last names encoded separately. Since Ken and Doug MacNeill share the same surname, then that one appears only once, making a total of eleven words allocated the final 11 word numbers, from hex value 0xC2 to 0xCC:
0xC2: greg
0xC3: rowland
0xC4: ken
0xC5: macneill
0xC6: doug
0xC7: hal
0xC8: schwab
0xC9: arthur
0xCA: abraham
0xCB: charles
0xCC: tingley
i.e. Greg Rowland, Ken MacNeill, Doug MacNeill, Hal Schwab, Arthur Abraham and Charles Tingley.
The best guess then is that Greg Rowland did this, as it doesn't follow any logical order otherwise. My guess is that the person that added these names to the game's words file added their own name first, then the others in the order that they thought of them.
Now, the mystery is, why would someone do this?
I wonder if perhaps the person had been instructed to only include certain names within the official credits screen in the game. Perhaps they felt that it didn't seem right to exclude Arthur Abraham and Hal Schwab, and so they added a kind of hidden "easter egg" credits list at the bottom of the WORDS list.
There is further evidence to support Greg being the person who did this, as there is only one of these "words" that is actually used within the game's room scripts, and that is the word "greg". It isn't configured as a synonym for anything. It is straight out using "greg". I think he might have been playing around with the parser and it ended up in the released game. Or perhaps it was deliberately kept in the game, so that in future years he could say: "Look... if I type "greg rope", then he climbs the rope". Might be an interesting party trick these days! ;D
For those that haven't heard the name Hal Schwab before, he published a game called "Golf Challenge" through Sierra On-Line in 1982: https://en.wikipedia.org/wiki/Golf_Challenge_(video_game) (https://en.wikipedia.org/wiki/Golf_Challenge_(video_game)). He would therefore have been around at the time that things were kicking off with the King's Quest project and so may have been involved early on. Given that his name does not appear in the credits list within the game's title screen, then he must have been another one similar to Arthur Abraham that left before the end of the project. Bob Heitman mentioned to me a few years back that the original King's Quest was written by a group under the direction of Hal Schwab, and he believes that it was Greg Rowland who told him this. I hadn't found any other evidence to back this up, until now. Hal really was part of the team, it would seem.
-
But Roberta is not mentioned? Or is she encoded elsewhere?
-
Her name appears on the official credits list in the game's title screen, but not in this hidden list at the end of the WORDS data. I guess that whoever added these names was thinking more of those who built it rather than designed it.
I did also spot "chris" and "teresa" in the list of words, but they're not in this same section at the bottom, so not sure why those two are in there. They don't appear to be used in the game scripts.
Immediately above the "build team" list of words (above with regards to word number) is just normal game words, e.g. 0xC1 = "holes", 0xC0 = "floor", 0xBF = "nap", 0xBE = "say", 0xBD = "pluck".
-
Very interesting.
Can you write a quick script the dumps all the words that are not referenced by any script? Maybe there are other interesting unused words in AGI games.
-
Would that "Chris" be Chris Iden?
-
Would that "Chris" be Chris Iden?
And Teresa Baker perhaps (see the 1988 Christmas Card)? But this is quite the rabbit hole. I've never heard of Hal Schwab before.
-
Very interesting.
Can you write a quick script the dumps all the words that are not referenced by any script? Maybe there are other interesting unused words in AGI games.
I had the same thought, and I might do this later on as a general tool for AGI V2/3, perhaps as a pop-up within AGILE that shows all unused words in the running game. But as its the original 1984 PCJR "GAL" version of King's Quest that I'm currently looking at, AGILE doesn't yet support that. I have run my eye over the word list a number of times and can't see anything else that stands out. It would be interesting though to see a list of unused words for each AGI game and then make some guesses as to why the words were added but ultimately not used.
-
Would that "Chris" be Chris Iden?
I had the same thought about this one as well. I've spoken to Chris Iden a few times and he assures me that he wasn't part of the original IBM PCJR King's Quest project team. He was, however, the programming department manager for a few months, roughly from the start of September 1983 for about three months. He was based in the programmer's office behind Ponderosa Printing, which was not where the King's Quest project team were based (they were in a secure office about 300 yards along the road). So Chris was the line manager of the programmers on the KQ team for those few months at the end of 1983, but not directly involved in the project itself. Perhaps one of the KQ programmers added his name to the word list for some reason.
Chris Iden was definitely involved with the releases of King's Quest after that original May 1984 releases though. His name appears in the credits of the August 1984 IBM PC release, and also the Tandy release:
https://nerdlypleasures.blogspot.com/2017/04/the-evolution-of-kings-quest.html
but not in the two May 1984 releases.
I have compared the WORDS data from the original PCJR version, IBM PC version from Aug 1984, and the Tandy version, and the WORDS data is identical across all three. If I can trust the PCJR disk image that I have, then that would seem to indicate that the "chris" word was already in the WORDS data in the May 1984 release.
-
I found the following in the 1984 IBM PC booter version of KQ, and also in the TANDY version, but it doesn't appear in the original PCJR version, suggesting that Greg added it after the initial PCJR release:
if (curRoom!=10 && curRoom!=11) {
if (said(greg,!) && v26==0 && v30==0) {
set(ducking);
ignore.blocks(ego);
op65(87);
end.of.loop(ego);
assign(v43,2);
}
if (said(jump,!) && v26==0) {
set(jumping);
}
}
And sure enough, if you run those versions in Dosbox, and you type "greg" in any room that isn't 10 or 11 (those are the goat enclosure rooms), then Graham does the ducking motion.
Charles Tingley's LinkedIn mentions that his contract with Sierra ended in May 1984, but I suspect that it was actually Greg that was preparing the final releases in May 1984. There are a couple of places online where Greg has commented that he was "the last man standing" on the King's Quest project, so both the hidden credits list, and the easter egg mentioned immediately above, might be a bit of evidence to support that.
Hmmm... just a thought. I wonder if this little easter egg is an attempt to show that Greg was the "last man standing", visually. The player types in "greg" and then Graham crouches down and then stands up. I wouldn't be surprised if it was. Perhaps we can call this "the last man standing" easter egg. :D
-
I just tried it and indeed he does kneel down.
-
Yes, and if you try it in the PCJR version, you'll notice that it doesn't do anything.
I think that the 1984 IBM PC version I have is the later 16th August release. I don't have the 30th May 1984 release. Which one did you try? If you have the 30th May 1984 release, then can you test if it works on that one?
Greg must have added this after the 10th May 1984 PCJR release, but the question is whether it was only just after, and therefore is in the 30th May release, or whether it was added later on and included in the 16th August release.
-
I have four booter images. The one that starts composite color mode does. The PCjr copy does not. The Tandy/PCjr and the Tandy do. Curious thing about the Tandy versions is that Graham stays crouching, while in the composite color one he bobs right back up.
I wish I could give you more info about the various versions, but since all of the files are in the images I am at a loss to how to get any more info from them. I wish I had a way to extract the files.
-
Use the tools that NewRisingSun has provided in this thread?
Also, I've looked a bit at the code. There was supposed to be a time penalty in KQ1:
$ grep -a "time penalty" KQ1.IMG
Your Score Is: with a & time penalty665535-->
Also, it seems the distribution disk used to contain the PCJR version. Line 1 and 2 are from the fairy godmother, but only line 2 is used:
$ strings KQ1.IMG | grep Graham | nl
1 "Ye best be careful, young Grahame. The
2 "Ye best be careful, young Graham. The
3 "Gentle Sir Graham, your quest is
4 Graham.
5 Good Luck, Sir Graham!
6 Go, Sir Graham! Go and bring me back
7 Come closer, Sir Graham, my voice is
8 Why, Sir Graham, have you failed me and
9 "Sir Graham, I am an old man. I fear my
10 I have chosen you, Sir Graham, to prove
11 Go, Sir Graham! Go and bring me back
12 Graham. You have been a good and
And it seems at one point you could reenter the castle without the treasures (line 8 )?
-
And this one is just silly:
if (said(climb,well)) {
print("You cannot climb the sides of the well.\n They are too steep and slippery.");
}
if (said(rowland,well)) {
print("You cannot climb the sides of the well.\n They are too steep and slippery.");
}
and more cases involving the rope in the well and the verb 'rowland' instead of 'climb'. They just duplicate the code of the 'climb' cases. I guess someone was tired of working on the project, or physically tired. Oddly, I can't get the interpreter to execute these statements. But they are there.
EDIT: And even more curiously, in the PCJR version (where the 'greg' animation doesn't work), we instead have:
if (said(climb,well)) {
print("You cannot climb the sides of the well.\n They are too steep and slippery.");
}
if (said(greg,well)) {
print("You cannot climb the sides of the well.\n They are too steep and slippery.");
}
-
I guess the "greg rope" joke earlier in the thread was almost correct.
-
To be fair, I had already seen the scripts that Lars found. These are the rope ones that he refers to:
if (said(greg,rope) && v137==1 && v145==0) {
set(v167);
}
if (said(greg,rope) && v137==0 && v145==0) {
print("The rope is out of reach.");
}
if (said(greg,rope) && v145==1) {
set(v112);
}
What I'm wondering now is why did (presumably) Greg add these ones? As Lars mentions, they're just a copy of the same statements that use "climb" instead. Why specifically did he copy those particular statements and create "greg" versions of them? Is it that he wanted to hide something in there that used his name? Or was he trying to debug an issue? Lars mentioned that he couldn't get the interpreter to execute the "greg" variants. I wonder if the "climb" variants work? If not, then maybe he was trying to debug that, using another "said" case.
If he wasn't debugging an issue, but instead hiding another easter egg in there, then why pick these "climb well" and "climb rope" statements to copy?
-
EDIT: And even more curiously, in the PCJR version (where the 'greg' animation doesn't work), we instead have:
if (said(climb,well)) {
print("You cannot climb the sides of the well.\n They are too steep and slippery.");
}
if (said(greg,well)) {
print("You cannot climb the sides of the well.\n They are too steep and slippery.");
}
Yeah, it does seem strange to presumably deliberately change "greg" to "rowland" for these statements. Sierra released the "greg" variants in the PCJR version, then changed them to "rowland" in the later IBM PC and TANDY versions. That does feel like a deliberate change, and it suggests that the original "greg" statements in the PCJR release were not mistakenly left in there, since someone changed the word to "rowland" and once again left them in there for the next release. They didn't spot it and think "Oh, I left that in there, better take it out" but rather "Let's change that to 'rowland' and use 'greg' for crouching instead".
-
Weird idea: the copy that has the "greg" saids but doesn't accept them deliberately doesn't recognize 0xC2 and higher?
-
I have four booter images. The one that starts composite color mode does. The PCjr copy does not. The Tandy/PCjr and the Tandy do.
I have managed to find what I think is the 30th May 1984 IBM PC release of King's Quest. NewRisingSun mentioned in another thread that that particular version has the text "BOOT v1.1" in it, rather than "BOOT v1.2". I found the version with "BOOT v1.1" on archive.org. So I now have all five of those early booter versions. The "LOADER" version also differs. The one with "BOOT v1.1" has "LOADER v1.15", whereas the one with "BOOT v1.2" has "LOADER v1.2".
I can confirm that this 30th May 1984 version does have both the "greg" crouching animation script and the "rowland" scripts from the well. So this would mean that these changes were made in the few weeks between the PCJR release and the first IBM PC release.
Curious thing about the Tandy versions is that Graham stays crouching, while in the composite color one he bobs right back up.
Yeah, you're right. I just tried that, and he does indeed stay crouching. Another mystery.
-
And yet another. Greg Rowland is only credited as an artist in KQ1 (and Dragon's Keep and The Dark Crystal), but it seems he was writing code too, slipping easter eggs into the game? And he did contribute code to PQ1.
-
Yes, a few years back, in fact it was over 7 years ago now, there was a thread on here in which we discussed what Greg had put in his online resume in regards to King's Quest:
KINGS QUEST I Development team member. Helped design and produce graphics and animation utilities, game logic compiler, later to become known as Adventure game development system AGDS. Substantially contributed to game design and story line. Built game screen graphics and animated characters. Developed game AI logics and user response messages.
So he was definitely doing more than just graphics. Not sure why the official credits list him only under graphics.
-
Very interesting findings here! Somehow I've seem to have missed that there was a working decompiler for the original KQ1.
Now I didn't check it out yet, but reading the thread: Isn't it just that someone (perhaps Greg) has overwritten the entry containing the verb for ducking/crawling when padding the dictionary with names of the team members? This also could explain some of the copied statements, e.g. "climbing" versus "crawling" (in a well, a rope), which are not synonyms.
-
I did wonder something similar, e.g. perhaps "greg" and "rowland" were added as synonyms for other words, or perhaps a word was completely replaced by "greg". I ruled out the synonym idea, as there is only one word with a word number of 0xC2 (i.e. greg) and one with a word number of 0xC3 (i.e. rowland).
Regarding the replacement idea, there is no "duck" or similar word in the original King's Quest WORDS list, so perhaps one of Greg's names did replace that word. The AGIv2 versions of the game do support "duck", but these early booter versions don't appear to have "duck" or "squat". There is, of course, the "-" key that makes Graham duck/squat, and that works similar to what typing "greg" does for the CGA and TANDY versions, except that for the CGA versions, "greg" squats then immediately stands, whereas for the "-" key, he stays down. For the other action words, i.e. "swim" and "jump", which have associated keys ("=" and "0"), the early booter versions of KQ do support those words, and they do the same as what the action key does... (well, it seems that the PCJR version doesn't jump when you type "jump", but the CGA versions do), whereas "duck" is mysteriously absent from the words, which is quite strange when the other two words are supported. So you could very well be on to something there. Maybe he did unintentionally overwrite a word that was doing something else.
But given that the "duck" word wasn't in the PCJR version, or the IBM PC CGA version released a few weeks after that, and yet the bit of code that supports the "greg" word making Graham crouch was added in between those two versions, I'd like to think that someone would have noticed when adding that new bit of code that it doesn't work for the originally intended word, assuming that it was added for ducking rather than as an easter egg. Maybe these releases of the game weren't properly synced up with regards to the WORDS list and the compiled scripts. If this is the case though, then all of these booter versions had the same problem. Surely they would have rebuilt the whole game each time it was released, unless the process of compiling the scripts was quite different in these early versions.
-
GALextract works well with getting the game resources out of the img, but are there any tools to dump all of the files in a booter img?
-
Do you mean the reverse process? I haven't seen one yet.
-
No, I mean want to get other files from the image like the loader or EXE and any of the non resource files.
-
No, I mean want to get other files from the image like the loader or EXE and any of the non resource files.
The funny thing is that the PCjr image is very different from the others. The PC and Tandy versions have an EXE file (as you say) which is odd because EXE is a DOS file format and these versions don't run under DOS. The EXE is located at the beginning of the image (after boot sector and loader). In the PCjr image, the main program file is not an EXE file, and it is located at the end of the image. It took a few tries to get it to load in IDA (enough to investigate the thing I wanted to).
-
I think that the 30th May 1984 date is wrong for the original IBM PC release of King's Quest. That date is from the timestamp of the MAIN.EXE directory entry on the disk, but the LOAD directory entry has a timestamp of the 31st May 1984, which would mean that the release can't have been the day before that.
These are the timestamps I calculated for the recognisable and properly structured DOS directory entries in the first IBM PC release (which we're assuming was at the end of May 1984):
MAIN.EXE 30448 30-May-1984 18:48:36 [cluster=6]
LOAD 3158 31-May-1984 02:39:58 [cluster=2]
290K 296960 19-May-1984 14:02:56 [cluster=66]
IBC 20 06-Dec-1983 10:20:48 [cluster=350]
PROTECT 22 02-Feb-1984 14:10:08 [cluster=351]
PROTECT.NO 22 02-Feb-1984 14:10:08 [cluster=352]
PROTECT.YES 22 02-Feb-1984 14:09:54 [cluster=353]
MAIN.EXE 0 28-May-1984 03:47:18 [cluster=0]
I think that the first two (MAIN.EXE and LOAD) are the main files, and even seem to be at those cluster locations.
-
And in case anyone cares, what I was looking at is a mysteriously nopped opcode, number 41. It is called in 9 places, all having to do with the various drowning sequences in the game. It doesn't do a thing in the KQ1 interpreters I have looked at! and I'm thinking 'why?' Was there supposed to be some effect (visual? sound?) that was ultimately scrapped, was it for debugging or something else? The integer argument to that opcode looks interesting as well:
17.cg: drown.stuff.nop(9);
23.cg: drown.stuff.nop(14);
32.cg: drown.stuff.nop(2);
41.cg: drown.stuff.nop(9);
41.cg: drown.stuff.nop(1);
43.cg: drown.stuff.nop(14);
47.cg: drown.stuff.nop(9);
4.cg: drown.stuff.nop(14);
7.cg: drown.stuff.nop(10);
The numbers look like they could be resource numbers...
-
The funny thing is that the PCjr image is very different from the others. The PC and Tandy versions have an EXE file (as you say) which is odd because EXE is a DOS file format and these versions don't run under DOS. The EXE is located at the beginning of the image (after boot sector and loader). In the PCjr image, the main program file is not an EXE file, and it is located at the end of the image. It took a few tries to get it to load in IDA (enough to investigate the thing I wanted to).
Yeah, it is strange that the PCJR image is so different. I am starting to think that there is more of a time gap in the build dates between the PCJR version and the first IBM PC version. I'm not sure where the official PCJR version's release date came from, but I suspect it was the copyright registration, which mentions the 10th May 1984. This sounds about right with regards to when it became publicly available, since I know that it wasn't available yet on the 20th April 1984, as I found a newspaper advert that mentions a demo of King's Quest to be given by Greg Rowland at an event in Fresno on that date, and the advert specifically says that it is a "sneak preview of Sierra's yet to be released 3D adventure game".
As a side note, the same newspaper advert describes Greg Rowland as a "star programmer". The exact text reads:
"Come see a sneak preview of Sierra's yet to be released 3-D adventure game "THE KING'S QUEST" and meet this star programmer Greg Rowland, Friday April 20 at 12:00pm & 5:00pm".
If only we had a time machine, then we'd know where to be.
Anyway, the point I was making is that the PCJR build may have been around for a while, but not yet released. There wasn't just this 20th April 1984 demo but others that were quite a bit earlier. There was one quite prominent demo at the 1984 International Winter Consumer Electronics Show that was held in Las Vegas, at the Hilton, Riviera and Sahara Hotels, from Saturday the 7th to Tuesday the 10th January. In the month's that followed, various magazines published screenshots of the game and mentioned the demo at the Winter CES. It is clear from the screenshots that they are all from the same set of screenshots, so I think that Sierra must have given various publishers a standard set of screenshots to use in their publications.
Also of note is that the trademark for the name "King's Quest" was filed by Sierra on the 23rd January 1984, in which it claims that the first use of the name was on the 13th January 1984. I'm not entirely sure what happened on the 13th, and I would have thought that the demo at the Winter CES show between the 7th-10th would have been the actual date of first use. Regardless, the first mention by name that I can find within a publication is a magazine article dated the 24th January 1984. That might be why they filed the trademark for the name the day before.
So what we have is that the PCJR version was being demoed for several month's before the 10th May 1984 release. I'm not sure how we can determine the actual build date though. We're fortunate that the subsequent booter versions have the DOS directory entries that contain timestamps, so we (in theory) know that the first IBM PC release was no earlier than the 31st May 1984. It is highly unlikely that it would ship on the same date as the build though. That's asking for trouble. So there would have been another round of QA after that I would guess, to make sure things were still working. I'm guessing a June 1984 release date for that first IBM PC version.
The one thing that disagrees with this (surely the build date can't lie though?) is that the May 1984 edition of the "ENTER" magazine has a small writeup and states that the game "is available from Sierra On-Line for the IBM PC and other computers with 128K". It specifically mentions the IBM PC. This might be a case of Sierra wanting to get the IBM PC orders starting to flow in without yet having the final release build ready, although, who knows, maybe some early purchasers got a buggy early build. I wouldn't be surprised if the sales and marketing side of Sierra bent the truth a bit, as sales people do, when using the word available. It was probably more "it will be available by the time you've sent your order and we've processed the order". - Incidentally, the "other computers" probably refers only to the PCJR at this stage, since the same "ENTER" magazine has another write up in their October 1984 edition that specifically mentions the IBM PC and PCJR as the machines that it is available for.
-
And in case anyone cares, what I was looking at is a mysteriously nopped opcode, number 41. It is called in 9 places, all having to do with the various drowning sequences in the game. It doesn't do a thing in the KQ1 interpreters I have looked at! and I'm thinking 'why?' Was there supposed to be some effect (visual? sound?) that was ultimately scrapped, was it for debugging or something else? The integer argument to that opcode looks interesting as well:
17.cg: drown.stuff.nop(9);
23.cg: drown.stuff.nop(14);
32.cg: drown.stuff.nop(2);
41.cg: drown.stuff.nop(9);
41.cg: drown.stuff.nop(1);
43.cg: drown.stuff.nop(14);
47.cg: drown.stuff.nop(9);
4.cg: drown.stuff.nop(14);
7.cg: drown.stuff.nop(10);
The numbers look like they could be resource numbers...
An interesting mystery. Looking at the room 41 script, it doesn't look like there is anything comparable in the AGI V2 version of the game. I also had a look at the byte code for room 41 in the Apple II version, which is very similar, but it appears to lack these calls as well. Whatever it is, it seems not to have been required, which is obvious I guess, given it doesn't do anything.
Have you been looking at any of the other currently unnamed opcodes?
-
Do we know if anyone has previously looked into the AGIV0/GAL picture format? I was looking at this a week or so back, seeing if I can load the pictures into the Java version of PICEDIT. The picture action codes are a bit different. The 0xF4 to 0xF7 codes appear to be the same but the fill codes are different, and I use codes plural since there are multiple, and they support setting the visual and priority colour with the fill action itself. The setting of the visual and priority colours is in general handled differently. There is another code, for example, that sets both the priority and visual in one go, and it seems that certain priority values are interpreted as the priority being off rather than drawing in the priority colour.
I have got my code so that the picture converts to AGIV1/2/3 format on load, so that PICEDIT can display it, and in general they display fine. There is still a bit of work to do with the finer details of the visual/priority colours. Interestingly, the background for the priority screen appears to be black, rather than red, and the priority band colours are shifted when compared with later AGI versions, so the ego walking test tool in PICEDIT doesn't currently work as a result of this.
Commands 0xF4 to 0xF7 are repeated from 0xF8 to 9xFB but are interpreted differently with regards to what they're drawing on.
Jeff & Chris may claim that they didn't create AGI, but it is clear that there was a big refactor of the code in between KQ and KQ2. The tidy up of the picture codes is one example of this. They must have seen that they didn't need 3 different fill actions, or a second version of each drawing command.
-
What about getting them to load with the AGI library?
-
You could compare them with ADL/PreAGI I guess.
-
What about getting them to load with the AGI library?
I was thinking the same thing, but I'll wait until I've worked out all the details.
-
You could compare them with ADL/PreAGI I guess.
I had a look at the ADL and pre-AGI picture formats last night, by looking over the code in scummvm. So the ADL picture format is quite different. The drawing actions are within the 0xE0 range, and it does have the standard four drawing actions, i.e. the X/Y "corner" actions, and the absolute and relative line actions, and also the fill, but as codes in the 0xE0 range. So those drawing actions have been around for a while, but have been shifted around over time. The ADL picture format uses the 0xF0 range for setting different colours, i.e. different codes for different "colours". This is going back to the Apple II days where Ken Williams was the main programmer of the picture editor, and the colours were kind of faked. Sierra published two different picture tools that I'm aware of that were both supposedly the ones that they used for these ADL games. The first was the "Paddle/Tablet Graphics" tool (I think the paddle bit might be where the X/Y "corner" action originated). This tool they were selling back in 1980, shortly after Mystery House was released. Then a few years later, they started selling "The Artist", which was once again claimed to be the tool that they were using internally, but packaged for the general public to purchase.
Looking now at the pre-AGI games:
The scummvm default picture version is the AGIV2 picture format, which is used by the Mickey and Winnie "pre-AGI" Disney games as well, and also the AGIV1 games (KQ2 and BC). Troll's Tale uses what scummvm calls the V1.5 picture format. The scummvm picture class also appears to support a "V1" picture format, but it doesn't look like it is used at present. The AGIV1 games such as KQ2 and BC that came out between KQ and the first AGIV2 games were already using the "AGIV2" picture format.
Looking at the implementation code for the various picture formats supported by scummvm, none of them is an exact match for what I'm seeing in the original King's Quest game. Instead what I'm seeing is a combination of the codes used in the V1, V1.5 and V2 scummvm picture formats. Specifically, it contains all of the picture code actions (0xF1, 0xF3, 0xFA and 0xFB) listed in the switch statement for the drawPictureV1 method (this is the one that I can't see any usage of, so might be a work in progress and therefore incomplete), and the 0xF8, 0xF9, 0xFA, 0xFB and 0xFE codes from the drawPictureV15 method (used by Troll's Tale), and the 0xF4, 0xF5, 0xF6, 0xF7 and 0xFC code from the drawPictureV2 method (I didn't even know that 0xFC was a code in AGIV2; it must be one of the pre-AGI games that uses this). In addition to this, it includes codes that none of the V1, V15 or V2 formats have a matching implementation for, i.e. 0xF0, 0xF2 and 0xFD.
Troll's Tale seems the closest, and it might be the case that this game doesn't use all of the codes, and thus why the scummvm implementation doesn't provide implementations for all of them. I would guess that the Troll's Tale engine is using essentially the same picture format as the booter versions of King's Quest, which hints at the placement of Troll's Tale within the evolution of the AGI picture format.
Likewise, the use of the AGIV1/2 picture format by the Mickey and Winnie games is very interesting. These two games were released at the end of 1984. King's Quest was released in May 1984. Development work on the Mickey and Winnie games probably started mid 1984. - Here's the interesting thing: Someone redesigned the picture editor created by the King's Quest project team in between the the KQ project and the release of the Disney games, and they did so within a quick enough timeframe that the artists working on Mickey and Winnie could use the new version. And that new version was what was subsequently used for the AGIV1 games, i.e. King's Quest II and Black Cauldron, and then also for the AGIV2 games.
My guess, a fairly safe guess I would say, is that this person was Bob Heitman. I will have to ask him this to see if he recalls. He must have done this in mid 1984. He has previously said that he inherited the picture editor built by the KQ team, but that it was from a maintenance perspective rather than building any new features in it. The question is whether this redesign/rearrangement of the picture codes qualifies as maintenance.
Regarding Troll's Tale, scummvm only has game definitions for the PC versions. I suspect that there must have been a project within Sierra to port the game to the PC, and at the time when they did this, the King's Quest picture editor was available for use, but perhaps not the new version that was redesigned for the Mickey and Winnie Disney games. The PC Booter version apparently came out in 1984:
https://www.mobygames.com/game/7271/trolls-tale/credits/pc-booter/
And Doug MacNeill (of King's Quest project team fame) did the graphics for it, and Peter Oliphant (of The Dick van Dyke TV show fame) did the programming conversion. Doug must have been quite busy in 1984, because he was also working on the Disney games. I think this places the Troll's Tale PC Booter conversion as taking place between the King's Quest project and the Disney games, since Doug was using the KQ picture editor (apparently built primarily by Ken MacNeill, according to quotes from Doug in Shawn Mills' "The Sierra Adventure" book) for Troll's Tale, but was using the revamped AGIV1/2 picture editor for the Mickey and Winnie Disney games. - I've just checked the Troll's Tale disk image for timestamps, and it looks like the LOAD directory entry has a 5th April 1984 timestamp, which is older than the LOAD timestamps in the first KQ releases. That suggests that the Troll's Tale PC conversation was being worked on prior to the KQ release, but probably after the bulk of the KQ code was written. It makes sense then that Troll's Tale uses the KQ/GAL picture format.
Incidentally, Greg Rowland was involved in converting the "Dragon's Keep" pictures for the PC version in 1984, probably also after the graphics work for the KQ project was complete, with the programming conversion also being done by Peter Oliphant:
https://www.mobygames.com/game/20644/dragons-keep/credits/pc-booter/
Peter was another one that was very busy in 1984, as he was the main programmer for Mickey's Space Adventure. So, Peter was working with Doug on the Troll's Tale conversion to the PC, and with Greg on the Dragon's Keep conversion to the PC. My guess is that Dragon's Keep also uses the KQ/GAL picture format then. I'd like to verify that, but the PC version of Dragon's Keep seems rare. Has anyone seen that one anywhere?
(it being rare might be why it isn't supported by scummvm)
Hmmm, now that I'm looking more closely at the specific picture codes of the King's Quest GAL picture format that Troll's Tale is using, it appears to be specifically the visual ones. All of the priority related codes have been avoided. 0xF1 is specifically for setting only the visual colour. 0xFE is for filling in only the visual colour. The codes 0xF8, 0xF9, 0xFA and 0xFB appear to be visual only versions of the more familiar 0xF4, 0xF5, 0xF6 and 0xF7 that draw to both visual and priority. This makes a lot of sense, because Troll's Tale does not have a priority screen. The original game was built in 1983, then ported to the PC, with the pictures being converted to the KQ/GAL picture format. There would be no need for codes that used the priority screen.
Anyway... very long story short, I think I can use some of what I've found in the scummvm source to validate what I've prototyped.
-
I've looked into the pre-AGI formats in the past as well (though not that thorough) and I believe the 0xE0 range was being used in the C64 version of Winnie the Pooh. At least I recall I had to shift the drawing actions to the regular AGIv2 codes in order to match them up to the PC version. The picture format in the PC version on the other hand is close to fully compatible with AGIv2 and I remember using the error message of PICEDIT (thanks!) to figure out the difference. It was only one instruction, I believe, that could be removed without any(?) consequences.
That said, I think the C64 or Apple version would fit better in your timeline, as the PC version seems to be ported from (one of) them and has a copyright date of 1985:
https://www.mobygames.com/game/7274/winnie-the-pooh-in-the-hundred-acre-wood/screenshots/dos/32029/ (https://www.mobygames.com/game/7274/winnie-the-pooh-in-the-hundred-acre-wood/screenshots/dos/32029/)
Mickey's Space Adventure for PC was released even later, with a copyright date of 1986:
https://www.mobygames.com/game/7273/mickeys-space-adventure/screenshots/dos/31261/ (https://www.mobygames.com/game/7273/mickeys-space-adventure/screenshots/dos/31261/)
[...] the PC version of Dragon's Keep seems rare. Has anyone seen that one anywhere?
It's not clear if it actually exists or was released. The MobyGames link you provided contains a thread which discusses the inclusion of the booter. There's quite some evidence, but it hasn't turned up yet. There are other PC versions of early Sierra titles rumoured to exist as well, some more likely than others.
Interestingly enough, the Northeastern Software advertisement, mentioned in the aforementioned thread, lists Golf Challenge (as mentioned earlier, by Hal Schwab) as being available for IBM too:
https://books.google.com/books?id=IJAhwYh-TZkC&lpg=PA297&ots=v2jFo2Ihih&dq="dragon's+keep"+ibm&pg=PA297&redir_esc=y#v=onepage&q="dragon's keep" ibm&f=false (https://books.google.com/books?id=IJAhwYh-TZkC&lpg=PA297&ots=v2jFo2Ihih&dq="dragon's+keep"+ibm&pg=PA297&redir_esc=y#v=onepage&q="dragon's keep" ibm&f=false)
-
That's some impressive work, Lance!
Yeah, I have looked at the missing opcodes. Many of them are related to movers/cyclers and aren't easy to decode. But I have worked out some, and I'm updating SYSDEFS (and GAMEDEFS) as I go. They don't map neatly to the AGI set (for example there's a specific opcode that I have called ego.falls; you can guess what it does). There are also a few mistakes in the ones that NewRisingSun identified (current.room.f takes two var parameters, not a number and a var).
-
I've looked into the pre-AGI formats in the past as well (though not that thorough) and I believe the 0xE0 range was being used in the C64 version of Winnie the Pooh.
Yeah, I did notice that the drawPictureC64 method in the same AGI picture.cpp file does use the 0xE0 range, and comparing it now to what the ADL games use, they appear to be closely aligned.
I think the C64 or Apple version would fit better in your timeline, as the PC version seems to be ported from (one of) them and has a copyright date of 1985:
https://www.mobygames.com/game/7274/winnie-the-pooh-in-the-hundred-acre-wood/screenshots/dos/32029/ (https://www.mobygames.com/game/7274/winnie-the-pooh-in-the-hundred-acre-wood/screenshots/dos/32029/)
Mickey's Space Adventure for PC was released even later, with a copyright date of 1986:
https://www.mobygames.com/game/7273/mickeys-space-adventure/screenshots/dos/31261/ (https://www.mobygames.com/game/7273/mickeys-space-adventure/screenshots/dos/31261/)
Yeah, you're right. I had assumed incorrectly that the PC version would have come out alongside the others. So this does indeed change the timelines a bit, and it makes my earlier comment about the PICTURE editor changing quickly after the KQ project unlikely. Instead, given that the PC versions of those Disney games came out in 1985 and 1986, it seems more likely that the PICTURE editor changed during the development of King's Quest II. I found a timestamp for MAIN.EXE in the 1.0W release of KQ2 of 24-Apr-1985. It would make sense then that the Winnie and Mickey PC conversions used that revamped Picture Editor.
It's not clear if it actually exists or was released. The MobyGames link you provided contains a thread which discusses the inclusion of the booter. There's quite some evidence, but it hasn't turned up yet. There are other PC versions of early Sierra titles rumoured to exist as well, some more likely than others.
If it did exist, then I hope it turns up one day, but perhaps it was never released. I know that the Goofy game was never released, despite being advertised numerous times, and despite development still continuing into 1986/7. I found an interview in a magazine with John Williams where he talks about that game and the issues.
Interestingly enough, the Northeastern Software advertisement, mentioned in the aforementioned thread, lists Golf Challenge (as mentioned earlier, by Hal Schwab) as being available for IBM too:
They did supposedly have a big team working on porting their older games to the IBM PCJR, as part of the top secret PCJR project. I've seen a quote from Ken from near the time period stating how much of his current dev team was invested in the various PCJR projects, and that if the PCJR wasn't a success, then he was in serious trouble. Well, we know what happened. He had to reduce his head count by approx. 100 not long after the PCJR release. Things hadn't been good in 1983 either, so it was the last straw I guess.
-
On a side note, do we have any tools for ADL?
-
I don't think I've seen any so far, although, as I mentioned in one of my earlier posts, "The Artist" tool is apparently what they used inhouse for graphics, and I did manage to find this tool on archive.org and had a quick play with it inside the emulator on the archive.org website. Whether or not it really can load the images from those "Hires" ADL games (such as the "Timezone" ADL game that it claims to have been used for) is another question.
Some of you might be interested in the attached advert I found for "The Artist". It reads like a resume for a person who worked at Sierra, but is in fact the picture editor that they are referring to.
-
Not that anyone would be trying to edit the old ADL games or create new one, it would be nice to have a set of tools to explore these old games. I would be curious to see the source scripts and other resources in the games. If nothing else to see more of the process they used to make them.
-
Yeah, I have looked at the missing opcodes. Many of them are related to movers/cyclers and aren't easy to decode. But I have worked out some, and I'm updating SYSDEFS (and GAMEDEFS) as I go. They don't map neatly to the AGI set (for example there's a specific opcode that I have called ego.falls; you can guess what it does). There are also a few mistakes in the ones that NewRisingSun identified (current.room.f takes two var parameters, not a number and a var).
You have inspired me to look into the disassembly of the GAL KQ as well, but my focus is going to be on the picture drawing logic, so there should be no danger of us doubling up. I've already identified the entry points for each of the picture commands. I'll report back in a day or two with what I've discovered. There is clearly some magic going on with some of the picture actions that scummvm hasn't captured yet, as the Troll's Tale probably isn't making use of it. For example, the 0xF0 picture code toggles something, and other picture codes set certain state that gets cleared by the use of other picture codes. I just need to work out now what exactly those bits of state are controlling and try to replicate it in my PICEDIT GAL import prototype.
-
So, it looks like the 0xF0 picture code toggles between the visual and priority screens with regards to which of those two screens the 0xF8/0xF9/0xFA/0xFB commands draw to.
0xF8 = The same as 0xF4, except that it uses the current setting of the 0xF0 toggle to determine if visual or priority is drawn to.
0xF9 = The same as 0xF5, except that it uses the current setting of the 0xF0 toggle to determine if visual or priority is drawn to.
0xFA = The same as 0xF6, except that it uses the current setting of the 0xF0 toggle to determine if visual or priority is drawn to.
0xFB = The same as 0xF7, except that it uses the current setting of the 0xF0 toggle to determine if visual or priority is drawn to.
This is why I was getting some strange behaviour in my prototype. I initially thought that this second set of line drawing commands were for visual only, given that Troll's Tale uses them, but it turns out that they support both visual only and priority only. The control of what screen is being drawn to is not as straight forward as it is in the AGIV2 picture format, where we instead have explicit commands for turning visual and priority on and off.
I haven't incorporated this discovery into my prototype yet but I'll do it soon. There is also something strange going on with the three variants of the fill command (0xFC, 0xFD and 0xFE) that I'll check out first.
The goal is not to build a GAL picture editor at this stage, but rather to see if those pictures can be cleanly imported. It looks like the pictures went through some sort of conversion in between the original KQ booter releases and the later AGIV2 release of KQ1, since the equivalent drawing actions are all in the same order and the lines appear to match. It will be interesting to see if the AGIv2 codes generated by my import align with what the AGIV2 KQ1 uses. I suspect that the pictures probably went through some manual touch ups, but regardless, it will be interesting to discover that either way. I'm just crossing my fingers that the line drawing algorithm remained consistent. A pixel placed differently here or there would mess things up.
-
Interestingly, the background for the priority screen appears to be black, rather than red
It turns out that I was wrong about the above. The KQ/GAL interpreter code is clearly setting the priority screen to be all blue. So blue is the default priority background. Black appears to be used a lot to fill in areas of water. I need to check a few more pictures to see if this is consistent, but so far for the few that I've checked, it does seem like water is priority black.
For the three fill modes, one fills in both visual and priority, the second visual only and the third is priority only. These fill modes not only behave like that, but they also include the colours to fill in with. So, for example, 0xFC includes a visual colour that it sets the visual colour to, then includes a priority colour that it sets the priority colour to, and then fills at the given points, in both the visual and priority screens. 0xFD includes a priority colour that it sets the priority colour to, then it fills in only the priority screen. And finally, 0xFE includes a visual colour that it sets the visual colour to, then it fills in only the visual screen. - So if there happen to be no points included to fill at, then these picture actions would only change the colour.
There are also separate codes for changing the colours. 0xF1 sets the visual colour. 0xF2 sets the priority colour. 0xF3 sets visual and priority colours. I think if 0xFC did not include any fill points, then it would behave the same as 0xF3, and it would be similar for 0xFD and 0xFE with regards to 0xF2 and 0xF1.
Now, back to 0xFF: the default mode for this one is that 0xF8/0xF9/0xFA/0xFB will draw only in the priority mode. The 0xFF action has to be used once to make these instead draw only in the visual mode. And now that I've had a look at a Troll's Tale picture, I can see that it uses 0xFF right at the start to toggle this mode, so that all subsequent drawing actions that it uses are drawing only in the visual screen. KQ instead uses 0xFF a few times during each picture, whenever it wants to draw lines only to visual or only to priority. It usually starts with using the 0xF4/0xF5/0xF6/0xF7 actions though, which draw to both screens, and it isn't until a bit into the picture that it switches to using the single screen modes.
-
There is one mystery with regards to the Troll's Tale format though. It appears that it isn't an exact match with the KQ/GAL picture format. The 0xFB command doesn't behave the same. For the KQ/GAL format, 0xFB is the same as 0xF7 (i.e. the shorter relative lines) except that 0xF0 controls what screen 0xFB is operating in. In the Troll's Tale format, 0xFB appears to be absolute lines rather than relative lines, so appears to be identical to the 0xFA command. I had to implement it as such in my prototype in order for the Troll's Tale pictures to render properly. Other than that, the KQ/GAL and Troll's Tale picture codes (at least in relation to the ones that Troll's Tale uses) are equivalent.
I hadn't noticed until now, but the scummvm code clearly points this out, and has a TODO message asking if this really is the case, i.e. the duplication (see below):
https://github.com/scummvm/scummvm/blob/master/engines/agi/picture.cpp#L473
case 0xfa:
// TODO: is this really correct?
draw_LineAbsolute();
break;
case 0xfb:
// TODO: is this really correct?
draw_LineAbsolute();
break;
-
I discovered a bug in GALextract affecting views. Besides generating files that weren't quite what the interpreter sees, some view numbers were unused and generated garbled files. This version of GALextract should fix both and also prints the view numbers that are unused.
-
Thanks. I'll give it a go tonight.
I've been meaning to post an update on where I got to with the GAL picture investigation. I'll hopefully find some time to do that tonight as well. There are a number of interesting differences when comparing the original KQ pictures from the Booter versions with the later AGI versions of the same pictures.
-
I have attached some comparison pictures between a GAL imported picture (i.e. imported into the PICEDIT branch I was working on) and the corresponding AGI picture from the AGI version of the game. I have done this for PICTURE 6 and PICTURE 23. The GAL picture in each case is not exactly as it would have appeared in the original KQ booter versions but rather what it looks like when converted to the equivalent AGI picture codes.
The visual screens look almost the same. In the case of PICTURE 6 at the top, there are only a few pixels different, where there is a white pixel in the GAL picture that shouldn't be white. Now this obviously isn't what it looked like in the original booter version of the game, so it suggests that the GAL line or fill algorithm is slightly different. When comparing the picture commands for the GAL vs AGI versions, the AGI version usually has additional fill commands to fill in these white pixels that shouldn't be there. This suggests that the pictures were converted to the AGI format and then touched up afterwards. You'll notice that they missed one pixel in the upper middle part of the picture though, as it is still white in the AGI version.
The visual screen for PICTURE 23 really does look identical. The GAL picture on the right is how it appears in my PICEDIT app after being imported, so the end result, at least as far as the visual screen goes, appears to be identical in this case.
Where things get very different though is in the priority screens. For starters, the most distant priority colour, i.e. the one at the back, is blue in the case of GAL but red in the case of AGI. The red, cyan and green priority colours in GAL are just normal priority band colours and don't appear to have special meaning.
You'll also notice that black is used for water in the GAL picture but cyan is used in AGI.
Another thing that is fairly obvious is that the priority band division must be different, since the same objects, e.g. the trees, log, rock, are using different priority colours despite being placed in exactly the same part of the screen. This isn't surprising, given that red, cyan and green are used as normal priority colours, so there are more colours to cover the screen.
The other big difference is that the GAL picture doesn't have any "block" control lines drawn. I have seen in some of the GAL pictures that they use the white colour as a block line, in the places where an AGI picture might use the black control line. This seems to be used quite rarely though, and it makes me think that the block control lines must be placed into the picture using a different mechanism, and not generally part of the picture itself. But, as I say, some pictures do use white for a block line, meaning that white must have that meaning in GAL, i.e. the same meaning as blank in AGI.
I think that covers all the obvious differences. It is due to these priority screen differences that a tool like PICEDIT or WinAGI can't really support importing a GAL picture. It could import the visual screen and get very close, but the imported priority screen would not be compatible with AGI v1/2/3. I wondered whether the priority colours could be changed on import, but I think that would get very tricky to get right, since the tool would be making guesses about whether the base of the object is at ground level or not. You'll notice from the PICTURE 23 example that in one case, there is an object that is light green in the GAL picture but split between two different colours in the AGI picture (light cyan and light red). This shows that when they were touching up the converted image for the AGI version of KQ1, they must have decided that they needed to change the priority colour partway up that object. Not sure why yet, but it does suggest a manual conversion of the priority screen rather than automated. Maybe they automated it to some degree, but as I say, it would be difficult to get right.
And the absence of the control lines would certainly be an issue as well.
-
I also played around with importing pictures from the ADL games, the importing involving converting the ADL picture codes to the relevant AGI ones. The first issue there was that the picture resolution is different. Those games were originally for the Apple II, so the width of the picture was 140 rather than 160. The height of the pictures appear to be 160 rather than 168. So after importing the picture into PICEDIT, it is slightly smaller than the available AGI picture area.
The second issue is that the fill tool works differently. ADL pictures support 22 "colours", where a lot of those colours are actually made up from alternating two of the real colours. This is a bit like some of the fills that the early 16 colour SCI games had. The available ADL colours are listed on page 18 and 19 of the following manual for the Tablet Graphics tool that Ken Williams wrote in 1980:
https://www.mocagh.org/sierra/tabletgraphics.pdf
And the same list of colours appears within one of the screens of "The Artist" tool that I mentioned earlier in this topic. "The Artist" appears to be a continuation of Ken's tool, with Warren Schwader taking over the programming.
So my import had to pick an AGI colour, one of the 16, that was closest to each of the 22. It doesn't really work, because some of the ADL pictures use different shades of certain colours that end up being the same colour in the import. It looks ugly to be honest, so I'm not certain it will be useful.
Unless someone wanted to get a head start on a project to port one of the ADL games to AGI. Don't think it would be Time Zone though, as that game allegedly has around 1400 pictures!! Not sure how we'd support that in an AGI game that is limited to 256.
-
So I might as well post my newest SYSDEFS and GAMEDEFS here...
-
Hmm. Donald Trivette is very explicit about control lines existing (which he calls skeleton lines):
The scenes are more than just static back grounds. For instance, if Sir Grahame staggers a bit and runs into a castle wall, he stops. How does the program know when the character hits something? There's a skeleton, an invisible structure, behind each picture. If you could see this skeleton, you'd notice lots of lines running all over the screen defining where Sir Grahame can and cannot walk. The lines were drawn into each room with the graphics tablet.
He then goes on to describe priorities.
-
Was that from the "Official Book of King's Quest"?
-
No, it's from the February 1985 COMPUTE! Magazine article that we discussed a few years back:
https://www.atarimagazines.com/compute/issue57/kings_quest.html
Interesting. Yeah, there obviously has to be control lines in there but I'm not sure where they are drawn. I haven't had much of a go looking for them yet.
-
I've had the chance to run GALdecompile on some Apple II images. It seems to be an odd mixture of old and new code. Load.pic and overlay.pic don't take any parameters (I'm guessing this is older than the PC version). There have been slight changes in the text, and numerous small code changes. The words.bin file has no sign of Greg, Hal or Arthur; all the word numbers are different. This means no 'greg' Easter egg, but the flamethrower Easter egg is present (which only got added to the AGI version for PC). The variable numbers will need to be redone.
Oh, Lance already did this. Never mind.
-
No worries ;D. To be honest, I didn't explore much more with the Apple II KQ1 other than using GAL decompiler to decompile some of the scripts. I did do quite a bit with the Apple II KQ2 though, including a whole feature branch of the jagi project that could view the various resources from it. That one is an AGI V1 game, so the PICTUREs are the same as AGI V2, but the logic scripts are different. The format of the LOGIC script is the same, but the opcode values for the commands are defined differently. This would be the same for the early PC versions of KQ2 as well, I would imagine. I think there are some threads in the forums where NewRisingSun also attached some tools for viewing AGIV1.
-
https://sciprogramming.com/community/index.php?topic=1695.msg10433#msg10433
-
I'm necroing this thread to say that GAL picture support has been added to ScummVM:
https://github.com/scummvm/scummvm/pull/6388
-
I would hve assumed that it already did.