Oui, plus ou moins, par exemple, tu peux rendre visible un objet Texte qui affiche “Chargement en cours…” juste avant une action de changement de scène.
Ainsi, pendant que les images se chargeront ( Ce qui est cependant assez court quand même généralement ), le joueur verra la dernière image de la scène, c’est à dire par exemple le joli texte “Chargement en cours…”.
Ce changement au niveau de la gestion des images est surtout visible lors du lancement du jeu. Par exemple, imaginons un jeu qui utilise des tonnes d’images et dont la première scène n’a pas d’images. Avec les anciennes versions, tout était chargée au démarrage, alors que maintenant, le démarrage est quasi instantané.
Si plus aucun objet n’utilise une image, elle est déchargée de la mémoire. Donc si tu est dans un niveau de ton jeu, et que tu reviens au menu, toutes les images du niveau sont déchargée.
hé donc avec les automatismes je vais pouvoir simuler de la graviter avec mes objet
cool reste pluque a savoir comment sa marche, je vais feuilleter l’aide
Bien sympa tout ça !
Bien vu le chargement progressif des images, vraiment pratique
Et le moteur physique a l’air plutôt solide, il faut que je trouve comment ça marche maintenant
Ce qui amène une question : peut-on (ou doit-on) remplacer les forces par cet automatisme ?
Je dis ça car la gestion des collisions (repousser un objet d’un autre) m’a l’air nettement plus efficace que ce que j’ai pu mettre en place auparavant…
Et dans ce cas, la consommation de mémoire est-elle plus grande qu’avec un système classique (basé seulement sur les forces) ?
C’est même du chargement “on-demand” . J’espère que ça permettra aussi de résoudre les problèmes de plantages bizarres quand trop de scènes sont ouvertes. Par contre dans l’éditeur, il faut fermer le jeu pour que les images soit déchargées. Mais ça peut être quand même utile pour éviter de tout charger pour éditer un menu, ou quand on a des scènes avec des images variés.
Pas vraiment non. Les forces intégrées à Game Develop permettent de déplacer facilement un objet sans se prendre trop la tête. L’automatisme Moteur Physique est (beaucoup) plus puissant mais aussi moins malléable, et ça sera plus prise de tête de lui faire faire exactement ce qu’on veut. Maintenant, suivant le jeu, le remplacement n’est pas impossible. Par exemple, dans l’exemple “3DEngineWithPhysics”, j’ai remplacé le déplacement et les tests de collision par le moteur physique.
Consommation mémoire, ce sera plus important ( maintenant, je sais pas à quel point, surement rien de prohibitif ). Question performance et efficacité, ce sera mieux que tout semblant de moteur physique utilisant les forces. Mais comme dit plus haut, il faut voir si le moteur physique peut s’adapter à ce que tu veux faire.
