«Je crée mon jeu vidéo» est une série d'articles sur la création d'un jeu vidéo, depuis la feuille blanche jusqu'au résultat final. On y parlera de tout : de la technique, du contenu, de la joie de voir bouger des sprites, de la lassitude du développement solitaire, etc. Vous pourrez suivre cette série grâce au tag gamedev.
Dans l'épisode 03, on a vu la version zéro du jeu : un sprite qui bouge sur une carte. Les commentaires se sont focalisés sur la carte (la manière de l'afficher notamment) et sur le scénario/guide/design du jeu. Certains lecteurs ont même tenté la compilation (et y sont parvenus pour la plupart, malgré les difficultés). Aujourd'hui, on va parler de moteur physique, et plus particulièrement de Box2D, qui devient de plus en plus une référence en la matière dans les jeux 2D.
Sommaire
Un moteur physique est une bibliothèque chargée de gérer les interactions physiques entre les entités du jeu. Techniquement, ça consiste à émuler des forces qui s'appliquent à des solides. Par conséquent, un moteur physique ne s'occupe absolument pas de la manière dont s'affichent les entités. On peut donc choisir son moteur physique presque indépendamment de son moteur graphique.
Le moteur physique Box2D
Box2D est un moteur physique. C'est une référence en 2D, le moteur est utilisé dans plusieurs jeux, dont le très célèbre Angry Birds. La dernière version (2.2.1) est un peu vieille (septembre 2011) mais elle est assez complète. Voici donc un petit aperçu de comment marche Box2D. Ce n'est pas vraiment un tutoriel, c'est plutôt un point d'entrée pour aller voir plus loin.
Bouge ton corps !
Un corps (body) est un élément solide, c'est-à-dire qu'il ne se déforme pas. Il est constitué de une ou plusieurs formes (shape), qui sont ajoutées au corps via des fixtures auxquelles on associe des propriétés matérielles (densité, friction, restitution). Plusieurs corps peuvent être unis par des liaisons mécaniques (joints) qui vont les priver de degré de liberté. Box2D permet de représenter toutes ces notions, voici quelques détails.
Les formes peuvent être très variées, depuis le cercle jusqu'à n'importe quel polygone convexe. On peut aussi créer des chaînes (chain) qui sont des suites de segments, ouvertes ou fermées, qui seront infranchissables par les autres solides (et on imagine assez bien l'utilisation qu'on va pouvoir en faire dans un jeu).
Comme dit précédemment, les fixtures contiennent des propriétés matérielles. La densité permet de calculer la masse du corps. La friction (ou frottement) permet de faire glisser deux corps l'un contre l'autre (pas d'allusion sexuelle dans cette phrase). La restitution permet de gérer les rebonds entre deux corps. Une fixture peut également devenir un capteur (sensor), c'est-à-dire qu'il n'y aura pas d'interaction avec les autres corps mais qu'on pourra tester si un corps est en contact ou pas.
Les corps peuvent être de trois sortes. Les corps statiques ne bougent pas, ils servent pour représenter des éléments fixes du décor et ne sont soumis à aucune force. Les corps dynamiques bougent, sont soumis à des forces et peuvent entrer en collision avec n'importe quel autre corps. Ils servent pour représenter les entités tels que les personnages. Une troisième catégorie de corps existe pour les corps qui ne doivent être soumis à aucune force mais qui doivent pouvoir bouger, comme une plateforme mobile par exemple. Ces corps sont des corps «cinématiques» (selon la terminologie de Box2D). Les corps statiques ou cinématiques ne peuvent pas entrer en collision les uns avec les autres.
Un corps a une position dans le monde et un angle. On peut également endormir le corps si jamais on veut qu'il ne participe pas à la simulation (quand on a beaucoup de corps par exemple). On peut indiquer qu'un corps va avoir une grande vitesse (comme un projectile par exemple) et qu'il faudra faire attention lors de la simulation. Dans ces cas là, Box2D utilise une détection de collision continue de manière à éviter les effets tunnels, c'est-à-dire un corps qui passerait par dessus un autre sans le toucher.
Enfin, il existe différents types de liaison mécaniques pour contraindre deux corps : liaison pivot, liaison glissière, etc. Elles permettent de modéliser des mécanismes tels que des poulies ou des tapis roulants ou plein d'autres choses de ce genre.
Que la force soit avec vous !
Tous ces objets sont définis dans un objet monde (world) qui s'occupe de la gestion mémoire et de la simulation proprement dite. Cet objet monde est défini avec un vecteur gravité qu'on définira à 0 si jamais on veut simuler un plan horizontal, comme dans un jeu en vue de haut, et à un vecteur descendant si on simule un plan vertical, comme dans un jeu en vue de côté. Ou à un vecteur bizarre dans un jeu où on s'amuse avec la gravité.
Hormis la gravité, il est également possible d'appliquer des forces, soit linéaires, soit angulaires. Ou alors une quantité de mouvement (impulse), soit linéaire, soit angulaire. Le corps se met alors en mouvement. C'est de cette manière qu'on peut faire bouger le héros ou les différents éléments mobiles d'un jeu.
Pour aller plus loin
Sur se former complètement sur Box2D, il y a d'abord la documentation officielle :
- la FAQ, à lire avant de commencer ;
- le manuel en PDF, qui décrit les concepts de manière simple et concise.
Une fois le manuel lu, vous aurez envie d'aller plus loin et là, il existe également de la documentation très intéressante :
- Box2D tutorials : une mine d'or, il y a les rappels de base, mais aussi des cas concrets qui sont décrits et implémentés dans l'outil de test de Box2D ;
- The nature of code : des tutoriels en vidéos, idéal pour ceux qui ne comprennent strictement rien aux paragraphes précédents.
Et pour ceux qui veulent en savoir plus sur les moteurs physiques :
- How to create a custom 2D physics engine, des articles qui montrent la création d'un moteur physique complet ;
- Game physics, une série d'articles sur les bases mathématiques des moteurs physiques ;
- Game Physics Simulation, le site de Bullet un moteur physique 3D.
Comment utiliser Box2D en pratique
Une échelle adaptée
Box2D requiert que les tailles des objets soient de l'ordre du mètre, la bibliothèque ne gère pas bien les très petits objets ou les très gros. Disons qu'entre une gemme et un dragon, ça passe. Il est donc nécessaire d'avoir une bonne échelle pour l'univers et de ne surtout pas utiliser des pixels comme unités. Une phase de conversion sera souvent nécessaire entre les coordonnées du monde Box2D et les coordonnées du monde du jeu ou celles de l'écran.
Intégrer Box2D dans un système à entités
J'ai repris l'exemple de balles rebondissantes que j'avais présenté dans l'épisode 01 pour ajouter la collision entre les balles à l'aide de Box2D. Le résultat est disponible sur le dépôt github de libes. Par rapport au tutoriel, voici les principaux changements liés à Box2D.
Au niveau des composants, les Position et Speed ont été remplacés par un composant Body qui contient simplement un pointeur vers un b2Body de Box2D (tout ce qui commence par b2, c'est de l'API Box2D).
struct Body : public es::Component {
b2Body *body;
static const es::ComponentType type = 1;
};Ensuite, il faut définir les murs et le sol. Pour cela, on utilise un corps statique (les constantes WORLD_WIDTH et WORLD_HEIGHT représentent la taille de la boîte dans laquelle les balles rebondissent). Ici, on dit que notre boîte fait trois mètres de haut pour 4 de large et on adapte l'échelle à la taille de la fenêtre.
// ground
b2BodyDef groundBodyDef;
groundBodyDef.position.Set(WORLD_WIDTH / 2.0f, -THICKNESS);
b2Body* groundBody = m_world->CreateBody(&groundBodyDef);
b2PolygonShape groundBox;
groundBox.SetAsBox(WORLD_WIDTH / 2.0f + THICKNESS, THICKNESS);
groundBody->CreateFixture(&groundBox, 0.0f);
// right wall
b2PolygonShape rightBox;
b2Vec2 rightPos(WORLD_WIDTH / 2 + THICKNESS, 2 * WORLD_HEIGHT);
rightBox.SetAsBox(THICKNESS, 2 * WORLD_HEIGHT + THICKNESS, rightPos, 0.0f);
groundBody->CreateFixture(&rightBox, 0.0f);
// left wall
b2PolygonShape leftBox;
b2Vec2 leftPos(- WORLD_WIDTH / 2 - THICKNESS, 2 * WORLD_HEIGHT);
leftBox.SetAsBox(THICKNESS, 2 * WORLD_HEIGHT + THICKNESS, leftPos, 0.0f);
groundBody->CreateFixture(&leftBox, 0.0f);Reste ensuite à définir des balles. Une balle a un corps dynamique de sorte que les balles vont s'entrechoquer et vont rebondir contre les murs et sur le sol.
b2BodyDef bodyDef;
bodyDef.type = b2_dynamicBody;
bodyDef.position = pos;
b2Body* body = world->CreateBody(&bodyDef);
b2CircleShape circle;
circle.m_radius = RADIUS / SCALE;
b2FixtureDef fixtureDef;
fixtureDef.shape = &circle;
fixtureDef.density = 1.0f;
fixtureDef.friction = 0.001f;
fixtureDef.restitution = 0.98f;
body->CreateFixture(&fixtureDef);Et voilà, il n'y a plus qu'à lancer tout ça. Et les collisions se font automatiquement, il n'y a rien à faire, juste à afficher où les balles se situent. Ici, on ne gère pas l'angle des balles. Comme elles sont rondes, pas besoin de faire de rotation. Mais si on faisait la même chose avec des carrés, il faudrait afficher les carrés avec le bon angle. Il n'empêche que les balles tournent bien sur elles-mêmes et que ça a un impact (jeu de mot toussa) sur les collisions.
J'oubliais presque. Pour simuler notre monde physique, il est nécessaire d'appeler la fonction adéquate, dans la mise à jour du système Physics :
int32 velocityIterations = 10;
int32 positionIterations = 8;
m_world->Step(delta, velocityIterations, positionIterations);On voit qu'on peut régler le nombre d'itérations. Concrètement, pourquoi a-t-on besoin de plusieurs itérations ? Si on considère un pendule de Newton, on se rend compte que la collision de la première bille va entraîner une force sur la seconde qui va elle-même entraîner une force sur la troisième, et ainsi de suite jusqu'à la dernière bille qui sera propulsée. Avec une seule itération, on ne pourrait gérer que la première interaction et non la suite d'interactions. Évidemment, il y a un compromis à trouver entre le nombre d'itérations et la précision : un grand nombre d'itérations donnera une meilleure précision mais prendra plus de temps et inversement.
Les autres nouvelles d'Akagoria
Git branching model
Sur les trois dépôts existants (libes, libtmx et akagoria), j'ai mis en place le fameux successful git branching model, histoire de m'y retrouver moi-même dans ce que je fais. Il existe désormais une branche develop qui reçoit les nouveaux développements, et une branche master qui sera synchronisée quand les développements fonctionneront à peu près.
En fait, ce modèle est très logique et fonctionne assez naturellement. L'essayer, c'est l'adopter !
Mise à jour libes : systèmes locaux
La libes a reçu un nouveau développement qui permet de différencier des systèmes locaux et des systèmes globaux. Un système global est un système qui agit sur l'ensemble des entités qu'il gère, c'est ce qui était fait avant. Un système local est un système qui gère uniquement une partie des entités, celles qui sont autour du focus. Chaque système local traite donc un ensemble d'entités réparties dans une grille rectangulaire propre à chaque système. Au moment de mettre à jour les entités, le système détermine les cases de la grille qui sont concernées, celles où se trouve le focus ainsi que les 8 cases adjacentes, et les transmet à la fonction de mise à jour.
Je ne sais pas si cette fonctionnalité est suffisamment intéressante pour se trouver ici ou si elle devrait être déportée dans le jeu lui-même. Pour l'instant, elle est ici. On pourrait encore l'optimiser. Pour l'instant, les entités concernées sont calculées à chaque fois, mais si le focus ne change pas, on pourrait renvoyer le dernier calcul fait, avec une mémoïsation.
Mise à jour d'Akagoria : carte partielle
Depuis le dernier épisode, je me suis concentré, entre autres, sur l'affichage de la carte (en mode moins bourrin qu'auparavant). J'ai utilisé pour cela les nouvelles fonctionnalités de libes décrites juste avant. J'ai donc créé un système MapRender qui est chargé du rendu de la carte. Il crée les entités correspondant à chacune des tuiles puis les place suivant une grille. La grille partage la carte en carrés de 50 tuiles de côtés, ce qui fait que sur ma carte actuelle, j'ai 25 cases en tout. Désormais, la carte n'est donc plus affichée entièrement. Quand on dézoome, on le constate, et quand on bouge, on le constate encore mieux, certaines zones disparaissent tandis que d'autres apparaissent.
Pas de capture d'écran pour cette fois, mais la prochaine fois, il y aura des surprises !
Et toujours IRC
Vous pouvez toujours passer sur le canal IRC #akagoria du réseau freenode pour poser des questions, avoir de l'aide pour la compilation du bouzin, ou juste pour dire bonjour. Il y a un compte connecté quasi en permanence qui me permettra de voir l'activité même quand je ne suis pas là.
Aller plus loin
- Akagoria, la revanche de Kalista (231 clics)
- le tag gamedev (155 clics)
- Box2D (183 clics)
# Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Paf, le chien.
Posté par rewind (Mastodon) . Évalué à 10.
Reste dehors, hein, ça ira à tout le monde ;)
# petit probleme dans le texte
Posté par djano . Évalué à 2.
s/linéaire,s/linéaires,/
[^] # Re: petit probleme dans le texte
Posté par Benoît Sibaud (site web personnel) . Évalué à 2.
Mea culpa. Re-corrigé merci.
# de la phy 2d
Posté par fabien . Évalué à 9. Dernière modification le 29 octobre 2013 à 13:53.
Déjà merci et félicitation pour cette dépêche, c’était très intéressant.
Je connaissais peu cette bibliothèque Box2D, et je dois dire que c’est un excellent boulot. Mais j’aurai deux petites remarques.
Premièrement, je me demande comment gérer des objets dont la gravité ne serait pas le seul propos. Par exemple, pour un mario bros (oldschool) autant le sol serait un solidet, mais les tiles/plateformes sur lesquels on saute ? si on en fait des solide ils vont tomber ?
Peut-on ajouter des interactions autre que le contact ? par exemple une porte, qui nécessite une clef, à la collision, peut-on sortir (callback) du moteur pour savoir si on ne passe pas la porte ou bien si ca passe (on ouvre la porte), idem pour les bonus peut-on faire en sorte que la collision avec celui-ci fasse une action (le prendre).
On pourrait imaginer ne pas mettre le bonus dans le moteur physique 2d, mais d’une ça serait crade (duplication) et aussi si on veut que nos bonus puissent vivre dans le niveau (rappelez-vous les champignons qui se déplacent dans mario)… idem pour les ennemis… et si je veux faire un ennemie qui marche aux murs/ aux plafonds (une araignée)
Deuxième remarque (qui est un peu le corolaire de la première, vu la complexité à sortir du modèle) j’ai un peu peur que de nombreux jeux basé sur un tel moteur 2d, ne soit rien de plus qu’un jeu de physique. Exemple typique : angry bird (certes très prenant, mais finalement pauvre). Je ne compte pas le nombre de jeu que j’ai essayé où je me suis dit « tiens il y a un moteur phy derrière » et du coup une fois qu’on a joué avec le moteur, ben c’est tout quoi. Ça serait dommage que ça ne soit le seul aspect positif d’un jeu, non ?
N’avez-vous jamais essayé un jeu avec des caisses qui rebondissent quand vous les effleurez ?
A mon sens, une bibliothèque physique apporte énormément (et je suis sûr que box2d est super) mais comme un moteur 2d ne peut pas tout faire, il y a plein de choses qui sont limitée ou très complexe, donc c’est les fonctionnalités du jeu qui risquent de s’en ressentir.
Ensuite, tout dépends de l’intention de l’auteur du jeu :
- s’il veut faire un jeu « de physique » sans autre ambition (genre un clone d’angry bird), le contrat est plus que rempli.
- s‘il veut faire un jeu 2d, et qu’il a plein d’idée non lié à la physique, s’il compte reléguer la partie phy à une bibliothèque, il risque de se prendre la tête, ou laisser quelques concepts de côté.
Enfin, c’est mon avis, hein…
[^] # Re: de la phy 2d
Posté par rewind (Mastodon) . Évalué à 7.
Non, ils ne vont pas tomber, si tu en fais des objets statiques, ils restent là où ils sont, ils ne sont pas soumis à la gravité.
Le moteur physique n'est qu'un élément du jeu. Donc, il y a une partie de la logique du jeu qui sera en dehors. Pour ton exemple avec la porte et la clef, je vois deux solutions : premièrement, tu peux créer la zone qui capte uniquement quand tu as récupéré la clef, ce qui fait qu'avant, tu ne peux pas passer ; deuxièmement, avec Box2D, tu peux créer un listener quand un objet entre en contact avec un autre, il suffit alors, dans ton listener de tester si tu as la clef. Pour ton bonus, c'est pareil, un petit listener et hop.
Là, je dois dire que tu me pose une colle. Je pense que c'est possible, il suffit d'appliquer une force contraire à la gravité en permanence mais je n'ai jamais essayé ni vu de choses à ce sujet.
Ou pas. Dans tous les jeux, tu dois gérer des collisions avec les éléments du décor. Tu peux le faire à la main pour des cas simples, mais dès que le jeu devient un poil complexe, tu te retrouves à réinventer la roue. Et là, tu découvres qu'un moteur physique, ça fait déjà tout et sans doute mieux. Et ça ne veut pas dire que ton jeu est basé sur la physique, juste que tu délègues cette partie à une bibliothèque qui le fait mieux que toi. Box2D a l'air suffisamment flexible pour traiter un grand nombre de situations (en tout cas, je ne me sens pas limité pour l'instant) donc, ce n'est pas vraiment un frein. Si jamais ça arrive, j'en ferai part dans un prochain article.
[^] # Re: de la phy 2d
Posté par fabien . Évalué à 4.
Justement je trouve pas génial le fait de "jouer" avec les forces, genre "appliquer une force contraire à la gravité en permanence".
C'est compliqué si le déplacement se résume à l'application de force, alors c'est vrai que c'est pratique, que ça fait un joli déplacement réaliste.
Par contre, si je compte faire une chauve-souris dont le déplacement (que j'ai) prévu est une sinusoïdale, si je dois jouer sur la "force contraire à la gravité" (mais pas en permanence pour le coup…)
ha, c'est bien ça. merci.
Ok, c'est pratique.
Merci pour ces éléments.
[^] # Re: de la phy 2d
Posté par rewind (Mastodon) . Évalué à 3.
Oui et non. En fait, je n'y avais pas pensé tout à l'heure mais Box2D permet d'appliquer un facteur (éventuellement nul) à la gravité sur chaque corps indépendamment. Donc, c'est bien prévu par la bibliothèque d'avoir ce genre de situation bizarre.
[^] # Re: de la phy 2d
Posté par Larry Cow . Évalué à 3.
Et heureusement, sinon comment gérer le cas des plus légers que l'air? :p
[^] # Re: de la phy 2d
Posté par rewind (Mastodon) . Évalué à 7.
Les plus légers que l'air n'ont pas une gravité plus faible mais une densité plus faible ;)
[^] # Re: de la phy 2d
Posté par Zylabon . Évalué à 2.
Et ça calcule la poussée d’Archimède ?
Please do not feed the trolls
[^] # Re: de la phy 2d
Posté par rewind (Mastodon) . Évalué à 2.
Non, je ne pense pas. Il n'y a pas moyen de définir des zones qui ont un comportement différent.
[^] # Re: de la phy 2d
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
Tu peux à tout moment retirer un objet du moteur physique et en faire autre chose: dans Newton Adventure, quand on ramasse une pomme, elle est retiré du moteur physique et remplacer par un simple sprite avec une animation pour la faire rétrécir et rejoindre le sprite de Newton.
Pour chaque objet du monde, tu peux désactiver la gravité ou en appliquer une différente.
C'est le principal problème des moteurs physiques actuels: il est difficile de mixer un gameplay "oldschool" avec une physique réaliste. J'ai mis beaucoup de temps à trouver les bons paramètres pour mon jeu et ça donne des bugs étranges…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: de la phy 2d
Posté par fabien . Évalué à 3. Dernière modification le 29 octobre 2013 à 17:55.
Exactement,
J'osai pas le dire mais initialement j'avais une 3eme remarque :
j'ai bien l'impression qu'il faut y aller a tatonnement dans les parametres de la physique
quand je vois :
fixtureDef.friction = 0.001f;
ça me fait juste peur : c'est quoi ce 0.001, ça sort d'où ? et le 0.98 etc…
Je n'aime pas utiliser un outils sans en connaître les tennants et les aboutissants.
ça donne l'idée qu'on est obligé de bricoler, du coups ça se ressent dans certains jeux…
[^] # Re: de la phy 2d
Posté par Batchyx . Évalué à 8.
C'est genre clairement expliqué dans le manuel utilisateur: c'est de le coefficient de friction de la loi de coulomb
[^] # Re: de la phy 2d
Posté par fabien . Évalué à 4.
Ce n'est pas le sens de ma question, je n'ai pas demandé "c'est quoi fixtureDef.friction ", mais plutot "d'où sort ce 0.001", tu as repondu (à raison) en physicien,
ma question est plus une question de developpeur : je veux faire un jeu avec box2d, je mets quoi dedans, dans ce source il y a 0.001, pourquoi 0.001 ?
Merci a Strash, pour l'effort d'explication.
et Merci a rewind pour les explications du passage de la physique à l'informatique (à "tatonnement".
Au passage, c'est intéressant de lire vos 3 posts dans l'ordre Batchyx, Strash, rewind : on passe de la physique pur, à des explications de plus en plus didactique puis quasiment opérationnelles. Ma question n'a pas été comprise de la même maniere en fonction de vos specialités.
mon problème c'est que je ne suis pas physicien, d'où mon appréhention sur la mise en oeuvre. C'est pas facile, tous les dev ne sont ingé en physique :)
Car je me lance : en général je suis souvent déçu du gameplay des jeux qui intègrent un moteur physique, je me dit que c'est soit une limitation de la bibliotheque soit une "limitation" du dev à l'utilisation, ou un mixte des deux.
[^] # Re: de la phy 2d
Posté par rewind (Mastodon) . Évalué à 5.
Je pense qu'utiliser un moteur physique sans comprendre un minimum la mécanique du solide, c'est dangereux. J'ai toujours eu horreur de la physique, mais j'ai quelques restes qui me permettent de comprendre grosso-modo les termes et leurs implications. Si je change un paramètre, je sais quel effet ça aura. Et ça, ça aide beaucoup. Du coup, le tâtonnement, il est très dirigé, ce n'est pas non plus du free style complet. Le manuel, d'ailleurs, est très bien fait de ce point de vue, il est fait par un physicien qui explique à des informaticiens ce qui se passe. Mais je pense que du coup, il ne va pas assez loin au niveau des explications du pourquoi du comment.
[^] # Re: de la phy 2d
Posté par fabien . Évalué à 5.
Ha mais je suis bien d'accord,
Mais il est facile pour quiconque de prendre 2 ou 3 exemples sur le net de "comment utiliser box2d", le dev lambda va copier/coller certains parametres qui juste marchent, ou il va dibouiller un peu pour que ça roule, sans tester aux limites.
Et ma fois… si les trucs rebondissent comme du polystyrene bah c'est pas grave hein, voir même c'est fun comme angry bird, et puis il y a tellement de jeux qui ont ce comportement, le joueur ne sera pas dépaysé :) du coups le dev est content (même si c'était peut être pas l'effet recherché, il lui convient)
[^] # Re: de la phy 2d
Posté par Strash . Évalué à 6.
Je n'y connais rien en Box2D mais je m'y connais en physique.
Je pense qu'il s'agit du coefficient de frottement cinétique, qui dépends des matériaux, de la lubrification, de l'état de surface, etc…
A partir de ce coefficient et du poids apparent, tu peux calculer le frottement cinétique qui va te permettre de calculer la décélération du corps en mouvement.
Donc ça n'a rien de sorti du chapeau, et si tu veux reproduire un comportement observé réellement tu peux mesurer le coefficient de frottement cinétique et ainsi déduire le chiffre que tu veux mettre dans ton simulateur.
Mais bon, comme c'est un jeu et non une simulation, on peut aussi faire varier les paramètres et voir ce qui semble le plus agréable à utiliser et à regarder. Chose qui est différent de la réalité physique.
[^] # Re: de la phy 2d
Posté par rewind (Mastodon) . Évalué à 4.
Ça sort de mon chapeau :P Non, sérieusement, comme dit plus haut, et si tu suis les liens dans la dépêche, ces valeurs ont une définition physique réelle. Le 0.98, ça veut dire que la balle va perdre un peu de son énergie et donc va rebondir un tout petit peu moins haut. Et le 0.001, j'y suis allé par tâtonnement, n'ayant aucune idée des valeurs réelles pour ce genre de matériau. Au début, j'avais mis quelque chose de plus haut et j'obtenais un comportement digne des vrais balles rebondissantes (ça «accrochait»). J'ai donc descendu la valeur jusqu'à ce que ça me semble plus glissant.
En fait, une fois qu'on comprend la signification physique, on peut jouer un peu. Le manuel donne aussi une indication essentielle pour savoir comment est calculé la friction et la restitution quand deux solides entrent en contact : pour la friction, c'est une moyenne géométrique des deux frictions ; pour la restitution, c'est le max des deux restitutions. Ça aide à comprendre un peu comment ça va se comporter.
# ça continue
Posté par reynum (site web personnel) . Évalué à 2.
Comme les précédentes, merci pour cette dépêche très intéressante.
kentoc'h mervel eget bezan saotred
# La vieillesse selon chacun
Posté par Zarmakuizz (site web personnel) . Évalué à 2.
Certes, dans le web 1 an ça commence à faire vieux, mais je suis dans une société où un logiciel sorti en 2005 est récent. Est-ce que tu peux expliquer en quoi 2 ans fait vieux pour un moteur physique ? (Il manque des petits détails ou des grosses fonctionnalités toujours pas en place ? Des bugs pas corrigés ?)
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: La vieillesse selon chacun
Posté par rewind (Mastodon) . Évalué à 3.
Le «problème», c'est qu'il y a eu des changements depuis cette dernière version, mais aucune release. J'avais vu une roadmap (mais je ne la retrouve plus) et il y avait encore des fonctionnalités prévues. Donc, le logiciel n'est pas abandonné, mais il n'y a plus de release depuis un moment.
[^] # Re: La vieillesse selon chacun
Posté par dave_null (site web personnel) . Évalué à 2.
J'en profite pour signaler au passage que dans le monde du web, il est arrivé un concurrent à Box2dWeb (Box2dWeb est un portage automatique de Box2dFlash, qui est un portage du Box2D original en C) : http://wellcaffeinated.net/PhysicsJS/
Grosso modo, ce qui change c'est l'API qui est dans les standards du langage au lieu d'avoir une façon de programmer à la C.
# Association autour des jeux vidéo sous GNU/Linux
Posté par aranud (site web personnel) . Évalué à 1.
Salut,
Je me permets d'un article traitant des jeux vidéos pour dire que je recherche des joueurs/joueuses sous GNU/Linux afin de monter une association à but non lucratif sur Marseille.
-> Etre majeur
-> Disponibilité le week-end (si possible dernier Samedi de chaque mois)
Rôle de l'association :
Install Party (migrer à Linux avec l'association CercLL)
Découverte des jeux sous Linux
Lan Party
…
News :
http://www.mageia-debutant.fr/news/news-1-22+association-de-jeux-bis.php
Vous pouvez me contacter :
http://www.mageia-debutant.fr/contact/index.php
Page FB :
https://www.facebook.com/pages/French-Linux-Gamers/511561308940850
Merci et à bientôt
Aranud
Webmaster Mageia-Debutant.fr
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.