TheGreatEscapeFacts.ref

;
; SkoolKit ref file for The Great Escape by Denton Designs.
;
; This disassembly copyright (c) David Thomas, 2012-2018. <dave@davespace.co.uk>
;

[Fact:unusedSupertiles:Unused super tiles]
There are two unused supertiles: $4F and $9A. The tiles are defined but not used in the map.

[Fact:alternatingSpeed:Game speed varies]
When our hero is outdoors the speed of the game can vary greatly depending on where he stands. Look at the rate at which the morale flag waves then take a single step. You will notice the flag waving faster or slower depending on where you started.

This is because the routine which copies the back-buffered game screen to the real screen has two modes: a fast mode where the bytes are copied directly and a slow mode where the pixels are rolled by a nibble before being written. Depending on where the hero is standing the screen buffer may not be aligned with regard to the screen and require use of the slow rolling routine.

Interior scenes in the game run far too fast so have a dedicated delay loop at #R$A095 to slow things down.

[Fact:unusedRooms:Unused rooms]
There are three unused room indices: 6, 26 and 27.

[Fact:unusedInteriorObjects:Unused interior objects]
There are three unused interior object indices: 21, 28, 39.

[Fact:neverUsesIX:The IX register is never used]
Nowhere does any routine in the game use the IX register. Of the two index registers it only uses IY.

[Fact:fullerJoystick:Unused Fuller joystick routine]
There is a Fuller joystick routine at $FEA3 / #R$FEA3 which is never used by the game.

The game supports keyboard, Kempston, Sinclair and Protek joystick interfaces. Once selected from the main menu the chosen keyboard or joystick routine is copied to $F075 and used from there. There is no way to return to the main menu, so the space occupied by the input routines is then reclaimed for the window buffer.

[Fact:randomness:Randomness]
With each call to #R$A035 the game increments a byte-sized counter at #R$A12F.  The game's main loop reads this counter and triggers events when the counter hits multiples of 64, including zero. In addition to waving the flag on the menu screen the main game uses the game counter for timing lock picking and wire cutting.

However this counter is *not* reset when the game is started. This means that the amount of time taken to choose the input device on the menu acts as a random seed into the behaviour of the game. So unless you start two games at *exactly* the same moment you will witness the hero waking up at inconsistent times and the supporting characters taking divergent routes through the game.

The game also uses pseudo-random values generated by the routine at #R$CB85. This isn't a particularly complicated routine: it just returns nibbles pulled from RAM at $9000..$90FF.

[Fact:deadGuys:Permanent Slumber]
Hut 1 - the highest and leftmost hut on the main map - has four beds, of which three are occupied by sleeping figures which - creepily - never appear to move.

Do these characters ever get out of bed? Well, there are no references to those bed objects in the #R$6B79 array which is used by #R$A289 and #R$A444 to alter the room data, so there's no way they can ever spawn.

Of the 26 characters in the game only six are prisoners. This seems a little low in comparison to the fifteen guards. We can posit that there were more prisoners planned - there's capacity for eleven of them plus the hero in the huts - but that speed or pathfinding congestion issues prevented the game being fully populated.