Pages: [1]
  Print  
Author Topic: Is There a Reason OA Is 85FPS by Default?  (Read 5343 times)
.Luke
Nub


Cakes 2
Posts: 38



WWW
« on: January 01, 2015, 04:05:35 pm »

Haven't posted in a while, I know, but I'm a bit curious. I've also only installed Quake III once, (Always use OpenArena to load it.) so I don't remember what its default frame-rate was.

I'm asking this because I only recently noticed it. OpenArena was using more CPU time than I was expecting, given the age of the engine. (50-60%. Not doable for a laptop.) Hardcore mode is also insanely fast and difficult, so it took me some time to power through the single player sides of both OA and Quake III.

Then, I decided to look through the settings, and viola, an extremely high frame-rate that doesn't do much good on a 60hz screen. I.e, impossible amounts of screen tearing. I tuned it down to 60FPS in the config file, and CPU usage went down to a cooler 30-40%. The AIs stopped being so difficult too; I can cream any of them easily on Hardcore, even when I'm rusty. It's encouraging me to try Nightmare.

The physics settings are frame-rate dependent on default, right? That would explain why OpenArena felt too fast for me to keep up with. Does most of the community play at this frame rate for more intense speed? I recall speed is one of the appeals of playing Quake III, whereas Unreal wasn't as fast.
Logged

|
fromhell
Administrator
GET A LIFE!
**********

Cakes 31
Posts: 14481



WWW
« Reply #1 on: January 01, 2015, 10:01:18 pm »

Because that's Q3A's default, and for a long time the physics were dependent on this FPS value, and it'd make less sense to change that default to 60 anyway (compatibility in mind).  Even if your panel doesn't see all frames beyond 60 there is still a difference input response-wise.  Mine doesn't either, it's why i'm trying to code in motionblur to blend in frames that I can't see Smiley

OA shouldn't overheat that much really, it's more of a CPU choker because of the model transform processing all those verts all in a single thread, and a relatively more potential GPU fillrate choker from the detail textures.  r_lodbias 2 and r_detailtextures 0 should turn things down to a more relative 'q3 look' .  Another CPU choke is the detail textures enabling the specular stage of player model skins and weapons, which require additional light reflection calculations for it to shine.

r_flares is also heavy in 0.8.8 because it is an expensive readpixel process (it's always slow to read from video memory).   The latest engine on git adds r_flarequality which can change the method to a faster but less accurate one (and makes a big difference in fps on some maps, like pvomit)


A Pentium M laptop should handle OA even at its battery-saving speed (around 500mhz IIRC)
« Last Edit: January 01, 2015, 11:44:55 pm by fromhell » Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
Gig
In the year 3000
***

Cakes 48
Posts: 4281


WWW
« Reply #2 on: January 02, 2015, 05:39:21 am »

A few more things related with CPU usage.
IIRC, the game is single thread, so it uses a single core of the machine it any case (oh well, one may use a process as a dedicated server, and then connect to it from another process as client from the same machine....)

IIRC, in the original Q3, also setting a lower com_fps value did not help saving the CPU, because the "wait" cycle it used always consumed all available CPU time. ioquake3 did change this behavior, so in ioquake3 (and in OA) you can actually save your CPU usage by setting lower FPS. It's however possible to set the old behavior.

About framerate, its default is 85 (actually 90) because that was the original value of Q3.
Most maps were designed with either 90 fps (default value) or 125 fps (usually set by "pro" players, due to giving some adavantage with framerate-dependent physics -at default 800 gravity-) in mind. I don't know if 60 fps gives the same good effects of 125 fps... However, nowadays one can use "accurate" physics in OA, where the jumps should be fair and should be something in-between the 90fps and 125 fps physics.

For more infos:

(DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Graphic_options#Framerate
(DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Graphic_options#Com_maxfps_ranges_and_actual_framerates
(DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Graphic_options#Com_busywait

(DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Game_physics
« Last Edit: January 02, 2015, 06:15:51 am by Gig » Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
grey matter
Member


Cakes 8
Posts: 381

>9k


« Reply #3 on: January 02, 2015, 09:21:27 am »

Even if your panel doesn't see all frames beyond 60 there is still a difference input response-wise.
Both input (keyboard, mouse, joystick etc.) and output (network packets sent) depend on your FPS. You can not send more packets than your render frames/s. You can not process more packets than you render frames/s. The whole game event loop is tied to your frames/s.

Give com_busyWait 0 and a lower com_maxFPS setting a try (see Gig's post).
Logged

This space is for rent.
Suicizer
Member
Member
*

Cakes 2
Posts: 401


WWW
« Reply #4 on: January 02, 2015, 12:00:07 pm »

Even if your panel doesn't see all frames beyond 60 there is still a difference input response-wise.
Both input (keyboard, mouse, joystick etc.) and output (network packets sent) depend on your FPS. You can not send more packets than your render frames/s. You can not process more packets than you render frames/s. The whole game event loop is tied to your frames/s.

Give com_busyWait 0 and a lower com_maxFPS setting a try (see Gig's post).

So if someone tries to play with the theoretical amount of 10fps; everyone else in the server is screwed when trying to aim at that player as only 10 packets each second are being send from the server to their OA? That's quite nasty.
Logged

I'm good at everything but can't do anything...
grey matter
Member


Cakes 8
Posts: 381

>9k


« Reply #5 on: January 02, 2015, 12:21:33 pm »

So if someone tries to play with the theoretical amount of 10fps; everyone else in the server is screwed when trying to aim at that player as only 10 packets each second are being send from the server to their OA? That's quite nasty.
There are minimum values for both fps and pps, but if your (altered or slow) client does not obey them, you're warping pretty badly (Unlagged's smooth clients can only do so much).
The problem is is not server → client, as the server's fps are independent. If your client is slow, it can't send enough packets and neither can process enough incoming packets (though only the former is visible to other players).
Logged

This space is for rent.
Marterzon
Half-Nub


Cakes 0
Posts: 56



« Reply #6 on: January 02, 2015, 12:54:14 pm »

What about if my fps is set to 333, which is at 333 for all/most of the time? What are the effects when it's not at 'accurate physics'?
Logged
sago007
Posts a lot
*

Cakes 62
Posts: 1652


Open Arena Developer


WWW
« Reply #7 on: January 02, 2015, 01:04:05 pm »

What about if my fps is set to 333, which is at 333 for all/most of the time? What are the effects when it's not at 'accurate physics'?
You will jump much higher and fall much slower than everyone else. This allows you to get enormous speed. In my experience the slow fall can however also be problem as your landing spot can be easier to hit.

I tried it. I found my timing completly of and some jump pads overshot the targets by far.
Logged

There are nothing offending in my posts.
Marterzon
Half-Nub


Cakes 0
Posts: 56



« Reply #8 on: January 02, 2015, 01:55:36 pm »

What about if my fps is set to 333, which is at 333 for all/most of the time? What are the effects when it's not at 'accurate physics'?
You will jump much higher and fall much slower than everyone else. This allows you to get enormous speed. In my experience the slow fall can however also be problem as your landing spot can be easier to hit.

I tried it. I found my timing completly of and some jump pads overshot the targets by far.

Then what is your recommended fps then? After all, mine is set at 333 fps although the servers I guess are just set at Accurate physics anyway...
Logged
.Luke
Nub


Cakes 2
Posts: 38



WWW
« Reply #9 on: May 14, 2015, 06:32:45 pm »

Sorry for the late reply, I haven't been back here in a while. I still play OA and Quake III just the same, though. Smiley

Because that's Q3A's default, and for a long time the physics were dependent on this FPS value, and it'd make less sense to change that default to 60 anyway (compatibility in mind).  Even if your panel doesn't see all frames beyond 60 there is still a difference input response-wise.  Mine doesn't either, it's why i'm trying to code in motionblur to blend in frames that I can't see Smiley

OA shouldn't overheat that much really, it's more of a CPU choker because of the model transform processing all those verts all in a single thread, and a relatively more potential GPU fillrate choker from the detail textures.  r_lodbias 2 and r_detailtextures 0 should turn things down to a more relative 'q3 look' .  Another CPU choke is the detail textures enabling the specular stage of player model skins and weapons, which require additional light reflection calculations for it to shine.

r_flares is also heavy in 0.8.8 because it is an expensive readpixel process (it's always slow to read from video memory).   The latest engine on git adds r_flarequality which can change the method to a faster but less accurate one (and makes a big difference in fps on some maps, like pvomit)


A Pentium M laptop should handle OA even at its battery-saving speed (around 500mhz IIRC)

That's interesting how much is being done on the CPU, and that's one reason I have the flares turned off. (I don't turn down model or texture quality, since I like pretty games, but I can make a few sacrifices with lighting for FPS if I have to.) This is an older engine we're talking about here, so that's expected, and if you're using an Intel GPU, like me, the CPU's stuck sharing some of the load on modern games anyway. *bricked*

A few more things related with CPU usage.
IIRC, the game is single thread, so it uses a single core of the machine it any case (oh well, one may use a process as a dedicated server, and then connect to it from another process as client from the same machine....)

IIRC, in the original Q3, also setting a lower com_fps value did not help saving the CPU, because the "wait" cycle it used always consumed all available CPU time. ioquake3 did change this behavior, so in ioquake3 (and in OA) you can actually save your CPU usage by setting lower FPS. It's however possible to set the old behavior.

About framerate, its default is 85 (actually 90) because that was the original value of Q3.
Most maps were designed with either 90 fps (default value) or 125 fps (usually set by "pro" players, due to giving some adavantage with framerate-dependent physics -at default 800 gravity-) in mind. I don't know if 60 fps gives the same good effects of 125 fps... However, nowadays one can use "accurate" physics in OA, where the jumps should be fair and should be something in-between the 90fps and 125 fps physics.

So the physics are indeed frame-dependent? And I didn't know the wait cycle behavior was improved with ioquake3. One of many reasons for me to keep playing Quake III with OpenArena instead of the original engine, wow.

When I have a desktop computer, and maybe a monitor with a higher refresh rate, I'd like to turn it back up to 85-90. The AI will probably beat me to a pulp again, though, they're a lot faster and smarter at that rate too. Cry Would defrag be better at 90, though? I get the feeling wall climbing with the Plasma gun is basically impossible at 60; I can only go so high before falling back down.

60 FPS feels pretty good in the meantime. It's still fast and doesn't tear as often.
Logged

|
Gig
In the year 3000
***

Cakes 48
Posts: 4281


WWW
« Reply #10 on: May 15, 2015, 01:10:34 am »

So the physics are indeed frame-dependent? And I didn't know the wait cycle behavior was improved with ioquake3.

In early Quake3 versions, physics were framerate-dependent only. Then (I suppose due to users discovering that and exploiting that to get advantage over other players), id software added the option to use "fixed" physics, roughly to allow server admins to choose which framerate emulate for all clients (although this has got some drawbacks). OpenArena added a third way to manage physics, using floating point variables instead of integer variables, hence dodging the "rounding problem" which was behind the framerate-dependent physics (at the cost of using some more bandwidth).
"Framerate-dependent" and "fixed" physics are supported in most MODs, while "accurate" physics are OpenArena-specific and thus only work with baseoa and OA mods (based upon gamecode derived from OA 0.8.x?).

About the com_busywait thing, I may be wrong, but I think it's engine-related and not gamecode-related, and thus should work with any mod.

For more infos:

(DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Graphic_options#Framerate
(DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Graphic_options#Com_maxfps_ranges_and_actual_framerates
(DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Graphic_options#Com_busywait

(DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Game_physics
« Last Edit: May 15, 2015, 03:20:29 am by Gig » Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
Pages: [1]
  Print  
 
Jump to: