Le moteur graphique s'occupe de l'affichage des graphismes principalement (c'est la partie "renderer"). En gros, il s'occupe d'aller chercher les informations des modèles, des textures, des maps, et de toute information de la manière à afficher (Cette texture doit-elle utiliser un masque ou de l'alpha blending ? Ce modèle utilise-t-il la texture-là ? Où dois-je placer les arbres ?).
Un fois la phase "stockage" terminée, c'est comme si on pouvait afficher en une seule fonction tout le jeu "in game".
Le moteur physique s'occupe, lui, d'autres choses : principalement des tests de collision, il doit aussi permettre de mettre en place la "physique" du monde : gravité, quantité de mouvement, et j'en passe.
Il se chargera de savoir si tu dois passer à travers le sol, ou que le joueur s'y réceptionne depuis sa chute. (et donc faire les déformations nécessaire dans l'animation du joueur : plier les genoux) Il peut aussi savoir si la balle du flingue se retrouvera dans la gueule...
Si tu veux, frappe une fois sur la table, et regarde tout ce qui se passe au niveau physique, pour comprendre.
Celui-ci n'a pas de réelle phase de lecture, sachant qu'une bonne partie des fichiers peut être retrouvée dans le moteur graphique. C'est pendant le jeu qu'il se charge de beaucoup plus : il est constamment mis à jour, et met constamment beaucoup de données à jour.
Un moteur graphique, c'est pas très dur à faire (si on passe par des librairies-tiers, bien sûr...
) : suffit de bien structurer les changements de textures et les changements de repères pour en avoir le moins possible.
Un moteur physique performant, c'est plus dur : il fait énormément de calculs, et faut jouer finaud dans les conditions, de manière à en avoir le moins possible.
Au fait, j'avais cité Newton, hein !
