1.6 - Le coding 2 : Actions, réactions
1.6 - Le coding 2 : Actions, réactions :
Après une petite discussion avec un des utilisateurs de MMF2, j'ai décidé d'approfondir encore un peu les explications sur le Runtime en même temps que ce tutoriel...
Mais pour commencer, je vais continuer à expliquer les techniques du coding sous MMF2. MMF2 ne jure que par ces fameux objets comme je vous l'expliquais dans les tutoriels précédents.
Vous devez être déjà un peu plus familiarisé avec les techniques de codages. Vous avez dû voir que le coding se passe presque entièrement dans l'éditeur d'événements.
Dans l'éditeur d'événements, il est nécessaire de bien comprendre la différence entre ces termes : les actions, les expressions et les conditions.
Les actions
Les actions sont en réalité les fonctions qui sont appelées lors d'un événement. Il peut y avoir des actions comme "changer la position en X d'un objet" mais aussi des actions spéciales en fonction de l'objet. Par exemple, l'objet sons dispose d'action comme "Jouer un son au format .wav". On peut appeler plusieurs actions lors d'un même événement, et même plusieurs actions appartenant à un même objet dans un même événement.
Lorsqu'une action existe dans la grille d'événement, un "check" s'affiche sur la ligne de l'événement et dans la colonne de l'objet auquel l'action appartient. En positionnant la souris sur le "check" on peut voir l'action qui est "Fixer la position X en (valeur)" :
Les expressions
Les expressions sont en fait les variables associées aux différents objets. Un exemple simple d'expression, ce sont les variables associées aux objets actifs. Au nombre de 26, elles peuvent être utilisées de plusieurs façon comme par exemple compter le nombre de vies restantes. Elles peuvent être récupérées via l'éditeur d'expressions :
Une fois récupérées, dans cet exemple, on va pouvoir mettre l'objet "joueur" à sa propre position + 1. Sa position changera à chaque événement "Toujours". Si vous testez ce code, cela aura pour effet de faire bouger le joueur vers la droite.
Les conditions :
Les "conditions" sont également appelées "événements". Chaque objet possède plusieurs événements qui lui sont propre. Par exemple, l'objet "Conditions spéciales" possède des conditions........ spéciales ;) comme par exemple la condition "Toujours" qui sera vraie à chaque fois que le Runtime va scanner la liste des événements.
Il est également possible de tester à tout moment la valeur de n'importe quelle expression via la condition "Comparer 2 valeurs générales" de l'objet "conditions spéciales" :
Les conditions "VRAIES" et "FAUSSES"
On peut différencier ces événements en disant que les conditions "VRAIES" sont des conditions "évènementielles" alors que les conditions "FAUSSES" sont des conditions "classiques".
Les conditions classiques sont évaluées à chaque boucle, alors que les conditions évènementielles ne sont évaluées que si l'évènement associé a été levé.
Il existe dans le Runtime une file d'événements qui porte bien leurs noms. Ces événements sont de vrais événements que Windows gère et renvoie au Runtime.
Les événements dits "VRAI" sont mis en rouge dans la liste d'événement. Alors que les "FAUX" sont en noirs :
En fait, à la fin de chaque boucle, MMF va aller redessiner la scène. Par exemple, il va le faire 50 fois par seconde pour un framerate de 50 FPS.
Pourtant, il est possible que si le calcul des actions ou que le calcul de l'affichage prenne trop de temps, alors il n'aura pas le temps d'afficher le bon nombre d'image. Mais si un événement doit être fait 50 fois par seconde alors c'est différent entre un vrai et un faux.
Par exemple si on met un mouvement de balle à un objet et que l'on dit que dès qu'il se trouve en superposition avec un autre, il s'arrête, ça fonctionne. Seulement si l'application rame et que le mouvement est dépendant du temps et non du FPS, on verra qu'il se pourrait que notre objet traverse l'autre, car MMF n'aura pas eu le temps de tester la superposition, l'objet ayant déjà dépassé l'autre avant rafraîchissement.
Alors que si l'on teste la collision au lieu de la superposition, ça va fonctionner car c'est un événement "VRAI". Cet exemple montre juste la différence entre les deux types d'événements.
Optimisation
Pour faire ramer à cause du code, on doit avoir des fonctions bien lourdes... Normalement on peut mettre autant d'actions et d'événement que l'on veut, ça ne ramera jamais... Il faut savoir également que les conditions et les actions ne prennent pas plus de ressources l'un comme l'autre.
Par exemple, tester si une variable est égale à 10, ça prend que dalle comme temps processeur ! Par contre tester une collision entre deux objets actifs assez gros, ça prend déjà plus de temps car il faut qu'MMF vérifie selon le masque de collision s'il n'y a pas superposition par rapport à chacun des pixels...
Et inversement, l'action mettre la valeur 10 dans une variable ne prend rien comme temps alors que l'action modifié l'angle d'un objet prend beaucoup plus de temps car il faut redessiner le sprite entier (en mode software, sinon c'est la carte graphique qui gère ça et elle a beaucoup plus l'habitude)
Mais encore une fois, ce n'est pas ça qui fait vraiment ramer MMF2. Le temps pour toutes actions étant très minime.
Un objet à utiliser avec précaution, c'est l'objet "Fast loop". Il prend la main sur MMF pour lancer une boucle et y exécuter des actions et conditions. La boucle doit être terminée avant que MMF ne puisse reprendre la main pour gérer l'affichage. Donc si dans la "boucle rapide" on as une succession de 1000 fonctions gourmandes et que l'on lance une boucle dans un "Toujours", alors là, ça va faire ramer MMF2 à fond !
Mais nous détaillerons cette fonctionnalité très utile et extrêmement puissante dans un prochain tutoriel.
Après une petite discussion avec un des utilisateurs de MMF2, j'ai décidé d'approfondir encore un peu les explications sur le Runtime en même temps que ce tutoriel...
Mais pour commencer, je vais continuer à expliquer les techniques du coding sous MMF2. MMF2 ne jure que par ces fameux objets comme je vous l'expliquais dans les tutoriels précédents.
Vous devez être déjà un peu plus familiarisé avec les techniques de codages. Vous avez dû voir que le coding se passe presque entièrement dans l'éditeur d'événements.
Dans l'éditeur d'événements, il est nécessaire de bien comprendre la différence entre ces termes : les actions, les expressions et les conditions.
Les actions
Les actions sont en réalité les fonctions qui sont appelées lors d'un événement. Il peut y avoir des actions comme "changer la position en X d'un objet" mais aussi des actions spéciales en fonction de l'objet. Par exemple, l'objet sons dispose d'action comme "Jouer un son au format .wav". On peut appeler plusieurs actions lors d'un même événement, et même plusieurs actions appartenant à un même objet dans un même événement.
Lorsqu'une action existe dans la grille d'événement, un "check" s'affiche sur la ligne de l'événement et dans la colonne de l'objet auquel l'action appartient. En positionnant la souris sur le "check" on peut voir l'action qui est "Fixer la position X en (valeur)" :
Les expressions
Les expressions sont en fait les variables associées aux différents objets. Un exemple simple d'expression, ce sont les variables associées aux objets actifs. Au nombre de 26, elles peuvent être utilisées de plusieurs façon comme par exemple compter le nombre de vies restantes. Elles peuvent être récupérées via l'éditeur d'expressions :
Une fois récupérées, dans cet exemple, on va pouvoir mettre l'objet "joueur" à sa propre position + 1. Sa position changera à chaque événement "Toujours". Si vous testez ce code, cela aura pour effet de faire bouger le joueur vers la droite.
Les conditions :
Les "conditions" sont également appelées "événements". Chaque objet possède plusieurs événements qui lui sont propre. Par exemple, l'objet "Conditions spéciales" possède des conditions........ spéciales ;) comme par exemple la condition "Toujours" qui sera vraie à chaque fois que le Runtime va scanner la liste des événements.
Il est également possible de tester à tout moment la valeur de n'importe quelle expression via la condition "Comparer 2 valeurs générales" de l'objet "conditions spéciales" :
Les conditions "VRAIES" et "FAUSSES"
On peut différencier ces événements en disant que les conditions "VRAIES" sont des conditions "évènementielles" alors que les conditions "FAUSSES" sont des conditions "classiques".
Les conditions classiques sont évaluées à chaque boucle, alors que les conditions évènementielles ne sont évaluées que si l'évènement associé a été levé.
Il existe dans le Runtime une file d'événements qui porte bien leurs noms. Ces événements sont de vrais événements que Windows gère et renvoie au Runtime.
Les événements dits "VRAI" sont mis en rouge dans la liste d'événement. Alors que les "FAUX" sont en noirs :
En fait, à la fin de chaque boucle, MMF va aller redessiner la scène. Par exemple, il va le faire 50 fois par seconde pour un framerate de 50 FPS.
Pourtant, il est possible que si le calcul des actions ou que le calcul de l'affichage prenne trop de temps, alors il n'aura pas le temps d'afficher le bon nombre d'image. Mais si un événement doit être fait 50 fois par seconde alors c'est différent entre un vrai et un faux.
Par exemple si on met un mouvement de balle à un objet et que l'on dit que dès qu'il se trouve en superposition avec un autre, il s'arrête, ça fonctionne. Seulement si l'application rame et que le mouvement est dépendant du temps et non du FPS, on verra qu'il se pourrait que notre objet traverse l'autre, car MMF n'aura pas eu le temps de tester la superposition, l'objet ayant déjà dépassé l'autre avant rafraîchissement.
Alors que si l'on teste la collision au lieu de la superposition, ça va fonctionner car c'est un événement "VRAI". Cet exemple montre juste la différence entre les deux types d'événements.
Optimisation
Pour faire ramer à cause du code, on doit avoir des fonctions bien lourdes... Normalement on peut mettre autant d'actions et d'événement que l'on veut, ça ne ramera jamais... Il faut savoir également que les conditions et les actions ne prennent pas plus de ressources l'un comme l'autre.
Par exemple, tester si une variable est égale à 10, ça prend que dalle comme temps processeur ! Par contre tester une collision entre deux objets actifs assez gros, ça prend déjà plus de temps car il faut qu'MMF vérifie selon le masque de collision s'il n'y a pas superposition par rapport à chacun des pixels...
Et inversement, l'action mettre la valeur 10 dans une variable ne prend rien comme temps alors que l'action modifié l'angle d'un objet prend beaucoup plus de temps car il faut redessiner le sprite entier (en mode software, sinon c'est la carte graphique qui gère ça et elle a beaucoup plus l'habitude)
Mais encore une fois, ce n'est pas ça qui fait vraiment ramer MMF2. Le temps pour toutes actions étant très minime.
Un objet à utiliser avec précaution, c'est l'objet "Fast loop". Il prend la main sur MMF pour lancer une boucle et y exécuter des actions et conditions. La boucle doit être terminée avant que MMF ne puisse reprendre la main pour gérer l'affichage. Donc si dans la "boucle rapide" on as une succession de 1000 fonctions gourmandes et que l'on lance une boucle dans un "Toujours", alors là, ça va faire ramer MMF2 à fond !
Mais nous détaillerons cette fonctionnalité très utile et extrêmement puissante dans un prochain tutoriel.