Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[adonf]

Ok, one last question and I'll stop bothering you for a bit :

Why does my script run 10 times slower when VSYNC wait is enabled ?

I measure the time that it takes to run a given script so that I can call it every n milliseconds. When I activate "wait for refresh" in my video card's drivers, that script takes much, much longer to finish: without VSYNC wait it takes an average of 9 milliseconds; with VSYNC wait on, at 75 Hz, it takes about 110 ms.

At 75Hz a call to "wait for VSYNC" takes at most 13 ms, so it's not just that the script is interrupted by screen draw each time it runs, there has to be something else.

Does anyone know what is going on ? Maybe it's just that I don't understand how script execution is scheduled... in this case is there something that documents it ?

Cheers,
  Olivier


Here's my main loop from scene_init.script:

Code: [Select]

while (DropGame.GameState != "end")
{
var duration;
var frame_time = 20;
var start_time = Game.CurrentTime;

// update
DropGame.Update();

duration = (Game.CurrentTime - start_time );
var sleep_time = frame_time - duration ;
if ( 0 < sleep_time)
Sleep(sleep_time);

Game.LOG("Frame time is "+duration);
}
DropGame.Update() does some array management and creates an Object every 3 frames. It used to update sprites but I took out all the graphics functions to see if they were causing the slowdown (it made things a little better but not much.)

[Mnemonic]

var start_time = Game.CurrentTime;
// update
DropGame.Update();
duration = (Game.CurrentTime - start_time );

This will not work unless Update() calls Sleep, because Game.CurrentTime is only updated once in each frame, so the two CurrentTime calls will return the same value.

The script runs infinitely until it yields the control back to the engine by calling Sleep or some "blocking" method, such as GoTo(). Scripts are not automatically interrupted by screen drawing, it's their responsibility to yield when they're done.
Perhaps you shouldn't base the logic on frames, but just on time intervals?

[adonf]

This will not work unless Update() calls Sleep, because Game.CurrentTime is only updated once in each frame, so the two CurrentTime calls will return the same value.

Well that's odd. I don't call Sleep() in Update() but still I get a different current time after the Update() than before it.

But anyway, i noticed that the game was way slower with VSYNC ON even before I measured the execution time for my main script (and before I took out the graphics updates of course), I believe that the script really takes longer to execute, I'll check that with a call to Sleep(1) before getting current time...

The script runs infinitely until it yields the control back to the engine by calling Sleep or some "blocking" method, such as GoTo(). Scripts are not automatically interrupted by screen drawing, it's their responsibility to yield when they're done.

Ok, thank you for the explanation.

Perhaps you shouldn't base the logic on frames, but just on time intervals?

I think that's what I do: I call the Update method at a fixed time interval (20ms in the example is not real life value, I plan to change this value dynamically to accelerate the pace of the game for difficulty)

[adonf]

So, after adding a call to Sleep(1) after the Update function, I get exactly the same kind of results as before.

I also renamed the variable frame_time to interval_time so now i'm using intervals

[Mnemonic]

Oh, sorry. I forgot calling a custom method in another script actually does yield..

[adonf]

Ok

But it still doesn't make sense to me. Doing a lot of screen drawings (ie. high FPS value) should slow down the script (less time to run script because more time is spent on updating the screen), not make it faster...

[Mnemonic]

But it still doesn't make sense to me. Doing a lot of screen drawings (ie. high FPS value) should slow down the script (less time to run script because more time is spent on updating the screen), not make it faster...

Actually it's like this: the scripts are updated in every frame. So, when the game runs with high framerate, the scripts get updated more often than with slower framerate.
That's why I suggested using time intervals over framerate. Framerate can change, time will not (but of course, you can miss the end of the interval if it's too short and the game's running slowly).

[adonf]

Ok, I think that I understand what you mean: you're saying that I should check the time since the last update and either pass a time interval to the Update function, or call Update several times if needed. Is that right ?

Well I can't really do this because the minigame I'm writing has a step-by-step progression more than a continuous one. Think of Tetris if you want: I need to update the scene each time the block goes down one row ; I cannot have the block go down two rows at one time or the player could lose and not understand what happened.

Anyway, thanks for the detailed explanation.

EDIT: I'll try to remove all calls to member functions since they make the script yield, that might fix the problem...

[Mnemonic]

Ok, I think that I understand what you mean: you're saying that I should check the time since the last update and either pass a time interval to the Update function, or call Update several times. Is that right ?

Not exactly. I meant something like this.
The main loop to simply get the game running:

Code: [Select]

while(true)
{
  Update();
  Sleep(100);
}


I.e. the minimal time step the game updates in. The sleep amount should be reasonable low to get a good time resolution, but not too low not to slow the engine down too much.
That way the game is updated approximately 10 times per second, no matter what the framerate is (unless it's very low, in which case the game will run slower).

And the detailed processing would be taking place in Update. Using the Tetris parallel, for example, there is some time amount before the falling piece is moved.

Code: [Select]

var LastFallTime = 0;
var FallingSpeed = 500;

function Update()
{
  if(Game.CurrentTime - LastFallTime >= FallingSpeed)
  {
    // move the falling piece
   
    // check if the piece filled entire time etc.
   
    LastFallTime = Game.CurrentTime;
  }
}

Of course, this code assumes the processing in Update takes "almost zero time" which is usually the case.

[Guardian]

Hi
This method, described above is preferred of course.
But there is one thing - currently  VSync cannot be change by user in WME. Change it in video driver settings is not good idea, isn't it?
And even with you method script run slowly sometimes. (With LCD monitors - refresh rate 75Hz max - very slow!)
It will be easy to add property to Game object called VSync, I think. There is nothing special, just one of presentation parameters on Direct3DDevice creation.
This is very important for us. We want to produce commercial game on you engine.

With best regards.

[Mnemonic]

I don't believe messing with vsync is the way to go. The game should be playable at any framerate, if possible. What are your scripts doing that 75 updates per second aren't enough for them? Perhaps they could be simplified, perhaps you could break their execution into smaller parts..?

[Guardian]

Well, I can explain what I do:
I'm just create new project with usual template in ProjectMan. There is nothing added to default script. And I put on scene two layers - one sky (800x600, with one sprite also 800x600), another layer foreground (2400x600, with smaller sprites - 3 of 800x600). ok, this sprites isn't optimized, but this is just a test. On PC with GeForce5900XT when player go scrolling speed is one. On another PC with integrated video card - Intel865 another. This isn't good. With VSync off frame rate is 8 time higher, and even mouse smoothly moves on each PCs and animation of "molly" is better looks. So that do you think about it? There is no GPU limit, just scripts lag and of couse VSync.
I just want to say that you main loop suggested above isn't be right for situation when VSync is on.

[adonf]

What are your scripts doing that 75 updates per second aren't enough for them?

In our case, we need to run the main update script at up to 5 times per second, but since we have many objects, each call of the kind myObject.MyFunction() and, from what I gathered, each call to a graphics function (like changing an entity's current sprite) will cause the main script to yield until the next screen redraw.

So if we have 75 objects and each one has its DoUpdate() function then when the game is running at 75 FPS the main loop only runs once per second.


I suggested a simple way to work around this with minimal changes to the engine here. Basically, letting the user temporarily turn on and off rendering from within the script could help time-sensitive scripts run more smoothly on machines with low screen refresh rates.

[Mnemonic]

from what I gathered, each call to a graphics function (like changing an entity's current sprite) will cause the main script to yield until the next screen redraw.

No, no, not at all. I must have confused you. The script only yields if you call one of the "blocking" methods (GoTo, Talk, TurnTo...), Sleep() or if you call a custom method which is defined in another script.

In other words, the suggested feature isn't really necessary (IMO), because the rendering IS suspended while the script is running (until it yields).

[Mnemonic]

There is no GPU limit, just scripts lag and of couse VSync.

I'm afraid it is a GPU limit. Normally the scripts do next to none work, so it's unlikely they're lagging the game execution. Note that this thread discusses a very special case of complex scripts executing very often (for minigames scripted from scratch etc.). It's not the case you're describing.
As for the scrolling speed, you can adjust it using the Scene properties (ScrollSpeedX, ScrollSpeedY, ScrollPixelsX, ScrollPixelsY). The default values are probably set too low, so the scrolling sometimes doesn't catch up when the framerate is low.