0 Members and 1 Guest are viewing this topic.
What is this about. What do you want.
It is in the newest version of the beta. It's also been suggested earlier.
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?
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.
Quote from: L[0ne]R on May 28, 2010, 07:31:46 pmWhat 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.Quote from: biohazard on May 28, 2010, 07:52:46 pmIts 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?
Quote from: Dusty on May 29, 2010, 07:01:56 amQuote from: L[0ne]R on May 28, 2010, 07:31:46 pmWhat 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.Quote from: biohazard on May 28, 2010, 07:52:46 pmIts 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.
Quote from: -Major- on May 29, 2010, 07:25:59 amQuote from: Dusty on May 29, 2010, 07:01:56 amQuote from: L[0ne]R on May 28, 2010, 07:31:46 pmWhat 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.Quote from: biohazard on May 28, 2010, 07:52:46 pmIts 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
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
blah
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;
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.
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;
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;
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;
lol Major, fpsFrameTime is not meant to increment like that.
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.
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.
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.
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.
the not is probably not needed, could be replaced with a >= instead.
Quote from: -Major- on May 31, 2010, 06:46:04 amhe 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?
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...
Quote from: -Major- on May 31, 2010, 06:57:40 amblahyour post is not representing my code :-SRender thing and all calculations are different, it shouldn't be done in the same procedure. ( of course )
Quote from: Neosano on May 31, 2010, 06:59:45 amQuote from: -Major- on May 31, 2010, 06:57:40 amblahyour post is not representing my code :-SRender thing and all calculations are different, it shouldn't be done in the same procedure. ( of course )I was explaining eCs code.
also... timepassed = timepassed + (x+1) -xso, the time will always increase, at a point when timepassed gets as big and bigger than the maxFPS, it'll draw every frame.
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.
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;
It still gives the exact same result Neosano, 200+ fps.and timeGetTime() = http://msdn.microsoft.com/en-us/library/dd757629%28VS.85%29.aspxAt 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 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.
Btw, Try 100 fps. maybe the problem is in dividing?
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 smthfpsRenderInterval := Round(1000 / maxFPS);begin fpsCurrentTime := timeGetTime(); if (fpsCurrentTime - fpsLastFrame) >= fpsRenderInterval then begin RenderFrame; fpsLastFrame := fpsCurrentTime; end; end;
still~the fps capping shouldn't only cap the drawed fps, but also all the processed data.
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.
Quote from: Neosano on May 31, 2010, 10:04:43 amBtw, 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.
Quote from: Neosano on June 01, 2010, 06:21:25 amUm.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.
if (fpsTimePassed >= fpsStep) then begin RenderFrame; fpsTimePassed := fpsTimePassed - fpsStep; end;
if (fpsTimePassed >= fpsStep) then begin RenderFrame; fpsTimePassed := fpsTimePassed - Trunc(fpsTimePassed/fpsStep)*fpsStep; end;
Quote from: -Major- on May 31, 2010, 07:17:32 amno.... 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?