Salut 4ian,
voilà, pendant que j’essayais de réajuster plusieurs éléments dans mon jeu (pour éviter que le tout rame trop),
j’ai jeté un coup d’œil aux chiffres des différentes forces qui pouvait s’y exercer… Et je me suis dit que cela
faisait (rien que pour UNE force) beaucoup de décimales !
En ne faisant faire qu’une esquive à mon vaisseau, voici ce que donne sa vitesse : 382.11128931.
Alors ma demande est peut-être assez stupide ou illogique (trop peu de sommeil…),
mais ne pourrait-on pas grandement améliorer le “moteur” de GD en limitant le nombre maximum
de décimales du calcul des forces ?
Et sinon, serait-il possible (utile en fait) de créer une action de déplacement simplifiée qui utiliserait
un multiplicateur fixe, genre 1 ? Cela éviterait au logiciel de devoir recalculer sa vitesse à chaque rafraîchissement.
Voilà, je propose cela car je vois à quel point ce sont les déplacements qui pompent les ressources d’un jeu
plus que toute autre actions. Surtout quand on essaie de créer un moteur physique !
J’utilise des “float” pour les coordonnées des forces, il est vrai que les opérations pourrait devenir vite assez couteuse.
J’essayerai d’effectuer des tests de vitesses en changeant ces “float” pour des entiers “int” et en voyant si ça change significativement quelque chose.
Par contre, si tu ne souhaite pas utiliser les forces, tu peux gérer manuellement les déplacements de tes objets :
Pour des déplacements simple, c’est aussi relativement simple. Par exemple, pour déplacer un objet de 100 pixels par seconde vers la droite, tu peux faire : Faire +100*VAL(timeDelta[]) à la position X de MonObjet. Le “VAL(timeDelta)” servant à obtenir un déplacement continu et non dépendant de la vitesse d’exécution des évènements.
Oui, mais le problème c’est que le déplacement de chaque quel objet du jeu se fait à 360°,
et puis tenter de créer un moteur physique sans force, ça va être dur, surtout pour les ralentissements,
la friction, etc… Mais je vais quand même essayer.
En tout cas, merci d’avance pour les tests, j’ai vraiment hâte de voir les résultats !
(surtout pour améliorer mes systèmes de particules ! )
PS : si le fait d’enlever les floats crée une problème d’échelle des forces,
on peut peut-être (si ça se fait) juste en faire une option à cocher pour l’action concernée ?
Re-PS : Question bête, mais y a-t-il une différence entre une accélération à “0.2” et une à “-0.2” par exemple ?
D’un autre coté, un moteur physique, c’est quelque chose de vraiment extra complexe.
Il faudra sans doute que j’introduise à un système de “comportements” ou quelque chose du genre avant de pouvoir profiter d’un véritable moteur physique dans Game Develop.
Rien ne t’empeche de moduler, par exemple avancer de 5 pixels par seconde en X et 30 pixels par secondes en Y.
Mais ça peut évidemment devenir vite galère, c’est à réserver au déplacement les plus simples.
Par exemple, tes particules pourrait être gérée par un simple déplacement de position si leur déplacement n’est pas trop complexe.
Qu’entendu tu par accéleration ? Si c’est la dissipation des forces, le fait d’avoir un moins va inverser à chaque rafraichissement le sens de la force ( C’est donc pas très conseillé ).
Au niveau physique pure, une accélération à “-0.2” est une décélération, la vitesse diminue.
Par contre, je ne sais pas si ça a a voir avec les forces mais moi j’ai des objets en masses dans PKMNCC qui fond l’arrière plan:
Vous savez ceux qui tournent et qui se déplacent:
Et ben en fenetre d’apercu il est frequent qu’ils tournent super vite: la vitesse que j’aimerais avoir tout le temps. par contre dès que c’est compilé ils tournent a 2 a l’heure
Le passage des composantes des forces de variables “float” à “int” ne semble pas beaucoup impacter sur les performances. A vrai dire, je n’ai pu relever de différence, sur un jeu de test composé de 1000 objets auxquels j’appliquais diverses forces : Que je leur ajoute 1, 2 ou 10 forces, les images par secondes de la version actuelle de Game Develop et de celle utilisant des int pour les forces étaient les mêmes.
Je suppose que si il y a optimisation à faire dans ce sens, ce serait plutôt au niveaux des calculs employés dans Game Develop.
Actuellement, je crois bien que c’est ce qui est à même de faire ramer le plus les jeux, un excès d’objets. Et surtout des objets où l’on va effectuer beaucoup de tests et de modifs ( 1000 objets complètement statiques, utilisés nuls parts dans les évènements, peuvent ainsi avoir un impact mesuré face à 100 objets qu’on teste en permanence, qu’on bouge, qu’on modifie…).
)