OpenArena - Recent changes [en]

Manual/Graphic options

2012-05-14T11:49:31Z

Com_maxfps ranges and actual framerates:

← Older revision		Revision as of 11:49, May 14, 2012
(4 intermediate revisions not shown)
Line 86:		Line 86:

	===Com_maxfps ranges and actual framerates===		===Com_maxfps ranges and actual framerates===
-	You may notice that your actual [[#Framerate\|framerate]] does not exactly correspond to your com_maxfps value (although your machine is powerful enough to handle it): it may even be higher. Typical case: your com_maxfps value is 85 and your framerate meter displays 90. This is due to how the engine works: while controlling the desired amount of fps, you are indirectly controlling the time to render a frame... what is important is how many milliseconds the engine has got to render a frame, and those milliseconds are discrete values; effective fps resulting, instead, can have fractional parts, but the meter "floors" them (always rounds them ''down''). This means that ''there are com_maxfps values "ranges" that have absolutely the same effect''. E.g. all com_maxfps values between 84 and 90 cause a frame every 11 ms, and thus all of them cause an ''effective framerate'' of 90+10/11 (or 90,90909090, if you prefer), that the meter rounds down to 90, altough being effectively closer to 91. If you set com_maxfps to 91, instead, it produces 100 effective fps, because it enters the range from 91 to 100 (10 msec per frame).<br />	+	You may notice that your actual [[#Framerate\|framerate]] may be a little ''higher'' than your com_maxfps value. Typical case: your com_maxfps value is 85 and your framerate meter displays 90. This is due to how the engine works: while controlling the desired amount of fps, you are indirectly controlling the time to render a frame... what is important is how many milliseconds the engine has got to render a frame, and those milliseconds are discrete values; effective fps resulting, instead, can have fractional parts, and the meter "floors" them (always rounds them ''down''). This means that ''there are com_maxfps values "ranges" that have absolutely the same effect''. E.g. all com_maxfps values between 84 and 90 cause a frame every 11 ms, and thus all of them cause an ''effective framerate'' of 90+10/11 (or 90,90909090, if you prefer), that the meter rounds down to 90, altough being effectively closer to 91. If you set com_maxfps to 91, instead, it produces 100 effective fps, because it enters the range from 91 to 100 (10 msec per frame).<br />
	A table to sum up:		A table to sum up:
	{\|		{\|
	\|''com_maxfps''		\|''com_maxfps''
	\|ms per frame		\|ms per frame
-	\|''real fps''<small>, assuming sufficient hardware (in brackets: fractional part, not shown in framerate meter, that always rounds down)</small>	+	\|''real fps'', <small>assuming sufficient hardware (in brackets: fractional part, that the framerate meter always "hides" rounding down)</small>
	\|-		\|-
	\|501...1000		\|501...1000

Game physics

2012-05-14T11:38:33Z

← Older revision		Revision as of 11:38, May 14, 2012
(3 intermediate revisions not shown)
Line 4:		Line 4:

	''Note'': if you are searching the variables to manually control in-game gravity, speed and knockback, see ''[[Special game options#Game physics]]'' instead. If you are searching info about "Vanilla" and "CPM" physics, see ''[[#Vanilla and CPM physics\|the dedicated section]]'' later in this page.		''Note'': if you are searching the variables to manually control in-game gravity, speed and knockback, see ''[[Special game options#Game physics]]'' instead. If you are searching info about "Vanilla" and "CPM" physics, see ''[[#Vanilla and CPM physics\|the dedicated section]]'' later in this page.
		+
		+	''Hint'': if the server is using "fixed" or "accurate" physics, each client's ''com_maxfps'' value does not influence player's jumps anymore... anyway it continues to control the number of frames-per-second rendered on their screens, and clients should continue to set it to a value their machine can handle constantly.

	== Frame rate dependent physics ==		== Frame rate dependent physics ==
Line 125:		Line 127:
	\| 29		\| 29
	\|}		\|}
-	Note: ''pmove_msec'' cannot take values below 8 (125 fps) or above 33 (30 fps).	+	Notes:
		+	* ''Pmove_msec'' cannot take values below 8 (125 fps) or above 33 (30 fps).
		+	* FPS values in the table above are "floored" (always rounded down), to fit the way the clients' framerate meter shows FPS.

	== Accurate physics ==		== Accurate physics ==
Line 155:		Line 157:
	* pmove_float 1 // This means that ''Accurate physics'' is enabled by default.		* pmove_float 1 // This means that ''Accurate physics'' is enabled by default.
	* pmove_fixed 0 // This means that ''Fixed frame rate physics'' is disabled by default.		* pmove_fixed 0 // This means that ''Fixed frame rate physics'' is disabled by default.
-	* pmove_msec 11 // This means that, if one would enable fixed-rate physics, it would be set to 90-91 fps emulation by default. Not important when fixed frame rate physics is disabled. <small>Trivia: in Q3A 1.32, default value was 8.</small>	+	* pmove_msec 11 // This means that, if one would enable fixed-rate physics, it would be set to 90 fps emulation by default. Not important when fixed frame rate physics is disabled. <small>Trivia: in Q3A 1.32, default value was 8.</small>
	Changes to their values are immediately effective.		Changes to their values are immediately effective.

	It is also possible to select the game physics from the menu, when setting up a new ''[[skirmish]]'' or ''[[multiplayer]]'' match using the GUI. The "Game server" menu allows to cycle between the following "Physics" values: ''Accurate'', ''Framerate dependent'', ''Fixed framerate 125 Hz'', ''Fixed framerate 91 Hz''. ''Accurate'' is the default option.		It is also possible to select the game physics from the menu, when setting up a new ''[[skirmish]]'' or ''[[multiplayer]]'' match using the GUI. The "Game server" menu allows to cycle between the following "Physics" values: ''Accurate'', ''Framerate dependent'', ''Fixed framerate 125 Hz'', ''Fixed framerate 91 Hz''. ''Accurate'' is the default option.
		+
		+	''Note:'' while, as you can imagine ''after reading this page'', "Fixed framerate 125 Hz" option sets pmove_float to 0, pmove_fixed to 1 and pmove_msec to 8 (giving 125 FPS physics)... "Fixed framerate 91 Hz" option sets pmove_msec to 11 (giving 90 FPS physics). The name "91 Hz" is due to a frame every 11 milliseconds causes 90+10/11 effective fps (or 90,90909090..., if you prefer), that is much closer to 91 than to 90 (but we aware that a com_maxfps 91 value, in a framerate-dependent server, would cause 100 fps physics instead: it would be like pmove_msec 10 in a fixed-physics server). You can read ''[[Manual/Graphic options#Framerate]]'' and ''[[Manual/Graphic options#Com_maxfps ranges and actual framerates]]'' to better understand the relationship between 90, 90+10/11 and 91, and what's the rounding behind that.

	== Mods ==		== Mods ==
Line 170:		Line 174:
	* [[Tweak#Tweaking online gaming parameters]] - Some infos about optimal settings.		* [[Tweak#Tweaking online gaming parameters]] - Some infos about optimal settings.
	* [[Manual/Graphic options#Framerate]] - When you are a client, it is important to select a framerate that your machine can provide constantly.		* [[Manual/Graphic options#Framerate]] - When you are a client, it is important to select a framerate that your machine can provide constantly.
		+	* [[Manual/Graphic options#Com_maxfps ranges and actual framerates]]
	* [[Special game options#Game physics]] - Infos about variables that control in-game gravity, speed and knockback.		* [[Special game options#Game physics]] - Infos about variables that control in-game gravity, speed and knockback.
	* [[Servers]]		* [[Servers]]

Manual/Graphic options

2012-05-14T10:00:12Z

Com_maxfps ranges and actual framerates:

← Older revision		Revision as of 10:00, May 14, 2012
(7 intermediate revisions not shown)
Line 71:		Line 71:
	You can use <tt>\cg_drawfps <0 or 1></tt> to display in the upper right corner how many frames per second (fps) your computer processes. You may check this when you are changing graphic options, trying to balance your graphic quality over speed. Default value is 0.		You can use <tt>\cg_drawfps <0 or 1></tt> to display in the upper right corner how many frames per second (fps) your computer processes. You may check this when you are changing graphic options, trying to balance your graphic quality over speed. Default value is 0.

-	You can also use <tt>\com_maxfps <number></tt> to change the maximum number of fps allowed. Default value is 85 and 0 means "no limit" (but it is ''not'' recommended!). You ''should'' set it to a framerate your machine can manage ''constantly''.	+	You can also use <tt>\com_maxfps <number></tt> to change the maximum number of fps allowed. Default value is 85 and 0 means "no limit" (but it is ''not'' recommended!). You ''should'' set it to a framerate your machine can manage ''constantly''. As [[#Com_maxfps ranges and actual framerates\|later shown]], more com_maxfps values can result in the same effective frames-per-second.

-	The game engine has an internal clock which runs at a frequency of 1 kHz -or put differently at 1000 fps- so each of the game clocks ticks has a duration of 1 millisecond (ms) exactly. The game engine can process a frame every clock tick (1000 fps) if processing a frame never takes longer than 1 ms, every second clock tick (500 fps) if processing a frame never takes longer than 2 ms, every third clock tick (333 fps) if processing a frame never takes longer than 3 ms, etc. By setting com_maxfps to a given frame rate you specify once in how many clock ticks the game engine should process a frame and more importantly how much time your computer has at maximum to process a frame. If you set com_maxfps to round(1000 / 1) = 1000 your computer has 1 ms to process a frame every clock tick, if you set it to round(1000 / 2) = 500 it has 2 ms to process a frame every second clock tick, if you set it to round(1000 / 3) = 333 it has 3 ms to process a frame every third clock tick, etc.	+	<small>''Tech note'': the game engine has an internal clock which runs at a frequency of 1 kHz -or put differently at 1000 fps- so each of the game clocks ticks has a duration of 1 millisecond (ms) exactly. The game engine can process a frame every clock tick (1000 fps) if processing a frame never takes longer than 1 ms, every second clock tick (500 fps) if processing a frame never takes longer than 2 ms, every third clock tick (333 fps) if processing a frame never takes longer than 3 ms, etc. By setting com_maxfps to a given frame rate you specify once in how many clock ticks the game engine should process a frame and more importantly how much time your computer has at maximum to process a frame. If you set com_maxfps to round(1000 / 1) = 1000 your computer has 1 ms to process a frame every clock tick, if you set it to round(1000 / 2) = 500 it has 2 ms to process a frame every second clock tick, if you set it to round(1000 / 3) = 333 it has 3 ms to process a frame every third clock tick, etc.</small>

-	Commonly used values for com_maxfps include 43, 76, 125 and even 333 because these represent sweet spots where the in-game physics (in case of "frame rate dependent physics" servers <small>-read ''[[game physics]]'' page for more info: if the server uses "fixed" or "accurate" physics, instead, the game physics should be fair for all players intependently from their single com_maxfps values chosen, if their hardware can manage them-</small>) are most advantageous to the player: the player can make higher jumps and consequentially can develop higher speed more quickly by strafing. Note: this is true while playing with the standard 800 [[gravity]].<ref>Different physics behaviors at different framerates are caused by the rounding that occurs while processing players' coordinates (that, except the case of "accurate" physics, are sent over the network as integer numbers); gravity may look like a constant here, but take in account that in some cases it may differ. Most maps use 800 gravity (and most framerate-dependent servers ''probably'' use ''g_gravitymodifer 1''), and with that, the rounding makes players jump a little higher when at 125 fps then at 90 fps. But if the gravity is different than 800, 125 fps may not give you rounding advantage anymore! At gravity 600, you will jump a bit higher at 90 fps than at 125!</ref><br />	+	Commonly used values for com_maxfps include 43, 76, 125 and even 333 because these represent sweet spots where the in-game physics (in case of "frame rate dependent physics" servers <small>-read ''[[game physics]]'' page for more info: if the server uses "fixed" or "accurate" physics, instead, the game physics should be fair for all players intependently from their single com_maxfps values chosen, if their hardware can manage them-</small>) are most advantageous to the player: the player can make higher jumps and consequentially can develop higher speed more quickly by strafing. Note: this is true while playing with the standard 800 [[gravity]].<ref>Different physics behaviors at different framerates are caused by the rounding that occurs while processing players' coordinates (that, except the case of "accurate" physics, are sent over the network as integer numbers); gravity may look like a constant here, but take in account that in some cases it may differ. Most maps use 800 gravity (and most framerate-dependent servers ''probably'' use ''g_gravitymodifer 1''), and with that, the rounding makes players jump a little higher when at 125 fps than at 90 fps. But if the gravity is different than 800, 125 fps may not give you rounding advantage anymore! At gravity 600, you will jump a bit higher at 90 fps than at 125!</ref><br />
	'''In any case''', ''it's important to pick a frame rate your computer'' (the bottleneck being your graphics card) ''can process '''constantly''''', because if processing a frame takes longer than the maximum time for a given frame rate, the game engine will drop the next frame. Unstable framerate makes the game less responsive and could even mean a packet with player information will not be sent to the server now and then. ''This also means setting com_maxfps to 0 for anything other than a performance test is a '''bad''' idea.'' <small>Talking about performance tests, you may be interested into using OpenArena as a benchmark tool: in this case, take a look to ''[[Timedemo]]''.</small>		'''In any case''', ''it's important to pick a frame rate your computer'' (the bottleneck being your graphics card) ''can process '''constantly''''', because if processing a frame takes longer than the maximum time for a given frame rate, the game engine will drop the next frame. Unstable framerate makes the game less responsive and could even mean a packet with player information will not be sent to the server now and then. ''This also means setting com_maxfps to 0 for anything other than a performance test is a '''bad''' idea.'' <small>Talking about performance tests, you may be interested into using OpenArena as a benchmark tool: in this case, take a look to ''[[Timedemo]]''.</small>

Line 84:		Line 84:

	For info about framerate-dependent, fixed and accurate physics, please read ''[[Game physics]]''.		For info about framerate-dependent, fixed and accurate physics, please read ''[[Game physics]]''.
		+
		+	===Com_maxfps ranges and actual framerates===
		+	You may notice that your actual [[#Framerate\|framerate]] does not exactly correspond to your com_maxfps value (although your machine is powerful enough to handle it): it may even be higher. Typical case: your com_maxfps value is 85 and your framerate meter displays 90. This is due to how the engine works: while controlling the desired amount of fps, you are indirectly controlling the time to render a frame... what is important is how many milliseconds the engine has got to render a frame, and those milliseconds are discrete values; effective fps resulting, instead, can have fractional parts, but the meter "floors" them (always rounds them ''down''). This means that ''there are com_maxfps values "ranges" that have absolutely the same effect''. E.g. all com_maxfps values between 84 and 90 cause a frame every 11 ms, and thus all of them cause an ''effective framerate'' of 90+10/11 (or 90,90909090, if you prefer), that the meter rounds down to 90, altough being effectively closer to 91. If you set com_maxfps to 91, instead, it produces 100 effective fps, because it enters the range from 91 to 100 (10 msec per frame).<br />
		+	A table to sum up:
		+	{\|
		+	\|''com_maxfps''
		+	\|ms per frame
		+	\|''real fps''<small>, assuming sufficient hardware (in brackets: fractional part, not shown in framerate meter, that always rounds down)</small>
		+	\|-
		+	\|501...1000
		+	\|1
		+	\|1000
		+	\|-
		+	\|334...500
		+	\|2
		+	\|500
		+	\|-
		+	\|251...333
		+	\|3
		+	\|333 (+ 1/3)
		+	\|-
		+	\|201...250
		+	\|4
		+	\|250
		+	\|-
		+	\|167...200
		+	\|5
		+	\|200
		+	\|-
		+	\|143...166
		+	\|6
		+	\|166 (+ 2/3)
		+	\|-
		+	\|126...142
		+	\|7
		+	\|142 (+ 6/7)
		+	\|-
		+	\|112...125
		+	\|8
		+	\|125
		+	\|-
		+	\|101...111
		+	\|9
		+	\|111 (+ 1/9)
		+	\|-
		+	\|91...100
		+	\|10
		+	\|100
		+	\|-
		+	\|84...90
		+	\|11
		+	\|90 (+ 10/11)
		+	\|-
		+	\|77...83
		+	\|12
		+	\|83 (+ 1/3)
		+	\|-
		+	\|72...76
		+	\|13
		+	\|76 (+ 12/13)
		+	\|-
		+	\|67...61
		+	\|14
		+	\|71 (+ 3/7)
		+	\|-
		+	\|63...66
		+	\|15
		+	\|66 (+ 2/3)
		+	\|-
		+	\|
		+	\|etc.
		+	\|
		+	\|}
		+	Simple formula to calculate the FPS (like in the counter) from a com_maxfps value:<br />
		+	<tt>fps = floor(1000/floor(1000/com_maxfps))</tt><br />

	==Lagometer==		==Lagometer==

User:Griffoso

2012-05-12T23:00:36Z

New user account

Manual/Graphic options

2012-05-12T14:21:46Z

Framerate:

← Older revision		Revision as of 14:21, May 12, 2012
(6 intermediate revisions not shown)
Line 75:		Line 75:
	The game engine has an internal clock which runs at a frequency of 1 kHz -or put differently at 1000 fps- so each of the game clocks ticks has a duration of 1 millisecond (ms) exactly. The game engine can process a frame every clock tick (1000 fps) if processing a frame never takes longer than 1 ms, every second clock tick (500 fps) if processing a frame never takes longer than 2 ms, every third clock tick (333 fps) if processing a frame never takes longer than 3 ms, etc. By setting com_maxfps to a given frame rate you specify once in how many clock ticks the game engine should process a frame and more importantly how much time your computer has at maximum to process a frame. If you set com_maxfps to round(1000 / 1) = 1000 your computer has 1 ms to process a frame every clock tick, if you set it to round(1000 / 2) = 500 it has 2 ms to process a frame every second clock tick, if you set it to round(1000 / 3) = 333 it has 3 ms to process a frame every third clock tick, etc.		The game engine has an internal clock which runs at a frequency of 1 kHz -or put differently at 1000 fps- so each of the game clocks ticks has a duration of 1 millisecond (ms) exactly. The game engine can process a frame every clock tick (1000 fps) if processing a frame never takes longer than 1 ms, every second clock tick (500 fps) if processing a frame never takes longer than 2 ms, every third clock tick (333 fps) if processing a frame never takes longer than 3 ms, etc. By setting com_maxfps to a given frame rate you specify once in how many clock ticks the game engine should process a frame and more importantly how much time your computer has at maximum to process a frame. If you set com_maxfps to round(1000 / 1) = 1000 your computer has 1 ms to process a frame every clock tick, if you set it to round(1000 / 2) = 500 it has 2 ms to process a frame every second clock tick, if you set it to round(1000 / 3) = 333 it has 3 ms to process a frame every third clock tick, etc.

-	Commonly used values for com_maxfps include 43, 76, 125 and even 333 because these represent sweet spots where the in-game physics (in case of "frame rate dependent physics" servers <small>-read ''[[game physics]]'' page for more info: if the server uses "fixed" or "accurate" physics, instead, the game physics should be fair for all players intependently from their single com_maxfps values chosen, if their hardware can manage them.-</small>) are most advantageous to the player: the player can make higher jumps and consequentially can develop higher speed more quickly by strafing.<br />	+	Commonly used values for com_maxfps include 43, 76, 125 and even 333 because these represent sweet spots where the in-game physics (in case of "frame rate dependent physics" servers <small>-read ''[[game physics]]'' page for more info: if the server uses "fixed" or "accurate" physics, instead, the game physics should be fair for all players intependently from their single com_maxfps values chosen, if their hardware can manage them-</small>) are most advantageous to the player: the player can make higher jumps and consequentially can develop higher speed more quickly by strafing. Note: this is true while playing with the standard 800 [[gravity]].<ref>Different physics behaviors at different framerates are caused by the rounding that occurs while processing players' coordinates (that, except the case of "accurate" physics, are sent over the network as integer numbers); gravity may look like a constant here, but take in account that in some cases it may differ. Most maps use 800 gravity (and most framerate-dependent servers ''probably'' use ''g_gravitymodifer 1''), and with that, the rounding makes players jump a little higher when at 125 fps then at 90 fps. But if the gravity is different than 800, 125 fps may not give you rounding advantage anymore! At gravity 600, you will jump a bit higher at 90 fps than at 125!</ref><br />
	'''In any case''', ''it's important to pick a frame rate your computer'' (the bottleneck being your graphics card) ''can process '''constantly''''', because if processing a frame takes longer than the maximum time for a given frame rate, the game engine will drop the next frame. Unstable framerate makes the game less responsive and could even mean a packet with player information will not be sent to the server now and then. ''This also means setting com_maxfps to 0 for anything other than a performance test is a '''bad''' idea.'' <small>Talking about performance tests, you may be interested into using OpenArena as a benchmark tool: in this case, take a look to ''[[Timedemo]]''.</small>		'''In any case''', ''it's important to pick a frame rate your computer'' (the bottleneck being your graphics card) ''can process '''constantly''''', because if processing a frame takes longer than the maximum time for a given frame rate, the game engine will drop the next frame. Unstable framerate makes the game less responsive and could even mean a packet with player information will not be sent to the server now and then. ''This also means setting com_maxfps to 0 for anything other than a performance test is a '''bad''' idea.'' <small>Talking about performance tests, you may be interested into using OpenArena as a benchmark tool: in this case, take a look to ''[[Timedemo]]''.</small>

Gravity

2012-05-12T14:09:45Z

Redirected page to Special game options#Gravity

New page

#REDIRECT[[Special_game_options#Gravity]]

Manual/Graphic options

2012-05-12T13:59:12Z

Framerate:

← Older revision		Revision as of 13:59, May 12, 2012
(One intermediate revision not shown)
Line 71:		Line 71:
	You can use <tt>\cg_drawfps <0 or 1></tt> to display in the upper right corner how many frames per second (fps) your computer processes. You may check this when you are changing graphic options, trying to balance your graphic quality over speed. Default value is 0.		You can use <tt>\cg_drawfps <0 or 1></tt> to display in the upper right corner how many frames per second (fps) your computer processes. You may check this when you are changing graphic options, trying to balance your graphic quality over speed. Default value is 0.

-	You can also use <tt>\com_maxfps <number></tt> to change the maximum number of fps allowed. Default value is 85 and 0 means "no limit" (but it is ''not'' recommended!). You should set it to a framerate your machine can manage ''constantly''.	+	You can also use <tt>\com_maxfps <number></tt> to change the maximum number of fps allowed. Default value is 85 and 0 means "no limit" (but it is ''not'' recommended!). You ''should'' set it to a framerate your machine can manage ''constantly''.

	The game engine has an internal clock which runs at a frequency of 1 kHz -or put differently at 1000 fps- so each of the game clocks ticks has a duration of 1 millisecond (ms) exactly. The game engine can process a frame every clock tick (1000 fps) if processing a frame never takes longer than 1 ms, every second clock tick (500 fps) if processing a frame never takes longer than 2 ms, every third clock tick (333 fps) if processing a frame never takes longer than 3 ms, etc. By setting com_maxfps to a given frame rate you specify once in how many clock ticks the game engine should process a frame and more importantly how much time your computer has at maximum to process a frame. If you set com_maxfps to round(1000 / 1) = 1000 your computer has 1 ms to process a frame every clock tick, if you set it to round(1000 / 2) = 500 it has 2 ms to process a frame every second clock tick, if you set it to round(1000 / 3) = 333 it has 3 ms to process a frame every third clock tick, etc.		The game engine has an internal clock which runs at a frequency of 1 kHz -or put differently at 1000 fps- so each of the game clocks ticks has a duration of 1 millisecond (ms) exactly. The game engine can process a frame every clock tick (1000 fps) if processing a frame never takes longer than 1 ms, every second clock tick (500 fps) if processing a frame never takes longer than 2 ms, every third clock tick (333 fps) if processing a frame never takes longer than 3 ms, etc. By setting com_maxfps to a given frame rate you specify once in how many clock ticks the game engine should process a frame and more importantly how much time your computer has at maximum to process a frame. If you set com_maxfps to round(1000 / 1) = 1000 your computer has 1 ms to process a frame every clock tick, if you set it to round(1000 / 2) = 500 it has 2 ms to process a frame every second clock tick, if you set it to round(1000 / 3) = 333 it has 3 ms to process a frame every third clock tick, etc.

-	Commonly used values for com_maxfps include 43, 76, 125 and even 333 because these represent sweet spots where the in-game physics (in case of frame rate dependent games <small>-read ''[[game physics]]'' page for more info-</small>) are most advantageous to the player: the player can make higher jumps and consequentially can develop higher speed more quickly by strafing. ''It's important to pick a frame rate your computer'' (the bottleneck being your graphics card) ''can process '''constantly''''', because if processing a frame takes longer than the maximum time for a given frame rate, the game engine will drop the next frame. This makes the game less responsive and could even mean a packet with player information will not be sent to the server now and then. ''This also means setting com_maxfps to 0 for anything other than a performance test is a '''bad''' idea.'' <small>Talking about performance tests, you may be interested into using OpenArena as a benchmark tool: in this case, take a look to ''[[Timedemo]]''.</small>	+	Commonly used values for com_maxfps include 43, 76, 125 and even 333 because these represent sweet spots where the in-game physics (in case of "frame rate dependent physics" servers <small>-read ''[[game physics]]'' page for more info: if the server uses "fixed" or "accurate" physics, instead, the game physics should be fair for all players intependently from their single com_maxfps values chosen, if their hardware can manage them.-</small>) are most advantageous to the player: the player can make higher jumps and consequentially can develop higher speed more quickly by strafing.<br />
		+	'''In any case''', ''it's important to pick a frame rate your computer'' (the bottleneck being your graphics card) ''can process '''constantly''''', because if processing a frame takes longer than the maximum time for a given frame rate, the game engine will drop the next frame. Unstable framerate makes the game less responsive and could even mean a packet with player information will not be sent to the server now and then. ''This also means setting com_maxfps to 0 for anything other than a performance test is a '''bad''' idea.'' <small>Talking about performance tests, you may be interested into using OpenArena as a benchmark tool: in this case, take a look to ''[[Timedemo]]''.</small>

	<!--The framerate multiplied by an integer must be equal one thousand. So if you use com_maxfps 125 you will get 125 frames per second because 8125 is 1000. If com_maxfps is 85 you will get 90.9 frames per second because 1190.9 = 1000.<br />		<!--The framerate multiplied by an integer must be equal one thousand. So if you use com_maxfps 125 you will get 125 frames per second because 8125 is 1000. If com_maxfps is 85 you will get 90.9 frames per second because 1190.9 = 1000.<br />
-	You should set it to the maximum fps your graphics card can deliver '''constantly''', to prevent big framerate changes during the game, which you could find annoying; remember also that your frame rate may slightly influence your in-game physics, so having them constant could make the game play a little more consistent. -->If you are using a laptop running on battery, and you want to maximize your battery duration, you could set a lower frame rate limit (maybe with a bit lower video resolution and quality settings, too) to prevent your PC from using 100% CPU (with Microsoft Windows, use your ''task manager'' to check the CPU load).	+	You should set it to the maximum fps your graphics card can deliver '''constantly''', to prevent big framerate changes during the game, which you could find annoying; remember also that your frame rate may slightly influence your in-game physics, so having them constant could make the game play a little more consistent. -->If you are using a laptop running on battery, and you want to maximize your battery duration, you could set a lower frame rate limit (maybe with a bit lower video resolution and quality settings, too) to prevent your PC from using 100% CPU (with Microsoft Windows, use your ''task manager'' to check the CPU load; with Linux, you can use "top" ''Linux console'' command).

	''Com_maxfps'' is related with ''cl_maxpackets'': for info about cl_maxpackets, please read ''[[Tweak#Tweaking online gaming parameters]]''.		''Com_maxfps'' is related with ''cl_maxpackets'': for info about cl_maxpackets, please read ''[[Tweak#Tweaking online gaming parameters]]''.

Framerate

2012-05-12T13:42:28Z

Redirected page to Manual/Graphic options#Framerate

New page

#REDIRECT[[Manual/Graphic options#Framerate]]

Servers

2012-05-11T10:37:33Z

Known Servers:

← Older revision		Revision as of 10:37, May 11, 2012
Line 40:		Line 40:
	\|Germany, Sweden		\|Germany, Sweden
	\|[http://www.gameupdates.org/details.php?id=1364 Map-pack required]		\|[http://www.gameupdates.org/details.php?id=1364 Map-pack required]
		+	\|-
		+	\|[http://www.arenawarriors.net/ ArenaWarriors]
		+	\|Italy
		+	\|Running [http://www.aftershock-fps.com/ AS] mod.
	\|-		\|-
	\|[http://cat-man-du.com/games/ cat-man-du.com]		\|[http://cat-man-du.com/games/ cat-man-du.com]

Talk:Configure GTK Radiant under Linux

2012-05-10T21:09:31Z

Tiny problems:

← Older revision		Revision as of 21:09, May 10, 2012
Line 52:		Line 52:

	--[[Special:Contributions/77.222.225.85\|77.222.225.85]] 19:22, September 4, 2009 (UTC) Mike		--[[Special:Contributions/77.222.225.85\|77.222.225.85]] 19:22, September 4, 2009 (UTC) Mike
-		+	===Links===
-	Links not working!	+	Links not working! --84.140.218.241
		+	:I tried some times to find someone able to update this page.. I hope someday (years?) someone will, hopefully updating links, too. In the meanwhile, you can try asking in the forums: http://www.openarena.ws/board Bye! ---[[User:The Gig\|The Gig]] <small>''([[User talk:The Gig\|Contact me]])''</small> 21:09, May 10, 2012 (UTC)

Talk:Configure GTK Radiant under Linux

2012-05-10T19:06:30Z

← Older revision		Revision as of 19:06, May 10, 2012
Line 52:		Line 52:

	--[[Special:Contributions/77.222.225.85\|77.222.225.85]] 19:22, September 4, 2009 (UTC) Mike		--[[Special:Contributions/77.222.225.85\|77.222.225.85]] 19:22, September 4, 2009 (UTC) Mike
		+
		+	Links not working!

OA3List

2012-05-09T14:32:32Z

← Older revision		Revision as of 14:32, May 9, 2012
Line 177:		Line 177:
	\|-		\|-
	\|Chicken		\|Chicken
		+	\| style="text-align: center;"\|
		+	\| style="text-align: center;"\|
		+	\| style="text-align: center;"\|No
		+	\|-
		+	\|Portal
	\| style="text-align: center;"\|		\| style="text-align: center;"\|
	\| style="text-align: center;"\|		\| style="text-align: center;"\|
Line 362:		Line 367:
	\|-		\|-
	\|'''Plasma Gun'''		\|'''Plasma Gun'''
-	\| style="text-align: center;"\|57%	+	\| style="text-align: center;"\|85%
	\| style="text-align: center;"\|45%		\| style="text-align: center;"\|45%
	\| style="text-align: center;"\|0%		\| style="text-align: center;"\|0%
-	\| style="text-align: center;"\|0%	+	\| style="text-align: center;"\|86%
-	\| style="text-align: center;"\|0%	+	\| style="text-align: center;"\|86%
	\| style="text-align: center;"\|Yes		\| style="text-align: center;"\|Yes
	\|-		\|-
Line 469:		Line 474:
	\|-		\|-
	\|'''Female'''		\|'''Female'''
-	\| style="text-align: center;"\|0%	+	\| style="text-align: center;"\|2%
-	\| style="text-align: center;"\|0%	+	\| style="text-align: center;"\|75%
	\| style="text-align: center;"\|Generic		\| style="text-align: center;"\|Generic
	\|-		\|-
Line 636:		Line 641:
	\|-		\|-
	\|Sorceress		\|Sorceress
-	\| style="text-align: center;"\|55%	+	\| style="text-align: center;"\|95%
	\| style="text-align: center;"\|Female		\| style="text-align: center;"\|Female
-	\| style="text-align: center;"\|0%	+	\| style="text-align: center;"\|72%
-	\| style="text-align: center;"\|0%	+	\| style="text-align: center;"\|25%
	\| style="text-align: center;"\|0%		\| style="text-align: center;"\|0%
	\| style="text-align: center;"\|0%		\| style="text-align: center;"\|0%

DeveloperFAQ

2012-05-09T01:06:32Z

How do I compile the sourcecode?:

← Older revision		Revision as of 01:06, May 9, 2012
Line 124:		Line 124:
	*probably more ...		*probably more ...

-	After that the compiling under Linux is as easy as typing 'make'. Change to the ioquake3svn148 directory and enter the command 'make'. Provided you have all the required libraries the binary openarena.i386 will be created in the ioquake3svn1438/build/release-linux-i386$ directory. You will need to change the mode to executable by entering the command 'chmod +x openarena.i386'	+	The compiling under Linux is as easy as typing 'make'. Change to the specific directory (e.g. ioquake3svn148) and enter the command 'make'. Provided you have all the required libraries the binary openarena.i386 (or openarena.x86_64) will be created in a subdirectory (e.g. ioquake3svn1438/build/release-linux-i386$ ). You may have to change the mode of the executable by entering the command 'chmod +x openarena.i386'

	====Windows user====		====Windows user====

← Older revision		Revision as of 14:32, May 9, 2012
Line 177:		Line 177:
	\|-		\|-
	\|Chicken		\|Chicken
		+	\| style="text-align: center;"\|
		+	\| style="text-align: center;"\|
		+	\| style="text-align: center;"\|No
		+	\|-
		+	\|Portal
	\| style="text-align: center;"\|		\| style="text-align: center;"\|
	\| style="text-align: center;"\|		\| style="text-align: center;"\|
Line 362:		Line 367:
	\|-		\|-
	\|'''Plasma Gun'''		\|'''Plasma Gun'''
-	\| style="text-align: center;"\|57%	+	\| style="text-align: center;"\|85%
	\| style="text-align: center;"\|45%		\| style="text-align: center;"\|45%
	\| style="text-align: center;"\|0%		\| style="text-align: center;"\|0%
-	\| style="text-align: center;"\|0%	+	\| style="text-align: center;"\|86%
-	\| style="text-align: center;"\|0%	+	\| style="text-align: center;"\|86%
	\| style="text-align: center;"\|Yes		\| style="text-align: center;"\|Yes
	\|-		\|-
Line 469:		Line 474:
	\|-		\|-
	\|'''Female'''		\|'''Female'''
-	\| style="text-align: center;"\|0%	+	\| style="text-align: center;"\|2%
-	\| style="text-align: center;"\|0%	+	\| style="text-align: center;"\|75%
	\| style="text-align: center;"\|Generic		\| style="text-align: center;"\|Generic
	\|-		\|-
Line 636:		Line 641:
	\|-		\|-
	\|Sorceress		\|Sorceress
-	\| style="text-align: center;"\|55%	+	\| style="text-align: center;"\|95%
	\| style="text-align: center;"\|Female		\| style="text-align: center;"\|Female
-	\| style="text-align: center;"\|0%	+	\| style="text-align: center;"\|72%
-	\| style="text-align: center;"\|0%	+	\| style="text-align: center;"\|25%
	\| style="text-align: center;"\|0%		\| style="text-align: center;"\|0%
	\| style="text-align: center;"\|0%		\| style="text-align: center;"\|0%