Official Soldat Forums

Soldat Talk => Game Improvements / Suggestions => Topic started by: -Major- on May 28, 2010, 04:20:11 am

Title: fps capping
Post by: -Major- on May 28, 2010, 04:20:11 am
it should be possible to fps cap soldat.
Title: Re: fps capping
Post by: DarkCrusade on May 28, 2010, 06:54:03 am
What is this about. What do you want.
Title: Re: fps capping
Post by: Dusty on May 28, 2010, 07:59:09 am
It is in the newest version of the beta. It's also been suggested earlier.
Title: Re: fps capping
Post by: Centurion on May 28, 2010, 02:55:07 pm
What is this about. What do you want.
Title: Re: fps capping
Post by: L[0ne]R on May 28, 2010, 07:31:46 pm
What does FPS capping do anyway? If I understand that right - it puts a limit on FPS.
But isn't the more FPS = smoother motion = better? If so - why would you want to limit it?
Title: Re: fps capping
Post by: biohazard on May 28, 2010, 07:52:46 pm
It is in the newest version of the beta. It's also been suggested earlier.

Its not coded well. It lower 20% less fps than set. Thats not like pro games, or vsync, where u cap at 100 fps and get 99.99/100 fps. Its just lower the ammount of fps showed. IT JUST SUX.
Title: Re: fps capping
Post by: Dusty on May 29, 2010, 07:01:56 am
What does FPS capping do anyway? If I understand that right - it puts a limit on FPS.
But isn't the more FPS = smoother motion = better? If so - why would you want to limit it?

Having a stable FPS of 50 is much better than having an FPS jumping between 50 and 100.

Its not coded well. It lower 20% less fps than set. Thats not like pro games, or vsync, where u cap at 100 fps and get 99.99/100 fps. Its just lower the ammount of fps showed. IT JUST SUX.

That I don't know much about. What is coded well in Soldat?
Title: Re: fps capping
Post by: -Major- on May 29, 2010, 07:25:59 am
What does FPS capping do anyway? If I understand that right - it puts a limit on FPS.
But isn't the more FPS = smoother motion = better? If so - why would you want to limit it?

Having a stable FPS of 50 is much better than having an FPS jumping between 50 and 100.

Its not coded well. It lower 20% less fps than set. Thats not like pro games, or vsync, where u cap at 100 fps and get 99.99/100 fps. Its just lower the ammount of fps showed. IT JUST SUX.

That I don't know much about. What is coded well in Soldat?
especialy since you eat a lot more with 60 fps than if you have 240 fps.
Title: Re: fps capping
Post by: Fireman on May 29, 2010, 10:31:24 am
What does FPS capping do anyway? If I understand that right - it puts a limit on FPS.
But isn't the more FPS = smoother motion = better? If so - why would you want to limit it?

Having a stable FPS of 50 is much better than having an FPS jumping between 50 and 100.

Its not coded well. It lower 20% less fps than set. Thats not like pro games, or vsync, where u cap at 100 fps and get 99.99/100 fps. Its just lower the ammount of fps showed. IT JUST SUX.

That I don't know much about. What is coded well in Soldat?
especialy since you eat a lot more with 60 fps than if you have 240 fps.
Elaborate please, what does your FPS have to do with lag? ( ping ) It doesn't matter whether you have 30 or 500 FPS. Unless you have proofs  :-\
Title: Re: fps capping
Post by: -Major- on May 29, 2010, 08:20:05 pm
What does FPS capping do anyway? If I understand that right - it puts a limit on FPS.
But isn't the more FPS = smoother motion = better? If so - why would you want to limit it?

Having a stable FPS of 50 is much better than having an FPS jumping between 50 and 100.

Its not coded well. It lower 20% less fps than set. Thats not like pro games, or vsync, where u cap at 100 fps and get 99.99/100 fps. Its just lower the ammount of fps showed. IT JUST SUX.

That I don't know much about. What is coded well in Soldat?
especialy since you eat a lot more with 60 fps than if you have 240 fps.
Elaborate please, what does your FPS have to do with lag? ( ping ) It doesn't matter whether you have 30 or 500 FPS. Unless you have proofs  :-\
I have asked like every guy that eats more than average about their fps and those who doesn't... the eaters ussualy are around 60 fps, the ones that doesn't are 200+.
now, I'm not sure if this is completely reliable, since it probably has a lot to do with the connection too.
Title: Re: fps capping
Post by: DarkCrusade on May 29, 2010, 08:32:26 pm
How can FPS be anyhow related to eating and lagging? FPS only tell you how many frames are shown per second.

What is why it is called FPS and not ping. Noone sees whether you have low or high FPS, but the difference between low and high ping are very visable, no? The same counts for eating.

Again: FPS have nothing to do with eating. You, -Major-, as someone who tells everyone how many things he knows about Soldat, should honestly think about not posting every little assumption that pops up in your mind because this is really hilarious..

------>                     FPS <> Ping
Title: Re: fps capping
Post by: -Major- on May 29, 2010, 09:14:37 pm
you don't even know what fps means do you?

anyway, there are games that run differently on various fps limits.
if you take cod4 for example, if you have a very high fps, you will jump higher and have less recoil. and if you have lower fps, you will jump longer but have slightly more recoil.

as I said, this might not be true with soldat.
Title: Re: fps capping
Post by: DarkCrusade on May 29, 2010, 09:38:02 pm
You seem to ignore every given sense to the maximum.. you imply that I don't know what FPS are? Seems more like you didn't learn how to read or you didn't read my post entirely because I stated what FPS are and what not.

Despite this little contradiction (because you neglected what FPS really are) this is Soldat. Soldat cannot be compared to 3D shooter games like, for instance, COD4, because the differences are too huge. It starts with 2D <> 3D and ends with bugs.

Didn't we already have this little discussion? Everyone had the opinion that you cannot relate Soldat to any 3D games, be it Halo, COD4 or Quake. Except you again..

I don't know why, but you really seem to ignore the content of my posts and only read my name. Because this is what I stated in my post before: Stop posting >assumptions< that sound like >facts< because you stressed them as if they were the one and only truth. It's kind of pathetic thinking about all those threads in which you post your assumptions that you defend like they were the Holy Grail.


Feel free to comment again, I look forward to some serious fun :)
Title: Re: fps capping
Post by: -Major- on May 29, 2010, 10:06:46 pm
You seem to ignore every given sense to the maximum.. you imply that I don't know what FPS are? Seems more like you didn't learn how to read or you didn't read my post entirely because I stated what FPS are and what not.

Despite this little contradiction (because you neglected what FPS really are) this is Soldat. Soldat cannot be compared to 3D shooter games like, for instance, COD4, because the differences are too huge. It starts with 2D <> 3D and ends with bugs.

Didn't we already have this little discussion? Everyone had the opinion that you cannot relate Soldat to any 3D games, be it Halo, COD4 or Quake. Except you again..

I don't know why, but you really seem to ignore the content of my posts and only read my name. Because this is what I stated in my post before: Stop posting >assumptions< that sound like >facts< because you stressed them as if they were the one and only truth. It's kind of pathetic thinking about all those threads in which you post your assumptions that you defend like they were the Holy Grail.


Feel free to comment again, I look forward to some serious fun :)
lol, you are retarded right? what sane person would talk that much bullshit?
Title: Re: fps capping
Post by: DarkCrusade on May 30, 2010, 04:00:05 am
I seriously can't stand the irony.. I am curious, what makes you think your opinion is more valid than mine
Title: Re: fps capping
Post by: Dusty on May 30, 2010, 06:37:54 am
blah

It's true that FPS can affect the gameplay. Helbreath for example, it's an old RPG. The higher your FPS is, the faster your character runs. The difference was easy to note if you played on an old computer against somebody who had a modern computer.

The joke's on you DC, just quit it... You never learn to give up, do you?
Title: Re: fps capping
Post by: biohazard on May 30, 2010, 07:41:06 am
mostly pro games has nothing to do with FPS affecting ur shits. Like on quake3 high fps = higher shits. On new Quakelive its solved.

Idk about Soldat, since the only way to limit the fps is setting vsync ON, which sux cuz the devices lag. If you just limit ur fps to ur monitor refresh rate value, the game will not flick, and run smoother. In the past i tried to use fpslimiter.exe but it fuck up the DX8 shit.

Btw, how its coded on 1.5.1, it just sux hard. Not limiting in fact the fps, but lowering the ammount, with a instable shit, and 20% lower. If you wants 100fps cap, u must set 120 atlest, but yet, instable to 70/80/90/100 fps.
Title: Re: fps capping
Post by: EnEsCe on May 30, 2010, 08:32:58 am
Code: (pascal) [Select]
var
  maxFPS: byte = 0;
  fpsLastFrame: DWORD = 0;
  fpsCurrentTime: DWORD = 0;

begin
  fpsCurrentTime := timeGetTime();
  if not ((fpsCurrentTime - fpsLastFrame) < (1000 / maxFPS)) then begin
    RenderFrame;
    fpsLastFrame := fpsCurrentTime;
  end;
end;
You tell me what is coded wrong about that, wiseguy.
Title: Re: fps capping
Post by: -Major- on May 30, 2010, 10:52:32 am
Code: (pascal) [Select]
var
  maxFPS: byte = 0;
  fpsLastFrame: DWORD = 0;
  fpsCurrentTime: DWORD = 0;

begin
  fpsCurrentTime := timeGetTime();
  if not ((fpsCurrentTime - fpsLastFrame) < (1000 / maxFPS)) then begin
   RenderFrame; 
   fpsLastFrame := fpsCurrentTime; 
  end;
end;
You tell me what is coded wrong about that, wiseguy.

altho.. shouldn't it be something like:

Code: (pascal) [Select]
var
 maxFPS: byte = 0;
fpsLastFrame: DWORD = 0;
fpsCurrentTime: DWORD = 0;

begin
    fpsCurrentTime := timeGetTime();
    if ((fpsCurrentTime - fpsLastFrame) < (1000 / maxFPS)) then begin
        RenderFrame;
    end;
    fpsFrameTime = fpsFrameTime + (1000 / maxFPS);
end;
or
Code: (pascal) [Select]
var
 maxFPS: byte = 0;
fpsLastFrame: DWORD = 0;
fpsCurrentTime: DWORD = 0;

begin
    fpsCurrentTime := timeGetTime();
    if ((fpsCurrentTime - fpsLastFrame) < (1000 / maxFPS)) then begin
        RenderFrame;
       fpsFrameTime = fpsFrameTime + (1000 / maxFPS);
    end;
end;
these checks really kills my mind these days... so it might have to be a if not... (I never got this so I always tried both~)
blah, if the counter doesn't show very accurate fps, just mess around with stuff....
Title: Re: fps capping
Post by: biohazard on May 30, 2010, 12:07:17 pm
I dont even need to understand of Delphi(?) coding, even none languange, to know its wrong. I may provide proofs if you cant understand what is going on.

Summarize:
-20% lower than the amount set on maxframerate
-instable(by high values)
-freezing

Prolly thats not the coding way pro games use to limit the FPS. Or maybe, Soldat itself dont work well with that.

FPS capped with vsync on my 100hz shit
(http://img714.imageshack.us/img714/2088/100ho.gif)

FPS capped on Soldat @ 150, vsync off
- As ya can see, its like 20% lower and very instable, not even close to what vsync does or how Quakelive/CS cap the FPS. To get it capped on 100fps i have to set 120 on maxframerate. This GIF is made on .15 beta, on .14 it was worse.
(http://img532.imageshack.us/img532/1687/150r.gif)

FPS uncapped, vsync off, 50% lower than current 1.5
(http://img41.imageshack.us/img41/3793/uncapavi.gif)

Title: Re: fps capping
Post by: -Major- on May 31, 2010, 05:06:51 am
Code: (pascal) [Select]
var
 maxFPS: byte = 0;
fpsLastFrame: DWORD = 0;
fpsCurrentTime: DWORD = 0;

begin
    fpsCurrentTime := timeGetTime();
    if not ((fpsCurrentTime - fpsLastFrame) < (1000 / maxFPS)) then begin
        RenderFrame;
       fpsFrameTime = fpsFrameTime + (1000 / maxFPS);
    end;
end;
this should be it. I doubt tho that enesce would even try to implent it because of his "pride".
Title: Re: fps capping
Post by: EnEsCe on May 31, 2010, 05:21:25 am
lol Major, fpsFrameTime is not meant to increment like that.
Title: Re: fps capping
Post by: -Major- on May 31, 2010, 05:26:22 am
lol Major, fpsFrameTime is not meant to increment like that.
it is, using gametime at that point will probably just give you a unreliable value.
as I said, you won't even try it.

if your code doesn't work, then obviously there's something wrong with it... don't you think?
Title: Re: fps capping
Post by: EnEsCe on May 31, 2010, 05:36:58 am
For starters, there is no fpsFrameTime variable (you also failed to use := ). I'll assume you meant fpsLastFrameTime, but even then so: DWORD can't have decimals, which is what occurs when you add (1000 / maxFPS). So I cant even try it because your code is flawed and won't even compile.
Title: Re: fps capping
Post by: -Major- on May 31, 2010, 05:40:08 am
For starters, there is no fpsFrameTime variable (you also failed to use := ). Secondly DWORD can't have decimals, which is what occurs when you add (1000 / maxFPS). So I cant even try it because your code is flawed and won't even compile.
I have never programmed in delphi, nor pascal. just convert the code into delphi. I also haven't done ANY programming in 3 years. I barely remember how a "for" thingy works anymore.
if DWORD can't have decimals, make a function to make the equation into an integer.

and you are really retarded, aren't you?

fpsLastFrame = fpsLastFrame + 1000/maxFPS


the MAIN issue is that you won't fix the broken code. even if my code paste doesn't work... YOUR CODE IS STILL FLAWED.
Title: Re: fps capping
Post by: EnEsCe on May 31, 2010, 05:43:43 am
It's OK Major, I shall tolerate your lack of maturity.

But anyway, even when I rounded 1000/maxFPS, and set my FPS cap to 75, the framerate is 160-200. So gg your code is worse.

Adieu.
Title: Re: fps capping
Post by: -Major- on May 31, 2010, 05:45:01 am
It's OK Major, I shall tolerate your lack of maturity.

But anyway, even when I rounded 1000/maxFPS, and set my FPS cap to 75, the framerate is 160-200. So gg your code is worse.

Adieu.
still your code is flawed.... so is mine.... both are completely useless.

Meaning, you have to fix it... not let it go half assed.
Title: Re: fps capping
Post by: EnEsCe on May 31, 2010, 05:54:31 am
The point of me posting the code was for someone with intelligence to point out the flaw, because there isn't one. It's being caused by something else in Soldat's original code, so your bashing of MY code is false.
Title: Re: fps capping
Post by: -Major- on May 31, 2010, 05:57:15 am
The point of me posting the code was for someone with intelligence to point out the flaw, because there isn't one. It's being caused by something else in Soldat's original code, so your bashing of MY code is false.
you intend to leave it out flawed -.-. so the bashing is well deserved.
Title: Re: fps capping
Post by: Neosano on May 31, 2010, 06:30:26 am
Code: (pascal) [Select]
var
  maxFPS: byte = 0;
  fpsLastFrame: DWORD = 0;
  fpsCurrentTime: DWORD = 0;

begin
  fpsCurrentTime := timeGetTime();
  if not ((fpsCurrentTime - fpsLastFrame) < (1000 / maxFPS)) then begin
    RenderFrame;
    fpsLastFrame := fpsCurrentTime;
  end;
end;
You tell me what is coded wrong about that, wiseguy.
Oh I really don't understand what is happening here, and what it was intended to do.
if not ( a < b) part is just ridiculous... why not to use >= ?

The problem here is obvious. (Well, from mine non-understanding point of view)
I'll not try to post a pascal code, cuz I really don't want to remember pascal. But here's how it should work theoretically(that's not a programming language):

fpsStep = 1000 / MaxFps
timePassed
lastTime


your BEGIN here

timePassed = timePassed + GetTime() - lastTime
lastTime = GetTime()

if (timePassed >= fpsStep) {
RenderFrame()
timePassed= timePassed-fpsStep
}

end


try it. should work :]
Title: Re: fps capping
Post by: biohazard on May 31, 2010, 06:34:44 am
I noticied this option vsync on config.exe capping the FPS to something around 65, even if ima using 100/120hz LCD s**t. Is it truly a vsync or just your FPS-cap code. Prolly its not vsync in fact, since u cant set it with windowed mode, vsync only works on fullscreen.

Btw, this s**t http://rs487l3.rapidshare.com/files/160642187/2081482/FPS_Limiter_0.2.rar limits very the FPS on Soldat, but would be nice to have it in-game well coded. Idk, maybe some1 might try to break its source and understand how to cap the fps.

For starters, there is no fpsFrameTime variable (you also failed to use := ). I'll assume you meant fpsLastFrameTime, but even then so: DWORD can't have decimals, which is what occurs when you add (1000 / maxFPS). So I cant even try it because your code is flawed and won't even compile.

At moment, ur code works in a decent way if the maxframerate is set at 100, anything else, not.
Title: Re: fps capping
Post by: -Major- on May 31, 2010, 06:46:04 am
he replaces last frame with the current frame at the end. however, doing that with my method should probably do about the same, except that it calculates the value instead of copying.

the not is probably not needed, could be replaced with a > instead. the "if not" means that, if statement is false, then proceed. ussualy you just use an if, which makes it, if statement is true, then proceed.

lets make max fps 100.

so, if this is false..

we start with currentTime as 1, 1 minus lastFrame (which is 0) is 1. this is less than 1000/100. so the statement is true. which ends the if thingy.

when the current time is 10 the statement is false, since 10-0 is 10, which is as big as 1000/100. the process begins.
it renders the frame and sets last frame to 10.

next frame would maybe be 13, as the check goes on again, it'll end with a result with 13-10 which is 10, and is less than 1000/100. which makes the statement true. therefore it does not proceed.


basically fpsLastFrame copies the last drawns frame game time.
using maxFPS/1000 should give the same value...

hopefully "RenderFrame" doesn't only draw it graphically, but also calculates everything that should happen that frame. otherwise this frame capping is utter bullshit...
Title: Re: fps capping
Post by: Neosano on May 31, 2010, 06:54:30 am
So, you, damn troll, ignored my post, right?

And you FAIL.
the not is probably not needed, could be replaced with a >= instead.
Title: Re: fps capping
Post by: -Major- on May 31, 2010, 06:57:40 am
he replaces last frame with the current frame at the end. however, doing that with my method should probably do about the same, except that it calculates the value instead of copying.

the not is probably not needed, could be replaced with a > instead. the "if not" means that, if statement is false, then proceed. ussualy you just use an if, which makes it, if statement is true, then proceed.

lets make max fps 100.

so, if this is false..

we start with currentTime as 1, 1 minus lastFrame (which is 0) is 1. this is less than 1000/100. so the statement is true. which ends the if thingy.

when the current time is 10 the statement is false, since 10-0 is 10, which is as big as 1000/100. the process begins.
it renders the frame and sets last frame to 10.

next frame would maybe be 13, as the check goes on again, it'll end with a result with 13-10 which is 10, and is less than 1000/100. which makes the statement true. therefore it does not proceed.


basically fpsLastFrame copies the last drawns frame game time.
using maxFPS/1000 should give the same value...

hopefully "RenderFrame" doesn't only draw it graphically, but also calculates everything that should happen that frame. otherwise this frame capping is utter bulls**t...
So, you, damn troll, ignored my post, right?
you didn't read what you wrote, right?

also... timepassed = timepassed  + (x+1) -x

so, the time will always increase, at a point when timepassed gets as big and bigger than the maxFPS, it'll draw every frame.
Title: Re: fps capping
Post by: Neosano on May 31, 2010, 06:59:45 am
blah
your post is not representing my code :-S

Render thing and all calculations are different, it shouldn't be done in the same procedure. ( of course )
Title: Re: fps capping
Post by: -Major- on May 31, 2010, 07:04:59 am
blah
your post is not representing my code :-S

Render thing and all calculations are different, it shouldn't be done in the same procedure. ( of course )
I was explaining eCs code.
Title: Re: fps capping
Post by: Neosano on May 31, 2010, 07:07:02 am
blah
your post is not representing my code :-S

Render thing and all calculations are different, it shouldn't be done in the same procedure. ( of course )
I was explaining eCs code.
What for? Just say that my algorithm works.

From: May 31, 2010, 07:13:03 am
also... timepassed = timepassed  + (x+1) -x

so, the time will always increase, at a point when timepassed gets as big and bigger than the maxFPS, it'll draw every frame.
no, you don't get it, it's right.
Title: Re: fps capping
Post by: -Major- on May 31, 2010, 07:17:32 am
no.... when time is 481029, and fps step is 100, the next frame will be 481030, that is still greater than 100, so that frame will also be drawn.

adding time to fps step would probably work tho.
Title: Re: fps capping
Post by: Neosano on May 31, 2010, 07:49:40 am
no.... when time is 481029, and fps step is 100, the next frame will be 481030, that is still greater than 100, so that frame will also be drawn.

adding time to fps step would probably work tho.
What are you talking about, retard?
Did you notice this line
timePassed= timePassed-fpsStep
?
Title: Re: fps capping
Post by: -Major- on May 31, 2010, 08:01:44 am
that's timepassed, but fpsstep remains the same.
Title: Re: fps capping
Post by: EnEsCe on May 31, 2010, 08:19:01 am
Tried your pseudo code Neosano, and it was also not capping FPS at all. I set maxFPS to 75, it was going at 200+ FPS.
Code: (pascal) [Select]
var
  fpsStep = 1000 / maxFPS;
  fpsTimePassed = 0;
  fpsLastTime = 0;

begin
  fpsTimePassed := fpsTimePassed + timeGetTime() + fpsLastTime;
  fpsLastTime := timeGetTime();
  if (fpsTimePassed >= fpsStep) then begin
    RenderFrame;
    fpsTimePassed := fpsTimePassed - fpsStep;
  end;
end;
Title: Re: fps capping
Post by: -Major- on May 31, 2010, 08:36:33 am
what does the renderframe do enesce? does it only render the graphics in the frame, or does it make everything in the frame?

anyway, I guess you could maybe try a more mathematical way to do it.... probably with modulator ussage it should be possible...

lets say we want to limit fps to 93...

then take 1000/93 = X, make X an integer... then..

if (fpsCurrentTime mod X = 0) then
renderframe;
end;

or

if (fpsCurrentTime mod X = 1) then
renderframe;
end;

(mix around some with if/if not and 1/0)

the maths might be off and might not compile, just convert the stuff that is needed.


aaaah... but this might get really fucked up....
Title: Re: fps capping
Post by: Neosano on May 31, 2010, 09:16:40 am
ooops.. I screwed this post
Title: Re: fps capping
Post by: EnEsCe on May 31, 2010, 09:34:02 am
It still gives the exact same result Neosano, 200+ fps.
and timeGetTime() = http://msdn.microsoft.com/en-us/library/dd757629%28VS.85%29.aspx (http://msdn.microsoft.com/en-us/library/dd757629%28VS.85%29.aspx)

At the moment I've got a better method, but still seems a tiny bit off. Capped at 75, getting 74-77 FPS, when capped at 120 getting 119-122. According to FRAPS.
Title: Re: fps capping
Post by: Neosano on May 31, 2010, 09:44:50 am
It still gives the exact same result Neosano, 200+ fps.
and timeGetTime() = http://msdn.microsoft.com/en-us/library/dd757629%28VS.85%29.aspx (http://msdn.microsoft.com/en-us/library/dd757629%28VS.85%29.aspx)

At the moment I've got a better method, but still seems a tiny bit off. Capped at 75, getting 74-77 FPS, when capped at 120 getting 119-122. According to FRAPS.
ok. When game starts it should set fpsLastTime to timeGetTime()
Otherwise it's set to 0, which makes a lot of difference.
Title: Re: fps capping
Post by: -Major- on May 31, 2010, 09:47:19 am
It still gives the exact same result Neosano, 200+ fps.
and timeGetTime() = http://msdn.microsoft.com/en-us/library/dd757629%28VS.85%29.aspx (http://msdn.microsoft.com/en-us/library/dd757629%28VS.85%29.aspx)

At the moment I've got a better method, but still seems a tiny bit off. Capped at 75, getting 74-77 FPS, when capped at 120 getting 119-122. According to FRAPS.
that little is probably because of fps drops and making stuff into integer tho...

however, what does renderframe do? is it only graphical drawing? make sure so the game doesn't update itself more than the capped fps.... otherwise the point of this is lost -.-
Title: Re: fps capping
Post by: EnEsCe on May 31, 2010, 09:58:57 am
Ok, when I do that it sits at 76-77 with a 75 cap; however at 120 cap it sits at 125 very steadily. 168 @ 160. 63 @ 60
@Major, yeah I agree its the decimal thing now. And RenderGame only renders the screen, all the time related events are outside the cap code.
Title: Re: fps capping
Post by: Neosano on May 31, 2010, 10:04:43 am
Ok, when I do that it sits at 76-77 with a 75 cap; however at 120 cap it sits at 125 very steadily. 168 @ 160. 63 @ 60
@Major, yeah I agree its the decimal thing now. And RenderGame only renders the screen, all the time related events are outside the cap code.
Well, sounds way better ^_^
maybe fpsLastTime is set to timeGetTime() in a wrong place? It must be set to it exactly when this algorithm starts. Well, I did what I can ^_^

Btw, Try 100 fps. maybe the problem is in dividing?
Title: Re: fps capping
Post by: -Major- on May 31, 2010, 10:08:14 am
Ok, when I do that it sits at 76-77 with a 75 cap; however at 120 cap it sits at 125 very steadily. 168 @ 160. 63 @ 60
@Major, yeah I agree its the decimal thing now. And RenderGame only renders the screen, all the time related events are outside the cap code.
so, then you should make the framecap code at the very base, so the game won't process any code unless a frame is supposed to be drawn~
Title: Re: fps capping
Post by: EnEsCe on May 31, 2010, 10:16:25 am
Btw, Try 100 fps. maybe the problem is in dividing?
100 sits perfectly at 100. So yes, it is something wrong with the dividing now.
Title: Re: fps capping
Post by: SyavX on May 31, 2010, 02:48:06 pm
Why does (1000 / maxFPS) calculating every time?

Code: (Pascal) [Select]
var 
 maxFPS: byte = 0; 
 fpsLastFrame: DWORD = 0; 
 fpsCurrentTime: DWORD = 0; 
 fpsRenderInterval: WORD = 0;
 
// calculate render interval time after you read maxFPS value from .ini or smth
fpsRenderInterval := Round(1000 / maxFPS);

begin 
   fpsCurrentTime := timeGetTime(); 
   if (fpsCurrentTime - fpsLastFrame) >= fpsRenderInterval then begin 
     RenderFrame; 
     fpsLastFrame := fpsCurrentTime; 
   end; 
end;

The problem could be related to timeGetTime accuracy. Try to digg into timeBeginPeriod/timeEndPeriod direction or even QueryPerformanceTimer.

upd: oh, you probably did, coz of posted link to MSDN
Title: Re: fps capping
Post by: -Major- on May 31, 2010, 02:50:27 pm
still~

the fps capping shouldn't only cap the drawed fps, but also all the processed data.
Title: Re: fps capping
Post by: biohazard on May 31, 2010, 03:08:44 pm
still~

the fps capping shouldn't only cap the drawed fps, but also all the processed data.

nop, only drawed, ima quite sure thats how fps limit is supposed to work.
Title: Re: fps capping
Post by: -Major- on May 31, 2010, 03:36:18 pm
nah... you wanna cap the updates per second.... otherwise you can't optimize your game -.-
Title: Re: fps capping
Post by: biohazard on May 31, 2010, 04:19:37 pm
http://dev.koonsolo.com/7/dewitters-gameloop/

I think that Soldat already follow "Constant Game Speed with Maximum FPS" concept and cant be changed easier as like coding some lines.
Title: Re: fps capping
Post by: -Major- on May 31, 2010, 04:37:54 pm
http://dev.koonsolo.com/7/dewitters-gameloop/

I think that Soldat already follow "Constant Game Speed with Maximum FPS" concept and cant be changed easier as like coding some lines.
hmm? can just put the update at the same place as renderframe.
Title: Re: fps capping
Post by: echo_trail on May 31, 2010, 06:41:58 pm
Neosano, I will have you keep a civil tone.
Title: Re: fps capping
Post by: Neosano on June 01, 2010, 06:21:25 am
Btw, Try 100 fps. maybe the problem is in dividing?
100 sits perfectly at 100. So yes, it is something wrong with the dividing now.
Um.
fpsStep mustn't be an integer or byte.. something float is needed here.
same goes for fpsTimePassed.

2echo_trail
OKies ^_^
Title: Re: fps capping
Post by: SyavX on June 01, 2010, 07:22:14 am
Um.
fpsStep mustn't be an integer or byte.. something float is needed here.
same goes for fpsTimePassed.

timeGetTime returns an integer value (DWORD type), so... you are wrong.
Title: Re: fps capping
Post by: Neosano on June 01, 2010, 08:02:00 am
Um.
fpsStep mustn't be an integer or byte.. something float is needed here.
same goes for fpsTimePassed.

timeGetTime returns an integer value (DWORD type), so... you are wrong.
fpsStep=1000/maxFPS

1000/75=13.3333 .....Definitely I'm wrong...

next time read the code... PLEASE...
Title: Re: fps capping
Post by: SyavX on June 01, 2010, 09:00:08 am
Think widely, there is no sense to hold a result of (1000/maxFPS) as float because it's comparing with timer value (ms).

fpsCurrentTime, fpsLastFrame, fpsTimePassed, etc. all are based on timeGetTime and are integer.
Title: Re: fps capping
Post by: Neosano on June 01, 2010, 11:50:41 am
nah..
Enesce, just change maxFPS and fpsTimePassed to floats, it gonna fix it.

and really you should use something more exact, since milliseconds are too big really :-S

From: June 01, 2010, 12:28:33 pm
btw
changing this
Code: [Select]
  if (fpsTimePassed >= fpsStep) then begin
    RenderFrame;
    fpsTimePassed := fpsTimePassed - fpsStep;
  end;

to this

Code: [Select]
if (fpsTimePassed >= fpsStep) then begin
    RenderFrame;
    fpsTimePassed := fpsTimePassed - Trunc(fpsTimePassed/fpsStep)*fpsStep;
  end;

Will fix a problem when fps goes higher than expected after a lag.
Title: Re: fps capping
Post by: FliesLikeABrick on June 03, 2010, 03:39:59 pm
no.... when time is 481029, and fps step is 100, the next frame will be 481030, that is still greater than 100, so that frame will also be drawn.

adding time to fps step would probably work tho.
What are you talking about, retard?
Did you notice this line
timePassed= timePassed-fpsStep
?

Warned for inflammatory posts.