Outils pour utilisateurs

Outils du site


Panneau latéral

Sidebar

doc:joueur:physique_fps

Physique du jeu et nombre d'images par seconde

OpenArena a hérité d'une particularité du moteur de Quake 3 qui rendait la physique du jeu (telle que la gravité) dépendante du nombre d'images par seconde (frame per second, abrégé en fps). Un effet notable, c'est qu'une personne possédant un haut fps pouvait sauter par dessus un muret par un simple saut (comme celui au centre de la carte ps37ctf) tandis qu'une autre ayant moins de 60fps ne pouvait pas.

download.tuxfamily.org_openarena_files_screenshots_l_ps37ctf_muret.jpg

Cette petite injustice n'est bien sûr pas souhaitable, et depuis la version 0.8.5 un mécanisme supplémentaire (pmove_float) a été ajouté pour apporter une solution à cette question, et permet d'homogénéiser la physique quel que soit le fps de la machine sur lequel le jeu tourne.

Hélas, le résultat obtenu par cette nouvelle méthode, certes plus fair-play, aboutit à sauter légèrement moins haut que par l'ancienne méthode dans le cas optimal (estimé à 125fps). Or, de nombreuses maps ont été conçues sur ces anciennes bases. Il arrive donc que l'on ne puisse pas franchir certains blocs de murs. La solution consiste, d'une part, à changer ponctuellement la gravité, avec g_gravity ou g_gravityModifier. Elle consiste, d'autre part, à ce que les nouvelles maps soient élaborées sur ces nouvelles bases.

Hormis ce détail qui ne vous gênera que sur certaines maps, vous n'avez plus à vous en préoccuper. La suite de l'article est utile uniquement aux curieux ou bidouilleurs.

3 approches

Préalablement à l'existence de cette variable magique, d'autres variables permettaient d'avoir une influence sur la physique. Nous distinguons ainsi 3 approches:

  1. physique dépendante du fps, bridage du fps par com_maxfps
  2. physique indépendante du fps, ajuster pmove_float à 1 (la méthode par défaut dans OA 0.8.5+)
  3. physique indépendante du fps, ajuster pmove_fixed à 1 (qui était une tentative, mais qui a d'autres défauts)

Physique dépendante et com_maxfps

D'abord, le but n'est pas d'avoir le plus haut fps, car pour des raisons propres à la manière dont est conçu le moteur de jeu (que l'on peut expliquer mathématiquement, 'tention c'est compliqué), certains taux d'images par seconde sont plus intéressants que d'autres. En particulier, avoir 125 en fps est considéré comme le plus pertinent par la communauté des joueurs. Et étant donné que cela fait plus ou moins office de norme, les cartes sont également adaptées pour être bien jouées avec ce fps.

Voici une liste des valeurs ayant normalement un effet positif notable: 43, 45, 47, 50, 52, 55, 58, 62, 66, 71, 76, 83, 90, 100, 111, 125, 142, 166, 200, …

Nous noterons aussi qu'il n'est pas souhaitable que votre fps fluctue entre ces valeurs intermédiaires, et que les effets sont accrus si vous gardez un fps constant sur l'une de ces valeurs. Pour parvenir à limiter ces fluctuations, l'une des variables clé est com_maxfps.

Com_maxfps est une variable qui bride le nombre maximum d'images par seconde affichées à l'écran. En l'ajustant à une valeur en accord avec ce que permet d'obtenir votre matériel, vous pouvez donc vous arranger pour obtenir un fps plus constant. Par défaut sur la plupart des versions d'OA, elle est réglée à 90. Si vous avez une suffisamment bonne carte graphique, et que vous jouez sur un serveur où la physique est dépendante du fps, nous vous conseillons donc d'entrer un /com_maxfps 125 dans la console. Toutefois cette valeur peut aussi être à votre désavantage et vous amener plus plus loin que ne vous le souhaiteriez. Par exemple, sur oa_ctf4ish, cette valeur vous oblige à freiner pour ne pas tomber dans le vide lorsque vous rejoignez l'une des plateformes en hauteur où se situe le railgun, ce qui n'est pas nécessaire si vous bridez à 90.

Bien sûr, hormis com_maxfps qui bride la limite superieure, si vous disposez d'un ordinateur un peu ancien, vous aurez également des difficultés à atteindre 125fps. Parfois vous l'atteindrez sur certaines maps mais sur d'autres non, certains effets graphiques peuvent aussi provoquer des baisses momentanées de fps. Vous pouvez dans ce cas consulter l'article sur le réglage des détails graphiques du jeu pour espérer gagner des fps. Les cas suivant décriront de toute manière des solutions pour avoir une physique adéquate même si votre matériel n'est pas en mesure de fournir suffisamment de fps.

pmove_float

Réglée sur 1 par défaut, ce réglage devrait être le plus commun sur les serveurs d'OA 0.8.5 et ulterieur. Dans ce cas-ci, la physique n'est plus dépendante du fps. L'avantage, c'est que même si vous avez un fps assez bas, tous les joueurs seront mis à pied d'égalité concernant la physique. L'inconvénient, c'est qu'utiliser cette solution consomme davantage de bande passante (au pire des cas par un rapport de 32 ! mais en pratique l'excès avoisinne plus souvent les 2Ko/sec). Un second désavantage, c'est que la physique émulée n'est pas identique à celle obtenue lorsque l'on a 125fps. Vous sauterez donc moins haut que la physique avantageuse dont nous parlions plus haut. Pour illustrer cet “hélas”, le muret de ps37ctf ne peut être franchi d'un simple saut lorsque pmove_float est ajusté à 1. Etant donné que cette physique reste une référence et que la jouabilité de certaines maps reposent dessus, il est toutefois possible d'y remédier. L'astuce consiste simplement pour l'administrateur du serveur à changer la gravité (g_gravity). En ajustant la gravité à 790 (au lieu de 800 par défaut) il devient de nouveau possible de franchir ce muret.

pmove_fixed

pmove_fixed a le même rôle que pmove_float. Cette variable est surtout connue de ceux qui jouent au mode Defrag, car pouvoir franchir les obstacles est d'autant plus crucial dans ce mode. Son avantage réside dans le fait qu'il simule bien la physique obtenue avec un taux de 125fps, même si votre ordinateur n'est pas en mesure d'en afficher autant. Cette variable s'utilise conjointement à pmove_fixed_msec qui indique quel fps il est censé émuler. Ce mode a aussi ces inconvénients. Notamment, il arrive que certains évènements de lecture de sons passent à la trappe, et donc que certains sons pendant la phase de jeu ne soient pas entendus. L'autre étant … euh, un peu compliqué. Il s'agirait d'erreurs d'arrondis dans les calculs, et du fait qu'il y ait quelques inconsistances notamment lorsque la gravité est changée.

Autres

D'autres mécanismes sont utilisés dans d'autres dérivés de Quake 3, notamment pmove_accurate, similaire à pmove_fixed, mais n'est pas implémenté dans OpenArena.

Références

doc/joueur/physique_fps.txt · Dernière modification: 2017/02/20 09:21 (modification externe)