Okay, this is very simple but confuses me.
Let's say I warp in a map and I want to set the volume gradually from 0 to 100 in 1 second.

I don't want to make a loop with showpage and render; I want to be able to do other things at the same time.
So I make a function:

void turnMusicOn()
{
   if (GetSongVolume() < 100)
   {
      SetSongVolume(GetSongVolume() + 1);
   }
}

Then:

HookTimer("turnMusicOn");

So far so good.
Now when the volume gets to 100, I want to stop hook timer, so:

void turnMusicOn()
{
   if (GetSongVolume() < 100)
   {
      SetSongVolume(GetSongVolume() + 1);
   }
   else
   {
      HookTimer("");
   }
}

But that crashes the game. I believe this is because you cannot delete the HookTimer from inside itself?

Then how do I know that it has finished outside of the function so that I can delete it from the maps .vc code?
Or do I use a HookRetrace? ;)

If I leave it there, each time I lower the volume manually it will get back up right away.

Thanks!
Eric

But that would force me to make a loop in the main program and wait until it finishes instead of letting it finish on its own :/

(Man, I really need to improve how code renders on this site...)

If I can say something, it will be that you shouldn't use HookTimer.

Why? Basically, the engine runs in one thread, and HookTimer runs in another thread. The HookTimer thread calls a function in the interpreter, and meanwhile, the engine itself (and your regular VC/Lua code) can also be trying to use the interpreter. It's basically a giant race condition waiting to happen, and it's a miracle that it even works some of the time.

Don't think of this race condition as just being the code you see in your main system code and in your HookTimer as being run at the same time. Look at this as the C++ code implementing the global interpreter for VC or Lua is being run in two threads at once, and the execution is being interleaved unpredictably. And of course, there is still also a giant potential resource contention for VC variables themselves, and for any global built-ins inside the engine. There are a million ways this can blow up or give invalid results.

If you must have a time-sensitive event trigger, what you should do instead, is add a retrace layer, and use HookRetrace. Use the systemtime variable to check the timer yourself.

Eventually, I may end up fixing HookTimer to be like HookRetrace, in that it's run on render, but no requirement on there being a layer, and the hook will be called as many times as frames were missed. Effectively giving around 100 updates per second still, just now without the ability for things to crash.

But until then, use HookRetrace or your own game loop, and use the timer variables. HookTimer is baaaad.

Yep, the rest of the hook functions are okay. HookTimer's the only one you have to really watch out for.

Checking that 1/100s has passed isn't terribly intensive. it's a quick variable comparison. If it hasn't, you won't be doing anything else during that pass of the loop, so it'll go very quickly.

If it has passed, then your normal loop code will execute.

Whoa, both cores? Verge should only ever tie up one whole core (and it basically does all the time, since it runs as fast as it possibly can).

Really, V3 could probably benefit greatly from someone taking a look at this and figuring out how to make it play more nicely with multi-tasking. Anyone a bad enough dude to want to do this?

I've already explained why HookTimer is a bad idea, and no other hooks have these problems. It is perfectly safe to unhook a retrace event from within the retrace event. And if you are mixing rendering and timing in a single retrace loop, you can do several things to toggle updates.

You could use a simple variable that toggles updates or you could use a string that points to the event to update, and call the event.

Verge shouldn't be using more than one core, and isn't on my Intel i5 750 quad core. If you're worried about CPU usage, basically check if any time has passed from the current frame. Otherwise sleep for a short interval using Sleep(), which will essentially yield the game's process to other processes running on your OS for at least the amount of time specified.

An example:

int lastFrame = 0;
int updateEnabled = 0;
void Retrace()
{
    int i, t;
    // ...
    // If we should update, then do some sort of processing.
    if(updateEnabled)
    {
        // Catch up on any time missed since the last updated frame.
        if(lastFrame < systemtime)
        {
            // Freeze a copy of the timer, so it doesn't change
            // any further while we're updating.
            t = systemtime;
            for(i = 0; i < t; i++)
            {
                UpdateGame();
            }
            lastFrame = t;
        }
        else
        {
            // Let the CPU rest a bit, no updates to catch up on yet.
            Sleep(10);
        }
    }
    // ...
}

This sort of logic works well, trust me. I have a few written games that actually have consistently timed loops. I usually take it one step further, make a frame throttler which has a max frame delta to prevent massive catch-up of lost frames in extreme cases. Instead it slows down slightly when behind, but this means smooth catchup rather than unpredictable skipping. This is generally good, and my low-end 1.6ghz netbook rarely falls that far behind.

It's more important to limit the CPUs that are running faster than the game was designed for (a strict fixed rate of 100 updates / second). Faster computers should likely use this time to sleep, so the end-user can multi-task better. It is important to let slower machines catch up, but it might be good to restrict how many frames can be caught up on, because over a certain amount, and you miss a noticeable amount of frames.

For networking, slowdown like that is unacceptable, and you'd want to sacrifice frames for consistent update timing. But on a regular offline kind of game, it's generally better to give the sense of smooth animation, and let the machine balance itself out. This is because usually time lag is a very temporary symptom I've found, and it resolves better if you don't sacrifice the visible frame rate excessively to accomplish catch-up.

A few frames, like maybe 3 or 4, but not much more. Anyways.

I probably shouldn't braindump like this at like 2 AM.

Hopefully this is of some use, and you can figure out something that works for you which is not HookTimer.