Pages: 1 2 3 [4] 5 6 ... 11
  Print  
Author Topic: Recap improvements needed in the Wiki site - Where?  (Read 289444 times)
Gig
In the year 3000
***

Cakes 45
Posts: 4394


WWW
« Reply #75 on: May 04, 2012, 03:42:23 PM »

Hi!
I was taking a look to DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Game_physics]Game physics and DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Manual/Graphic_options#Framerate]Manual/Graphic_options#Framerate (and a little of DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Tweak#Tweaking_online_gaming_parameters]Tweak#Tweaking_online_gaming_parameters).
Com_maxfps default value is 85... while closest framerates emulable via "fixed" physics mode are 83 and 90-91 (being 1000 / pmove_msec = emulated framerate... 1000 / 11 = 90 and 1000 / 12 = 83).
The question is: is there some rounding reason for which 85 and 90 fps are exactly the same, or it isn't possible to emulate 85 fps physics? And if they are not the same... what's better, 85 or 90?

PS: and what's the rounding type when calculating 1000/pmove_mesec? Always round down? 1000/11 is equal to 90,9090909090909090....
« Last Edit: May 04, 2012, 04:17:15 PM 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.
7
Member


Cakes 7
Posts: 278


Is 7 up?


« Reply #76 on: May 06, 2012, 07:58:38 AM »

The engine has an internal clock that gives a pulse every millisecond, so a frame can be rendered every clock pulse (1000 / 1 = 1000 fps), every second pulse (1000 / 2 = 500 fps), every third pulse (1000 / 3 = 333 fps) etc. It's impossible to generate frames in between clock pulses, so you cant run the engine at 700 fps for instance, it's either 1000 fps of 500 fps.

The engine rounds up com_maxfps to the nearest possible value (calculated with 1000 / pmove_msec formula), so setting com_maxfps to 85 produces a real frame rate of 90 fps. You can display the real achieved frame with \cg_drawFPS 1.

You have to always round down when calculating the frames per second (using the 1000 / pmove_msec formula), because the engine can't render fractions of frames, it either renders a full frame or it doesn't render a frame at all.
Logged

I'm on the ten most wanted list, I've got it dead in the groove.
My face is on every wanted poster in town, for the way I move.
sago007
Posts a lot
*

Cakes 62
Posts: 1664


Open Arena Developer


WWW
« Reply #77 on: May 06, 2012, 12:10:07 PM »

As I read the code in "qcommon/common.c" the engine does only round the first time to get a fixed frame size. The frame size is calculated as "floor(1000/com_maxfps)". I expect the engine to calculate 1000 frames every 11 seconds if com_maxfps = 85.

In frame rate shown with cg_drawFPS is floored/rounded* to nearest int before being drawn. The displayed value is based on the last 4 frames. It will be calculated as "4000/(11+11+11+11)" (if the last 4 frames took 11 ms to calculate)


* ANSI C demands that the result of an integer division is floored. However rounding is a faster operation, so some early (non-ANSI) C compiles did rounding instead. The lcc compiled used to compile qvm-files does (did?) rounding.
Logged

There are nothing offending in my posts.
7
Member


Cakes 7
Posts: 278


Is 7 up?


« Reply #78 on: May 06, 2012, 04:04:01 PM »

As I read the code in "qcommon/common.c" the engine does only round the first time to get a fixed frame size. The frame size is calculated as "floor(1000/com_maxfps)". I expect the engine to calculate 1000 frames every 11 seconds if com_maxfps = 85.

Rounding down an inverse (the result of a 1000 * 1/x type division) has the same effect as rounding up the x before dividing (the bigger the x, the smaller the resulting inverse). In essence the whole com_maxfps range from 84 to 90 will produce an 11 ms rendering time per frame: floor(1000 / 84) = 11 but floor(1000 / 90) = 11 also.

Quote
In frame rate shown with cg_drawFPS is floored/rounded* to nearest int before being drawn. The displayed value is based on the last 4 frames. It will be calculated as "4000/(11+11+11+11)" (if the last 4 frames took 11 ms to calculate)

Agreed, I was quietly assuming a stable frame rate, so the floor((4 * 1000) / (4 * 11)) will produce the same result as floor(1000 / 11) = 90 fps.
Logged

I'm on the ten most wanted list, I've got it dead in the groove.
My face is on every wanted poster in town, for the way I move.
Gig
In the year 3000
***

Cakes 45
Posts: 4394


WWW
« Reply #79 on: May 06, 2012, 05:14:42 PM »

Range from 84 to 90 or more?
In the table here (DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Game_physics#Fixed_frame_rate_physics
we can read that
1000/8=125
1000/9=111
1000/10=100
1000/11=90
1000/12=83
What happens to framerate if I set com_maxfps to 91, 92, 98 or 99?

And how to sum up everything for users? Simply something like "due to the way the game works, there are groups of various com_maxfps values that will give you the same actual framerate: as example, any com_maxfps value between 83 and 90 [are we sure?] will make your machine show up to 90 frames-per-second maximum." in the Framerate section of Graphic Options page, or something more precise?
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.
7
Member


Cakes 7
Posts: 278


Is 7 up?


« Reply #80 on: May 07, 2012, 02:54:28 AM »

Let's recap how it works in principle: first the engine calculates how many milliseconds it can spend on rendering a single frame from the com_maxfps value you give it, then, by rendering a frame every x milliseconds (x = calculated in the first step) it produces an actual frame rate.

So if you set com_maxfps to 84, first the engine calculates a 11 ms render time for a single frame. Then the engine starts rendering a frame every 11 ms, which gives you 90 completely rendered frames per second (fps).

What this means for the table is:

com_maxfps ms per frame real fps*
501...100011000
334...5002500
251...3333333 (+ 1/3)
201...2504250
167...2005200
143...1666166 (+ 2/3)
126...1427142 (+ 6/7)
112...1258125
101...1119111 (+ 1/9)
91...10010100
84...901190 (+ 10/11)
77...831283 (+ 1/3)
72...761376 (+ 12/13)
67...711471 (+ 3/7)
63...661566 (+ 2/3)
etc.
* assuming sufficient hardware

You can verify this yourself by setting cg_drawFPS and playing around with com_maxfps values.

edit:
A simple formula to calculate the real fps from a com_maxfps value would be:
Code:
fps = floor(1000 / floor(1000 / com_maxfps))

edit2:
Added the fractional parts of the fps calculation to the table.
« Last Edit: May 07, 2012, 10:04:54 AM by 7 » Logged

I'm on the ten most wanted list, I've got it dead in the groove.
My face is on every wanted poster in town, for the way I move.
Gig
In the year 3000
***

Cakes 45
Posts: 4394


WWW
« Reply #81 on: May 07, 2012, 04:24:53 AM »

Quote
91...100   10   100
84...90   11   90
So, you are saying that com_maxfps 90 is different than com_maxfps 91 (while being the same of com_maxfps 85)...
But then the menu option "fixed framerate 91 Hz" description is WRONG! If it sets pmove_msec to 11, it uses 90 fps physics, while "91" would have meant pmove_msec 10, and thus the physics of framerate 100, not 90.

I can imagine this is a misunderstanding born due to the fact that 1000/11 is equal to 90,9090909090909090 (one would think to round it up to 91... but it had to be floored instead!).... the problem is that now we have this 91 Hz/91 fps referenced here and there, while it is misleading.
I suppose we should search for these references and change them to 90, right? The menu option should be named "fixed framerate 90 Hz", to fit the actual thing, right?
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.
7
Member


Cakes 7
Posts: 278


Is 7 up?


« Reply #82 on: May 07, 2012, 04:48:02 AM »

It's a little more complicated still. Smiley When the engine produces a frame each 11 ms, it produces 1000/11 = 90 10/11 frames per second exactly, so it really does produce much closer to 91 fps than to 90 fps. The real problem is that the engine (as well with the com_maxfps values as with the cg_drawfps indicator) uses floored values, so we can either confuse the hell out of everyone by being more exact and rounding differently from what the engine does, or be less exact and give players a chance to understand the engine but draw flack for stating inaccuracies... That's one hot potato I'm not going to touch Wink
Logged

I'm on the ten most wanted list, I've got it dead in the groove.
My face is on every wanted poster in town, for the way I move.
Gig
In the year 3000
***

Cakes 45
Posts: 4394


WWW
« Reply #83 on: May 07, 2012, 05:54:57 AM »

[...]it produces 1000/11 = 90 10/11 frames per second exactly [...]
Excuse me, what's this "10/11 frames per second" in this sentence?
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.
7
Member


Cakes 7
Posts: 278


Is 7 up?


« Reply #84 on: May 07, 2012, 08:27:22 AM »

A simple elementary school fraction, ten elevenths.
Code:
1000      10
---- = 90 --
 11       11

edit:
I've added the fractional parts to the table in the post above.
« Last Edit: May 07, 2012, 10:06:12 AM by 7 » Logged

I'm on the ten most wanted list, I've got it dead in the groove.
My face is on every wanted poster in town, for the way I move.
andrewj
Member


Cakes 24
Posts: 584



« Reply #85 on: May 07, 2012, 10:39:49 AM »

* ANSI C demands that the result of an integer division is floored. However rounding is a faster operation, so some early (non-ANSI) C compiles did rounding instead. The lcc compiled used to compile qvm-files does (did?) rounding.
To be a bit clearer, ANSI C demands round-toward-zero behavior (-0.3 becomes 0, not -1)

From my pokings around the lcc and Q3 code (like vm_x86.c and asm/ftola), lcc creates an OP_CVFI instruction to convert a float to integer, and the VM uses '_ftol' on Windows (a built-in function which uses the current rounding mode) or on other platforms uses 'qftol0F7F' where 0F7F is the control word for round-toward-zero (i.e. ANSI C) behavior.
Logged
Gig
In the year 3000
***

Cakes 45
Posts: 4394


WWW
« Reply #86 on: May 10, 2012, 01:14:09 AM »

It's a little more complicated still. Smiley When the engine produces a frame each 11 ms, it produces 1000/11 = 90 10/11 frames per second exactly, so it really does produce much closer to 91 fps than to 90 fps. The real problem is that the engine (as well with the com_maxfps values as with the cg_drawfps indicator) uses floored values, so we can either confuse the hell out of everyone by being more exact and rounding differently from what the engine does, or be less exact and give players a chance to understand the engine but draw flack for stating inaccuracies... That's one hot potato I'm not going to touch Wink

Uhm... I'd like to write something anyway. "91 Hz physics" makes pmove_msec 11 (corrected: I initially wrote alien but it was simply a typo), which is the physics that one usually obtained with com_maxfps between 84 and 90, not 91. It's true that actual framerate of 90,909090 is closer to 91 than to 90, but on-screen rounding writes 90. A com_maxfps value of 91 would cause 100 fps (rendered -and physics, if framerate-dependent-. I don't know if 100 fps physics is better, worse or equal to 90 fps physics.) instead.
Maybe we may simply remove references to 91 Hz from the game (writing 90 instead), and in some notes in the wiki (like "trivia") writing that, although actual framerate technically being closer to 91 fps than 90, the value is rounded down to 90 (floored).

I'd like to know Fromhell's and Sago's thoughts about this.
« Last Edit: May 12, 2012, 02:56:50 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.
7
Member


Cakes 7
Posts: 278


Is 7 up?


« Reply #87 on: May 11, 2012, 08:20:09 AM »

A little correction: 91 Hz physics in the menu makes pmove_msec 10. 125 Hz = pmove_msec 8.

I think 100 Hz physics are a little better than 90 10/11 Hz, but you can't make the 125 Hz jumps by a long shot.

You can get a good idea of jump heights for different frame rates by walking up against a low wall, do a few jumps while standing still, switch to different com_maxfps and do a few jumps again, etc. As you look over the wall at the highest point of your jump, the higher over the wall the features that appear from behind it get at a certain com_maxfps, the higher the jumps (logically) must be at that frame rate. I prefer the bridge railing on ps37ctf2 for this because the two health bubbles down below are a good indicator of jump height and if the physics are 125 Hz or better I can jump on top of the railing so that's pretty obvious too.
Logged

I'm on the ten most wanted list, I've got it dead in the groove.
My face is on every wanted poster in town, for the way I move.
Gig
In the year 3000
***

Cakes 45
Posts: 4394


WWW
« Reply #88 on: May 11, 2012, 02:59:08 PM »

Are you saying that 91 hz in menu sets pmove_msec to 10 (100 fps physics), not 11 (90 fps physics)? I will have to check this tomorrow.
This sounds a bit strange, considering that the default com_maxfps value (85) causes 90 10/11 effective fps, not 100... and pmove_msec default value is 11 (trivia: it was 8 in Q3A).

Why using 100 fps physics?

And another thing... does somebody know what the "accurate" physics is more similar to? I know it is not similar to 125 fps physics... but is it more similar to 90, 100 or what?
« Last Edit: May 12, 2012, 05:53:28 PM 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.
7
Member


Cakes 7
Posts: 278


Is 7 up?


« Reply #89 on: May 11, 2012, 05:12:18 PM »

Don't check, you're right. The first sentence in your previous post is wrong so I meant to correct that, but I made a typo myself; 11 is right (the second sentence in my previous post wouldn't make sense otherwise).

I really don't know what com_maxfps setting accurate physics with g_gravitymodifier 1 is most like.
Logged

I'm on the ten most wanted list, I've got it dead in the groove.
My face is on every wanted poster in town, for the way I move.
Gig
In the year 3000
***

Cakes 45
Posts: 4394


WWW
« Reply #90 on: May 12, 2012, 03:00:26 AM »

Ah, okay... it was simply due to a typo of mine (I incorrectly typed 8 instead of 11) and then a typo of yours (you typed 10 instead of 11). Then ok, 91 Hz physics in menu sets pmove_msec to 11, emulating default com_maxfps (85, that produces 90,909090 fps).

Then, again, I'd like to know Sago and Fromhell opinions about this.
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.
sago007
Posts a lot
*

Cakes 62
Posts: 1664


Open Arena Developer


WWW
« Reply #91 on: May 12, 2012, 03:30:30 PM »

If I where to make a new mod that did not need to keep backward compatibility I would only have allowed "Accurate".

But that would have signaled mapmakers that they could assume the physics to be constant and one could get tempted to only support one physics setting. The 91/125 Hz options have been included to remind people that all maps must be playable with both com_maxfps 85 and com_maxfps 125 to ensure mod compatibility.

I liked to give them explaining names without referring to framerate. I did not felt bound to say 90, just because the framerate counter rounds incorrectly. Regardless of what it is called I don't think it can be explained in one line to a person not already familiar with Q3A physics.
Logged

There are nothing offending in my posts.
Gig
In the year 3000
***

Cakes 45
Posts: 4394


WWW
« Reply #92 on: May 14, 2012, 04:50:59 PM »

Okay guys, I added a "foot note" and a new sub-section in the section about framerate in Graphic options page
(DO NOT LINK) h t t p s : / / openarena . wikia . com/index.php?title=Manual%2FGraphic_options&action=historysubmit&diff=12502&oldid=12436
and some notes in the Game physics page (DO NOT LINK) h t t p s : / / openarena . wikia . com/index.php?title=Game_physics&action=historysubmit&diff=12497&oldid=12464

... if someone wanna check I didn't did bad errors...
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.
7
Member


Cakes 7
Posts: 278


Is 7 up?


« Reply #93 on: May 15, 2012, 06:02:20 AM »

Good job Gig, as usual Wink
Logged

I'm on the ten most wanted list, I've got it dead in the groove.
My face is on every wanted poster in town, for the way I move.
Gig
In the year 3000
***

Cakes 45
Posts: 4394


WWW
« Reply #94 on: June 16, 2012, 06:18:39 PM »

Hi guys! An IP created this page: "DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Need_music_while_playing%3F]Need music while playing?".... do you think I should simply delete it, or do you think it is possible to get something useful from it?
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.
Gig
In the year 3000
***

Cakes 45
Posts: 4394


WWW
« Reply #95 on: June 29, 2012, 02:17:51 AM »

Hi! Did someone noticed the post above this one?
What should I do?

Anyway, guys... the old Gig will get married tomorrow... so I will not be available at all for some weeks, and also then, I will have much less time for internet things... so I should be back active, but much less active than before, sorry.

In any case, it has been a pleaseure in these years with you.

Fromhell, I will not be able to take care of the wiki in the next weeks, take a look to it. Other guys: please continue expanding, correcting it, but if possible do not completely revolutionize it in the next weeks...  Smiley

BYE for now!  Smiley
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.
7
Member


Cakes 7
Posts: 278


Is 7 up?


« Reply #96 on: June 29, 2012, 06:32:24 AM »

Wishing you all the best for tomorrow and your shared future together.

Molto buona fortuna con vostro matrimonio. Tanti auguri che il vostro cammino insieme duri per tutta la vita!
Logged

I'm on the ten most wanted list, I've got it dead in the groove.
My face is on every wanted poster in town, for the way I move.
Gig
In the year 3000
***

Cakes 45
Posts: 4394


WWW
« Reply #97 on: June 29, 2012, 07:04:00 AM »

Thank you! Smiley
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.
dbX
Member


Cakes 11
Posts: 199

Shazpaca!


WWW
« Reply #98 on: June 29, 2012, 07:56:40 AM »

All the best Gig.
Logged

In defeat we learn.
Neon_Knight
In the year 3000
***

Cakes 49
Posts: 3775


Trickster God.


« Reply #99 on: June 29, 2012, 08:30:10 AM »

Best wishes for the future, and thanks for all!
Logged


"Detailed" is nice, but if it gets in the way of clarity, it ceases being a nice addition and becomes a problem. - TVT
Want to contribute? Read this.
Pages: 1 2 3 [4] 5 6 ... 11
  Print  
 
Jump to: