Voilà, j’ai donc un problème avec les objets dont je réduit la taille :
j’ai remarqué par exemple que la fonction “distance entre deux objets” créé des aberrations quand on réduit la taille de l’objet,
ce qui fait que, en application de collisions par exemple, le vaisseau se heurte non plus au centre de l’image mais au bord supérieur gauche de l’objet.
Je reconnais que c’est quelque part logique dans la programmation, mais cela pourrait être très facilement contourné si, en plus de la fonction
“distance entre deux objets” , on avait une fonction du genre “distance entre deux points d’objets”.
Je sais que ce serai plus simple de faire mes tests de collision justement avec la fonction “collision” plutôt qu’en fonction des distances,
mais il faut avouer que ça bouffe du framerate, et si tous les tirs, les éclats, etc… utilisent de vraies collisions, ça va être dur ! 
En effet, en augmentant un objet, l’expression calculant la distance entre deux objets semble perdre la boule.
Mais par contre, la distance est normalement calculé suivant la distance entre les deux points centre des objets. Dans si un objet grossis ou diminue, la distance devrait rester correcte quand j’aurai effectué la correction.
J’ai donc refait différents tests, et… j’ai toujours le même résultat…
J’envoie un grand nombre d’objets tirs depuis mon vaisseau sur un astéroïde et qui s’arrêtent à une certaine distance de ce dernier,
et ces tirs se condensent TOUS autour d’un point en haut à gauche de l’astéroïde, comme si l’image était décalée… Help.
J’ai réglé le problème du centre qui s’en va n’importe où, maintenant si on demande de diriger un objet vers un autre, ou qu’on demande d’afficher la distance entre deux objets, le déplacement/calcul est fait en fonction du centre des objets comme actuellement, mais le centre reste maintenant correctement placé même si l’objet est agrandi/réduit.
Par contre, si ton astéroïde n’est pas redimensionné, les tirs devraient bien se diriger vers le centre de celui ci, si tu utilise l’action “Diriger un objet vers un autre”…
Peut être une copie d’écran des évènements impliqués aiderait. Ou alors, fait un mini jeu qui montre ce qui va pas, car j’ai testé l’action “Diriger un objet vers un autre”, l’objet est bien dirigé vers le centre de l’autre ( tant qu’on ne redimensionne pas un des deux vu que c’est actuellement buggé donc. )
Non, en fait je tirais juste dessus avec le vaisseau (visée à la souris), les tirs n’étaient pas guidés, je me suis mal exprimé…
Par contre je comprends pas, tu dis que le centre s’en allait n’importe où et que tu as pu régler le problème, où qu’en fait il n’y en avait pas ? (sur la fonction distance)
Actuellement, dans la version que tu as :
-Si tu ne change pas la taille des objets, il n’y a normalement pas de problème. C’est à dire que le centre reste bien là où il doit être, la distance est calculée en fonction de la distance entre les deux centres, et les actions qui dirige les objets dirigent bien le centre d’un objet vers le centre d’un autre.
-Si tu change la taille des objets, la position du centre est mal calculée.
J’ai corrigé pour la prochaine version :
-Même si la taille des objets est changée, le centre est correctement placé.
Tu utilise la condition distance pour faire les collisions tirs/astéroïde, c’est ça ? Dans ce cas, la distance testée correspond à la distance entre le centre du tir et de l’astéroïde donc.
Avec la version que tu as, si tu change la taille d’un des objets, ça risque de perdre la boule par contre, vu que le centre sera mal placé.
Oui, comme tous mes astéroïdes possédaient une taille aléatoire en fonction de leur vie, le problème était généralisé…
Mais merci d’avoir réglé ça !
Une dernière question à propos des objets multiples à l’écran : le fait que le jeu rame quand il y a trop d’objets
ne serait-il pas un problème de technologie ? Un défaut de l’openGL par rapport à directx par exemple ?
Je ne pense pas, la bibliothèque d’affichage qui utilise donc OpenGL est performante.
Le problème viendrait plutôt à mon avis du système de sélection d’objets, qui est plus lent plus il y a d’objets à tester ( même si il y a plein d’objets qui servent d’effets par exemple et un seul objet “Héros”, plus il y aura d’objets effets, plus ce sera lent ).
En parlant d’optimisation, j’ai remanié ( encore ) la partie qui gère l’évaluation des expressions. Cette fois, toute les expressions sont “parsées” au démarrage, les fonctions à appeler mises en mémoire au démarrage aussi, ce qui fait qu’il n’y a plus que l’évaluation proprement dite à faire en plein jeu.
En pratique, ça ne se voit pas forcément sur les jeux, mais sur un jeu de test avec 1000 objets tournant sur eux mêmes, on passe de ± 45 fps à ± 100 fps. ( Attention, ça reste peu visible sur les véritables jeux cependant. )
Waow, c’est tout de même impressionnant ! et puis c’est important d’avoir des bases efficaces pour le logiciel.
Dis-moi, je m’écarte une peu du sujet, mais j’ai pas envie de créer un topic juste pour ça :
A propos de la technologie utilisée (dont je te parlais), pourquoi les développeurs choisissent-ils telle ou telle interface ? (directx ou opengl)
C’est aussi parce que je crois me souvenir que dans un sujet tu disais que de se baser sur directx était une mauvaise idée…
On me pose tout le temps la question et jusque-là je n’ai jamais eu une vraie idée de la réponse 
A nuancer, à nuancer, hein, ça ne se verra sans doute pas de façon flagrante sur un véritable jeu ( par contre, avec le jeu de test, pas de doute possible, il y a de l’amélioration ).
OpenGL est portable, ce qui permet aux jeux de fonctionner sur d’autres systèmes que Windows, alors que DirectX n’est pas près d’être adapté sur d’autres plateformes. Par contre, DirectX est beaucoup plus utilisé par les jeux commerciaux entre autres, OpenGL est plus laissé de coté ( quoique les moteurs des fps d’ID Software fonctionnent avec ).
DirectX est plus vaste, avec de nombreuses bibliothèques qui ne font pas que de la 3D, mais aussi du son, du réseau. OpenGL reste cantonné à l’affichage, on pourrait donc plutôt le comparer à Direct3D/DirectDraw, les bibliothèques d’affichages de DirectX.
Après, on peut utiliser directement ces bibliothèques ou en utiliser qui agisse en “surcouche” par dessus, voir en utiliser qui ne font appel ni à OpenGL ni à DirectX ( comme SDL, mais si on veut avoir des performances décentes, on en arrive rapidement à utiliser OpenGL ).
Ensuite, le choix de se baser sur l’une ou l’autre dépend de chacun. Personnellement, j’avais entendu parlé de SFML, une bibliothèque 2D intégralement écrite en C++, libre, portable et performante.
Personnellement, je cherche presque toujours des bibliothèques libres, parce qu’on peut consulter le code source, parce qu’on peut les utiliser souvent sans trop de restrictions, et portables, car cela signifie qu’elle n’utilise pas d’obscures codes qui risque de ne plus marcher lors de la mise à jour du compilateur/du système, et parce qu’on peut les utiliser sur d’autres systèmes.
Donc directx est plus performant q’OpenGL?
Dit voir
Ce serait possible d’utiliser des fonctions de directx dans les futures extensions de gd ainsi de bénéficier des fonctions de directx sur OpenGL 
Voila 
Où est ce que j’ai dit que DirectX était plus performant ? Nulle part.
Et non, je ne vais pas commencer à mélanger directX et OpenGL. Je perds alors l’avantage de la portabilité, et je ne fais pas des choses mieux avec.