Logo Pending

Save early, delete when you need

There’s one interesting tidbit missing here, which is how deletion (SCI1 and later) is implemented. Namely by manipulating the .DIR file in the script, and not – as any sane person would do – with a kernel call.

So wrote Iskovlun in a comment some time back. Let’s see exactly how insane it really is.

; First we open up the directory file.
; Confusing, I know, to call it a directory file. Perhaps
; "catalog" would be better considering a directory is
; already something else. And in SCI32, they did!
((= fd (File new:))
  name: (DeviceInfo diMAKESAVEDIRNAME @str (gGame name?))
  open: fCREATE
; The format of a save game directory is pretty straight-
; forward -- a word for the index, then the name, terminated
; with an $0A, repeat until done, end with $FFFF.
; (File write:) requires a pointer to the data it is to write,
; so we need to put values into variables, rather than just
; passing them immediately. Well, unless you have SCI11+ with
; the extra file kernel calls I nabbed from SCI32 and a matching
; File class, in which case you could just do (File writeByte:
; $0A) if you were so inclined!
(= ret $0A0A)
; Now we write the number and name of each saved game, EXCEPT
; for the one that was selected for deletion.
(for ((= i 0)) (< i numGames) ((++ i))
  (if (!= i selected)
    (fd write: @[nums i] 2)
    (fd writeString: @[names (* i COMMENTBUFF)])
    (fd write: @ret 1)
; Now we write the terminating $FFFF to finish the catalog
; I mean directory off.
(= ret -1)
  write: @ret 2
; Now that that's done, we can safely delete the actual
; save game file.
(DeviceInfo diMAKESAVEFILENAME (gGame name?) [nums selected])
(FileIO fiUNLINK @str)

I almost feel like doing the so-called sane thing and adding a DeleteGame kernel call to SCI11+.

[ ] Leave a Comment

VGA Versus VESA – A Followup

Back in the days, if you wanted square pixels in your games you had to either switch to 640×480 with only 16 colors or use Mode X, which offered 320×240 with all 256 colors but both of these stored their pixel data in those funky non-packed or non-linear formats.

Sure. Sure. With Mode X you could write a whole bunch of pixels at once. It’s a trade-off, and one that I’d rather not have to make. Give me linear frame buffers or give me death!

But what if there was a third option? Turns out on DOSBox’s approximation of the S3, mode 151h offers 320×240 pixels in 256 colors! Besides the need to switch memory windows to access the bottom 36-something lines, that’s as friendly to work with as anything! And if, unlike me, you write DOS games in 32 bits, even that shouldn’t be a problem!

Too bad whatever VirtualBox exposes on my system doesn’t include one of those — it has no 320×240 at all.

As a bonus for sticking with me for this tomfoolery, here’s DOSBox running a test of mine.

[ ] 2 Comments on VGA Versus VESA – A Followup


We’re all familiar here with the classic 320×200 pixels, 256 color screen mode popularized by the VGA video card, colloquially known as Mode 13h. Most old DOS games from before a particular point in time used it. But what if you want or need bigger? Or more colors? Enter the Super VGA cards with their extended VESA modes.

These VESA modes number 100h and higher, but which exactly are available and what their specs are depends on your exact hardware. As such you can’t rightly assume a certain mode is available and will be that particular resolution and color depth. What you’re supposed to do is ask the system what VESA video modes are available, walk the list to see if you find the one you need, and note its number.

All I have is a copy of DOSBox and a copy of VirtualBox, and of vesachk.exe, available here if you want to try it out yourself. This application gives you that list. Now, the two systems yield vastly different results, mirroring differences in video hardware. DOSBox for example emulates some form of S3 card.

I’ve noticed that when an SCI32 game is made for low-res it runs in plain ol’ Mode 13h, but if it’s meant for higher it’ll use Mode 101h. That’s one of the few in the list that DOSBox and VBox agree on — it has 640×480 resolution at 8 bits per pixel, packed, starting at 0xA0000000.

On the one hand, a regular old 16-bit DOS application wouldn’t be able to address all 307,200 pixels at once the way you can in mode 13h. On the other, a 32-bit application would have direct access to the full linear frame buffer no matter its size. A 16-bit application would need trickery to reach any pixel beyond a certain point, setting the window registers to basically shift the next part of video memory into that same 64 kb block.

This is why SCI32, when switching to mode 13h, just does so:

void Vga::Set320x200()
	union REGS reg;
	reg.w.ax = 0x0013;
	int386(0x10, &reg, &reg);
	SetVideoMode(1);	// clear all video memory
	SetVideoMode(0);	// back to Normal Mode 13
	lenx = 320;
	leny = 200;

But when it switches to mode 101h, it jumps through several hoops. First it checks if VESA is supported at all, then it switches to mode 101h, and then it does some more checks to see if things are as they should be, bailing out if they’re not.

And that’s all good.

But what if you were to find a VESA video mode that was 320×200 with 256 colors? Is there such a thing? A redundancy with mode 13h? As a matter of fact, there is! On the S3 emulated by DOSBox, it’s VESA mode 150h, and once you switch to it things work exactly the same as in mode 13h, except the memory access timing or whatever is different.

; VGA mode 13
mov ah, 0x00
mov al, 0x13
int 0x10
; VESA mode 150h
mov ax, 4F02h
mov bx, 150h
int 10h

But on whatever VBox has to offer, which is a vastly longer list with about a hundred more modes, this could be 146h, 346h, 546h, or 746h. And that’s why you really should ask the system about it!

But SCI32 basically assumes 101h is what it needs to be and presumably the folks at Sierra tested a bunch of contemporary cards and found this to be true.

Fun fact: SCI16 has all its video driver code in files like VGA320.DRV, but SCI32’s VGA.DRV is practically empty. It’s technically a valid SCI driver file but it’s basically just a header. Same with its VESA.DRV. All their code is in the interpreter itself, much like the mouse driver. It’s only there so the installer can offer it and the interpreter can determine which was chosen. And even then, the interpreter for later high-res only games like Gabriel Knight 2 will happily ignore all that.

[ , ] Leave a Comment

Go home, Twitter

This is seriously something that happened earlier today on Twitter. I asked what to blog about, since my last post here was in May, and I could see I got a reply, but not what that reply was.

There was no “unavailable” placeholder or anything, no “potentially offensive” click barrier, just a non-zero counter. Logging out, switching to private mode, no difference. Then @Purrpleneko1 replied, I went to their profile to check their replies, and found what was being hidden from me: a perfectly good suggestion that unfortunately fell outside of my interests and expertise — I’m more into software than hardware. Why was this being hidden from me? I could see their other replies just fine!

So yeah. Go home, Twitter. You’re drunk on algorithms.

*sips cuppasoup*

[ , ] Leave a Comment

On Palettes

Recently, a friend who shall remain anonymous said to me he wanted to draw some pixel art and would set Aseprite to use the NES color palette because it didn’t have a SNES one.

I was quite amused by this because there is no such thing. The NES, SNES, and IBM PC-Compatible with a VGA card all have one thing in common in that they have program-specifiable palettes. On the NES, you can pick some 28 colors by my count from a fixed master palette:

This isn’t even necessarily correct because of how these colors are generated but whatever. On the SNES though? You have a 256-color palette space, split in 16 rows of 16 colors each. The first of each row is considered transparent (leaving out mode-specific stuff for simplicity) and the final background color behind all the layers is the top-left one. Also, the bottom half is reserved for sprites.

But what do you assign to them? 256 of these bad boys:

Each entry is a 15-bit RGB value, ignoring the 16th. In other words, you have 32.768 different possible colors to pick and choose roughly 256 from. The palettes in Aseprite, or really any graphics editor that has an “indexed” mode, only go up to 256 entries.

On the venerable VGA graphics card so widely used in IBM PC-compatibles and still emulated by even the latest powerhouses, you get as many colors but this time you can use all of them at once. And they’re not even 15-bit but a whopping 18, for an impressive 262.144 different shades to pick from:

Still, you’d actually have more of a point speaking of “the” VGA palette. When a SNES boots up there’s no telling what’s in the palette RAM, but when a PC boots up, you know the VGA palette will default to this:

For both SNES and PC though, you’d be better off speaking of specific applications, games, or scenes in games. For example, here’s the default from DeluxePaint:

So just like how you can refer to “the” VGA palette, you can have “the” DeluxePaint palette.

Nicole remarked on Twitter that I missed an opportunity to mock the Genesis. Here ya go, ma’am.

Nine bits, 512 possible colors, 64 at once in memory but only 61 effectively because the first one’s transparent like on the SNES. Here’s the SNES again for easy comparison:

Leave a Comment

Menu Slowdown Mystery

Yesterday I had the idea to make a small “game” demonstrating various SCI11+ features, and instead of a main menu screen full of buttons I thought I’d use a proper menu bar. The kind you’d see in the old SCI0 games with the text parser and the low-resolution version of Leisure Suit Larry 6. Which incidentally is the only SCI11 game to have such a menu bar. The high-res SCI2 version’s menu bar is implemented entirely in script but the other one is 100% the same as in SCI0. If you were to copy the interpreter from any other SCI11 game over to LSL6 and run it you’d get an error saying AddMenu is not supported.

If you were to build your own SCI11, you’d find there are four targets; with the built-in debugger, with menu bar support, both, or neither. Most SCI11 games come with a “neither”, except for LSL6.

But this post’s title mentions slowdown. Why?

I defined two menu items, File and Topic. No Sierra logo menu here, not this time. One has About and Quit, the other lists the various features. As you do. But somehow when opening the second menu things would slow down just before it got to the last item, about the support for SCI32-style no-lookup font and color change control codes.

I thought maybe I’d messed something up when I cleaned up the source code, or when I added the thing where the menu bar is drawn in the same colors as the status line.

So I built an SCI11+ with all switchable hacks turned off. No dice, the menu was just black and white now but still slow. So that ruled out the extra features.

A “base” build that’s missing all new features? Nope.

Copy the terp from LSL6 and run that. Same deal so it’s not the cleanup either.

So I tried reorganizing the menu items. And I saw my mistake.

I had used a | to separate the Unicode and SCI32 control code items where it should’ve been :. For added insult, that’s the text formatting control code.

I wonder if AddMenu would work better as a variadic function 🤔

[ ] Leave a Comment

Perspective is a tricky thing

This topic was suggested, more or less, by Phil Fortier.

What do these screenshots from DoomLeisure Suit Larry 3, and Secret of Monkey Island have in common?

Their perspective. Every single wall is a straight line. I put Doom there to show it’s not just adventure games, and Monkey Island because the arcs end in straight lines, but otherwise they all have the same perspective. Don’t believe your eyes? Here, let me spell it out for you:

This is one-point perspective, where lines converge to a single point.

Here’s a Youtube video I picked out at random from my search results while I ensured I wasn’t pulling crap out of my ass. You’ll notice a hallway like that could do well as an adventure game background.

They’re also a pain in the ass when you render your game’s backgrounds with a program that doesn’t do 1PP, like I do. I mean, I could use this copy of 3D Studio Max that I have collecting dust over here, but all my prefabs are in Daz Studio? So I gotta fake it somehow. Very carefully align the camera so the walls point straight up.

In this old version of Alhor’s Garage in The Dating Pool, the walls are not straight. So I went back and tweaked the camera along with a few other details.

I feel much better about this version. But for other scenes, to get enough floor space in view, I have to pull back the camera drastically. Normally you’d increase the floor space by angling the point of view down. I’m sure you can agree that in Chairman Kenneth’s office, the camera is pretty far up. If I tried to reproduce that image in Daz, I’d get diagonal walls. So how do you fix that?

There’s practically no floor space here! If I used this, the main character would have a line to move along, and if other characters were to try and pass there’d be almost no space to show it. Moving the camera up mostly increases the ceiling space…

And of course you could fake it by tilting the walls back to compensate.

Or you can just say fuck it and deem the perspective distortion negligible after downsampling.


I seriously wish I had the means to acquire some nicely painted backgrounds, even after years of demos with rendered ones.

[ , , , , , ] Leave a Comment

File functions in SCI11 and SCI2 compared

Not to be confused with the other one.

In SCI11, we get the following FileIO functions:

(FileIO fileOpen name mode) Opens file name with the given mode and returns a handle.
(FileIO fileClose hnd) Closes the given file handle.
(FileIO fileRead hnd ptr size) Reads size bytes to the given address.
(FileIO fileWrite hnd ptr size) Writes size bytes from the given address.
(FileIO fileUnlink name) Deletes the given file.
(FileIO fileFGets ptr size hnd) Reads a string of up to size bytes to the given address.
(FileIO fileFPuts hnd ptr) Writes a string from the given address.
(FileIO fileSeek hnd where from) Seeks to the given location.
(FileIO fileFindFirst pattern ptr attr) Finds the first file matching the given pattern and copies its name to the given address.
(FileIO fileExists name) Checks if the given file exists.
(FileIO fileRename from to) Renames the given file.
(FileIO fileCopy from to buffer len)

Hmm. So, only null-terminated strings and arbitrary data blocks, huh? Surely you can do better? I wouldn’t want to have to do this every time I wanted to simply save a single 16-bit variable:

(= val gRating)
(FileIO fileWrite hnd @val 2)

Actual code from an earlier build of The Dating Pool, in case the name of the global didn’t tip you off.

Now, SCI2 added a whole bunch of extra options to the above:

(FileIO fileReadByte hnd) Simply reads and returns a single byte.
(FileIO fileWriteByte hnd val) Simply writes a single byte.
(FileIO fileReadWord hnd) Reads a single 16-bit word.
(FileIO fileWriteWord hnd val) Writes a single word.
(FileIO fileCheckFreeSpace ???) I’m not sure how this one works yet.
(FileIO fileGetCWD ptr) Was a separate call in SCI16.
(FileIO fileValidPath ptr) Checks if the given string is a valid path, I guess.

Wow. So what I did after learning these existed and looking back at the long-since scrapped persistent settings in The Dating Pool was, I added some of these to SCI11+. Specifically, the first four.

It was that or switch to using the File class exclusively and add wrapper functions for simple value reading and writing to it. But I can honestly say The Dating Pool doesn’t use File at all.

[ ] Leave a Comment

Linguistics, my weakness!

This topic was suggested by Phil Fortier.

I don’t normally bother with SCI0 except to gush over the artwork, but what can you do? Phil suggested I explain the parser, so I’ll try to explain the goddamn parser.

Let’s look at something more basic first. In AGI, there was little to no sense of grammar so your input had to be more rigid. This does make it simpler to explain and thus get something to work up from.

We start by defining a dictionary of words, mapping groups of synonyms to number values:

0 (a whole bunch of “filler” words)
1 anyword
2 check, examine, look, see
3 swim, swimming, wade, wading
4 enter, go
5 acquire, get, pick, pluck, rob, swipe, take
6 climb, scale
21 building, castle, cottage, fort, house, leanto, palace, tower
22 door, doors
23 dragon

The “anyword” entry is literally that. We’ll get back to that.

In the script code, system scripts and the current room’s script alike can at any point check to see if you said something:

if (said("check", "room"))
  print("You are standing outside a castle surrounded by an alligator filled moat.");
if (said("pet", "alligator"))
  print("What!  Are you crazy?");

It should be noted that the way it’s presented here is but an illusion, granted us by the decompiler. The said function’s parameters are actually a straight series of numbers, referencing the dictionary. This way it can match both >CHECK ROOM and >LOOK ROOM. But what if you typed >LOOK AT ROOM? There’s no check for that.

When the AGI engine parses your input, it goes through it word for word and tries to match everything to the dictionary. It first sees look, matching that to entry 2 and remembering it as such. It then sees at which is one of the “filler” words and skips it. The last word found is room, which is matched to 137. So now the “said buffer” as it were contains 2 137 and the said function can compare its parameters against it. Two special meta-words, anyword and rol, are available to match literally anything and to ignore the rest of the buffer if any.

If you were to tell King’s Quest 1 to >LOOK AT THE CROCODILES it’d tell you it doesn’t understand “crocodiles”. Those aren’t in the dictionary so there’s nothing to match them against. Those are alligators in the moat.

SCI is a bit more involved than that, but you should have a good basis to work from now.

In SCI0, the dictionary is extended to include grammatical types for each entry. For example, the first item might be marked “article”. Indeed, it’s a group of words like “the”, “a”, “an’, and for our Spanish players “el”, “la”, and “los”. Then you might have a numbered entry “give, offer” marked as being a verb. Words like “lock” would be marked as being both verbs and nouns.

All that so a very nifty state machine can determine what you want to do, what you want to do it to, and what you want to do it with, among other phrases.

Every time you enter a command, a said event is fired. Through the usual systems, this event is passed down to the current room’s handleEvent method, which can tell it’s a said event. So now we know that something was said in the first place, but what exactly? At this point things turn a little AGI-like again.

(switch (pEvent type?)
    ((Said 'close/door')
      (Print "Check again! It IS closed.")
    ((Said 'look>')
        ((Said '<in,through/craft,chute,pane[<escape]')
          (Print "This task is impossible since the door is sealed from the inside.")
        ((Said '/pane')
          (Print "The window is clear enough to reveal the blackness inside.")
        ((Said '/door,door')
          (Print "The solidly built door looks to be locked in place.")
        ((Said '/nozzle')
          (Print "The pod's thrusters are very small. They have been cold for a long time.")
        ((Said '/craft,chute[<escape]')
          (Print "This is the escape pod which safely whisked you away from Vohaul's burning asteroid fortress.")
        ((Said '[<at,around,in][/area,!*]')
          (Print "You are standing in a debris-cluttered junk bay.")
    ; ...

First of all, don’t be fooled. Those strings have single quotes around them for a reason. They too are stored as numbers, and so are the other characters. For example, 'close/door' is 1157, 242, 2110. The actual order of things might be a little off to see though. Obviously the > at the end of the look clause means that the rest of the sentence is to be considered separately. That’s all good. But the / does not mean to continue from here, since 'close/door' has it right there in the middle. No, the / means that the next word is to be the direct object. The thing you want to close. The first word is the verb, considering the imperative nature of these games. If there’s a second /, that’ll be the indirect object, but we don’t have one here. The < in '/craft,chute[<escape]' modifies the object it succeeds, while the [] around it make it optional. Thus, 'look/craft,chute[<escape]' matches >LOOK CRAFT>LOOK AT ESCAPE SHUTTLE, and various other ways to phrase it. Oddly, even though the description calls it an escape pod, “pod” is not a valid synonym. Oh well.

But how does the engine know what the verb and objects are? Well, it figures that out via that state machine I mentioned. When you start to enter a command in SCI0, the User script handles showing you the command window and such, then passes what you entered to the Parse kernel command, hereafter “the parser”.

One particular resource lists all the possible types of phrase, such as “shoot”, “talk to dwarf”, or “hit redneck with plank”, but stored in the sense that a verb phrase can be just a verb, a verb followed by a direct object, or a verb followed by a direct object and an indirect object. The parser then tries to find the verb phrase that best fits the input, filling in placeholders until done.

For example, say we entered >LOOK AT HOBO. The parser will try to find the best-fitting verb phrase, starting with a bare core verb. In turn, it will consider the various core verb structures listed in the grammar, eventually finding a bare “just a verb”, which “look” matches, but there might still be a better match. The very next option is indeed “a verb followed by a position”, which matches “look” and “at” in that order. No other core verb structures match, so we can write that down and continue with the rest of our verb phrase. Which is now done.

But again, there might be a verb phrase that better matches our input and we do have more words to consider — we’ve only looked at “look at”, not the whole “look at hobo”!

The next verb phrase is “a core verb followed by a noun phrase.” Hmm. Again, we look through the various grammatical definitions of a “noun phrase”. The first one is “an article followed by a core noun.” Well, we didn’t say to look at the hobo, so that one’s out. The next one wants a hobo with an article and an adjective, then a hobo with only an adjective… but we do eventually get a noun phrase that’s just a core noun, and in turn that core noun is reduced to just the single word “hobo”.

So now we know that our verb is “look” and our direct object is “hobo”. The parser can now generate something from this information that Said can compare against, keeping it in mind until the event is eventually claimed, be it by a successful Said match or the game giving up on your strange input.

[ , ] Leave a Comment

Save early, save… how?

This topic was suggested by Phil Fortier.

I can’t speak for the engines that came before, but saving and restoring a game in SCI11 is remarkably straightforward. The whole thing’s basically a dump of heap memory with some extra bits.

The hell is heap memory you might ask. Well, there’s two kinds of memory available to the actual game, provided by the engine, and those are heap and hunk. Every script whose objects or classes are used at a given time is loaded into heap space, most every other kind of resource goes into hunk space. In SCI11 specifically, scripts are split up into two parts, one with the actual code that goes in hunk space, and one with object definitions, local variables, and stuff like inline strings that goes on the heap. Correct me if I’m wrong on that one, Phil, cos I’m a little fuzzy on the details. (Update: I was.)


When you save the game, the size of the heap and variables are written first, followed by the game’s version string. This part is why you can’t mix and match saved games between different versions of the same game. Then, since events are objects and thus in heap space, all pending key presses are flushed out. The engine source code explains this is to prevent stuff like re-restoring a just-restored game by having an F7 press in the buffer. Then all the unused space in the heap is zeroed out.

There’s a good reason for that. It’s because when the actual contents of the heap are saved, as one big blob, it’s compressed. Imploded, to be precise, almost but not entirely unlike how you’d make a ZIP file. And if you zero out the bits you don’t even use, it’ll compress much tighter. So a whole bunch of variables that are all packed together at a known location and the heap space are imploded and saved.

Then the plubus and grumbo are shaved away. Next, the state for any PalVary effects is saved, also in an imploded form. That there is any state to save at all is one of those variables I mentioned earlier.

The saved game’s file is closed, and the catalog file is updated. That being the ___SG.DIR file, which simply lists all the saved games’ names. The actual saves are those numbered ones, ___SG.000 and on.

Fun fact: the heap is about 64 kilobytes in size. Compression all but eliminates the unused, zeroed out parts. That leaves you with relatively small save game files. For example, this Dating Pool save is only 6203 bytes. But my unfinished shit is hardly representative… one of my Police Quest 3 games is 22.9 kilobytes.


Restoring a game starts out basically like the exact opposite of saving, exploding the variables and heap blob. Since all other resources are in hunk space, these are all unloaded at this point. Yeah, not a typo, I’m talking about the pictures and sounds and such that were already there. The hunk is cleared so that the stuff from the saved game can go there, obviously.

Throughout their lifetime, object properties and local variable values can and will change, of course (I’ll mention real quick that global variables are just the locals for script zero, which is never disposed of). Since those things are part of the heap, object and variable state is restored free of charge — all you really need to do manually is to get the code back. Given a list of supposedly-loaded scripts that should go in hunk space, again one of those variables, the restore routine can now iterate that list and repopulate the hunk.

At this point, PalVary state is handled if needed, the video mode is switched between Mode 13h and Mode X if it was different, and the PMachine is restarted. It knows we just restored a game, so the freshly-restarted PMachine knows to call the replay method instead of play. From that point, given a heap-restored state, the game can redraw its background at the time and enter the same endless doit loop as it would at the end of play. Any sounds, pictures, or views on the heap by now will have their resources loaded to hunk space as they are used.


Oh, didn’t expect that one! There’s this tricky pair of commands you can use in C, setjmp and longjmp, that to quote Wikipedia “provide control flow that deviates from the usual subroutine call and return sequence.” Right before the PMachine is spun up at the end of engine initialization, a sort of snapshot is taken to right that moment, consisting of all important CPU registers, including the one that determines where the next command will be. The SaveGame and RestartGame kernel calls use this to jump back in time and enter an all new PMachine loop. But what does restarting do exactly?

First, it sets the restart flag and disables PalVary. Jeez, does that subsystem start sounding hacky to anyone else or is that just me? Then it unloads every resource and resets the heap to one big block marked “free”. I didn’t say it zeroed out that block, because it doesn’t. Anything marked free is zeroed out while saving.

And the first thing the PMachine routine does? Get a handle on script 0, export 0 — the main game class. The last thing is to invoke its play or replay method, and since either of these methods end in a doit loop that doesn’t stop until gQuit is true, that invocation won’t return until then.

If C++ didn’t give me a headache, I’d look into how SCI32 may or may not be different from this. I know it has a bigger heap space, considering the whopping 117 kilobytes for a single save game from Love For Sail, but it’s the methodology that matters, right?

I suppose I owe you an answer to that question about the twenty game limit, don’t I? Well, I have a catalog file here listing about twenty-four so let’s see w–

[ ] 5 Comments on Save early, save… how?