[Lightspeed]

its a really good book, btw.

[J3Vr6]

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.

[marajin]

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

[taylor]

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.

[Kazan]

how bout no

[taylor]

Originally posted by Kazan
how bout no

Not sinister enough then. O well.

[kasperl]

Kazan: Why?

[J3Vr6]

What's the point of having it?  It wouldn't be an accurate representation of FPS...

[Kazan]

exactly

[Bobboau]

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.

[Kazan]

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 -

[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.

[taylor]

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.

[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

[taylor]

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!!".

[Kazan]

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

[taylor]

Doesn't it do that already (please read the last paragraph before saying it's framerate dependent)?

Code: [Select]

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?

[Kazan]

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