Official Soldat Forums
Soldat Talk => Game Improvements / Suggestions => Topic started by: -Major- on May 28, 2010, 04:20:11 am
-
it should be possible to fps cap soldat.
-
What is this about. What do you want.
-
It is in the newest version of the beta. It's also been suggested earlier.
-
What is this about. What do you want.
-
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?
-
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.
-
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?
-
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.
-
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 :-\
-
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.
-
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
-
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.
-
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 :)
-
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?
-
I seriously can't stand the irony.. I am curious, what makes you think your opinion is more valid than mine
-
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?
-
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.
-
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.
-
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:
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
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....
-
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)
-
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".
-
lol Major, fpsFrameTime is not meant to increment like that.
-
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?
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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 :]
-
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.
-
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...
-
So, you, damn troll, ignored my post, right?
And you FAIL.
the not is probably not needed, could be replaced with a >= instead.
-
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.
-
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 )
-
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.
-
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.
-
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.
-
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
?
-
that's timepassed, but fpsstep remains the same.
-
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.
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;
-
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....
-
ooops.. I screwed this post
-
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.
-
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.
-
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 -.-
-
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.
-
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?
-
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~
-
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.
-
Why does (1000 / maxFPS) calculating every time?
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
-
still~
the fps capping shouldn't only cap the drawed fps, but also all the processed data.
-
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.
-
nah... you wanna cap the updates per second.... otherwise you can't optimize your game -.-
-
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.
-
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.
-
Neosano, I will have you keep a civil tone.
-
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 ^_^
-
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.
-
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...
-
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.
-
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
if (fpsTimePassed >= fpsStep) then begin
RenderFrame;
fpsTimePassed := fpsTimePassed - fpsStep;
end;
to this
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.
-
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.