Documentation

Quand vous utilisez le double cache, d'abord vous définissez vos caches avec SETDBUF, ensuite vous générez vos sprites dans le cache de rendu avec SPRITES et finalement vous appelez la macro DBUF_DISPLAY pour intervertir les deux caches. Facile non ?

Malheureusement, y'a un piège, après avoir repris le contrôle en sortie de DBUF_DISPLAY, RenderBuffer contiendra l'adresse du cache qui est toujours affiché par le matériel. Si vous commencez à générer vos sprites dans le cache avant le début de l'image suivante, vous allez probablement écraser l'affichage courrant avant que le système ait fini de l'afficher. Le résultat : un affichage de couches disgracieuses. A la place, vous devrez attendre que le matériel ait fini d'afficher le cache courrant avant de pouvoir commencer à y faire des générations en tant que nouveau cache de rendu. On peut le faire en utilisant la macro WAITEOF (Attendre Fin d'Image / Wait End Of Frame) dans une séquence d'événements comme celle ci :

¤ Démarrer le moteur de sprites avec la macro SPRITES qui vous rends le contrôle après que les sprites soit générés.
¤ Utiliser DBUF_DISPLAY pour paramétrer le matériel pour afficher le cache d'affichage fraichement généré au début de la prochaine image.
¤ Réagir aux actions de l'utilisateur, gérer les ennemis et faire le reste des opérations du jeu
¤ Configurer les sprites pour l'affichage de la prochaine image
¤ Utiliser WAITEOF pour attendre que la dernière ligne de l'affichage courrant ait été traitée
¤ Recommencer en haut de cette boucle

La technique ci dessus nécessite que vous soyez certains que la logique de votre jeu soit accomplie avant que la fin d'image soit atteinte. Si votre code met trop de temps et que vous ratez la fin d'image, vous allez vous retrouver dans l'obligation de devoir attendre la fin d'une nouvelle image. Une solution alternative est d'attendre que le matériel ait fini d'afficher le cache courrant avec la macro WAITNEOF (attendre sans effacer la fin d'image/wait no-clear for end-of-frame) avec une séquence d'événements comme celle ci :

¤ Démarrer le moteur de sprites avec la macro SPRITES qui vous rends le contrôle après que les sprites soit générés.
¤ Utiliser DBUF_DISPLAY pour paramétrer le matériel pour afficher le cache d'affichage fraichement généré au début de la prochaine image.
¤ Sauver l'octet de statut du processeur, désactiver les interruptions, effacer le DISPLAY_EOFFLAG dans la variable DisplayFlags, restaurer l'octet de statut du processeur
¤ Réagir aux actions de l'utilisateur, gérer les ennemis et faire le reste des opérations du jeu
¤ Configurer les sprites pour l'affichage de la prochaine image
¤ Utiliser WAITNEOF (qui n'efface pas le DISPLAY_EOFFLAG) pour attendre jusqu'à ce que la ligne0 de l'affichage courrant ait été traitée (ça peut déjà avoir été fait)
¤ Recommencer en haut de cette boucle

Bientendu, tout a un coût. Le problème avec cette technique alternative est qu'elle vous autoriser de dépasser EOF.

Les macros WAITEOF et WAITNEOF et le DISPLAY_EFFLUVIA sont décrits dans la section Attendre la fin d'image et la fin de ligne.

Après que la macro DBUF_DISPLAY ait fini sont travail spécifique au double cache, l'adresse dans le nouveau cache d'affichage est stockée par le gestionnaire de fin d'image du système dans les registres matériels de l'affichage.