Logicielsmoto.com

Pour répondre à Bentoc sur un sujet dédié pour ne plus polluer celui sur mission:liftoff

La démo rends vraiment bien. Bravo!

L'idée d'un générateur de code externe pour les sprites est une excellente idée car de toute façon on a de la place dans les banques mémoire pour mettre pas mal de code sur TO8.

J'ai regardé le code ASM que tu as eu la bonne idée de mettre dans l'archive. Je vois que tu n'accèdes aux données de l'écran qu'avec des offsets négatifs. Il y a une raison que je n'ai pas vue ? Parce que tu pourrais avancer S (LEAS) de 8 lignes en 8 lignes au lieu de tous les 4 max en utilisant à la fois les offsets positifs et négatifs: de -120,S à 120,S (ce qui reste un décalage de 1 octet par rapport à S donc ne change pas la taille du code.)

Autre chose: je vois que tu utilises X pour lire/écrire 2 octets d'un coup quand il n'y a pas de masquage. Mais lors des masques, tu travaille octet par octet uniquement avec le registre A. Or tu pourrais aussi bien travailler les masques sur A et B et faire des LDD / STD pour le même coût que LDX/STX. Tu gagnerais même pas mal dans la mesure ou tu peux faire un truc genre:

_________________
Good morning, that's a nice Tnetennba

Merci pour ces deux très bonnes idées !
Je vais essayer d'implémenter ça dans le générateur.

Salut Samuel,

Je pense qu'il a utilisé la même méthode que moi pour les masque, c'est à dire sans utiliser de masque (d'une part, ça gaspille beaucoup de RAM (256 octets) aloprs que peu (31 octets) ne sont utilisé et d'autres part, ma méthode utilise moins de 30 cycles d'horloge contre 43 pour la tienne (gain de 33% quand même) dans le cadre d'un masque sur 1 octet
Mais bon là je n'arrive même pas à afficher un Sprite en Assembleur...

En tous cas, c'est un chouette moteur, mais perso, je préfère utiliser les outils Thomson et DCMoto de Daniel Coulomb, qui permet de faire des copier coller très pratiques pour les éduiteurs Pascal, Assembleur. En plus, ça permet de travailler jusqu'à 10 fois la vitesse des Thomson (Pas le choix mon TO8 est en panne depuis des lustres, par contre, le MO5 lui fonctionne)

Je suis un peu perdu. De quel code de 41 cycles vs 33 du parles? A mon avis les deux codes en questions ne font pas la même chose car j'ai du mal à croire que j'aurais proposé un code inefficace (si tu parles du code que tu cite, n'oublie pas que les cas 1,2,3,4 sont exclusifs les uns des autres et figurent dans le code généré. On ne peut pas faire plus rapide.)

_________________
Good morning, that's a nice Tnetennba

La remarque de Samuel est très pertinente :

Dans mon générateur, dès que je rencontre un octet contenant donc deux pixels dont l'un est transparent, je n'utilise que le registre A.
Je ne cherche pas à savoir si juste après j'ai un autre octet à traiter.
L'idée de Samuel est de traiter la gestion des pixels transparents sur A et B à la place de A uniquement, ce qui permet de réduire le nombre de cycles puisque je travaille avec le registre D.

Je vais en profiter pour reprendre tout le code du générateur de sprite, car celui-ci est mal foutu. Il y a plein d'aspects que j'ai découvert en chemin et qui sont venu se greffer, ou d'autres fonctionnalités abandonnées qui sont restées ...

La nouvelle version du générateur de sprite compilé est bien avancée.
Le principe est toujours le même, on réalise en un passage la sauvegarde du fond et l'écriture du sprite.
Le code d'effacement du sprite charge les données sauvegardées et repositionne le fond (juste les pixels utiles).

Avec la nouvelle méthode j'obtiens un gain de 16% en cycles par rapport à l'ancienne version.
J'ai également remplacé la sauvegarde du fond par auto-modification de code en une sauvegarde dans un tableau de données.
Le code du sprite ne nécessite plus d'être dupliqué en cas d'instance multiples du sprite (comme dans la version précédente), on a juste besoin d'une zone mémoire pour stocker les données de fond.

U pointe sur le tableau de sauvegarde des données de fond
S pointe sur la zone écran

Le code est plus complexe à lire compte tenu des différentes optimisations en jeu, il est beaucoup moins séquentiel qu'avant.
Je donnerai un peu plus de détail sur le fonctionnement dans les jours à venir si ça vous intéresse.

Je suis preneur de vos retours, si vous voulez que je passe une image dans le générateur, postez là je vous donnerai l'équivalent en code.

en pj un exemple de code généré (toujours la même image)

Voici les étapes pour la construction du sprite compilé (on peut le faire à la main aussi) :
Image de départ :


On divise l'image en deux, une partie pour la RAM A et une autre pour la RAM B
Voici une représentation des données pour la RAM A :


Les points sont des pixels transparents
L'image est complétée sur 80 pixels de large pour respecter l'aspect continu de la zone mémoire et faciliter les calculs.
De l'espace vide est présent en haut de l'image car le sprite est issu d'une planche, ça n'a pas d'importance pour l'exemple.

Etape 1
La lecture commence en haut à gauche et on cherche des motifs, a chaque motif est attribué un code correspondant.
On trouve donc :
motif XX (ligne 1) , motif XX (ligne 2), motif _XXX (ligne (3) , motif X_ (ligne 3), ...

Le motifs sont attribués dans l'ordre en utilisant les moins couteux d'abord en terme de cycles.
On fait ça pour toute l'image.

Etape 2
Chaque motif utilise soit un adressage indexé (LD offset,S), soit un adressage immédiat (PULS) pour la lecture du fond à sauvegarder.
On va donc constituer des "noeuds" ou groupes autour des motifs utilisant un adressage immédiat.
On cherche ensuite à rattacher des motifs à adressage indexé dans la limite -128 +127 pour ne pas être pénalisé par le cout de l'offset (ici seulement +1).
Une fois qu'on a fait ça, on recherche les motifs qui ne sont pas rattachés à des noeuds et on en constitue des nouveaux.

ça donne pour l'image de référence :

Noeud 1
(index:position:offset:pattern)
(0:362:-120:Pattern_11)
(1:402:-80:Pattern_11)
(2:441:-41:Pattern_0111)
(3:443:-39:Pattern_10)
(4:482:0:Pattern_1111)
(5:522:40:Pattern_1111)
(6:562:80:Pattern_1111)
(7:602:120:Pattern_1111)

Noeud 2
(index:position:offset:pattern)
(8:642:0:Pattern_1111)

Noeud 3
(index:position:offset:pattern)
(9:682:-119:Pattern_1111)
(10:721:-80:Pattern_0111)
(11:723:-78:Pattern_11)
(12:761:-40:Pattern_0111)
(13:763:-38:Pattern_11)
(14:801:null:Pattern_111111) Adressage immédiat
(15:842:41:Pattern_1111)
(16:882:81:Pattern_1111)
(17:922:121:Pattern_1111)
(18:924:123:Pattern_10)

Etape 3
On a maintenant une liste de motifs ou "patterns", on va parcourir cette liste et générer le code ASM.
On prends le premier noeud et on calcule le LEAS à partir de la position actuelle du sprite à l'écran (chargée dans S)

Etape 4
La suite se complique un peu ...
On va prendre chaque motif et quand c'est possible, dissocier le code de sauvegarde du fond de celui de l'écriture du sprite.
C'est possible sur un motif :


On peut executer dans n'importe quel ordre dans le noeud, car S ne bouge pas, il faut juste qu'on écrive la sauvegarde du fond avant l'écriture du sprite ;-)

ça ne fonctionne pas pour les motifs avec gestion de transparence par contre...

L'idée est donc constituer des sous-groupes dans le noeud qui ont la même "empreinte".
Par exemple si on a deux motifs d'écriture (avec la même valeur) de :


Etape 5
mais pourquoi ?
Car on va ensuite tester tous les agencements de sous-groupes pour le noeud, en modifiant leur ordre.
S'il y a moins de 10 groupes on test toutes les combinaisons possibles, sinon on teste les combinaisons hasard dans une limite de qq millions.
Pour chaque combinaison on évalue le cout en cycles et on garde la meilleure proposition.
Les variations en terme de cout sont liées aux optimisations lors de la génération du code.

Etape 6
Otpim 1 : sur la sauvegarde du fond, on regroupe les registres a sauvegarder sur un PSHU commun
Optim 2 : sur l'écriture de l'image, on réutilise les registres déjà chargés
Optim 3 : sur le rétablissement du fond, on regroupe les registres sur les PUL/PSHU
Optim 4 : on sauvegarde S au milieu des données de l'image, et ce une seule fois pour tout le noeud ... le rétablissement se fait donc uniquement par PUL, PSH et STD indexé, S étant rechargé par PUL/PSHU, donc pas besoin de LEAS

Pour le noeud 1, la meilleur solution trouvée est la suivante :
Rappel des patterns du noeud
(0:362:-120:Pattern_11)
(1:402:-80:Pattern_11)
(2:441:-41:Pattern_0111)
(3:443:-39:Pattern_10)
(4:482:0:Pattern_1111)
(5:522:40:Pattern_1111)
(6:562:80:Pattern_1111)
(7:602:120:Pattern_1111)

Code de sauvegarde du fond et de l'écriture de l'image :



Code de rétablissement du fond :

Whaou, la vache! Ca c'est de l'optim. Tu as du passer pas mal de temps à peaufiner l'algorithme de génération de code.

_________________
Good morning, that's a nice Tnetennba

Effectivement j'ai passé beaucoup de soirées sur le sujet depuis fin aout !
J'ai complété les explications ci dessus pour que ce soit le plus clair possible.

Le générateur peut être modifié relativement facilement pour ajouter de nouveaux patterns ou en retirer.
On peut implémenter également d'autres optimisations sans avoir a tout réécrire.

J'ai encore qq idées pour le générateur, mais je vais passer à la suite, le résultat étant déjà satisfaisant.
Je vais travailler sur la modification de la démo et intégrer :
- Une gestion du chargement des sprites et des données d'animations en mémoire au travers d'un concept de "niveaux" de jeu
- Une compression/décompression des données par Exomizer (il me semble que vous avez bien bossé sur le sujet il y a quelque temps, si ça ne vous dérange pas je compte réutiliser du code.)

L'objectif est, dans un jeu ou dans une démo, de pouvoir appeler le niveau suivant, ce qui provoque le chargement de tous les éléments nécessaires pour ce niveau en RAM (juste les images et animations, les zones mémoires nécessaires à la sauvegarde de fond des sprites (qui dépend du nombre d'instances de chaque sprite), les données d'apparition des sprites ... et tout code ASM nécessaire pour le niveau courant). Tout ça étant décrit dans un config.properties.

Je dois aussi développer le code ASM pour gérer les apparitions de sprites ennemis, ...

Bref bcp de travail encore ;-)

Vas-y, c'est fait pour ca!

_________________
Good morning, that's a nice Tnetennba

Salut Samuel

Eh si, on avait discuté la dessus, tu m'avais proposé ta méthode de masque, contre mon cpode qui utilisait des if et des variable locales. Ce code était pour l'affichage de sprites en bm13, pour la partie transparence, j'avais essayé ta méthode avec masque optimisé, et la mienne, et la tienne était plus lente (et en plus demandait un gaspillage de mémoire (d'autant que ça nécessite un masque par sprite!!)

Je remets ici mon code complet permettant d'afficher non seulement des Sprite mais aussi des Tiles.



La partir traitement de la transparence n'utilise que entre 31 et 36 cycles pour 2 pixels en mode BM16.

Oui et le code que je proposais plus haut prends entre 20 et 25 cycles pour 2 pixels en mode BM16. Il est donc plus rapide pour cette même opération.

_________________
Good morning, that's a nice Tnetennba

Désolé si c'est le même code dont on avait parlé (que tu m'avais proposé) avec masque de 256 octets (dont une grande partie était vide) et ce que tu m'avais noté, NON ton code dépassait les 40 cycles (sinon je l'aurais adopté). ON en a déjà parlé.

Bon je ne vois pas de quoi on parle alors. Ca manque de références précises.

Moi, dans ce fil, je parle de : viewtopic.php?p=6233#p6233

Toi je pense que tu parles de : viewtopic.php?p=6289#p6289 qui a bien 41 cycles, mais pour 4 pixels, soit 20.5 cycles pour 2 pixels. C'est à dire l'algo généraliste le plus efficace qui soit (l'algo de pointeur précédent n'est en revanche pas généraliste: il dépend du sprite à afficher)

_________________
Good morning, that's a nice Tnetennba