This easter egg is present in script 805. In this easter egg, Gabriel
draws a doodle of Jane Jensen in the whiteboard, if the player uses the
operate action below the whiteboard's eraser. This easter egg looks for
a file named "buster" to be present, so that it is enabled. We always
report that this file exists, to unlock the easter egg.
Special thanks to sluicebox for his awesome work on discovering this
easter egg: https://www.benshoof.org/blog/gabriel-knight-1-easter-eggs
Inspecting the disassembly more closely and trying to fix the usecode for the
Crusader spider bombs (CRU_SPID::ordinal20), the parameter for this intrinsic
is not "force", but more like "move until blocked", and when it's false the
item should not move at all if there is a block.
The spider bomb usecode tries to move the bomb down every now and then to check
for a fall, but if it meant "force" then the bomb would go into the floor. It
would also never explode because it was always forced into the new position and
never fails.
The return value is whether the move completed.
Makes the signature more precise so that it's not accidentally applied
to the wrong place when a script already contains this patch.
Fixes incompatibility with NRS' SQ4 Update 1.3
These changes are currently pointless, since the affected function variants won't be called. The Japanese game versions for which they would be used are not supported in non-USE_RGBCOLOR builds. But the code should be correct nonetheless...
("drawing" in this case means the data conversion and transfer from the gfx layers to the screen buffer)
From my measuring experiments in the MSVC debugger this speeds up the drawing 2 - 3 times. Not sure about release builds, whether these profit even more.
--debuglevel=2 will show the call stack after each function call
--debuglevel=3 will show the current instruction
--debuglevel=5 will show the stack after each instruction
--debuglevel=9 will show the variables after each instruction
(partly revert fb8f1084)
There is no simple solution that would still leave the "butter smooth" scrolling for faster platforms intact. I have measured times between several code points to find any bottlenecks. My finding is that even single script opcodes may well take over 200ms to execute. And exceeding a singe 60 Hz tick happens way more often (which makes the scrolling fall behind and have to catch up, thus becoming a bit sloppy). So, for the "butter smooth" scrolling I'll probably implement a timer for the screen updates (which will then really behave much more like the interrupt handler of the original). But that's for a separate commit. This one is mostly about the bug ticket..
