I noticed in the new Thief 1 and Thief 2 patch that the physics engine was decoupled from the rendering engine and capped at 60 fps (or ms equivalent). This allows the rendering engine to render as many FPS as possible or limit it to whatever the user wants.

Now with the release of Doom 3 source code, is this not also a possibility? Or is the physics code tied to tightly to the renderer?

I already thought D3 render was decoupled from the game time.

D3 renderer is limited to 60 fps so physics don't go all wonky. If you remove that limit with the cvar com_fixedTic by setting it to 0 will allow the FPS to go higher, but if your fps drops below like 20 or 30, then you slow down and feel like you are moving through molasses. The opposite it also true if it goes too high your movement speed is increased as well.

EDIT:

Hmm, found this info;

com_fixedTic [-1,0,1] - If set to 0 (the default) Doom 3's ticrate is capped at 60FPS, meaning the game framerate cannot exceed this, except when running a timedemo. If you want to remove this cap, set com_fixedTic to -1. Setting it to 1 removes the cap, but causes the game physics to go out of sync. Removing the FPS cap doesn't necessarily improve performance, and can lead to more variable framerates. Note that com_fixedTic -1 doesn't work as of the latest patch.

I've never noticed the physics going out of sync. I thought that rate was defined in the engine code and was unrelated to whatever you're seeing.

You can try it yourself, "com_showFPS 1". Even with VSync off, it won't go higher then 60 fps.
Then try com_fixedTic 0 then try it with 1 and then turn everything way down so the game runs really fast like 150 fps. Then try running at normal speed.

I know how the tic system works, but the physics is synced to the tic, irregardless of how fast the video renders. 1 tic = 1 tic to the physics. If they were linked then it would be 1 frame = 1 tic, so 100fps = 100 tics per second, 10fps = 10 tics per second.

Telling it to speed up/slow down the game will make things go faster but it will always be one game frame = one tic. One video frame could be many, or fractions of, a single tic.

So did you try it in game to verify your point? As that is not what I experienced.

EDIT: And irregardless is not a word. It's a double negative and makes me cry whenever I see it.

EDIT 2: I take that back looks like it's been added to many dictionaries online :oops:

Still it's a retarded word as 'ir' which means 'not' and 'less' means 'without'. However most dictionaries list it as incorrect or nonstandard. Still it makes me cry whenever I see smart people use it in prose.

What's the point of getting more than 60 fps when rendering?

If user has weaker machine, it will not make the game run faster.

I'll have to look in to the stock code more, but com_fixedtic only seems to be used for changing the current tic if it's above 0 & the drawfps only uses milliseconds.

motorsep wrote:

What's the point of getting more than 60 fps when rendering?

If user has weaker machine, it will not make the game run faster.

I'm just going to ignore this.

Thank you for looking into this though. Unlocking FPS cap without screwing up physics would be perfect.

I am just trying to understand your logical position that, that's all.

It's like another programmer user to have 1000 fps using DarkPlaces engine, without any rt lights (pure Quake basically). Then engine grew and matured (or whatever engine team did to it), and he got "only" several hundreds fps (I don't recall exact number, but more than enough). That was OMG moment which is 100% illogical and was based on "I just want to have 1000 fps again".

You only need 120 fps stable for VR headmount or 3D TV/monitor or glasses.

motorsep wrote:

I am just trying to understand your logical position that, that's all.

Games pre-D3 era (from what I understand, HL2 had a fixed tic rate too) use the display FPS to also control the physics. I don't know the whole story, but that's what many Q2 players don't like to play on servers where the server caps the server FPS at certain rates (same with HL1) because they can't do certain things based on math rounding. For example (just an example), in Quake 2 if you're running at 60fps (remember, display is locked to game tic in Q2, so 60fps display = 60 fps to engine), you can't make the same jump distances as 120fps. I'd imagine DP still does the same if that's considered an issue (r1q2 based on quake 2 unlocked them and they're both customizable). It's not a magic number of higher = better either, I've read the "magic" numbers are multiples. IE it could be every 20fps. So, imagine a sin graph where X = jump distance and Y = game FPS, the high jump points could be multiples of 20fps.

D3 eliminated that by locking the games @ 60 fps but the display isn't locked at that (if the render goes higher or lower the game still runs at 60fps). IE if I tell D3 to wait 1 frame in a script, it waits 1 frame. If I tell Q2 to wait 1 frame (1000ms), it waits 1 VISUAL frame, which is a variable of milliseconds. could be 1000ms, could be 950ms, could be 1500ms, all depending on how fast things are going.

Increased server fps also increase CPU load, and from what I'm told it can make a Q2/HL1 server actually use more CPU load then a D3 server (laughable, but when I see how much CPU D3 uses on my server, but it's true).

EDIT: com_fixedtic -1 used to unlink them. So something was changed somewhere.

And that was my understanding also pretty much.
The same with Q3/QuakeLive, you want 125 fps so you can get the highest/furthest jumps, anything more doesn't make much difference but anything less does.
However what I experienced in Doom 3 was that when I set fixedtic to 1, when my FPS in Doom 3 dropped to like 30 fps, the whole game slowed down to half it's normal speed, like I was moving in slow motion. Doors would open really slowly. And the opposite was also true, at 135 fps, doors would open really fast and I could run pretty quick about double speed.

I'll try it again though.

EDIT: Just tried it with Steam's Doom 3 and yes setting com_fixedTic to 1 makes the game go fast or slow depending on FPS.

motorsep wrote:

I am just trying to understand your logical position that, that's all.

It's like another programmer user to have 1000 fps using DarkPlaces engine, without any rt lights (pure Quake basically). Then engine grew and matured (or whatever engine team did to it), and he got "only" several hundreds fps (I don't recall exact number, but more than enough). That was OMG moment which is 100% illogical and was based on "I just want to have 1000 fps again".

You only need 120 fps stable for VR headmount or 3D TV/monitor or glasses.

Yes that is one reason to unlock the FPS. What if I wanted my game to sync with my Plasma refresh rate of 600 hz? Probably impossible, but it's worth trying and it's nice having the option. Hell console devs keep telling us you don't need more then 24-30 fps anyways, so let's lock all PC ports to that also. It's total bullshit. I didn't get 2 5870s to have them run at 12% utilization.

AluminumHaste wrote:

...so let's lock all PC ports to that also. It's total bullshit.

Indeed it is, because Doom 3 was not developed for consoles. It was developed for PC.

AluminumHaste wrote:

I didn't get 2 5870s to have them run at 12% utilization.

And yet, any movies you watch still run at 24/29.97 fps (depending what country you are in) on your plasma screen with 600Hz refresh rate. Doom 3 is not competitive online shooter where you need to jump higher/farther. 60fps is more than enough for smooth motion/animation/physics in game. As far as refresh rate, use r_displayRefresh cvar and then vid_restart.

AluminumHaste wrote:

motorsep wrote:

I am just trying to understand your logical position that, that's all.

It's like another programmer user to have 1000 fps using DarkPlaces engine, without any rt lights (pure Quake basically). Then engine grew and matured (or whatever engine team did to it), and he got "only" several hundreds fps (I don't recall exact number, but more than enough). That was OMG moment which is 100% illogical and was based on "I just want to have 1000 fps again".

You only need 120 fps stable for VR headmount or 3D TV/monitor or glasses.

Yes that is one reason to unlock the FPS. What if I wanted my game to sync with my Plasma refresh rate of 600 hz? Probably impossible, but it's worth trying and it's nice having the option. Hell console devs keep telling us you don't need more then 24-30 fps anyways, so let's lock all PC ports to that also. It's total bullshit. I didn't get 2 5870s to have them run at 12% utilization.

If you were forced to imagine a reason why game developers want standardisation, at gun point, could you come up with a valid reason?
I can, I think. The issue is (and usually was) support. Where the user range has grown, it's intelligence has not. Where games, 15 years ago, were still played by the nerds and game-elite (frowned upon by the rest of humanity at that time if I might add) the users were smart enough to figure out most issues that popped up.

Not these days.
These days you have people that don't have the first clue about computers, demanding that it's a flawless experience... Just not understanding that with extra customisation options 'comes responsibility'. So the support forums are filled with crap users asking crap questions about crap problems that 75% of the time they created themselves.
Times... have changed. And no matter how contrived that sounds, it's the hard business truth. What good is profit when you have to spend it on crap support?

And I don't think support is the only reason for standardisation either, both in technology and in gameplay features.
People are complaining that MP should be 'cross-platform', how's that going to work out with a different gameplay experience depending on OS and computing capability?
I can tell you, not well. There will naturally be a pre-dominant platform (most likely PC) if all MP games would be cross-platform.

And I don't think that those two are even the only reason to choose standardisation over customisation.
Customisation means extra programming. And not not just a bit of extra programming, but a f''ing lot of extra programming.
Because when you uncap a feature you also have to make sure you're not blowing up hardware (this DID happen in the past and people complained about that less back then also. If some piece of hardware were to blow up due to Call of Duty then trust me, hell would break lose on Twitter, Facebook and the entire intarwebs..). So you to have program all these safeguards that you usually wouldn't have to create because you capped those dangerous values to begin with.

And besides those three reasons there are 10 more very good business reasons to choose standardisation over customisation.

So no matter how much you and I like to be able to tweak our games to bits... forget about it, it's just not going to happen and for some bloody good reasons to boot.
Sorry.

Excuse me but did you just blame faulty hardware on software? How is it the fault of any game company that ati or nvidia approved an inadequate cooling solution because most people will never push their hardware that hard?
Just take a look at all the flak that blizzard got in regards to starcraft 2s in game running at 3000 fps and inadequately cooled hardware overheated and melted.
Blizzards fault? No fucking way in hell.

AluminumHaste wrote:

Excuse me but did you just blame faulty hardware on software? How is it the fault of any game company that ati or nvidia approved an inadequate cooling solution because most people will never push their hardware that hard?
Just take a look at all the flak that blizzard got in regards to starcraft 2s in game running at 3000 fps and inadequately cooled hardware overheated and melted.
Blizzards fault? No fucking way in hell.

No I did not. You can't call hardware faulty when a dumbass uses some program to turn off the fan and the CPU burns out. Just like you can't call hardware faulty when a user downloads a display driver that forces the VSync to 120 on a 60hz monitor (hence blowing out both his card and monitor, yes this can happen). All you can do is blame the user, which was the entire point of my 'f''ing' post.

Personally, I don't care for all these tuneup cvars. I never miss them in modern games if developers bothered to put just enough options to tune performance from the menu. I don't go for "last drop" fps I can squeeze out of the game. Are you there to play a game or fool around with cvars?

motorsep wrote:

Personally, I don't care for all these tuneup cvars. I never miss them in modern games if developers bothered to put just enough options to tune performance from the menu. I don't go for "last drop" fps I can squeeze out of the game. Are you there to play a game or fool around with cvars?

It's like you're at a race track asking why people need more than a Smart car. :mrgreen:

I think you need to remember what site you're on. This is a modding site for an 8 year old game. For many people playing the game hasn't been interesting for almost 8 years.

Changing the game, modifying whatever is possible, is the point. Understanding how the physics and rendering are related, how that could be changed, and why developers make the decisions they do is the kind of thing that should be discussed here. It's far more than just squeezing out extra fps.

And even getting more fps and proper physics can be beneficial to some users. People vary in their sensitivity, and while some can play a game and never notice the differences, it can drive others crazy.

stabinbac wrote:

Changing the game, modifying whatever is possible, is the point. Understanding how the physics and rendering are related, how that could be changed, and why developers make the decisions they do is the kind of thing that should be discussed here. It's far more than just squeezing out extra fps.

Which isn't related to the desire on the first poster to relate game fps and his screen's refresh rate

stabinbac wrote:

... it can drive others crazy.

Good thing that group is a minority

BloodRayne wrote:

AluminumHaste wrote:

Excuse me but did you just blame faulty hardware on software? How is it the fault of any game company that ati or nvidia approved an inadequate cooling solution because most people will never push their hardware that hard?
Just take a look at all the flak that blizzard got in regards to starcraft 2s in game running at 3000 fps and inadequately cooled hardware overheated and melted.
Blizzards fault? No fucking way in hell.

No I did not. You can't call hardware faulty when a dumbass uses some program to turn off the fan and the CPU burns out. Just like you can't call hardware faulty when a user downloads a display driver that forces the VSync to 120 on a 60hz monitor (hence blowing out both his card and monitor, yes this can happen). All you can do is blame the user, which was the entire point of my 'f''ing' post.

Well yeah, if a user does stupid stuff to their hardware then yes it's their fault. But the cases I outlined above, in which a user installs a game, doesn't modify his system at all, and the game causes the GPU to overheat because of inadequate cooling, well that's not the users fault or the software's fault.
My coworker is actually part of the Toshiba class action lawsuit in regards to inadequate cooling with putting P4 desktop processors in the laptops with little cooling.
And how can you force 120hz on a 60hz monitor? The monitor would just report "Out of Range" or just give you a black screen. Are you talking about ancient circa 1990s CRT monitors? Also why would this blow up his card? How? Killing the RAMDAC?

Anyways this is all off topic to the OP. You guys don't see the point of anything over 60 fps in Doom 3 I get it. Thank you for stopping by to contribute to my request.

AluminumHaste wrote:

You guys don't see the point of anything over 60 fps in Doom 3 I get it.

I don't see the point as there is no correlation between refresh rate of your plasma screen and in-game fps. You can run Quake at 1000 fps on 60Hz screen.
I gave you cvar that specifically increased refresh rate. Have you tried it?

On the other note, all idTech based games prior to idTech 4 have simplistic physics. So when physics goes out of sync, it doesn't have much negative effect on the game. It's quite opposite with idTech 4 and perhaps many modern engines with complex physics.

motorsep wrote:

AluminumHaste wrote:

You guys don't see the point of anything over 60 fps in Doom 3 I get it.

I don't see the point as there is no correlation between refresh rate of your plasma screen and in-game fps. You can run Quake at 1000 fps on 60Hz screen.
I gave you cvar that specifically increased refresh rate. Have you tried it?

On the other note, all idTech based games prior to idTech 4 have simplistic physics. So when physics goes out of sync, it doesn't have much negative effect on the game. It's quite opposite with idTech 4 and perhaps many modern engines with complex physics.

The plasma screen was just an example because you talked about 60-120hz displays. My laptop monitor only refreshes at 60 hz.
And yes there is no correlation between refresh rate and in-game fps, however there is a noticeable difference between 60 fps and 125 or 200 fps in the way a game feels, how it responds to mouse/keyboard inputs.
Games like Mirror's Edge or Quakelive show this where even 60 fps induces slight lag in movement that can be frustrating for people who notice these things. 125 fps is preferable and I have ME running at over 150 fps and that seems about perfect for any situation in the game.
While Doom 3 might not be fast paced, that doesn't mean that every mod based on this engine will also be slow paced. Hell even ID thought it worth it to up the FPS limit in the BFG edition to 120 fps.

motorsep wrote:

Which isn't related to the desire on the first poster to relate game fps and his screen's refresh rate

Read the original post again. It's about separating the graphics from the physics to get a consistent physics performance no matter what the graphics rate is.

A decoupled system could have physics updating 120 times per second even if the graphics is capped at 30 fps. The screen would update slowly, but the input and action would be updating 4 times for every frame drawn.

Alternatively you could have a slowly updating system ticking in 10 times per second, but still deliver a smooth 60 or 120 fps out of the graphics. That's obviously a horrendous extreme, but it's something not possible in a coupled system.

It might also be fun to have a variable update rate on the physics while maintaining a constant graphics frame rate.

AluminumHaste wrote:

Hell even ID thought it worth it to up the FPS limit in the BFG edition to 120 fps.

Is that only because they need double the frames to get 60 fps in 3D?

AluminumHaste wrote:

Hell even ID thought it worth it to up the FPS limit in the BFG edition to 120 fps.

Is that only because they need double the frames to get 60 fps in 3D?[/quote]

Perhaps, but even without 3D you get 120fps

There is a difference between 120 FPS and 60 FPS. It's not all about how smooth it LOOKS.

If 60 FPS means 60 tic, then your input is only being captured 60 times in a second. If 120 FPS means 120 tic then it's being captured 120 times in a second. And so one may argue that well who cares if your input is being captured faster if it only renders it at 60hz. The point is, in a twitch action game like Quake 3 when the human reaction time is very important and a guy pops around the corner and I fire in "between" frames by the time it renders then next frame on my monitor it's all ready been processed and he's hit. Even the sound will technically play before I even see it. When you're playing online, that means your client will tell the server more accurately when you press that mouse button, and assuming all players have the same ping but you're the only one with an FPS above 60, that means YOU have the advantage.

It just feels smoother.

That being said, I've never noticed Doom 3 being capped at 60 fps with Vsync off... Maybe I should install it again and check it out.

Doom 3 isn't a twitch shooter and will never be, unless networking will improve drastically.

motorsep wrote:

Doom 3 isn't a twitch shooter and will never be, unless networking will improve drastically.

Mods for doom 3 can be whatever the hell modders want it to be now that the source code is out. That's partly why I am asking. But I guess since no one seems to care about it except to say that more then 60 fps is not needed. Might as well delete this thread, it's going nowhere.

It's been a pretty productive thread already. I learned some things, but beyond that I haven't read anything that makes it sound like anything more than 60hz is needed unless you want 60fps 3D support.

bkt wrote:

It's been a pretty productive thread already. I learned some things, but beyond that I haven't read anything that makes it sound like anything more than 60hz is needed unless you want 60fps 3D support.

OMG not 60 hz, this has nothing to do with display refresh. Doom 3 caps it's renderer at 60 FRAMES PER SECOND, this is evident to anybody using GPUz to monitor the GPU utilization. Even at 1920x1200 with 16AF and 8xAA, Doom3 is only using like 40% of my GPU. If you don't understand why people would like a higher frame per second output even if those frames are not displayed on the monitor, thank you point taken, please fuck off, for christs' sake.

God what a pointless website. Asking general engine questions about Doom3 on a website titled Doom3world.org is apparently pointless. To the person who originally was looking into the engine, thank you very much for your time and expertise, it was greatly appreciated. However the overall response is that everybody is happy with 60 fps and are not interested in anything to make Doom 3 render more frames, even wasteful ones.

AluminumHaste wrote:

OMG not 60 hz, this has nothing to do with display refresh. Doom 3 caps it's renderer at 60 FRAMES PER SECOND, this is evident to anybody using GPUz to monitor the GPU utilization. Even at 1920x1200 with 16AF and 8xAA, Doom3 is only using like 40% of my GPU.

That's totally unrelated issue o_O idTech 4 is CPU heavy, if you haven't noticed and did some R&D on the subject. No matter what GPU you have, it will never use its potential because that's how engine is programmed - to utilize CPU for many things that could be on GPU nowadays. And it has nothing, absolutely nothing to do with physics engine.

AluminumHaste wrote:

If you don't understand why people would like a higher frame per second output even if those frames are not displayed on the monitor

I don't understand your ultimate goal because you can't explain it. Decoupling physics from rendering to utilize full potential of GPU is ... nonsense.

AluminumHaste wrote:

God what a pointless website.

There is no other site on the subject, so...

It's okay don't bother I got my answer

Long and short the answer is no it won't be done. Save your braincells my friend, this topic is not worth your time.

The main idea was to unlock the FPS cap in Doom 3 to let the renderer render as many frames as possible like normal games. But when you do that with com_FixedTic, the game speed itself slows down and speeds up by how fast everything is being rendered.

So if your game is running at 120 fps, everything in game will run a twice normal speed. you walk twice as fast, barrels move twice as fast, doors open twice as fast etc.
The opposite is also true in where 30 fps causes the game to run twice as slow.

The question was to remove the renderer from game tic and limit the physics system to 60 fps or ms equivalent.

Then everybody came in saying that was pointless and you don't need more then 60 fps anyways, while offering nothing useful except the guy who originally responded who actually took the time to look at the source code. Thank you to him.

AluminumHaste wrote:

Then everybody came in saying that was pointless and you don't need more then 60 fps anyways, while offering nothing useful except the guy who originally responded who actually took the time to look at the source code. Thank you to him.

On every forum there's always a noise to signal ratio.

Over the years I tried my best to suppress the noise, knowingly at the expense of mainstream popularity.

I'm unhappy to hear you're dissatisfied with our service albeit you got what you needed.

Also people bitching about 60 vs whatever frames can easily get attributed to a full decade of advertising alternated by hardware or software vendors that every frame beyond 60 is wasted. What you hear is an echo, keep that in mind.

Very true, thanks for stopping by BNA, haven't seen you in a while. I was judging the forums based on responses, nothing against the Admins or moderators. You can close this thread now as this discussion is going nowhere.

AluminumHaste wrote:

Very true, thanks for stopping by BNA, haven't seen you in a while. I was judging the forums based on responses, nothing against the Admins or moderators. You can close this thread now as this discussion is going nowhere.

My pleasure - I'm always here

But I'll keep the thread open, you'll hever know where and when it leads to something interesting.

I also believe if you'd written "60 frames rule" you would have gotten the same antagonizing responses the other way around.

There's real life and forum reality, each rabbit hole has it's perks

For what it's worth, I agree that it is worth someone looking at the 60fps lock, but I probably don't have time to look into it myself at the mo.

The way q4 players reacted to si_fps 90/125 it is clear that lots of people can tell the difference of changing the rate that is currently locked at 60. The question in my mind is which part?

In the d3 engine, lots of things are locked together because of the original network design, so we aren't talking about just framerate, but the simulation of the world on both client and server, and the way that interacts with the network. As currently designed, all clients need to have the same tickrate, which is a big downside to just tweaking the frametime constants.

For what it's worth, the physics and framerate aren't fundamentally linked in the same way as the old q3 floating point rounding bugs. To set it to 125fps should be as simple as changing some constants from 16 to 8. The physics will be fundamentally similar though - you won't jump further etc.

Com_fixedTic 1 simply tells the engine to not delay until the next tick, which isn't a good solution. It sounds as if someone had a go at coding a better solution with the now disabled -1 case, but I guess that didn't actually work. I guess this shows the difficulty of getting a correct solution.

It's maybe worth also highlighting that SD decoupled the renderer in etqw so that the renderer could go at multiples of the game tickrate, and lowered the game/server tickrate to lower client and server CPU loads (I guess that was the main reason). They did get bitching about the fact that things didn't move smoothly because the client game code was running at a lower framerate though (so affecting anims etc)

Now that is interesting to know thank you for your post

That explains a lot of why Id made the decisions that they did in developing this engine.

I'd be interested to see if this is fixed in BFG. This is one of the show-stopper bugs for me for using idtech4 for anything, along with the netcode. As one of the elite PC gaming master race I can tell if a game is running at 60fps vs 100fps. 60fps in a fast MP plays like crap to be honest. Almost any game at 30 fps just isn't playable at all to me. I get ~70fps in Skyrim and it's almost too low.