They’re not really that weird on the face of it, but that depends on who’s looking.
The decompiler in SCI Companion is a work of art. You can tell because I didn’t write it. (I only fixed a thing or two.) But there are some things that it can’t figure out, and when that happens the function or method body is replaced with a raw asm block. For example, the copy protection in Laura Bow 2 – The Dagger of Amon Ra has loop in it that SCI Companion can’t hack.
It’s a bit much to take in but the important bits are as follows: this code block (rm18::init) has four discrete segments. The first isn’t shown here and sets up a few simple things. The second (code_0087) is a regular loop, where temp0 counts up from zero to eleven. When it hits twelve, the loop is broken and we go to section three, code_00ad. Section three is a weird loop. If you look at the check at the top we see this:
pushi #size pushi 0 lofsa tempList send 4 bnt code_0116
Which basically means that when (tempList size?) returns zero/is false, we skip to section four. At the bottom of the section, right before the label for code_0116, there’s the command that makes section three a loop; jmp code_00ad.
So that means that section three keeps repeating until tempList is out of items. Section two put a bunch of values in it, and section three then takes items out at random and puts them into goodList, effectively randomizing the order. The items, incidentally, are the tiles depicting the various Egyptian gods that the copy protection is all about, clones of egyptProp given increasing cel values. Section three positions them as they’re added to goodList. It’s a good routine, Brent.
The problem that trips up SCI Companion and makes it spit out the stuff in those two pictures is that it doesn’t recognize the second loop for what it is. Counting from one value to another by a given increment? Easy. Iterating over a collection? It can figure those out. But picking items from a bag until it’s empty? That’s not on the menu.
To make this decompile, then, we first need to break the loop by commenting out that last jmp command. A single ; suffices. Compile the script resource, then go back and re-decompile it. A conditional loop, of course, consists of a check and a jump. We removed the jump so now it’s just the check:
(method (init &tmp i theTile theX theY) (LoadMany rsVIEW 18) ; load the tiles (super init:) (gGame handsOn:) (gIconBar disable: 0 1 3 4 5 6 7) (goodList add:) (tempList add:) (= theX -32) (= theY 46) (= i 0) ; Instantiate twelve tiles, with increasing cel numbers. (while (< i 12) (tempList add: ((egyptProp new:) cel: i yourself:)) (++ i) ) ; This should be "(while (tempList size?)" but we removed the jump, remember? (if (tempList size?) ; Pick a tile number. (= i (Random 0 (- (tempList size?) 1))) ; Get the i-th tile. (= theTile (tempList at: i)) ; Set up the tile's position on the grid and add it to goodList. (goodList add: (theTile x: (= theX (+ theX 48)) y: theY yourself: ) ) ; Once we're halfway through, CRLF to the next row. (if (== (goodList size?) 6) (= theX -32) (= theY 111) ) ; Actually remove the tile from tempList so we won't pick it again. (tempList delete: theTile) ) ; Section four (gGame handsOff:) (self setScript: sInitEm) )
The cool part is that once we replace that if with a while and compile the script, the result is effectively the same as the original. Only some of the specific opcode choices are different. For example, the original uses the two-byte pushi 1 throughout (also 0 and 2), but SCI Companion’s script compiler prefers to use the one-byte push1 there. The same values are pushed regardless.
