Mais comment font-ils ?

Je vous livre une interrogation à chaud entre deux tests de mon appli car ça fait des mois que je veux poser cette question sur la cafzone et à chaque fois je l’oublie, tant que j’ai l’esprit à ça je me lance donc :

Il y a quelques mois, j’ai ré-installé un super vieux jeu (époque des 486) sur mon P4 2.3Ghz.
J’ai été surpris de constater que le jeu était injouable car beaucoup trop rapide ; j’avais bien déjà entendu parler des ralentisseurs de proc’ mais je me demandais l’utilité de la chose, maintenant j’ai compris.

Là n’est pas le problème, je tiens simplement à faire un constat étrange : prenez les très vieux jeux 2D qui étaient très bien programmés (dans le sens où les programmeurs grapillaient le moindre octet et optimisaient leur opérations à mort pour que ça puisse tourner), or le changement de générations de proc’ a complètement “déréglé” la vitesse du jeu.

Maintenant, prenez un très vieux jeu (oui encore) mais en 3D (on va dire duke nukem ou quake par exemple) : il tourne à la même vitesse mais de manière beaucoup plus fluide. Et d’ailleurs, les différents jeux des 5 dernières années ont un comportement de “fludification” (?) avec un ordinateur plus puissant, contrairement aux vieux jeux qui s’accelerent.

Ma question est donc multiple : avons-nous changé notre méthode de programmation ? Somme nous-passés d’une méthode par cycle d’horloge intemporel à un cycle défini sur le temps mais offrant plus d’interstices ? (1) Les jeux d’aujourd’hui vont-ils un jour tourner à 100 à l’heure sur les bécanes du futur ?

(1) : oui, cette phrase ne veut rien dire au premier abord mais relisez bien et vous comprendrez peut être ce que je veux dire. Et puis là je suis vraiment à la masse faut pas m’en demander trop…

Ben c’est peut être que les programmeurs ont compris a un moment que le PC ca evolue et que du coup ben il faut prevoir que les jeux s’adaptent a des pc plus rapides sans en devenir injouable (mais plutot + jouable). Du coup ben vi, un jeu actuel sera sans doute bien mieux sur un pc du futur, si toutefois ce jeu sait tourner dessus (pb d’O/S ou de genration de CPU qui serait incompatible par exemple … ou meme de technologie logicielle pour la 3D vu que directX ou open gl seront peut etre remplaces par autre chose tout comme le glide l’a ete …). Bref, qui vivra verra ;-p

Bon, que des gens du metier (ie programmeur de jeu video) me
contredisent mais pour moi, il a 2 manieres de programmer un jeu.

  1. A la Bourrin

Le jeu est ecrit et fait pour que ca tourne parfaitement sur la machine
Y: Aucun gestion d’horloge, de temps, de timing rien, tout est base sur
la machine de reference. C’est le cas de Moktar ou de Test Drive 3 par
exemple.

Je suppose que c’est comme ca que sont realises les jeux consoles
actuels: La plateforme est toujours la meme pour tous les utilisateurs,
on optimise de maniere a ce que ca tourne nickel dessus.

2.Synchrone.

Sur PC, il existe une interuption logicielle  (je me souviens plus
du numero) qui, par defaut, fait 18,2 interruptions par secondes. Une
technique classique etait de change la frequence (genre 25 int par
seconde) pour gerer le jeu: A chaque interruption, on rafraichit
l’image. Comme exemple, j’ai Tornado (excellente simulation).

Pourquoi l’un ou l’autre? La 2eme version est plus complexe a
programmer: Dans le cas 1, on appuie sur une touche (normalement, c’est
une INT aussi, mais bon, y a programmeur et programmeur), ca fait un
truc. Quelque soit la puissance de la machine. Dans le cas 2, l’appuie
sur la touche ne doit rien faire de special a l’ecran (vu qu’il faut
attendre le refresh), mais il faut mettre a jours des variables pour le
prochain refresh.

Ca vous va? Comme c’est quand meme assez technique, je verais bien ca
dans SegFault, surtout que c0unt0 pourra nous en dire plus (et me
corriger )

LoneWolf

Aaaah les interruptions logicielles… l’bon temps, ca, gamin.

Non en fait l’idée c’est que y’a une boucle dans laquelle, à chaque passage, on redessine l’image du jeu. Prenons l’exemple d’un jeu de voiture.

A l’ancienne mode, on dit que à chaque fois qu’on passe dans la boucle, la voiture avance de 20 cm, et ça tourne nickel sur le 386 de l’époque. Quand on se retrouve avec un monstre à 2 Ghz, la voiture change de galaxie dès qu’on appuie sur la touche pour accélérer -> pas génial.

Nouvelle mode, on dit que à chaque fois qu’on passe dans la boucle, on regarde l’heure qu’il est (avec un précision de l’ordre de la milliseconde), et on compare avec l’heure qu’il était la dernière fois qu’on est passé. Du coup, on connait la vitesse de la voiture distance/temp, on connaît l’intervalle de temps, donc on peut déterminer de combien la voiture a avancé depuis la denière image.

Le truc bien avec la deuxième méthode, c’est que sur une machine lente, la voiture avancera de beaucoup à chaque image (ça va saccader), sur une machine rapide ce sera plus fluide, mais dans les deux cas la voiture avancera à la même vitesse.

Et voilà

BERK!

Le systeme des interuptions est nettement plus propre, je trouve. 'fin bon…

LoneWolf

Super decu que ca n’a pas evolue…

[quote]BERK!

Le systeme des interuptions est nettement plus propre, je trouve. 'fin bon…

LoneWolf
Super decu que ca n’a pas evolue…[/quote]ha, perso je suis pas d’accord avec toi Lone… Pour moi les INT ici, c’est un peu hors-sujet (si je peux le dire)

En fait, la solution de Drealmer est celle que je connait et que tout le monde a ma connaissance utilise… C’est aussi la plus logique, une des plus simples à mettre en oeuvre, et puis elle est extremement sure

La longueur des mouvements dépendent du temps passé à rafraichir l’ecran et à faire les calculs…

QUESTION : la fonction delay (du C) dépendrait-elle du temps du cycle processeur et non du temps, le vrai ?

:remouk

Ah je vois: dans la solution INT, il faut que le PC soit assez puissant, sinon, ca deconne completement.

N’empeche que c’est plus joli

Sinon, pour delay:

motoko:~# man delay

No manual entry for delay

LoneWolf

Ca doit pas etre ca

[quote]Sinon, pour delay:
motoko:~# man delay
No manual entry for delay

LoneWolf
Ca doit pas etre ca

Sinon je parlais du delay parce que justement, on avait fait un jeu en C (Turbo C, donc) à l’IUT et on utilisé un petit systeme pas con pour limiter la vitesse, mais qui ne s’applique qu’a la 2D, ou alors au détriment de la fluidité pour la 3D.

Le principe c’est de bloquer la boucle avec un delai (fonction delay, donc), de manière à ce que chaque itération dure le meme temps (1/30 de seconde par exemple)…
Ce qui fait que, tout simplement, à partir d’une certaine vitesse de processeur, le jeu tourne au même nombre de FPS (bloqué par le delai) sur tout les PC. Le probleme c’est qu’on ne peut pas dépasser un certain nombre de FPS et donc d’avoir un jeu plus fluide que l’eau.

Et le dernier probleme c’est que malgré ca, c’etait trop rapide sur un bon PC. Le prof nous à dit que la fonctione delay n’etait pas bien, mais sans dire pourquoi… bon tant pis

:remouk

vous etes mignons les gars…

maintenant pour une VRAIS explication

de tout temps, les jeux ont eu besoin d’etre synchronise sur quelque choses (car si on synchronise sur rien (genre logique/display/logique/display) ca ne va bien tourner que sur la machine ou ca a ete ecrit, et rien d’autres !!!

avant, sur PC, (a l’epoque du 486) : les jeux/demos etait synchronise a la frame!
bougez pas j’esplique : 99% des cartes videos tournaient, dans la plus part des modes video, a une vitesse STABLE : elles etait toutes entres 60 et 65Hz, et que, a l’epoque, les CMs n’avait pas de timer correct (en terme de precision ou de stabilite, et en plus il etait pas  super pratique), donc ce qu’on faisait c’est qu’on attendait la frame :

logique
rendu
waitforframe < — > attent la fin de la prochaine frame

et apres le but etait code de manieres a tourner dans une frame sur la machine la plus basse (souvent 386 ou 486/33).
A part certain titres, qui eux avait eu le courage d’utilise la methode 2 (ci-apres )
sinon, plus vicieux, mais surtout utilise en demo, : on synchronisait sur la musique !

puis est venue, les pentioums, et les vrais CM et tout un tas d’autres truc :

  • d’abords, avec les pentioums, on a vue de plus grandes differences de perfs entre les differents PC, et ca c’etait genant !
  • puis est arrive le VESA, et des nouvelles cartes videos, avec plein de modes video bizarres et differents, et avec des frequences et des performances variables,
  • et puis souvent des timers enfin utilisable !
  • et puis aussi le marche du jeux pc devenait un vrais marches, pas trois gugusse (avec des GUS (demo joke inside) ) !
    donc ce qu’on a decide de faire, c’est de synchronise au timer, plutot qu’a la frame :

startTime = EndTime = 0
[…]
[…]

startTime = GetTime
DeltaTime = endTime - startTime
logique(DeltaTime);
rendu
EndTime = GetTime
waitforframe < — c’est plus vraiment necessaire mais c’est souvent plus propre ! >
ou autre model du meme genre ! (y a d’autre moyen de faire, sisi j’insiste !)

dans ce modele la, toute la logique est fait pour etre calcule en fonction du temps ecoule, et plus en fonction d’un pas precis :
avant :
voiture.position = voiture.position + voiture.vitesse;
avec le timer
voiture.position = voiture.position + voiture.vitesseparseconde * DeltaTime;

petit problem : ca rajoute une multiplication dans le calcul, donc ca demande plus de calcul, c’est pour ca que bien souvent, sur console, on persiste a utilise la frame pour faire la synchronisation, parce que c’est stable et que c’est moins cher !

et la, soudain, la lumiere vous frappes :  “Mais, Mais, Mais sur consoles, c’est pas stable, ca peut etre 50 ou 60 !!!” et vous avez raison : ca peut, et c’est entre autre pour ca que porter un jeu 60 (jap ou US) vers 50 (europe) peut etre : a)bacler : on garde tout comme ca, on change pas la frequence de la logique et ca ira pas a la meme vitesse ou B) un peu long : il faut tout porter/adapter/modifier pour que ca tourne a la meme vitesse sur 50 que sur 60 !

voila !!!

et pour les interruptions : ca marche sans doute tres bien dans un micro-controleur de portes d’ascenceurs, mais pour un jeu, y a d’autres trucs a faire avec les interuptions, et puis surtout sur PC, avec winwin et tout le bordel : on fait plus, du tout, jamais, c’est mal !!!

et le delay : oui c’est mal, car ce n’est pas sence etre precis, c’est plus pour dire : arrete toi un peu on va voir ce quisse passes (genre donner un peu de temps aux aurtres thread ou des trucs quoi ) que pour faire un truc vraiment timer aux petits poils !

[oublie le delay + relecture RAPIDE !]
Ce message a été édité par c0unt0 le 21/05/2003

Tu veux pas nous faire une chronique : “Programmation dans les jeux videos”
1 article par semaine ??

Tu aurais au moins un fidel lecteur

Merci de ces explications.

[quote]Tu aurais au moins un fidèle lecteur [/quote]2!!
même si je n’y pane rien en programmation, c’est pourtant très intéressant

Trops la flemes : seulement si on me paye !
Et puis je suis nul en orthographe
(et puis Use- a ete obliger de faire du lobying par ICQ pour que je jetes un coup d’oeil
mais merci !

Je vote aussi pour! aller, si on arrive à 20 tu nous fait un mini article comme celui-ci par semaine, dis oui dis oui, aller stéuplaaaiii 

Roh!!! oui!!! c’est bon encore !!!

ok, si vous arrivez a 20, et que vous me posiez des questions (parce que je suis nul de pour trouvez des sujets tout seul !)…
et ptet meme j’installerais le correcteur francais sur mon word anglais !

vous pouvez maillez vos questions a : c0unt0@ikillclowns.com

a oui, et aussi y aura des semaines ou y aura rien, parce que j’aurais pas le temps

Merci d’avoir réexpliqué de manière surement plus claire
Ce message a été édité par remouk le 21/05/2003

et de 4… avec remouk, 5 avec moi

Ce message a été édité par Nightwing le 21/05/2003

[quote]Je vote aussi pour! aller, si on arrive à 20 tu nous fait un mini article comme celui-ci par semaine, dis oui dis oui, aller stéuplaaaiii [/quote]Je vote aussi pour!
C’était vachement intéressant, et surtout facile à comprendre! 

Edit: Comme Boltac, je suis aussi pour les concepts, parce que le code et moi ça fait 2. Les réponses de ce thread étaient bien claires pour des neuneus en programmation comme moi.
Ce message a été édité par koba le 21/05/2003

dis monsieur tu nous la fait ta chronique stp???

ceci dit, je suis vachement plus interesser par les concept que par le code.

en fait l’explication quetu nous a donné dans ce tread, c’est ce genre la que je voudrait.

ha oui, MERCI

Moi aussi je vote pour !

Si c’est la partie ortho/mise en forme qui te gène, je peux aider, hein. Je veux bien jouer les correcteurs. Seulement, je te laisserai les trucs trop pointus pour moi.  

Je vote pour. Ne serait-ce que pour une chronique mensuelle.