Folco (./11) :
Les explications sur le système évènementiel me semblent pas mal en effet, en tout cas pour le côté "propreté du code". Reste la question de la performance. Le script, c'est bien, mais un moteur de script, c'est comme un doberman, ça bouffe.

C'est négligeable. Mais vraiment.
Je sais que tu ne me crois pas, et je pense que tu devrais vraiment une fois essayer pour voir ce qu'a un PC dans le ventre. Je me rappelle quand j'avais reçu mon Pentium 4, je débutais plus ou moins la prog, et je codais un éditeur de maps où je dessinais en soft. Je dessinais plusieurs plans superposés, avec un coefficient de transparence, et un code dégueulasse (je faisais des divisions par 255, des multiplications signées et tout, et ce pour chaque sous couleur RGB de chaque pixel) et pourtant sur les 1280x1024 pixels de mon écran ça ne ramait pas un poil.
Ensuite j'ai implémenté un algo de réduction de couleurs d'image. Le truc était une horreur, j'essayais de déterminer les couleurs les plus proches et j'essayais de fusionner diverses permutations tout en recalculant ensuite à chaque fois une image finale avec les couleurs restantes (en prenant pour chaque pixel la couleur la plus proche), et calculais alors un coefficient d'erreur (à quel point chaque pixel était "faux" par rapport à l'image d'origine) et je prenais l'image minimisant la somme des erreurs. Bref le truc immonde que tu te dis que ça va tourner des années. Bref je lance, et c'est fini. J'y crois pas, je vais vérifier, le fichier est bien là, et a le bon nombre de couleurs...
Plus tard j'ai encore implémenté des algos plus compliqués et là ça commençait à prendre plus long pour de grosses images, mais bon... et puis ça restait ridicule pour le service rendu.
Et ça c'était un bête P4, le truc que je pense que mon smartphone est plus puissant. Un Core i7 ça doit être 30x plus puissant à la louche, donc si tu le faisais maintenant je pense que tu serais encore plus "blazé" que moi.

Tout ça pour dire que ce n'est vraiment pas le plus important, surtout que le gros de la complexité dans ce code repose dans std::vector, et rien n'empêche de remplacer par une autre implém si tu devais avoir à coder sur genre moins puissant que la GBA. Tu pourrais aussi en dernier recours faire directement les appels aux "event handlers" plutôt que passer par une liste, mais pour quelque chose qui sera parcouru moins de 100 fois par seconde, et "gaspillera" une vingtaine de cycles par événement attaché, le jeu n'en vaudra pas la chandelle. Bref après c'est du détail d'implémentation qui dépend de la machine cible, mais si t'es sur PC ça ne vaut pas la peine de refuser une solution sous prétexte qu'elle risque de ne pas tourner très vite sur une NES. Surtout que sur NES genre l'int 32 bits ça n'existe pas... Bref si tu veux coder pour une petite machine il faudra de toute façon réfléchir autrement, donc regarde un peu ce que vaut le PC et fais en fonction