J'ai réalisé 2-3 jeux sur ma ti-89 mais toujours avec une méthode assez pénible surtout lors des animations.
prenons un exemple:
3 balles qui rebondissent dans un rectangle.
l'algo c'etait  
tant que vrai
 je deplace d'une unité la balle 1
 je deplace d'une unité la balle 2
 je deplace d'une unité la balle 3
fin tant que
mais ca deviens assez pénible si on ne déplace plus des balles mais des animations(et je pense qu'avec la 3D c'est pire). Car pour chaque animations on doit savoir où l'on en est de l'animation et afficher l'état suivant.
 
Maintenant vu la compléxité(au niveau des entités animées) des jeux d'aujourd'hui, je me demande si il n'existe pas d'autres méthodes beaucoup "mieux".
 
J'ai pensé à l'utilisation de threads mais bon prennons un jeu comme warcraft ou plusieurs dizaines d'unités sont animées et interagissent. Il faudrais forcément introduire la notion de sémaphore sur beaucoup de variable Ca fais beaucoup de threads  et beaucoup de sémaphores sur beaucoup de variable(hp de l'unité, mana de l'unité, or des mines, bois, positions sur la map etc etc)
 
Donc voilà si y en a parmis vous qui ont d'autres idées
 
 
PS: Si ca a déjà été demandé je m'en excuse mais j'ai pas trouvé ...

nan, pas de thread,du bete sequentiel, et hop

oué, de tout ce que j'ai vu c'était pareil : automate explicite, on calcule l'état suivant puis on l'affiche. Des fois c'est un poil plus fin, avec plusieurs granularité d'horloge, mais le principe reste le même.

tu voudrais que lanimation soit independante du deplacement du perso c ca ? ou du moins pas a la meme vitesse  
bon imaginons que tu ait fait une structure pour ton perso (2d):
 
int x;
int y;
int noanim;   // no de l'anim en cours (chaque no correspondant a un sprite)
....
 
apres il te reste plus qua modifier noanim en fonction du nombre de frames qui on se sont ecoulees (genre 1 frame sur 5)
 
 
tu faisais allusion a plusieurs balles et au fait que ca devenanait difficile a gerer.... pourquoi ne pas faire un tableau regroupant tout les balles en question puis parcourir simplememnt le tableau
 
jvous vraiment pas ou est le probleme ou alors jai pas compris ta question....

@red faction : c'était un exemple et deplus ca je sais faire .
Le problème c'est que je trouve que cette méthode difficil à gérer quand tu as des dizaines d'entités à animés.
 
@Tous : merci je pensais que de nouvelles techniques était apparue

Je doit avouer que je ne comprends pas ton probleme.
Qu'est ce que veut dire difficile a gerer pour toi?
Juste pour savoir quels sont les languages que tu connait?

en fait difficile n'est pas le mots. C'est plutôt lourds que je voulais dire.

 
Ben si tu decompose bien les differents problemes c'est pas si lourd que ca (diviser pour mieux regner, tu connait? ).

le déplacement d'une main au dessus de la tête pour l'unité 1  
et deplacer vers le bas la main pour l'unité 2:
tant que vrai
 deplacer le bras de l'unité 1
 deplacer le bras de l'unité 2
fin tant que
 
pour 50 unités ca deviens lourd.
Quand j'ai fais mes jeux, j'ai trouver ca super chiant comme méthode(bon okai c'était en assembleur mais bon)
 
Enfin bon la n'est pas le problème. Je voulais juste savoir si il y avait d'autre méthode.

Ton proleme, je crois, c'est que ta vision de la prog est restreinte a ce que tu as fait sur calculatrice (dit moi si je me trompe).
 
Imaginons que tu est une liste d'unite.
 
L'algo que tu donne devient:
 
ajoute unite1 dans la liste
ajoute unite2 dans la liste
 
tant que vrai
    pour toutes les unitees dans la liste
         gestion de l'unite
fin tant que
 
Au niveau bien sur pour l'execution du programme ca changera pas grand chose, mais pour le programmeur ca simplifi enormement les choses

euh oui tu te trompe
 
je n'ai pas dis que je savais pas le faire ni que j'avais des pb d'écritures des algo. Je cherche à savoir si il existe d'autre méthode.

 
ben pour ce qui est affichage, sequentiel roulaise (et d'autre part je pense pas que D3D/OGL apprecierait de se prendre deux rendus dans la tete en meme temps ) Ptet pour l'IA que le multithread aurait un interet (multiagent) si il ne bouffait pas autant de perf

Pas a ma connaissance.
Le coup du un par thread/entite, est mon avis: bien plus complexe pour le programmeur, bien plus lourd a gerer par le programme.
 
Apres du tes trucs du style un thread pour gerer la logique du jeu, un thread pour gerer l'affchage du jeu, meme si je ne l'ai jamais fait je sais que c'est qqchose de faisable.

oui vu comme ca.
Y a pas d'autre méthode oki.
 
 
PS: c'est pas pour faire un jeu c'est que je n'arrivais pas à dormir car je me disais qu'il devait y avoir mieux

 
dans certains jeux (enfin bon je connais que quake3 qui le fasse ) le calcul de géométrie hors carte graphique peut être réparti sur deux threads, ce qui accélère un peu le rendu sur un bi proc. Mais le gain n'est pas si terrible que ça pour que cette méthode ce généralise, sans compter que seuls des geeks utilisent un bi proc pour jouer (en attendant les fututres puces bi cpu dont l'hyperthreading est un avant gout douteux).

 
Je vois pas trop ce qu'il pourrait y avoir d'autre comme méthode. Tu es bien obligé de mettre a jour au moins une fois chaque unité par frame, non?