Hello,

i recently discovered, that if i move objects at a steady, high! speed in the engine while running windowed mode with a static camera, the movement is not steady but stuttering. You realise this best if the object is not animated and you have a static camera looking at it from above at a distance.
I tested various fps_max, fps_min and time_smooth values - but nothing could solve this issue.
Since i believe supporting windowed mode in a game is very important, i compiled a little demo program and ran it on different pc's and let it test some people.

The result was, that 7 pc's had the stuttering to a different extend - while only 3 did notice it a little bit.

The testprogram contained the following code:

Code:

---

///////////////////////////////

#include <acknex.h>
#include <default.c>

// system libs
#include <stdio.h>

// debug
#include "deb.c"		// debug
#include "deb.h"		// debug


///////////////////////////////

function testentity()
{

deb_print("Q to start movement | R reset position");
while(!key_q){wait(1);}
while(key_q){wait(1);}

	while(1)
	{


	vec_accelerate(my.skill1, my.skill10, vector(5,0,0), 0.5);
	c_move (me, me.skill1, nullvector ,IGNORE_YOU|IGNORE_MODELS|IGNORE_MAPS|IGNORE_PASSABLE|IGNORE_SPRITES|IGNORE_PASSENTS|IGNORE_CONTENT);	
	
		
	wait(1);
		
	if(key_r)
	{
		while(key_r){wait(1);}
		vec_set(my.x,nullvector);
	}
		
	}

}



function main()
{
	level_load("test.WMB");
	wait(2);

	video_set(800,600, 32, 2); // init video adapter

	fps_max = 60;

	wait(1);

	ent_create("cbabe.mdl",nullvector,testentity);
}

---

You can download it here: http://www.ackbytes.com/upload/fpstest.zip

You can test this program or try to recreate the behaviour with the above code. The worst result i had with a university computer, where the movement was almost like stop and go.
The problem seems to be most noticable in windowed mode under the above circumstances, in fullscreen it seems to be not so present, only if you really try to find it.
This is really bothering me, because it kind of prevents fast moving objects in window mode and will mess up the whole gameplay in this case.
If it would happen only on one pc i wouldn't mind reporting this problem, but it really happend on a lot of machines.
It's really strange that it's not so noticable on some pc's while most of the testsystems revealed an extreme behaviour with the same code.
So please look into it, maybe i just did anything wrong or there is an easy way to get around. Right now i fear this is engine specific to window mode and no one reported it because its limited to windowmode, fastmoving objects, static camera. Thanks for your understanding.

Stuttering is an often reported user problem. It won't be noticeable in a professional game with complex levels that consume lots of CPU cycles, but mostly in test games with almost empty levels and no content.

The two reasons are background tasks, like disk accesses, and coarse scheduler resolution that leads to inaccurate task start times on particular PCs. The latter depends on the memory and the number of tasks running.

You can check the first reason yourself: use diag_frame to check both time_frame and time_step. Then compare the list of values in the acklog.txt. Look for sudden high values in this list. They are due to something happening on that PC. This can't be fully compensated by your script because time_step contains the time for the _last_ frame, not for the current frame. So when a disk access occurs, you have one frame freezing and the following frame a huge motion step due to a high time_step value.

Stuttering problems are why many professional games limit the frame rate not with giving task time back to the Windows task scheduler - as fps_max does - but by really burning CPU cycles in some or the other way.

Hope this helps.

Yes, thanks this helped a lot. I ran a quick test with 30 actors following a path in the testproject and the noticable stuttering was reduced, although it was still there if you look close enough, but i think one can live with that.

Maybe you can give any hints or clues about how to achieve this burning of CPU cycles depending on the current gamestate. So when the game needs CPU power the burning is reduced and vice versa?

Thanks again.

Maybe you could use the currenttime=timer();
As high precision clock, and create your own timestep value.

If this value is more exact than time_step,
you can use the delta value from the last timer() to calulate the
precise position, the unit has to move.