Je trouve le moteur physique un petit peu dépassé pour des jeux plus complexe comme un MarioBros-like, ainsi , actuellement, le moteur physique ne gère pas les pentes, ou tout autre objet biscornu. Il lui manque quelques fonctions, déjà proposé dans le passé, mais sans grande réponse. Ainsi voici une liste non-exhaustive d’amélioration au moteur physique.
Option “Considérer comme un obstacle” au moteur physique. Ainsi, un objet pourrait laisser passer un autre objet et inversement.
Reconnaissance automatique des masques de collision des sprites par GD, ou manuelle par l’utilisateur, qui devra les dessiner.
Collision encore plus précise : actuellement, un ou deux pixels séparent les objets (se voit très bien dans SoccerPea)
Pourtant si j’ai bonne mémoire, Box2D est entièrement intégré dans les sources et indépendant de quoi que ce soit d’autre. Tu as essayé de faire une recompilation ( Rebuild ) entière du projet ?
Ah oui, en effet, fallait recompiler entièrement.
Merci.
Sinon, j’ai réussi à contourner les limitations de Box2D (maximum 8 vertices, pas de forme concaves) grâce à un algo qui triangule le polygone que l’utilisateur crée.
Jusqu’ici, le fait d’imposer à l’utilisateur d’entrer les coordonnées du polygone ne m’attirait pas tant que ça… Mais au final, il y a aura peut être moyen d’intégrer une petite zone à coté permettant d’avoir un aperçu du polygone, ça permettra de faire un peu moins “brut”. Je m’occuperai de ça au besoin.
Oui, mais la base est là.
Je vais tenter de faire ça, mais c’est toi qui a crée le widget qui gère les sprites (celui qui permet de placer les points) ?
Il n’est pas dans le GDLSDK ?
Oui c’est moi, mais il serait de toute façon assez difficile à extraire de son contexte, et puis c’est pas un modèle d’ergonomie ( L’éditeur des objets Sprite serait à recoder entièrement pour être plus clair et ergonomique ).
J’ai regardé l’exemple “dragimag” de wxwidgets ( répertoire samples ) qui montre une fenêtre où l’on peut déplacer les images. Dans l’idéal, l’édition du polygone se ferait comme ceci, avec des points que l’on peut glisser et déposer.
Sinon, j’ai un problème avec le redimmensionnement.
Je voudrais savoir l’échelle de redimensionnement d’un objet afin d’adapter le polygone de collision, mais impossible de trouver une méthode qui fasse ça… (ou au moins avoir la taille originale de l’objet)
Sinon, pour facilement avoir un vector à partir d’un std::string et inversement, il y a deux fonctions statiques dans PhysicsAutomatism :
[code]/**
Return a string representing the coordinates vector.
\param vec the vector containing coordinates
\param coordsSep the separator between coordinates
\param composantSep the separator between the X and Y composant of a coordinate
\return a std::string representing the vector
*/
static std::string GetStringFromCoordsVector(const std::vectorsf::Vector2f &vec, char coordsSep = ‘\n’, char composantSep = ‘;’);
/**
Return a vector created with a string containing coordinates
\param str the string
\param coordsSep the separator between coordinates
\param composantSep the separator between the X and Y composant of a coordinate
\return a std::vector< sf::Vector2f >
*/
static std::vector<sf::Vector2f> GetCoordsVectorFromString(const std::string &str, char coordsSep = '\n', char composantSep = ';');[/code]
Pour l’éditeur de coordonnées, j’ai rien pu faire : je suis vraiment nul avec WxWidget (ça se comporte jamais comme je veux en fait…)
Ce masque de collision custom sera compatible avec les Lumières ?
Autant je ne suis pas convaincu qu’un masque de calque polygonal soit essentiel (un carré fait le boulot dans 99% des cas), autant avoir des lumières qui suivent effectivement la forme du sprite serait génial.
)
