Yeah, I meant in Roodylib, since it has a HiddenPause routine for "press a key" type stuff (although it's based on some Future Boy! code so it shows up in spots there, too).

[quote="Roody_Yogurt"]It's used as a fancy cursor-hider during "press a key" type things.[/quote]
OK, that makes sense. I forgot about the blinking cursor hack in Hugor.


[quote]Honestly, I was unsure how much processing power such a trick would use up. If it's really drastic, I could change it so the cursor goes to the status window (which should be hidden in Hugor, right? even though it'd still show in the old official 'terp).[/quote]
I assume you mean RoodyLib. No, I think keeping it as-is is a good idea. The CPU load can be reduced in Hugor itself, as right now it does some unnecessary screen repaints that I can cut down on. Since there's no output from the game during the delay/getkey loop, getting rid of the repaints should reduce the CPU load.

It's used as a fancy cursor-hider during "press a key" type things. Honestly, I was unsure how much processing power such a trick would use up. If it's really drastic, I could change it so the cursor goes to the status window (which should be hidden in Hugor, right? even though it'd still show in the old official 'terp).

while not key
{
    system(32)
    key = system(11)
}

I recently noticed that almost every game seems to eat up CPU cycles when just waiting for a key press after showing a "more" prompt. They seem to do the following:

[code]
while not key
{
system(32)
key = system(11)
}[/code]

I'm wondering what the reasoning is. I would have expected a "pause" statement instead of generating CPU load on something that should be a simple wait operation?