3 votes

TimerEvent vs. ENTER_FRAME dans les jeux AS3/Flex ?

J'essaie d'écrire un jeu simple en AS3 / Flex 4, et j'essaie de trouver la meilleure façon de gérer dès le départ l'exécution minutée du code.

L'approche la plus naturelle serait d'utiliser un ensemble de Timer tout au long du programme. Cependant, cela est supposé être assez coûteux en cycles CPU, comparé à ENTER_FRAME .

Cependant, je ne suis pas sûr qu'il soit naturel de baser toute l'exécution chronométrée d'un programme sur la base de ENTER_FRAME et j'ai lu sur stackoverflow qu'il avait des problèmes - que Timer ne le fait pas - en ce qui concerne le ralentissement de l'animation et du framerate lorsque la complexité du programme augmente.

Une autre option qui me vient à l'esprit est d'utiliser simplement un Timer dans le programme, dont le gestionnaire d'événements passera en revue et vérifiera tout en une seule fois - un peu comme si l'on mélangeait l'habituel objet Timer y ENTER_FRAME approches.

Ma question est la suivante : Quelle est la meilleure idée pour un jeu vidéo en AS3/Flex 4, et pourquoi ? Merci !

4voto

Marty Points 22040

Cela dépend entièrement de quand vous voulez mettre à jour les valeurs, vérifier les collisions, gérer les entrées, etc. par rapport au moment où vous voulez réellement voir quelque chose se produire sur l'écran.

  • ENTER_FRAME rendra votre logique de mise à jour et le rendu de votre jeu synchrone .

    Chaque fois un ENTER_FRAME est déclenché, la scène est redessinée. Cela signifie que toute la logique de mise à jour de votre jeu est toujours immédiatement suivi par le rendu de l'écran. Si le taux de rafraîchissement de votre jeu diminue en raison de la lenteur du rendu des graphiques complexes à l'écran, la vitesse de mise à jour de votre jeu diminuera également. ENTER_FRAME sont erratiques, ce qui signifie qu'elles ne sont pas adaptées aux tâches de mise à jour que vous devez effectuer à intervalles réguliers.

  • Les temporisateurs font en sorte que votre logique de mise à jour et le rendu de votre jeu deviennent asynchrone .

    Les minuteurs peuvent se déclencher beaucoup plus ou beaucoup moins fréquemment qu'une ENTER_FRAME handler le ferait. Cela signifie que votre boucle de mise à jour peut s'exécuter plusieurs fois avant que la scène ne soit redessinée, ou que la scène peut être redessinée plusieurs fois sans changement. Les minuteurs sont moins erratiques que les ENTER_FRAME les manipulateurs, en les rendant plus aptes à faire quelque chose à intervalles réguliers. Cela dit, il y aura toujours un petit décalage entre les mises à jour :

    En fonction de la fréquence d'images du fichier SWF ou de l'environnement d'exécution (mémoire disponible et autres facteurs), le moteur d'exécution peut envoyer des événements à des intervalles légèrement décalés. Par exemple, si un fichier SWF est configuré pour être lu à 10 images par seconde (fps), ce qui correspond à des intervalles de 100 millisecondes, mais que votre minuterie est configurée pour déclencher un événement à 80 millisecondes, l'événement sera distribué à proximité de l'intervalle de 100 millisecondes. Les scripts gourmands en mémoire peuvent également décaler les événements.
    - help.adobe.com | flash.utils.Timer

Personnellement, j'ai toujours utilisé ENTER_FRAME contre les chronomètres. Pour moi, il est logique que si j'apporte des modifications aux objets d'un jeu, ces modifications soient immédiatement représentées à l'écran.

Les minuteurs sont utiles si vous souhaitez pouvoir mettre à jour les composants de votre jeu plus rapidement que le taux de rafraîchissement ne le permet. Les minuteries sont également utiles si vous souhaitez qu'un nombre donné de mises à jour soit effectué dans un certain délai, car elles ne sont pas liées à la vitesse à laquelle l'écran peut être redessiné, comme c'est le cas pour le système de gestion de l'image. ENTER_FRAME est.


Pour ce qui est de la mise en œuvre concrète, il est préférable de choisissez-en un y mettre en œuvre un gestionnaire . Cela signifie que vous ne devriez avoir qu'une seule fonction dans tout le jeu qui sera déclenchée par un Timer ou un ENTER_FRAME . Vous ne voulez pas créer des gestionnaires individuels dans chaque classe qui doit être mise à jour. Au lieu de cela, vous voulez que votre classe de niveau supérieur (ou un proche parent de cette classe) définisse le gestionnaire. Vous voulez également créer une liste dans cette classe qui représentera tout ce qui doit être mis à jour dans le jeu.

À partir de là, vous créerez une petite collection de méthodes qui s'occuperont de lister et de dé-lister les instances actualisables de cette classe. Chaque instance de mise à jour implémentera une interface ou étendra une classe qui définit une méthode de mise à jour. update() méthode. Cela pourrait ressembler à ceci :

public interface IUpdatable
{
    function update();
}

À partir de là, le gestionnaire de mise à jour de la classe updater va simplement itérer sur tous les éléments à mettre à jour de la liste et appeler leur update() comme ceci :

for each(var i:IUpdatable in updateList)
{
    i.update();
}

Enfin, cette approche signifie que si vous décidez d'abandonner l'utilisation d'un fichier de type ENTER_FRAME à un Timer ou vice versa, il s'agit d'un simple changement dans la classe updater et ne nécessite pas de modifier une autre partie du code du jeu. Si vous créez des gestionnaires dans chaque classe qui doit être mise à jour, votre changement d'avis vous obligera à modifier chaque classe.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X