Problèmes et questions - Page 2

move.l (a0),d2
and.l d0,d2
or.l d1,d2
move.l d2,(a0)

> je pensais à ça quand je demandais si un move était plus rapide pour les adresses effectives

ouep mais justement c pas plus efficace (c aussi ce à quoi j'avais pensé au début)

mais j'attends tjs la solution de Sasume ^^

C'est à la solution du post ./29 que je pensais.
Désolé, je n'ai pas pensé à préciser qu'on pouvait détruire les registres.

Sinon vous en avez pas à proposer ?

Pollux :
ouep mais justement c pas plus efficace (c aussi ce à quoi j'avais pensé au début)

D'ailleurs, un jour, en essayant d'optimiser les fonctions d'extgraph, j'ai eu cette même idée, j'ai regardé mes docs pour voir si je gagnais en cycles, et je me suis trompé en lisant, ce qui fait que j'ai cru obtenir un gain de quelques cycles. J'ai ensuite fait un bench pour mesurer le gain en % par rapport à l'ancienne version et je suis arrivé à une valeur de 3% environ... Puis j'ai relu ma table de cycles et je me suis aperçu que je m'étais trompé la première fois et qu'il n'y avait pas de gain.
Pourtant les résultats du bench étaient différents...
Je ne sais pas pourquoi, mais sur ma TI-89 HW2, c'est plus rapide... (pas de beaucoup ok)
Et je ne pense pas que ce soit le bench qui soit en cause.
Je me souviens, j'avais fait un topoic ici à ce sujet.

D'autre part, il semblerait que l'instruction add.l dn,am est un poil plus rapide qu'un lea d(an),an sur HW1 (3% environ) mais pas sur HW2.

Bizarre non ?

Oui, j'ai toujours trouvé les bench sur vraie TI très bizarres... Notamment selon l'agencement des instructions, le temps d'exécution pouvait varier légèrement (mais de manière fiable )... En tout cas ça a été mentionné plusieurs fois ici et personne n'a été capable de trouver plus d'infos là-dessus.


Bon, alors voilà mon "petit" problème :

    // arguments fournis
#define vs_w 128
    long xdiff,ydiff;
    TILE **tiles;

    // variables de boucle
    long xval,yval;

    // contenu de la boucle
    {
        xval += xdiff;
        yval += ydiff;
        TILE *tile = tiles[((xval>>16)>>3)+vs_w*((yval>>16)>>3)];
        SetNextGray4PixHorizontally(GetGray4Pix(tile,(xval>>16)&7,(yval>>16)&7));
    }

Le but est d'optimiser le contenu de la boucle, sachant que :
[ul][li] on a le droit de faire tous les précalculs qu'on veut en dehors de la boucle (dans la limite du raisonnable moins de 500 cycles par exemple)
[li] on peut prendre autant de registres que nécessaire
[li] la précision ne doit pas impérativement être celle que j'ai donnée, on peut très bien enlever une petite dizaine de bits si ça peut aider (par exemple on peut précalculer xdiff4 = xdiff>>4, et modifier à chaque itération xval4, approximation de xval>>4 calculée par xval4 += xdiff4, et utiliser xval4>>12 au lieu de xval>>16)
[li] important : on peut supposer que 'tile' change peu souvent (tous les 4 pixels disons)
[li] on peut optimiser le remplissage des pixels en regroupant les différentes exécutions de la boucle
[li] SetNextGray4PixHorizontally, la structure TILE et GetGray4Pix sont volontairement indéfinies, tous les formats de stockage sont acceptées, tant que :
[ul][li] il y a au plus, disons, 4 octets par pixel de tile
[li] le format de sortie est le format standard de l'écran
[li] par exemple, on peut avoir cette implémentation (peu efficace) :

typedef struct {
    unsigned char dark[8];
    unsigned char light[8];
};

#define GetGray4Pix(tile,x,y) tile->dark[(y)]&(1<<(x)),tile->light[(y)]&(1<<(x))

int cur_x=7; unsigned char *darkplane,*lightplane;
void SetNextGray4PixHorizontally(unsigned char dark,unsigned char light) {
    if (dark)
        *darkplane  |= 1<<cur_x;
    if (light)
        *lightplane |= 1<<cur_x;
    if (!cur_x--)
        cur_x+=8, darkplane++, lightplane++;
}

[/ul]
[li]on peut supposer que xdiff, ydiff, xval et yval sont raisonnablement faibles, par exemple plus petits en valeur absolue que 128<<16[/ul]

Ca serait pas une boucle de Mode 7 ?

Ca y ressemble furieusement Mais oui, j'ai oublié de le dire, mici ^^

Le but du jeu est de faire ça en un peu moins de 90 cycles dans le pire des cas

xdiff et ydiff sont compris dans quel intervalle ?

Et on doit écrire nous aussi les fonctions GetGray4... et SetNext... ?

Ah oui, je voulais le rajouter :
on peut supposer que xdiff, ydiff, xval et yval sont raisonnablement faibles, par exemple plus petits en valeur absolue que 128<<16

Sasume
: Et on doit écrire nous aussi les fonctions GetGray4... et SetNext... ?

J'ai fait une version de base pour voir ce qu'il faut mettre dedans...

>Et on doit écrire nous aussi les fonctions GetGray4... et SetNext... ?
C'est justement l'interet.

Encore une petite question, pour avoir une idée, quelle est la taille acceptable pour une routine de traçage de droite ?
Pour un affichage de sprite 8 bits, 12 bits?

Traçage de ligne, ça dépend de la rapidité que tu souahites et de l'algo, mais ça me paraît difficile de dépasser 500 octets.
Je pense que 300 octets peuvent suffir.

Okay, merci.
Pour le moment j'en suis à 300 et des banannes, mais je ne gère que les droites du premier octant.
Enfin, j'ai mon idée et je pense ne pas dépasser 450 octets.

Bah, moi j'ai une routine de tracé de lignes en 4 octets: 0xf9a74e75.

hum...

Sasume
: ça dépend de la rapidité que tu souahites

Le plus rapide possible.
Enfin presque, j'esseye d'éviter d'avoir du code qui se répète.
Mais par exemple, qu'elle est le poids d'une routine comme celle d'extgraph?

Je répondais à Kevin, qui faisait le malin avec sa solution hyper-lente...

Et pour connaître le poids, rien de plus simple que d'inclure et de voir la différence de taille... (tu peux aussi voir ça à l'éditeur hexa sur un fichier objet, mais c plus délicat).

Ok Merci.