Hey all.

To expand on the frameskipping thingamy.

Heres code snippet #1.

*************************************

Procedure CalcTiming;
begin
TimeInMilLast:=TimeInMil;
TimeInMil:=timegettime;

if TimeInMil-timeinmillast>2000 then
TimeInMilLast:=TimeInMil; {saftey precaution}

Timepassed:=Timepassed+(TimeInMil-TimeInMilLast);
SecondsLast:=Seconds;
Seconds:=trunc(Timepassed/1000);

if Seconds<>SecondsLast then begin {new Second}
TicksPerSecond:=Ticks; Ticks:=0;
FramesPerSecond:=Frames; Frames:=0;
end;

TickTimeLast:=TickTime;
TickTime:=trunc(Timepassed/(1000/GoalTicks));
end;

*************************************

*Gosh I hope the messageboard doesn''t chew that up.

Ok. So we have some interesting variables here. This procedure is expecting to be called from within a high resolution timer, maybe set to 0 or something. (1000 times a second).

*************************************

FramesPerSecond <= Will always contain the current FRAMERATE
TicksPerSecond <= Will always contain the current TICKRATE

GoalTicks <= Set this to 60 if you want 60 ticks per second.

And the rest are just Floats/Singles/whatevers.

*************************************

Alright - so you''re timer code would look somthing like this.

********************************************

procedure YourTimerFiringOffThingy;
var
MainControl:Integer;
HaveTicked:boolean;

begin

HaveTicked:=FALSE;

CalcTiming; {defined up top there}

for MainControl:=1 to (Ticktime-ticktimeLast) do
begin
UpdateInput;

Ticks:=Ticks+1;
HaveTicked:=TRUE;

ProcessGameLogic;
{This is what you want to happen TICKRATE
number of times per second}

end;


if (HaveTicked) then RenderScene;
{Whatever is inside RenderScene
should only be related to rasterizing graphics}

end;


********************************************

And that, my friends, it that. Things to note are that A) This routine is only really useful if you''re engine is capable of processing the game logic at the specified TICKRATE on all target platforms (think QUAKE). B) That you''re RenderScene is designed to be the slower and more expendable portion of you''re engine.

But Im pretty sure that''s what everyone was after, anyway. This chunk of code was actully posted about a year ago on the old turbo forums, but, minus one little conditional check to see if the logic had actually been updated before re-rendering a pre-existing frame. You could use a check just after this bit of code, to see if HAVETICKED is still false, and yes, expand you''re AI''s path searching abilitys by 1 unit the next process. If it''s not, do nothing, if the While loop gets executed more than once, then scale back the AI. Actually, what would make more sense, is to scale the number of TICKS between updating the collision detection between objects (capping it of course). Or, whatever you like.

Just after doing some tests, if you''re TICK processing takes too long, (ie collision detecting 200 odd objects per TICK - sigh - which is what Im currently facing) - it will still maintain the underlying World Speed. Bet you''re glad to hear that huh?

Anyway - Nuff outta me, I realize Im only expanding on what was already said - I just thought It might be useful for me to post a full framework up here for ya''s.

Back off to C++ land (sigh) .

#27

Actually - just some more things - Im pretty sure the above bit of code qualifies for "one of those things that looks like it shouldn''t work, but does" - things. All those variables up top are supposed to just be globals initialized to 0, except for the GoalTicks variable - which you should set to 30, 60, 200 or whatever. Also - the call to TimeGetTime comes from the MMSYSTEM unit, just in case you didn''t stumble across that one already.

I encourage anyone interested in this sort of thing to try it out and see =) Im kinda proud of it - but the one thing that irks me still, is that seeing it is basing the prediction for the next TICK upon whether the last FRAME ran overtime, quickly flicking between high intensity scenes and low intensity scenes causes slight waverings in the TICKRATE. But Im just being picky. If anyone else has a different approach, I''d love to hear it. (the whole thought of using of multiple threads, one to render, one to Logic, bothers me immensely. Ever heard of LockUP? )

Later.

#27

Could reply a long ago but was too busy. Although I got my way of getting same speed on different refesh rates, I don''t think it''s useful to publish it - you got plenty anyway - mine will just mess up the thread ;-)
I heard an idea of using two threads - one for drawing and another for everything else. I used the exact method before until I found problem on fast machines:
When (in thread) you render everything - you use Rendering routines (let''s suppose from DelphiX) from MAIN THREAD. Again, when you use any render-independent processes (let''s say AI or network code) - you also use routines from MAIN THREAD (unless your networking component runs in its own thread). Now let''s assume your great accelerator card allows 85 Hz refresh rate (and some GREATEST card can even do 120) you use routines from main thread a lot. As a result, your main thread is occupied all the time so there''s NO POSSIBLE WAY to respond to key command (or to windows commands), etc. What''s more - your TIMING FUNCTIONS (to calculate ticks, etc) are also ran in main thread!!! So you completely block your application as well as your threads. Another thing - as you render and process your data your both threads may block each other reading and writing data, or at least (if you used critical sections) your processing or/and rendering engine will jerk and glick. I tried this and it "worked" ...
The solution: don''t do it
My suggestion: use threads only for internal processes that doesn''t use main thread a lot (remember - most VCL routines use it!).
I know my post doesn''t help to answer the question - it''s just a personal experience I wanted to share with.

LP: Still good to know

Those solutions where pretty easy to put into my program.

Thanks all for your help !

Gunner.
Sysimage Inc.