Inscription : 15 Août 2008, 13:00 Message(s) : 968 Localisation : Troyes, France
Quelques petits trucs mais j'ai pas de recette magique, je dirai veiller à bien aligner tes données sur les pages de 256 octets , entrelacer tes octets de pixels et de masque , travailler sur des sprites plus petits de taille fixe histoire d'optimiser au max tes routines, tu peux même songer à entrelacer tes données sauvegardées et tes données à afficher ensemble histoire de faire ta sauvegarde et ton affichage dans la même passe.Dans le genre captain obvious , je dirai avoir 2 sprites (en mode 0) décalés pour le mouvement d'un pixel. Un truc qui peut te faire gagner est d'avoir tes données en zig zag pour éviter de recalculer l'adresse de ton sprite à chaque ligne. Genre au lieu de faire
0-1-2-3 4-5-6-7
et devoir revenir en arrière à chaque ligne , stocker :
0-1-2-3 7-6-5-4
ça t'éviter de recalculer ton retour à la ligne à l'écran (et du coup de n'avoir qu'à t'occuper que des bits qui changent).Enfin , tout ça ça vaut si tu n'a pas de clipping à gérer. Un truc qui est pas mal aussi est de dérouler ta routine pour savoir quand tu aura un saut de ligne de caractère et de brancher ta routine en fonction de la position du sprite.Après ça ne vaut que pour les sprites de taille fixe et de préférence sans clipping car évidemment là faut prévoir plusieurs routines.
Enfin , voilà quelques pistes de réflexion que j'ai déjà explorées mais il doit y avoir encore d'autres méthodes, bon brainstorming
_________________ "NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)
Inscription : 12 Juin 2008, 20:29 Message(s) : 1709
en fait, c'est simple comme tuto :
frame 1 : affichage page 1 en &c000 (par exemple) avec des outs au CRTC écriture de la nouvelle animation du sprite en page 2 en &8000 frame 2 : affichage page 2 en &8000 avec des outs au CRTC écriture de la nouvelle animation du sprite en page 1 en &c000 etc...
Inscription : 28 Mai 2010, 11:34 Message(s) : 99 Localisation : Eteauville, France
merci, c'est ce que j'ai implémenté. Ca m'a permis d'avoir des sprites sans avoir à me soucier du retour de balayage.
Pour les routines de sprites, j'utilise maintenant la pile pour les adresses écran. C'est plus optimal, mais ca nécessite de couper temporairement les interruptions.
Du coup, lorsqu'il y a trop de sprites à l'écran (environ 8 sprites de 8 pixels/32 lignes), c'est fluide, mais ca fait déconner ma rupture d'écran (les 8 premières lignes sont en mode 1, le reste en mode 0).
Si tu as une idée je suis preneur. Sinon, je vais me rabattre sur un seul mode, tant pis
Inscription : 28 Mai 2010, 11:34 Message(s) : 99 Localisation : Eteauville, France
dans l'idée, ma table contient l'adresse de chaque ligne de l'écran. Je fais pointer la pile sur l'adresse de la première ligne. Ensuite, dans l'idée ca ressemble à quelque chose comme ça,
pop de ld a,e add #00 ld e,a ... ld a,(hl) ld (de),a
où la valeur ajoutée à E est patchée en dehors de la boucle pour éviter d'utiliser un registre juste pour X.
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 6 invité(s)
Vous ne pouvez pas publier de nouveaux sujets dans ce forum Vous ne pouvez pas répondre aux sujets dans ce forum Vous ne pouvez pas éditer vos messages dans ce forum Vous ne pouvez pas supprimer vos messages dans ce forum Vous ne pouvez pas insérer de pièces jointes dans ce forum