6 réponses à ce sujet

[alliop]

Bonjour

Tout est dans le titre et c'est peut être une question idiote, mais je préfère la poser au cas où ^^.

Supposons qu'une nouvelle compétence magique moddée requiert un écran de dialogue lancé par l'équipement d'un livre, c'est à dire un test sur "equip" et une créature "placeAtPc".

Vaut-il mieux en termes de légèreté faire exécuter ce test par un global, ou par un local dans le bouquin.

A priori je me dis que c'est la même chose, puisque les locaux sur les items continuent de tourner dans l'inventaire (quelle idiotie!!!), que le test est permanent et que le livre accompagnera le joueur (sauf s'il le dépose quelque part, mais il n'y aura aucun intéret^^).

Mais peut être pas. Si quelqu'un à une idée là dessus... merci.

[Kafou]

En termes de "légèreté" on s'en fout un peu, ce n'est pas l'exécution d'un script qui détecte si on équipe un objet qui va ralentir le jeu. Les performances d'exécution ne sont à prendre en compte sérieusement que si l'objet sur lequel se trouve le script est présent en de très nombreux exemplaires dans la même cellule, ou si ton script exécute de très nombreuses opérations à chaque frame.

Mais comme tu le dis, entre un local qui tourne tout le temps et un global, il n'y a pas de différence niveau quantité d'exécutions.

En termes de simplicité et de clarté du code, il vaut mieux utiliser un script local puisqu'il est directement lié à l'objet (et d'ailleurs, il me semble que tu es obligé d'utiliser un script local pour détecter l'équipement de l'objet).

[elendell]

Bonjour,

Si ta première instruction est la vérification de "equip" avec un "return si 0", le coût sera le même en local dans l'inventaire qu'en global. Ce qui aurait pu changer la donne pour envisager une solution moins couteuse (avec un local qui déclenche un global) aurait été le coût en mémoire des variables. Mais j'ai lu dans un autre sujet que toutes les variables étaient toujours chargées, qu'elles soient globales, locales dans un global ou même dans un local qui ne ne tourne pas car dans une autre cellule que le PC. Si l'info est juste, local ou global, il n'y aurait donc aucune différence (dans le cas d'un script qui a une vérification au début avec "return" si 0).

A propos des couts des fonctions, je signale que Nerwal a fait une recherche intéressante, <ICI>.

Ce n'est pas une réponse à ta question mais ça concerne les couts et donc la légèreté. Son étude m'a fait changer certaines manières d'écrire. Par exemple, pour mettre une variable à 1 avec un "set" une fois pour toute, je faisais une vérification :

if ( variable != 1 )
set variable to 1
endif

Mais en fait, si ça permet de mieux structurer le script et semble plus propre, ça coute quand même plus cher qu'un simple "set variable to 1" qui se fait à chaque frame, sans vérification.

[alliop]

Merci merci.

Les petits ruisseaux faisant les grandes rivières, certaines gouttes d'eau déborder les vases, et comme il n'y a pas de petites économies, en vue d'un gros mod chargé en scripts ou simplement de l'accumulation d'esp dans une liste de chargement, la moindre optimisation est toujours bonne à appliquer.

@Kafou : "OnPCEquip" ne fonctionne qu'en local si déclarée en short. La fonction "HasItemEquipped" (TR) marche en global.

@Elendell :
Les tests de Nerwal sont très intéressants, oui.
J'utilisais moi aussi un test avant la mise à jour définitive de variables, je ne le ferai plus que lorsque c'est indispensable.

Cette question du coût en mémoire des variables reste ouverte. La seule info que j'ai trouvée à ce sujet est quelque part dans le bottin.... euh.. le readme de GCD, où Galsiah écrit en substance "considérant que le chargement d'un millier de variables est d'un coût en mémoire négligeable"....
D'autre part questionnant un jour Nenphea au sujet d'une éventuelle limite du nombre de globales, il m'avait répondu en substance "tu peux en déclarer autant que tu veux, ce n'est pas un problème tant que tu gardes les ID claires".

Dans la pratique je me fie à ces deux indications.

Modifié par alliop, 01 avril 2009 - 07:58.

[Kafou]

Je confirme aussi que la quantité de variables c'est négligeable.

Pour l'optimisation des scripts, le truc c'est que le temps d'exécution d'un script lui-même est négligeable comparé au temps de rendu (comme on le voit sur les tests de Nerwal, bien que je sais pas quelle machine il a utilisé pour ça, il faut des centaines et des centaines d'opérations par frame pour réduire de 10% les performances du jeu). Donc si tu veux que ton mod tourne mieux, les idées à suivre sont plutôt :
- ne pas trop charger les cellules en objets affichés
- ne pas trop charger les cellules en objets scriptés
- ne pas trop charger les objets en polygones (dans le cas où tu en rajoutes)

Ce que je voulais dire avant c'est surtout : un script tout seul est négligeable, mais s'il est exécuté 100 fois par frame c'est une autre affaire et là oui il devient intéressant de l'optimiser. Sinon, on n'en sort jamais et quitte à être perfectionniste sur le temps d'exécution d'un seul script, il faut l'être partout ailleurs et on n'en sort jamais.

[alliop]

Ok merci

Kafou, le 01.04.2009 à 09:47, dit :

- ne pas trop charger les cellules en objets scriptés

Oui. Moralité : si l'on veut exécuter des commandes complexes sur un type d'item représenté en grand nombre dans une cell (par ex les "livres+1" dans les biblio des guildes des mages de Nova    ).... il vaut mieux utiliser un seul global testant les références en une ou quelques frames sous MWSE, avec des conditions "return" bien pensées (si toutefois les bouquins font partie des réfs testables sous MWSE... à voir).

Citation

quitte à être perfectionniste sur le temps d'exécution d'un seul script, il faut l'être partout ailleurs et on n'en sort jamais.

Mais nous le sommes, nous le sommes! (Et non moins "paresseux" néanmoins ^^ ).

Modifié par alliop, 01 avril 2009 - 09:55.

[Finraïl]

alliop, le 01.04.2009 à 10:49, dit :

(si toutefois les bouquins font partie des réfs testables sous MWSE... à voir).

Je pense que je ne me mouillerais pas trop en disant que c'est le cas.