Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: TopAce on April 26, 2004, 12:41:58 pm
-
If the thread title does not make it clear:
Can I remove the FPS limit so that I could get the FPS value my machine is actually able to produce? The FPS counter stops at 60 at me, but I am sure my machine is better than that.
-
That's almost definitely VSync. Turning it off can add visual artifacts and you won't notice any better framerate because your monitor can't refresh the screen fast enough.
I don't know if the SCP added VSync or not. It could have been in the original FS2, I don't know. Or, it could be something different from VSync, but I haven't a clue as to what.
-
I can reach a FPS value of 200 in Quake 3. And it definitely runs faster than it does at 60 FPS. I guess the same would be valid for FreeSpace.
-
-d3d_no_vsync
-
Does that completely remove the FPS limit?
-
no it doesn't there is a 120.0FPS cap
-
well, depends on your system, off course.........
i just updated the wiki to include this command line...
-d3d_no_vsync Disables Vsync; Vsync makes your graph card wait for your monitor to draw the current frame before providing the next. Disabling this will take a FPS "cap" off (when your FPS holds consistently at a certain number, like 60) but will cause "tearing".
http://dynamic4.gamespy.com/~freespace/fsdoc/index.php/Command-Line%20Quick%20Reference
-
there is a framerate cap of 120.0 FPS coded into the code.. i hit it all the time
-
Unless I'm confusd about something, if your monitor can't refresh faster than sixty times per second (60 hertz), then it would be impossible for you to notice any difference at a higher FPS. Since VSync makes it so that the game only goes up to however fast your monitor can refresh, in this case 60 times per second, I can't see how disabling VSync would give any real performance boost.
But then, I don't know too much about how VSync works. It may give a very slight performance boost to have it off, even when you're monitor can't show anything more. But then again, disabling VSync can give you graphical glitches, so I tend not to do that.
-
oh, ok.....
you posted while i was typing, but anyway....
who has a monitor that goes behond 120Hz?
-
I DO - there is a cap of 120.0FPS CODED INTO THE GAME
-
hey, no need to yell, i asked if anyone had a monitor that can take those framerates, nothing to yell about.....
if it is coded, is it easy to just say "bump" like with all the other stuff?
-
In theory, my monitor can refresh at the speed of 60 Hz. But how can that be that I can see difference between 60 FPS and 120 FPS in Quake 3?
-
TopAce: several ways, none of which i can pull to the top of my head right now
i just doubled the framerate cap.. and i hit it... let's see if i can remove it
-
Originally posted by kasperl
who has a monitor that goes behond 120Hz?
I do. I think it goes up to 180Hz, but I keep it locked at 85 most f the time.
-
A monitor of that kind is certainly not cheap.
-
I just hit 358FPS in FS2 with the cap disabled :D
I'm going to make a command line param to remove the cap - hopefully when the effects get batched in HT&L i'll be able to do 180+ FPS with a dozen ships on my screen, i can do it with certain ships on my screen, but ones with fancier effects slow it down to average
-
In theory, my monitor can refresh at the speed of 60 Hz. But how can that be that I can see difference between 60 FPS and 120 FPS in Quake 3?
One way could be that the code showing the FPS in Quake3 is incorrect, or somehow innaccurate, or something like that. Always possible.
Another could be that you aren't actually seeing a difference, you only think you are. The ol' placebo effect.
-
Quake3 is always correct. Unfortunatly, I am now longer able to run Q3, so I couldn't test it.
-
RT is working on that, there was a comand line added for it I think recently.
-
Langy: no, there really is a difference - it's in physics calculation accuracy mostly - the small the time sample the more accurate the movement
Think about Reimann Sums with low n values compared to Reimann Sums with high n values (or a Reimann Sum with an infinite N value - a integral)
-
"-no_fps_capping" will disable framerate capping - committing to CVS now
PS: I can tell the difference in the accuracy of the physics at different framerates
-
Ahah. That actually makes sense. Thanks for the explanation, Kazan.
-
commit again? I am still running the update from an hour ago.......
Am i doing something wrong?
Doesn't this count as a feature BTW?
-
Er...
Perhaps it doesn't count as a feature because it fixes the 'bug' where the FPS is capped at 120?
-
it was trivial.. 7 lines of code
your update may be frozen.. kill and retry
-
retrying now.....
i really, really hope this doesn't take another hour....
btw, it keeps spewing lines of code, even though silent mode is on.
and should i use "query update" (F4) or "update selected" (ctrl+u)?
-
ctrl+u
-
ok, i did that.
how long is a CVS update supposed to take?
-
not long... when did you last update and what is your processor, and internet connection
-
Kazan, I wouldn't just flippantly put that command-line thing in... IIRC taylor said the cap was there for a reason. I'll PM him.
-
last update, this afternoon, took me 5 min or less
net conn, cable, 300KBPS down is normal if i got a fast peer.
processor: P3 800.
-
goober5000: hence why i made it a command line OPTION to disable
-
Yes, I see that. And that's better than adding it by default. At the same time, it would be useful to know why it's that way so as to warn people using the command-line argument.
-
Aye, most games have a hardcap because their developers accept that machines will not be able to maintain their system best FPS very much of the time, and, to most gamers, especially those that like to push their games -- not just their machines with their games, bouncy FPS is VERY VERY noticable no matter what end of the scale you're on.
In my experience, at least.
-
Wow. I never knew that upping my refresh rate would help my framertes... Too bad my monitor doesn't support higher than 85hz on oddball resolutions. (I'm stuck at 75hz for my 1152x864 rez)
-
doesn't really "help your framerates" (unless you are using Vsync), but the higher the refresh rate, the more frames you are actually seeing with your eyes and the longer it will take for you to get a headache from staring at your screen...heheh...personally, I can no longer stand anything below 85Hz anymore. It BURNS! LOL
For gaming purposes, VSync rules...and yet...well...l do not understand why some hardcore gamers (not accusing anyone here, I've seen this behavior elsewhere) insist upon always uncapping the framerate for every game they play, yet have monitor refreshrates of, like, 60Hz or so, so their eyes can only SEE 60FPS out of the 300+ their Uber L337 system is producing.
there is no **** point to having a 312+ FPS if only 85-100FPS or (85Hz or 100Hz at 1024x768) of em are visible!
of course, the real reason they do it is probably so that at lan parties they get lots of jealous people staring at their framerates *sigh*
I have noticed that setting a custom FPS cap that matches or is slightly above your screen refresh rate with a game option of some kind (e.g. the FSO Launcher's flags) seems to work better than using Vertical Sync. Dunno why, it just seems to, sometimes. Then again, I could be just imagining it...
-
The 60 FPS limit comes from WinXP or Win2000.
On any proper OS you will have your refresh rate as a maximum FPS (V_Synch) - DO NOT TURN V-SYNCH OFF if you dont need to. It tends to create ugly lines and choppy images, and you will see absolutely no difference. Because if your FPS drop below the V_Synch limit, they will equally do so without V_Synch.
there is no **** point to having a 312+ FPS if only 85-100FPS or (85Hz or 100Hz at 1024x768) of em are visible!
... and the human only seeing 30-40 of them... :p
Wow. I never knew that upping my refresh rate would help my framertes...
It doesnt.
-
Originally posted by Lightspeed
The 60 FPS limit comes from WinXP or Win2000.
On any proper OS you will have your refresh rate as a maximum FPS...
Wow. I never knew that upping my refresh rate would help my framertes...
It doesnt. [/B]
:wtf:
-
WinXP and Win2k limit games to 60 FPS normally, whereas Win98SE, Linux, and any other operating systems do not.
When V_Synch turned on on a 85 Hz screen mode you would have 60 FPS on Windows XP, but 85 FPS on Win 98.
However, (second line) if you only get 34-40 FPS, you will have 34-40 FPS *BOTH* on Windows XP and Win98. And since our eyes are only able to see about 30-40 images a second it actually doesnt change much. I expect no-one is running a screen mode below 40 Hz? :p
-
Here is what taylor had to say on this:
It's a sanity check to keep everything in sync. Without it the processing input events becomes sketchy, a/v sync goes haywire, anis play as fast as possible, etc. Anis play a frame on each page flip so if you get, say, 300fps on the mainhall then a door ani that played for about 2 seconds will now be less than 1. Same thing for talking heads, they would last a fraction of a second and you'd just get the sound. This also makes mission time be way off and a 2x setting will be closer to an 8x setting. The faster your computer can render frames the worse the problem gets. I'm not really sure why they settled on 120 but I'd guess that it's based on how fast various elements get played (anis, sound timings, etc).
Someone mentioned in that thread that Quake3 has a much higher FPS and that's true, if you use "timedemo 1" on the console. And when you do that it plays a level as quickly as possible to see how many frames it can render in a second but you would never be able to *play* that fast. In normal gameplay the FPS has a limiter to keep it playable.
-
I have NEVER seen a screen artificat due to removal of VSync - LS what it CAN do and what it does are two different things
Look back to my mathematical explaination of why you can tell the difference -
think of your framerate as the n in a Reimann Sum - it has the same properties when it comes to accuracy of the game physics as N in a Reimann Sum
-
Wooooohhhooooo :D
Damn you guys are good, yeah :D
The last time I tried the shine maps on this 600mhz pc I got 4fps
Now i`m getting 32fps, wipes tear from eye, keep up the great work, yeeehhaaaww
Thanks very much Whitelight :D
-
when I turn off VSync I constantly see problems, almost every frame, if you know what it looks like it's fairly distracting.
-
Originally posted by Lightspeed
WinXP and Win2k limit games to 60 FPS normally, whereas Win98SE, Linux, and any other operating systems do not.
Actually. I just turned up the refresh rate, and my framerates went up to the 75+ that it should be. I'm using windows 2000 by the way. :p
-
Lightspeed: That rumor that people can only see 30-40 (usually 32) images per second is just that, a rumor. There have been tests that show people can tell a difference up to something silly like 200 frames per second. I can't remember the specifics, but I know that it was over one hundred.
Also, WindowsXP defaults to only allowing a 60Hz refresh rate, no matter the mode. As far as I know, this is an extremely easy to fix bug in the operating system that Microsoft refuses to fix. Probably because setting it any higher can potentially break the monitor if the monitor isn't made for that.
-
My monitor can only hit 85 at 1024x768, kinda annoying.
-
Originally posted by Langy
Also, WindowsXP defaults to only allowing a 60Hz refresh rate, no matter the mode. As far as I know, this is an extremely easy to fix bug in the operating system that Microsoft refuses to fix. Probably because setting it any higher can potentially break the monitor if the monitor isn't made for that.
Generally this is really only a problem with 640x480 and 640x400 modes. Some stupid bug MS never got around to fixing.
Of course, if you've never set your moniter to 800x600 or 1024x768 (assuming you use a large resolution), if a game switches to those modes it'll default at 60Hz as well.
I play FSO at 1024x768. MY desktop resolution is also 1024x768@85Hz. Therefore WinXP defaults to 85Hz for 1024x768.
-
And you're all still ignoring the mathematics behind WHY 60 fps is different from 200 FPS - it all comes down to physics errors, your brain is incredibly proficient at spotting physics errors
(i don't know the physical refresh rate of the human eye... would be interesting to find out -- but if X was that limit, you would still be able to tell the difference between X FPS and 2X FPS - because of physics accuracy)
-
Kazan: Though that's not neccessarily the case. A game could still have the accuracy of a higher fps while still being in VSync at 60hz. It depends on the way the program is coded. If it is made so it can take advantage of all of the extra processing power being left behind in order to calculate all of the higher-accuracy physics, then there wouldn't be that difference between 200 and 60 FPS, except the one at 200 FPS can have visual artifacts.
-
Langy: no - high-granularity approximations are never as accurate as low-granularity approximations - that's mathematical fact
http://archives.math.utk.edu/visual.calculus/4/riemann_sums.4/
-
Originally posted by Lightspeed
... and the human only seeing 30-40 of them... :p
Lol, that's plain wrong, the human eye is not a digital camera, it doesn't divide what you see in "frames", thinking that is just silly. :)
And beside, you can CLEARLY see the difference between a game running at 40fps and one runnign at 60fps, like you can again clearly see the diference between a monitor refresh of 60 and 85 (no that i'm used to 85, putting it at 60 just hurt my eyes in a few minutes, i can easily tell when the monitor is set at 60 without looking in the options)
-
WinXP and Win2k limit games to 60 FPS normally
It's 60 Hz for OpenGL fullscreen, 75 Hz for Direct3D fullscreen, and it's because 2k/XP don't have the "Optimal" setting for the monitor refresh rate that 9x/ME does. Normally it doesn't matter what resolution you use either. Dxdiag.exe can override the D3D side, you need a 3rd-party program to override for OpenGL. (most of which do D3D as well)
-
Originally posted by ryuune75
Lol, that's plain wrong, the human eye is not a digital camera, it doesn't divide what you see in "frames", thinking that is just silly. :)
And beside, you can CLEARLY see the difference between a game running at 40fps and one runnign at 60fps, like you can again clearly see the diference between a monitor refresh of 60 and 85 (no that i'm used to 85, putting it at 60 just hurt my eyes in a few minutes, i can easily tell when the monitor is set at 60 without looking in the options)
I know it isnt. But still the human eye can only distinguish a certain number of frames per second. However, this varies for different parts of your field of view, as well as on the type of perception. While your ability to see sharp coloured pictures (cone cells) is indeed limited to around 30 a second (being aware of them, subconciously you can see more - but you will not 'see' them as a visual image) your rod cells can percieve a lot more images a second - more than 60 images :D
That's the reason why you can see monitors with lower refresh rates flicker horribly from the edge of your field of view, but see a steady image when directly looking at them.
In an actual game however, you're normally not able to see any difference between 40 and 60 FPS, what you normally get to see is if the FPS drop or rise greatly. If the FPS stay steady you will NOT see any difference.
As for monitor refresh rates, thats a whole thing altogether. It is drastic image changes (namely the image being drawn from upper left to bottom right) whereas in real life or your 3D game the framerate also has VERY subtle changes to the image to create a fluid movement. Also, you do not really see much difference in the image above ~70 Hz, except for your eyes getting tired and getting a headache (you do not see it, but feel it). As you can still see the individual screen blanks with your rod cells on 60 Hz you *can* see the monitor flicker (especially when not looking at it directly) - because of the high contrast changes.
-
The limit for the human eye is 15 FPS. Anything above, and it looks smooth, anything below, it looks like it's skipping some movements.
-
The human eye has NO limits as far as I have seen. But it does get "used" to whatever higher refresh rates you are using (and FPS of them). And that's, in my opinion, very bad. :) Using really high refresh rates will force you to always be discontent with your framerate. Whenever your framerate isn't at least that of your refresh rate its GOING to look bad.
I won't notice the difference between 85 and 100Hz/FPS until I go to 100 and then switch back later. However, I do notice a distinct difference when switching UP to 140Hz/FPS, in which case everything seems smoother...the problem is that after using 140Hz/FPS, absolutely all the frequencies/framerates below that look choppy to me. Basically, I think the brain reconfigures its "normal" idea of what a "comfortable" refresh rate is if you increase your refresh rate. Reason being, I run 640x480 at 140Hz and 1152x864 at 85Hz, and after exiting the 640x480 game I get headaches from looking at the 85Hz thing.
Also...
60FPS + 140Hz = "Choppy"
85FPS + 140Hz = "a bit choppy"
100FPS + 140Hz = "barely noticeable"
140FPS + 140Hz = "smooth"
Then if i switch back to 60Hz suddenly from 140, I get a migraine. I personally recommend 85-100Hz for all gamers for the simple reason that if you need to use someone else's computer and their refreshrate sucks you won't get a huge headache from it. Also, to avoid perceived "choppiness" in your FPS, always keep your monitor refresh rate as high as most of your games' FPS are stable at, and no higher...too high, and you risk suffering from this "raised bar" of framerate that your brain creates.
Your mileage may vary.
-
Unknown Target: That is completely and utterly false.
Look here for why (http://www.100fps.com/how_many_frames_can_humans_see.htm)
Kazan: Of course. I wasn't suggesting otherwise. What I was saying was that if the program made the physics calculations more often than it did the other visual effects calculations, like shadows and lighting, then the program could potentially be just as accurate at lower FPS as higher FPS. As I said, it depends on the way the program was programmed.
-
It's the general rule I use. Haven't you ever tracked your FPS on a comp, and found that when it dips below 15 FPS, the game begins to look choppy?
-
Below 15 it almost always looks choppy. But above 15, it also looks choppy. It looks choppy to me from about 25 and below. But I know that the human eyes can definitely see more than just 15 frames per second.
-
According to what I was taught: What happens is that anything below 16 fps is interpreted by your brain as a sequence of still images. 16 and above, your brains treats it as a moving image. It'll still look choppy until you get to just under 24 fps, the rate that most cinemas show films. I'd expect it's the higher resolution on our monitors that makes the effect more pronounced.
-
Arc: From what I know, that's incorrect. It's the lack of motion blur that makes it more pronounced. Anyways, the link I posted explains it all very clearly.
-
the brain does not work in terms of FPS - PERIOD - however it's ability to interpret is capapble of easily telling 300fps from 30fps
added to that the fact you can only have one set of physics calculations per "tick" of the engine, and the number of ticks depends on the framerate on almost all engines (engines that have asynchronus rendering and calculation are a different story)
the "Shorter" each tick - ie more per ammount of time - the better the calcuations get due to the mathmatical properties of the equasions
THIS really shows - the human eye is able to detect an error of 1 arcsecond in a supposedly straight line, or a supposedly smooth curve - etc
-
Originally posted by Kazan
the brain does not work in terms of FPS - PERIOD - however it's ability to interpret is capapble of easily telling 300fps from 30fps
added to that the fact you can only have one set of physics calculations per "tick" of the engine, and the number of ticks depends on the framerate on almost all engines (engines that have asynchronus rendering and calculation are a different story)
the "Shorter" each tick - ie more per ammount of time - the better the calcuations get due to the mathmatical properties of the equasions
THIS really shows - the human eye is able to detect an error of 1 arcsecond in a supposedly straight line, or a supposedly smooth curve - etc
Best Post I think.
Langy posted a decent site for this.
Edit;
I should probably add I think the only thing we've specifically and medically (scientifically) proven about the human eye in terms of Frames Per Second Processing, is that the brain does NOT LIKE Processing non-motion blurred images below 72 FPS for extended periods of time.
If the images are of "live action" .....say....... The Olympics, or something similiar, like Formula 1 (which is still edited for ease on the eye... but in other ways...) or football, the human brain does the same thing it does when you're actually IN that situation.
It calculates, and fill in the frames.
Sometimes when people say "Oh you blinked and missed it" isn't really you blinking and missing something, it was that your eye didn't gather enough detail on what happened to be able to extrapolate the entire sequence of events and -- rather than mixing wires(confusing you), it just ignored it completely.
-
Originally posted by Unknown Target
It's the general rule I use. Haven't you ever tracked your FPS on a comp, and found that when it dips below 15 FPS, the game begins to look choppy?
Anything higher than 25 FPS will look smooth, everything below will look choppy. Anything below 13 FPS will look as a series of images.
A that low number of images per second works on your screen, because the relatively small surface fits into your central fovea of retina - you will see a sharp image from the first to the last pixel - nearly EXCLUSIVELY with your cone cells, as the rod cells are situated around the centre of your retina. Also, they will not allow a sharp or detailed image. On your screen however, you see everything perfectly sharp (also the different depths, which you shouldnt be able to focus all at the same time) - this is why 25 FPS works perfectly to create a smooth looking image.
The human eye does have a 'maximum frames per second' however it varies in every specifc spot of the eye, depends on each individual person, on your brain, and a lot of other things. So generalizing a 'max FPS' is wrong, but you could say that around 98% of mankind would not notice any difference between 30 and 300 FPS, unless something moves incredible fast near the camera.
-
Lighty;
In FS2 the game looks choppy as hell to me when it dips to 30fps.
Being used to 85 FPS Solid everywhere else (85hz refresh and that's what most of my games play to in XP now heh).
Generally speaking the game annoys me the most when the FPS is flicking between 29-40 FPS.
Simply because of the amount of slow down in my turn, the ability to predict flight patterns, the ability to hit accurately, and my ability to gain aspect lock (I mean in 85 FPS on Vanilla FS2 I can lick a friggin helios on a myrm if they're not pure doggying ME (though if they're doggying someone else then I can) -- you've seen my do it ffs :P)
I *Know* the difference.
Whether I can see it or not, I'm not so sure, but my dodging ability also seems to be effected by FPS.
As does my ability to compete in Neocron.
....Heh.
Whether or not I can SEE the difference ...like I said, I don't know...
I sure as hell know the difference though...
-
Just wondering but why is the FPS capped at 120?
-
SUPPOSEDLY screwy things happen at higher framerates - but i have to wait until the effects get batched so they don't drag the framerates down to find out
-
Originally posted by QuantumDelta
Lighty;
In FS2 the game looks choppy as hell to me when it dips to 30fps.
Being used to 85 FPS Solid everywhere else (85hz refresh and that's what most of my games play to in XP now heh).
Generally speaking the game annoys me the most when the FPS is flicking between 29-40 FPS.
Yes, but that is something else altogether - As I said, any major changes in the framerate look *very* choppy, and will mess up everything. So when it 'dips' to 30 FPS it's indeed horrible, but if everything would be running stable at 30 FPS you would not have any problems.
Flicking FPS are what makes everything look odd and choppy, and that's exactly the thing you enforce when removing all the limits. It's a very GOOD thing it caps out at your V_synch as it (should) keep the framerate a) in synch with your VBlank, and b) keep the framerate steady.
-
Originally posted by Kazan
SUPPOSEDLY screwy things happen at higher framerates - but i have to wait until the effects get batched so they don't drag the framerates down to find out
Not SUPPOSEDLY, I removed the FPS cap on the icculus.org port a year and half ago. All of the things I mentioned were what happened when I did. With FS1 I could get just over 200 FPS without the cap so I know for sure what happens. And for the record I will NOT release a build with the FPS cap removed by default. Period.
-
taylor: for the record it's not disabled by default - you and goober need the read the thread
-
Originally posted by taylor
All of the things I mentioned were what happened when I did.
Out of interest, Just what did happen?
-
Originally posted by taylor in internal
That game caps at 120 and changing that causes quite a few problems. Problems that include mission time getting wonky, anis that play *really* fast and some stutters where there wouldn't be otherwise. The framerate cap was played with on the icculus.org version since at one time the game would become unplayably slow if the cap was hit (sleep problems). We raised it and even tried removing it (not easy) but sticking with 120 was the only thing that kept the game stable and playable.
If you are constantly getting 120fps then the only thing you've got to worry about is me coming to steal your gaming rig :D
-
Originally posted by Kazan
taylor: for the record it's not disabled by default - you and goober need the read the thread
I know it's not enabled by default now but people are going to start asking for it. It happend last time I worked on this issue. The cap is not arbitrarily there people, V put it in for a reason. Anyone who uses the command line option needs to understand that and the higher the frame rate you get the more pronounced the problems are going to be.
For everyone that will just max out at 125 or 130 FPS then you aren't going to have a noticable problem but if you are that hard up for 10 extra FPS then you need help. Professional help. I know that "timedemo 1" in Quake3 is the geek-gamer form of dick measuring but I think that's really the wrong kind of fun to get from a game.
(disclaimer: the above paragraph is from a "timedemo 1" junky. please accept those statements as pure self-denial. thank you. :drevil: )
The point is that it does cause problems and unless large portions of code are rewritten to be independant of frame rate while others are dependant then not having a cap will continue to be a problem. I looked at doing that before but decided it wasn't worth the effort involved. I don't mean to say that you (Kazan or anyone else) should not work on this but know that it may just lead to a lot of wasted time. But if you get it working without side effects then I'll... kiss the big toe on your left foot. :ick: :lol:
-
Originally posted by Kazan
taylor: for the record it's not disabled by default - you and goober need the read the thread
We did read the thread. You need to stop jumping to conclusions. We're raising legitimate discussion points.
-
I haven't seen any problems with the uncapping - i'll play more extensively later
-
*imagines how this thread would look if it were taylor who removed the cap and kazan who knew about the bugs it causes* :rolleyes:
Actually, that's quite an entertaining thought. :lol:
-
:lol:
-
i have been very iritable as of late :D
-
It's ok Don Quixote, you'll get Dulcinea one day :)
-
just went i was starting not to mind the title someone makes a reference to the book i haven't read
-
its a really good book, btw. ;)
-
:nod:
Anyway, I don't think many people hit that 120 fps limit so I don't know what the big deal is on pushing it. What do you see/feel/rub better at 250 fps than at 120? This is coming from a guy who's never had a game be at 60 or above.
-
Jocks compare what they stash in their pants... Geeks compare their FPS counts.. I think Taylor mentioned this earlier ;)
Personally I do smack head first into that 120FPS limit, but I don't mind. I'm generally happy at anything above 30
-
I had a sinister idea last night, although today it seems a bit more practical: having the FPS counter in the HUD be independent of the cap. The counter would tell you what you would get if the cap weren't there but since the cap is there you don't get the problems involved with removing it. It would only take a couple lines of code to get working so if people would like that and nobody else minds then it can be easily implemented.
-
how bout no
-
Originally posted by Kazan
how bout no
Not sinister enough then. O well. :D
-
Kazan: Why?
-
What's the point of having it? It wouldn't be an accurate representation of FPS...
-
exactly
-
well if it figured what fraction of the frame time was being used, then multiplyed the frame time be the reciprical, I think that would be fairly acurate.
-
it isn't an accurate representation of the FPS - IE the FPS number isn't the number being rendered
cheating with projections is just stupid -
-
That's like driving your car at 30 mph but the speedometer shows 90 cuz that's what it would be at if there wasn't a speed limit.
-
Originally posted by J3Vr6
That's like driving your car at 30 mph but the speedometer shows 90 cuz that's what it would be at if there wasn't a speed limit.
Which is why I called it "sinister", it is cheating. The cap is not going to be able to be fully removed though. Various parts could probably be made independent of the cap but it still has to be there or the game can get out of control. In about 3 years when hardware (and game optimization) will probably be able to push 200 fps pretty easily then people are going to complain at no end that the fps counter is capped at 120.
I don't really care either way that it's there or not since the 120 fps cap doesn't bother me any and I think it's plenty fast at that speed. Adjusting various physics stuff to better handle the fps differences might be good but I have yet to see a well coded game that didn't have some sort of fps cap in it.
-
there is absolutely no reasons why parts of it are framerate-dependant algorithmically - we can change how they're fed data to fix the problem
-
Originally posted by Kazan
there is absolutely no reasons why parts of it are framerate-dependant algorithmically - we can change how they're fed data to fix the problem
Which is what I'm hoping you'll be able to do. I couldn't figure out how to make it work correctly when I tried. It gets the frametime every frame and Sleep()'s away any time over the cap to keep it processing at that speed. Mission time is set to the frametime so if the cap is gone then the mission time goes as fast as it can. Accuracy and damage is influenced by frametime so capping that at a lower level would probably make accuracy a bit more predictable (wild a$$ guess).
Uhh, drudging this up again is making my head hurt. I'm too stupid to get around this one. I probably should have paid more attention in math class all those years ago. I can see her now "'told ya!!". :rolleyes:
-
the proper way of doing time handling - which is framerate independant requires a static last time variable
static unsigned int lasttime;
and a 'diff' variable
unsigned int timestep;
at the begining of each processing
timestep = time(0) - lasttime;
lasttime=time(0);
which obviously leads to a very small theoreticl error in time processing, but it's so insignificant that the precision loss due to the time storage format is greater
-
Doesn't it do that already (please read the last paragraph before saying it's framerate dependent)?
cap = F1_0/Framerate_cap;
if (Frametime < cap) {
thistime = cap - Frametime;
Sleep( DWORD(f2fl(thistime) * 1000.0f) );
Frametime = cap;
thistime = timer_get_fixed_seconds();
}
...
Last_time = thistime;
flFrametime = f2fl(Frametime);
This is in game_set_frametime(). flFrametime is what's passed around the game. There is a little more to it than that obviously but that's the gist of it. The Sleep() command is the only thing that's different from what you've got and it's what keeps the game processing within the cap, otherwise the cap doesn't mean much. The game would process frames as quickly as it possibly could and the capped frametime would only take affect when it's used to determine weapon damage, accuracy and a few other variables. anis would play incorrectly, sound sync would be off, etc.
This is framerate dependent obviously but with a minor change or two could also produce an additional framerate independent variable. I guess the problem I can't seem to get around is that if game processing is kept under the cap (with Sleep()) then would an independent frametime actually have the desired effect?
-
updating frames without physics updates is pointless
there shouldn't be problems with sound and animation sync unless they did something massively stupid - but it should still be fixable