En même temps que demi vie 2, sauf si ce dernier ne s’avérait en fait n’être qu’une vaste fumisterie, c’est à dire au printemps.
Je crois qu’au final on mélange plusieurs chose. Horloge et Affichage.
L’horloge interne calibre la reaction du jeu, c’est à dire qu’on aura que 60 actions par seconde de possible. Ou tout du moins on aura 60 instants T où les actions seront analysés et traités. Cela ne veut pas dire qu’il affichera uniquement 60 images seconde. Si il n’y a pas de bridage d’affichage, les actions iront à la meme vitesse et les frames affichés en plus des 60 instants T ne seront que des frames d’affichage et non de traitements des mouvements. Par contre, une question se pose : Que doit faire le jeu si on affiche plus que 60 fps ? Comment doit réagir le jeu lors de ces image supplementaires ? Je vais utiliser un exemple pour être clair.
Prenons une horloge interne à 60 on a donc 60 instant T. Le PC qui fait tourner ca peut afficher plus que 60 fps. On a donc 60 instants T et plein d’instant Y à afficher en plus.
T1 Y1 Y2 T2 Y3 Y4 T3 Y5 Y6 T4 etc…
Comment dois réagir le jeu lors des instants T ? Comme on est sur la frequence de l’horloge, le jeu doit analyser les gestes du joueurs et faire réagir le perso en consequence. Mais pour les instant Y ? On est en dehors de l’horloge et donc le jeu ne doit pas modifier le deplacement du joueur. 2 possibilités : Y3 et Y4 sont identiques à la frame precedente (ici T2) ou bien Y3 et Y4 utilisent des calculs d’interpolation entre T2 et T3 pour bien positionner le joueur.
Si Y3 et Y4 sont identiques à T2 on va avoir l’impression de saccades continuelles. Dans cas contraire, cela veut dire que le moteur est capable de calculer la position d’un joueur et de l’afficher en dehors de l’horloge interne le tout sans changer la direction du joueur (ou sa frequence de tir) car on est en dehors des instants T. C’est pas mal comme solution mais on aura une impression de latence dans les reactions du gameplay. En effet, le jeu ne reagira pas à la frame pres mais à modulo(Y,60) frame (pas le temps de verifier que ma formule est bonne mais l’idee est là ). Effectivement pour un bench graphique ca suffit amplement, mais pour des joeurs exigeant ca risque d’etre limite… surtout dans un FPS ou le gameplay doit réagir au doigt et à l’oeil.
Si l’oeil et le doigt sont synchronisés à 60fps, effectivement plus aucun probleme, mais est ce que ce bridage ne sera pas penalisant par la suite sachant que leurs moteurs sont souvent destinés à rester longtemps sur le marché (On attend encore des jeux comme Call of Duty, basés sur le moteurs de Q3 sorti 99). Et surtout, est ce que ca va pas reduire l’interet d’un quake (ses deplacements et sa precision) ??
Personnellement, je ne pense pas que Carmack s’amuserait à faire ce genre de trucs si près de la sortie du jeu s’il y avait un risque de flinguer le gameplay et de se mettre à dos tous les fans…
[quote]Pleins de trucs[/quote]A nous deux, on deux, on doit converger vers la bonne explication vu qu’on pense quasiment la même chose.
J’ajouterais à tes propos (plus clairs que les miens ) que Carmack dit bien que l’horloge à 60 Hz coordonne l’affichage ET les commandes du joueurs. Ceci dit + nos explications = on doit converger vers le vrai !
[quote]Personnellement,
je ne pense pas que Carmack s’amuserait à faire ce genre de trucs si
près de la sortie du jeu s’il y avait un risque de flinguer le gameplay
et de se mettre à dos tous les fans…[/quote]Oui mais je me demande si ID Software a besoin de ces fans. Cette boite fait des jeux, c’est sur et certain. Mais ils font surtout un moteur. C’est sur ce produit qu’ils font de l’argent. Ils ont peut etre decidés qu’ils feraient surtout un moteur hyper polyvalent avant de faire un jeu au gameplay impeccable. Avoir une horloge interne fixe pour analyser les ractions du joueur facilite grandement le portage vers d’autres horizons…
Edit : Ash> ouais on doit se rappocher de l’explication. Du coup si on enleve la limitation d’affichage de frame, on aura bien un moteur de Bench mais pas de jeu vu que le gameplay sera toujours calibré sur les 60 Hz du moteur
Ce message a été édité par Donjohn le 27/10/2003
Tiens une idée pour laquelle on possède maintenant les capacités techniques : pourquoi ne ferait-on pas un jeu mettant en pratique le phénomène de persistance rétinienne ? L’effet de flou de mouvement n’en est pas une vraie application puisqu’il n’est appliqué que ponctuellement, mais pourquoi ne pas mettre ces effets dans la vision globale du joueur, un peu comme nfs underground mais en plus reussi.
Sinon, pour un joueur moyen je pense pas que le bridage à 60 img/s changera grand chose, surtout s’il est confronté à une IA. J’espère seulement qu’elle sera pas trop débile…
Ce message a été édité par Ashira le 27/10/2003
Pour ce qui est des Benchs a de Doom III, je cite Materiel.be :
" A noter que les futur benchmark dérivés de Doom III ne devraient pas logiquement être affectés par cette restriction"
J’aimerais bien qu’un dev de jeu donne son avis. Au hasard : C0unt0
[quote]J’aimerais bien qu’un dev de jeu donne son avis. Au hasard : C0unt0
Moi, programmeur de jeux, j’approuve ce qu’a dit notre ami c0unt0 
Lockons la frame mes amis !
A ce propos, ça se trouve c’est pour le réseau qu’ils ont fait ça : un thread pour l’IA / Input qui tourne a 60 FPS, un thread qui synchro le reseau avec ça, a 60 aussi, et un thread qui ben affiche tout ce beau monde a la vitesse qu’il peut, sans dépasser 60.
Enfin bref, cela dit 60 FPS sur PC me parait un peu faiblard comme limite, moi mon écran est à 100Hz, donc à 60 FPS je suis désynchronisé avec mon écran et c’est pas beau Mais bref, je jouerai a 60Hz a Doom3. Ou plutot à 100Hz à HL2
[quote][quote]J’aimerais bien qu’un dev de jeu donne son avis. Au hasard : C0unt0
Par contre je ne comprend pas ton arguement de developper des boucles optimisés et quid des temps de latences dans le gameplay ? J’aimerais bien savoir comment on peur faire croire que le taux de rafraichessement des controles est superieur à 60 ? Ou alors 60 c’est une limite d’humain ? merde je suis inhumain…
tout ce que je retiens de se fabuleux thread: Tous les jeux sorti sont codés avec les pieds, car si ils doivent se positionner sur le framerate pour que cela soit jouable hum c’est bon les pieds. C’est pas un troll juste un constat, apres on approuve ou non. Mais ne pas avoir un systeme controle se basant sur une variable flottante super les mecs ! ca c’est du taf bien fait…
silka, relis le thread et utilise ton cerveau. Les deux choix ont des avantages et des inconvenients… donc c’est pas si simple que tu le laisses croire et non Carmack developpe pas avec ses pieds ca se saurait
C’est mon avis, vous pouvez tres bien le critiquer, mais cela etant dit, ca reste se basé sur ma plus grosse B. , la ca marchera mieux.
Bref, baser le gameplay sur une valeur aleatoire…
[quote]Par contre je ne comprend pas ton arguement de developper des boucles optimisés et quid des temps de latences dans le gameplay ? J’aimerais bien savoir comment on peur faire croire que le taux de rafraichessement des controles est superieur à 60 ? Ou alors 60 c’est une limite d’humain ? merde je
Bas tu as plusieurs choix la :
a) tu t’en fout
tu interpole entre deux frame, en te disant qu’a 1/60 de secondes pres, le gugusse a pas eu le temps de vraiment changer d’avis
c) (le choix des maitres) tu « stack » tout les changement des controles entre les deux frames, et quand tu resous : tu calcul la complete : donc si entre deux frames tu fait gauche-droite-haut + click, tu execute la totalite des mouvements enregistre, mais en une fois, avec un peu de smooth ou un filtre passe-bas optionels pour enlever les glitchs des joueur parkinsonien
En fait tu fais comme sur console… ou meme si ton moteur peux calculer plus de truc : tu es toujours locker a ta frequence de rafraichisment (50Hz en Pal, 60Hz en NTSC)…
sinon pour le choix de la frequence, je pense que c’est base sur a) le fait que le 60Htz (60fps) est deja utilise sur console : donc connu et maitrise et que c’est le plus petit denominateur commun de la plus part des cartes video et des ecrans : si tu fais plus haut tu risques de perdre des parts de marche !
c0unt0, lockeur de frame depuis 1987 (je le faisais deja avant : mais j’en etait pas conscient )
[Edit special silka]
[quote]Mais ne pas avoir un systeme controle se basant sur une variable flottante super les mecs ! ca c’est du taf bien fait…
[/quote]Mais je le base sur ce que je veux mon systeme de controle ! et puis flotant ou pas flotant : si tu integres pas le delta-temps entre deux frame et tout un tas d’autre truc : tu en chies…
L’idee de johnny C. c’est que c’est plus simple(et plus efficaces en matiere de code) de downsampler, ou de « ratrapper » le temps en executant plusieur fois ta boucle de jeux avec un pas de temps maximum fixe, que de coder un truc ou tu dois TOUT integrer en fonction de ton delta…
Et pour le nombre de jeux qui codent leurs system de controles comme des pieds : oui, c’est enaurme, j’ai des listes, j’ai des noms : et parfois pas des moindres : le problem c’est que dans la plus part des boites, c’est un stagiaire qui va faire le system de controle (chez nous, dans le jeux video, on dit un « code monkey », ou un nul, aussi) et qui va donc se dire : « ho! si je multiplie tout par deltaT en flotant et que je smooth sur plusieurs frames, ca marche alors ? » et la t’aura un system de control pourrits… tout pourrits
Ce message a été édité par c0unt0 le 27/10/2003
Ce message a été édité par c0unt0 le 27/10/2003
c0unt0 a dit:Mais je le base sur ce que je veux mon systeme de controle ! et puis flotant ou pas flotant : si tu integres pas le delta-temps entre deux frame et tout un tas d'autre truc : tu en chies...
L’idee de johnny C. c’est que c’est plus simple(et plus efficaces en matiere de code) de downsampler, ou de “ratrapper” le temps en executant plusieur fois ta boucle de jeux avec un pas de temps maximum fixe, que de coder un truc ou tu dois TOUT integrer en fonction de ton delta…
Et pour le nombre de jeux qui codent leurs system de controles comme des pieds : oui, c’est enaurme, j’ai des listes, j’ai des noms : et parfois pas des moindres : le problem c’est que dans la plus part des boites, c’est un stagiaire qui va faire le system de controle (chez nous, dans le jeux video, on dit un “code monkey”, ou un nul, aussi) et qui va donc se dire : “ho! si je multiplie tout par deltaT en flotant et que je smooth sur plusieurs frames, ca marche alors ?” et la t’aura un system de control pourrits… tout pourrits
Juste pour nuancer : ça dépends quand meme un peu du jeu aussi hein tous les jeux ont pas les memes exigences en terme de controles…
Pff tuo et c0unt0 les deux mecs qui font genre on s’y connait on se la pète
non mais genre…
oups
/me s’enfuit
Ce message a été édité par yavin le 27/10/2003
oui, fuis mécréant, avant que c0unt0-le-modo ne te tombe sur le dos (quelle belle rime )
Moi, Antoine Viau, ex-programmeur de jeux, j’approuve et appuie les propos de mes ex-collègues Tuo et C0unt0. Locker la frame c’est bien, mangez en.
Et puis moi, de toutes façons, j’avais pas besoin de locker, j’étais toujours en dessous de 30 FPS (dis patron, c’est quand qu’on renouvelle le matos de la boite ?).
Plus sérieusement, le problème de notre ami John je le comprends. Pour l’avoir fait dans Nomad Soul (ceci explique cela) la gestion du framerate combinée avec celle des contrôles est un fucking casse-tête.
D’une machine à l’autre tu passes d’un jeu beau, fluide à un machin totalement injouable parce que les anims des persos deviennent plus ou moins incompréhensibles et surtout l’arrivée des entrées de contrôles (souris, pad, clavier, pédalo, etc.) devient de plus en plus anarchique. Un exemple ?
Si le joueur appuie sur les boutons [A] et [B] simultanément on aura selon la machine :
[A][A][A][A+B][A+B][A+B][A+B][B][B][B][B][B] (machine rapide)
ou
[A+B][A+B][A+B] (machine lente)
En lockant tout un tas de paramètres, tu te simplifies la vie sur pas mal de choses.
Enfin moi ce que j’en dis…
Antoine (programmeur auto-locké