Do triggers still only run at 16 FPS?

[AionCannonzSC2]

Is the shortest time interval in-game still 0.0625?

 

[mrzwach]

No, the shortest time interval in-game is 0.03125 (0.0 gametime seconds, it rounds up to 1/32nd of a second).

 

[cookies4you]

How can you make it .03125 then? I still wanted to know if it was only .0625 also.

 

[mrzwach]

You use a duration of length 0.0 seconds. It becomes 0.03125.

 

[cookies4you]

cool. ill try that.

 

[Dr Super Good]

Actually... Time is realitive.

Using game time you can achieve 1/32 of a second because the game runs on fastest by default and as such everything is at twice the speed of normal.
Using real time it will be 1/16 of a second, this is because it is the same delay as game time but is not altered by game speed.

 

[FelFox]

Actually... Time is realitive.

Using game time you can achieve 1/32 of a second because the game runs on fastest by default and as such everything is at twice the speed of normal.
Using real time it will be 1/16 of a second, this is because it is the same delay as game time but is not altered by game speed.

To my knowledge, faster is 40% faster than normal.
Anyway, Mrzwach is correct. A wait of 0 will time out for 1/32 of a second, and this is the minimum possible interval.
However, any events firing will snap to a grid with 1/16 interval. Timers will also do this.

 

[Itachi009]

Is the shortest time interval in-game still 0.0625?

this depends on your os and fps rate too !

on windows for example the accuracy of the default timer of nearly every programming language (java, C#, C++...) is 1/18 seconds, if you use the gametime related timer inside starcraft 2 i think it will be accurate to your fps rate, since every gameloop just do: update, draw, update, draw, update, draw...

 

[Dr Super Good]

Itachi009, incorrect. All PC processors have a nanosecond timer which although not totally accurate servers to allow benchmarking of code, I can confirm that this is in java and python and probably also C/++. Additionally games usually have more than 1 thread now and with DX10 cards it is possible to have multiple threads creating graphics at the same time (or quing instructions to be sent via buss). Further more game time via main loop is horriably inaccurate and SC2 definatly does not use it outside of the game engine. We all know how SC2 has no framerate cap on certain scenes and as such could obtain 500+ FPS which would make everything seem speeded up thus the overall flow of the game is syncronized by a proper timer. Additionally this points towards there being a separate graphic thread whos purpose is just to instruct the creation of the next scene so any virticle sync cap is ignored completly.

You can also run SC2 at any frame rate again throwing that idea out the window as it would then not be syncrnous for multiplayer so cause people to drop almost instantly.

Game loops might be what good old sega genisis or nes or SC1 used, but with or 4-6 processors and 100s of shaders it is a pretty usless design. Ultimatly there will be the basic idea of a loop inorder to keep the program going but the loop might do nothing more than set up and direct threads to keep the game in sync. I know for certain SC2 was designed for 2 main threads eating up most of a processor each although it does have other minor threads (1-2% of a processor) which handle inturupts, input and background tasks.

Oh yes, I forogt to mention that the clock generator circuit used to keep your processor syncronized and drive it is pretty accurate (your processor clock rate varies minimally in opperation) and as such you could even use it to get a pretty accurate timing.

 

[Dark.Revenant]

The SC2 trigger timer is probably a technical limit imposed by some performance optimization. After all, to achieve 1/64 timing (64FPS, which is enough for any map, ever), the event timer would have to be quadrupled in speed. It would lose a little bit of stability and be a LOT harder on the processor, plus would generate more network traffic inherently. So the trade-off is we get faster code execution and handling but we lose the 60fps step timing that we enjoyed in WC3.

On a related note, are waits accurate now? I'd imagine they are, since everything is clamped to 1/16 (or 1/32, in some cases) second intervals.

 

[Itachi009]

Itachi009, incorrect. All PC processors have a nanosecond timer which although not totally accurate servers to allow benchmarking of code, I can confirm that this is in java and python and probably also C/++. Additionally games usually have more than 1 thread now and with DX10 cards it is possible to have multiple threads creating graphics at the same time (or quing instructions to be sent via buss). Further more game time via main loop is horriably inaccurate and SC2 definatly does not use it outside of the game engine. We all know how SC2 has no framerate cap on certain scenes and as such could obtain 500+ FPS which would make everything seem speeded up thus the overall flow of the game is syncronized by a proper timer. Additionally this points towards there being a separate graphic thread whos purpose is just to instruct the creation of the next scene so any virticle sync cap is ignored completly.

You can also run SC2 at any frame rate again throwing that idea out the window as it would then not be syncrnous for multiplayer so cause people to drop almost instantly.

Game loops might be what good old sega genisis or nes or SC1 used, but with or 4-6 processors and 100s of shaders it is a pretty usless design. Ultimatly there will be the basic idea of a loop inorder to keep the program going but the loop might do nothing more than set up and direct threads to keep the game in sync. I know for certain SC2 was designed for 2 main threads eating up most of a processor each although it does have other minor threads (1-2% of a processor) which handle inturupts, input and background tasks.

Oh yes, I forogt to mention that the clock generator circuit used to keep your processor syncronized and drive it is pretty accurate (your processor clock rate varies minimally in opperation) and as such you could even use it to get a pretty accurate timing.

well, its not incorrect !

what you mean isnt a timer, its called a stopwatch (in C#) and the System.nanoTime() in Java, in game design this is usually called a high precision timer, this tells you the CURRENT time in nanoseconds, a Timer is an object which calls a specific function in a specific interval, which is NEVER accurate in nanoseconds (as i said, the native timer on windows is accurate to 1/18 seconds, i got this information from their official website for C#)

besides synchro between server and pc runs over 2 sepperate timings, one on the server and one on the pc, and whenever the server gets the information from the pc he also gets the time in nanoseconds from the pc and then calculates the delay

and every game uses a gameloop, from the top selling x-box games to the top selling pc-games, in pseudo code it looks like this

while(game isnt finished)
{
update(elapsedTime);
drawAllStuffHere(Graphics ....);
}

this is the reason why nearly every game (including scII) takes up ~100%, or 50% on a dualcore from the processor. so every game got as much frames per second as good your pc is which is quite intelligent.

scII 100% uses a normal game loop because all calculations are made within it (the units for example, x += SPEED * elapsedTime * Cos(angle)...) are moving equally fast on every fps rate

so the timing could look like this:

update(double gameTime)
{
timer += gameTime;
while(timer >= INTERVAL)
{
timer -= interval;
DO STUFF FOR TIMER !!!!;
}
}

this timer-snippet is also used in about every game, of course in a more complex way

so, in normal games... timers are related to fps rate, it just could appear that if the fps are too low, the timer is called twice a frame !

 

[Dr Super Good]

this is the reason why nearly every game (including scII) takes up ~100%

SC2 loads 2 processors at 60% and 80% respectivly as well as loads of other low threads.

Only crap games use a loop like you described as it results in a huge wastage of system resources. Instead it puts the thread on hold allowing the time splicing kernal to allocate the processor to do something else in the mean time. Additionally it may wait for the graphic update thread or other threads to reach a certain stage so as to keep the game engine in sync. Ofcourse some games still run at 100% but that is because instead of instructing the kernal to let the prcoessor do something else in the mean time, it instead tells the kernal to keep the thread ready so the processor is equivently blocked until the thread gets revived.

In SC2, the game updates a fixed number of times per second and has to. If too many units move you will get a "your too slow" message meaning your processor can not keep up with that rate per second so the game will slow down. However every frame inside the game will be calculated. The graphics you see use their own framerate and ulike the internal game engine, not all frames have to be renderd cause they are based upon the current state of the internal engine unlike the internal engine which is based on previous states of itself.

In SC2 the graphics probably have their own thread, it makes the most sense since it allows an axceptable framerate even if the engine is overloaded while also allowing it to use dual cores cause most of SC2's CPU needs are for the graphics. It also explains why you can not reach 100% CPU usage on a single processor because the main engine thread has to wait until the graphic thread has read the current state values to prevent a scene being generated from an old and new frame. It also explains how frame rate drops when the main thread is heavilly loaded because there are less idle times from which data is safe to axcess for use with the graphic thread.

Yes all very confusing but PC programming is.

I do agree however that you have described is perfect for micro controlers / processors because they do not have things like the kernal to manage resources so need an infinite loop to function safely (otherwise they execute any old garbage from memory due to the auto incrementation the program counter register gets after each instruction is run).

However even modern micro controlers have built in timer systems and event systems to accompany those so you can just asign a perodic code block to an event which runs when the timer reaches a certain state which will automatically handle stack dumping etc instead of you having to program it into the main loop of your program.

 

[Itachi009]

SC2 loads 2 processors at 60% and 80% respectivly as well as loads of other low threads.

where did you got this information from?

Only crap games use a loop like you described as it results in a huge wastage of system resources. Instead it puts the thread on hold allowing the time splicing kernal to allocate the processor to do something else in the mean time. Additionally it may wait for the graphic update thread or other threads to reach a certain stage so as to keep the game engine in sync. Ofcourse some games still run at 100% but that is because instead of instructing the kernal to let the prcoessor do something else in the mean time, it instead tells the kernal to keep the thread ready so the processor is equivently blocked until the thread gets revived.

ofcourse, i wrote that it is in pseudo code

In SC2, the game updates a fixed number of times per second and has to. If too many units move you will get a "your too slow" message meaning your processor can not keep up with that rate per second so the game will slow down. However every frame inside the game will be calculated. The graphics you see use their own framerate and ulike the internal game engine, not all frames have to be renderd cause they are based upon the current state of the internal engine unlike the internal engine which is based on previous states of itself.

and what if someone got a 0.6 GHZ processor, will the game then run on 3 fps for EVERY player?

In SC2 the graphics probably have their own thread, it makes the most sense since it allows an axceptable framerate even if the engine is overloaded while also allowing it to use dual cores cause most of SC2's CPU needs are for the graphics. It also explains why you can not reach 100% CPU usage on a single processor because the main engine thread has to wait until the graphic thread has read the current state values to prevent a scene being generated from an old and new frame. It also explains how frame rate drops when the main thread is heavilly loaded because there are less idle times from which data is safe to axcess for use with the graphic thread.

you mean most of sc2 GPU needs are for the graphics, right? else i dont understand why the graphics should use the processor to render like in GDI or X11

 

[Dr Super Good]

where did you got this information from?

Alt + Ctrl + delete oh and from a website which was benchmarking its performance on Core I7 processors.

and what if someone got a 0.6 GHZ processor, will the game then run on 3 fps for EVERY player?

On average, yes. The game will firstly try lowering to slow and then even slower to keep it running fluid. Howevever if it is only 1 person with such a processor it will go in bursts of 0.5 seconds fluid play then the screen will hang for him to catch up and it is likly he will time out eventually and be dropped.

you mean most of sc2 GPU needs are for the graphics, right? else i dont understand why the graphics should use the processor to render like in GDI or X11

Sigh, someone has not looked up how computer graphics are made have they. The image is rendered by the GPU, yes, but the instructions to the GPU of how to render the image have to come from the CPU. This includes stuff like animations, reflections, praticles, and physics are all set up by the CPU (the GPU just makes the image out of them).

 

[Itachi009]

Alt + Ctrl + delete oh and from a website which was benchmarking its performance on Core I7 processors.

can you give me a link? im interested too

Sigh, someone has not looked up how computer graphics are made have they. The image is rendered by the GPU, yes, but the instructions to the GPU of how to render the image have to come from the CPU. This includes stuff like animations, reflections, praticles, and physics are all set up by the CPU (the GPU just makes the image out of them).

well i thought you mean that the image itself is rendered by the cpu which would make no sense.

and if the game runs on a fixed interval it would make sense that timers only run at 1/16 - 1/18 - 1/32 - 1/64, whatever intervals, but thats just what i wrote at the very beginning