Yesterday I had the idea to make a small “game” demonstrating various SCI11+ features, and instead of a main menu screen full of buttons I thought I’d use a proper menu bar. The kind you’d see in the old SCI0 games with the text parser and the low-resolution version of Leisure Suit Larry 6. Which incidentally is the only SCI11 game to have such a menu bar. The high-res SCI2 version’s menu bar is implemented entirely in script but the other one is 100% the same as in SCI0. If you were to copy the interpreter from any other SCI11 game over to LSL6 and run it you’d get an error saying AddMenu is not supported.
If you were to build your own SCI11, you’d find there are four targets; with the built-in debugger, with menu bar support, both, or neither. Most SCI11 games come with a “neither”, except for LSL6.
But this post’s title mentions slowdown. Why?
I defined two menu items, File and Topic. No Sierra logo menu here, not this time. One has About and Quit, the other lists the various features. As you do. But somehow when opening the second menu things would slow down just before it got to the last item, about the support for SCI32-style no-lookup font and color change control codes.
I thought maybe I’d messed something up when I cleaned up the source code, or when I added the thing where the menu bar is drawn in the same colors as the status line.
So I built an SCI11+ with all switchable hacks turned off. No dice, the menu was just black and white now but still slow. So that ruled out the extra features.
A “base” build that’s missing all new features? Nope.
Copy the terp from LSL6 and run that. Same deal so it’s not the cleanup either.
So I tried reorganizing the menu items. And I saw my mistake.
I had used a | to separate the Unicode and SCI32 control code items where it should’ve been :. For added insult, that’s the text formatting control code.
I wonder if AddMenu would work better as a variadic function 🤔
