Sounds great, that must mean you plan on keeping SCI around for some time!
This whole discussion gave me a chuckle. These are issues that ScummVM and FreeSCI before it have struggled with. ScummVM performs strict bounds checking on stack reads and writes and requires workarounds for anything sketchy. The bounds checking stems from a rewrite of the PMachine in FreeSCI which we used to call Glutton (the original being rather more true to the Sierra implementation) which Christoph Reichenbach, original author of FreeSCI, implemented for student credit. He's now a university professor at a location relatively close to me; maybe I should catch up sometime.
From a software engineering perspective, these are bugs in SCI games even though they sometimes show no symptoms in original SCI due to its design. In the FreeSCI days we would have considered this out of scope and let the games crash, but ScummVM contains a workaround system (several, in fact) with much time spent on patching each individual bug. We have also had one here at sciprogramming, that seemed to stem from some manually entered code with a typo in it (remember that, Kawa?
).
SCI32 handles are far more robust, but even SCI32 can have subtle memory-related bugs (in QfG4, a plane id is sometimes NULL and it works - I worked on that bug over Christmas in 2018).
Show Posts