I don't understand what you mean by "wait period and execution of frame commands being parallel".
Starcraft is 100% linear. The only additional threads are created by external libraries.

I don't understand your question in EDIT2 either.

As you've said, there is a special behavior of a variable-- operator. I wonder how SC counts down milliseconds to have a delay between frames. If it's a call of a function, there might be the same behavior, so that instead of 42 milliseconds on fastest we get 43 and etc. But now as I think of it, because the number 42 is proven on practice everything should be okay.

Yeah I got it. So it takes the time to execute the current frame, and after that it waits frameRate milliseconds to execute the next frame again. Then I thought we don't really make the game run smoother if we execute triggers every 4th frame instead of every second for example, but it seems I was wrong here too.

Thanks. My questions are answered.

Starcraft uses GetTickCount(). You can only determine the number of milliseconds that have passed through system function calls unless you have inline ASM and are using some kind of non-standard coding.

Oh, so it's a system call. But... does it start to count the next 42 milliseconds from the time when frame commands start to execute, or from the moment when they finished execution?

EDIT:
In other words is the delay between frames equal to max{frameExecutionTime, frameRate} or frameExecutionTime+frameRate, where frameExectuionTime is time which required to execute all commands of a frame (triggers included if triggers are being executed) and frameRate equals to 42 on fastest.

Why would it be frameExecutionTime+frameRate? If that were the case then games with lag would be twice as bad.

(simplified as an example)


This is also how Starcraft reaches (or used to reach) 100% CPU, 100% of which is drawing objects to the screen repetitively.