[Résolu] Physique dans les jeux = OpenGl ??

[Stilgardt]

Bonjour,

Je me demandais si les effets physiques dans les jeux (comme les chutes d'objets empilés qui tombent lors d'une collision) sont le résultat de certaines fonctions OpenGl ou bien d'autre choses?

Les jeux comme Angry Birds, iDemolished ou autre ont l'air d'avoir tous le même système de gestion de cet "équilibre" et la

chute se fait de la même manière aussi (d'une manière assez lente). Du coup, je me demandais s'ils utilisaient tous le même morceau de code et si ça venait d'OpenGl ou d'une autre librairie que je n'ai pas encore découvert? :/

Bon après-midi! :)

[Zerrac]

OpenGL ne fait que de l'affichage (et encore, la partie très bas niveau). La physique se fait donc par un autre moteur.

En moteurs gratuits, nous avons par exemple Box2D (qui comme son nom l'indique est en 2D, pas en 3D) qui fonctionne très, très bien.

Moi j'ai fait mon petit moteur physique perso très simple pour les besoins très spécifiques de mon jeu, mais ça demande quelques connaissances en cinématique et en dynamique... si tu n'es pas à l'aise avec ces notions regarde du côté des moteurs libres, ce qui ne t'empêchera pas de devoir comprendre quelques concepts de base pour bien les utiliser.

Autre chose: généralement, la physique a une rerésentation très différente de la 3D; par exemple une sphère qui roule sera vue par OpenGL comme un ensemble de faces triangulaires texturées, mais comme une sphère parfaite par le moteur physique (ie. un point et un rayon). Les calculs entrant en jeu n'ont rien à voir.

[Alocaly]

Effectivement, la plupart des jeux utilisent Box2d, pour lequel un port de bonne qualité a été fait sur Android.

Apres, pour l'affichage, tu peux utiliser ce que tu veux, OGl ou les canvas.

A noter: il existe plusieurs moteurs sur Android qui combine Box2D et un affichage 2D...

C'est pratique :)

[Stilgardt]

@Zerrac et Alocaly: Merci pour vos réponses! :)

OpenGl est encore obscur pour moi donc je lui attribuais certaines qualités qu'il n'a pas :-)

Ca me semblait plutôt compliqué de définir la chute d'une colonne en fonction de sa collision donc je vais aller voir vers Box2D pour voir ce qu'il propose (et ça tombe bien car je ne m'intéresse qu'à la 2D pour l'instant donc tant mieux si je peux me passer des connaissances OpenGl dans un premier temps).

[Zerrac]

Note bien que tu peux très bien avoir un moteur physique en 2D, et un affichage en 3D, tant que l'action se déroule dans un plan, rien n'empêche de faire un habillage en "fausse 2D" avec des graphismes 3D... mais on s'égare un peu ;-)

[Alocaly]

Tu peux effectivement utiliser OpenGl pour faire aussi de la 2D. Des jeux comme Replica Island l'utilise pour gagner en performance.

Mais encore une fois, surtout si tu débutes, je te conseille d'utiliser un moteur tout fait. Je pense en particulier à Rokon ou à AndEngine.

Ils ne permettent sans doute pas de faire les jeux les plus optimisés qui soient, mais ca te fait une bonne base pour commencer un jeu en 2D avec des sprites et de la physique. Tu n'auras pas à te soucier d'Opengl, de comment inclure Box2D, et tu pourras te concentrer sur le reste du jeu ( ce qui est souvent deja pas mal )

Emmanuel / Alocaly

[Stilgardt]

Je me suis déjà fait mon propre moteur maison qui gère des trucs de base comme les collisions, les déplacements, la gravité, les animations de sprites, etc... donc ça m'embêterait de laisser tomber tous ces week-end passés là-dessus en recommençant avec un truc déjà fait ;)

En plus, faire son propre moteur permet d'avoir uniquement le code utile et de l'optimiser suivant les besoins (et ça me fait du bien au moral de voir peu à peu que je pourrais presque reproduire les jeux avec lesquels j'ai tant joué dans mon enfance :) )

Mais je trouvais qu'il me manquait la gestion de la dynamique/physique. Car gérer des collisions, des sauts, des trajectoires, c'est bien mais faire en sorte que quand un objet en cogne un autre et suivant où il le cogne, cet objet réagit différemment (sans forcément rebondir dans la direction opposée!), c'est mieux! :D

D'où l'objet de ce sujet car je pensais qu'ajouter un peu d'OpenGl résoudrait ce que je n'ai pas codé (on peut toujours rêver!).

Ce qui m'embête quand même avec Box2D, si c'est lui qui est utilisé pour AngryBirds et iDemolished, c'est que la gestion de la physique est plutôt lente (sûrement très consommatrice en temps de processing) et du coup, ça nuit au dynamisme de ces jeux car il faut tout le temps attendre assez longtemps avant que toutes les pièces soient réellement étalées sur le sol.

Je pense qu'on peut mieux faire donc mais je ne sais pas encore comment :)

Peut-être en approximant certains opérations complexes par des opérations plus simples mais avec des constantes bien étudiées? Un peu comme l'algorithme d'inverse de racine carrée écrit par John Carmack (le développeur de Doom) et que l'on peut retrouver sur sa page française Wikipedia: http://fr.wikipedia.org/wiki/John_Carmack

Bref... à suivre!

[Alocaly]

Mouaif.... Pas tres glorieux, cette page sur Carmack de wikipedia...

Concernant ton probleme, il ne faut pas confondre le temps que prend la simu, et la vitesse à laquelle se déplacent tes objets.

J'ai pas l'impression que le frame rate soit mauvais avec Box2D ( pour un nombre raisonnable d'objet ), apres tu peux passer à ta lib physique un delta T plus grand que le vrai pour booster un peu les choses, ou modifier les différentes inerties pour avoir un résultat qui te convienne mieux...

[Stilgardt]

Mouaif.... Pas tres glorieux, cette page sur Carmack de wikipedia...

Concernant ton probleme, il ne faut pas confondre le temps que prend la simu, et la vitesse à laquelle se déplacent tes objets.

J'ai pas l'impression que le frame rate soit mauvais avec Box2D ( pour un nombre raisonnable d'objet ), apres tu peux passer à ta lib physique un delta T plus grand que le vrai pour booster un peu les choses, ou modifier les différentes inerties pour avoir un résultat qui te convienne mieux...

Le livre "Les Maitres du Jeu Video (Masters of Doom)" est en effet bien plus à la gloire de John Carmack (et de John Romero). :)

Concernant ton autre remarque, c'est vrai que j'ai peut-être fait l'amalgame entre affichage et simulation. En étant moins précis sur certains aspects d'affichage, ce sera peut-être plus dynamique. Reste plus qu'à essayer pour me faire une idée ;)