null Le 10/08/2003 à 20:06 Pour tout ceux qui programme avec TIGCC, ça vous arrive d'utiliser les fonctions de double buffering ? :
Au début du programme :
void *GrayBuffer=malloc(7688);
void *Light_addr,*Dark_addr;
GrayDBufInit(GrayBuffer);
Dans la boucle principale du programme :
Light_addr=GrayDBufGetHiddenPlane(LIGHT_PLANE); Dark_addt=GrayDBufGetHiddenPlane(DARK_PLANE);
GrayDBufToggle();
memset(Light_Buffer,0x00,3000);
memset(Dark_Buffer,0x00,3000);
... Et ensuite vous dessinez dans Light_addr et Dark_addr.
Bon par contre après il faut attendre les switch pour les HW1 en faisant :
GrayWaitNSwitches (2);
Moi j'attend qu'un switch en général.
Par contre je n'ai pas bien compris comment utiliser GrayGetSwitchCount, si quelqu'un pouvait m'expliquer ?
Avec ça c'est possible de faire quelque chose en attendant la synchronisation des plan au lieu d'attendre pour rien, non ?
Parce-que c'est vrai que ce sont des fonctions qui sont encore assez récentes et avec la doc en Anglais c'est pas très facile de comprendre (dû moins pour moi ça été la cas et j'ai dû me faire expliquer). Et puis il n'y a pas beaucoup de monde qui à l'air de les utiliser alors que pour les jeux en niveaux de gris ça augmente considérablement les performances !
... Ou alors vous utiliser toujours memcpy() ?
www.wikio.fr/user1921&info=comments
ca n'augmente pas les performance car il faut attendre la synchronisation!
null Le 10/08/2003 à 20:33 Oui mais justement avec GrayGetSwitchCount, il n'y a pas moyen de faire quelque chose pendant ce temps au lieu d'attendre à rien faire ?
www.wikio.fr/user1921&info=comments
Autrement dit tu fais du triple buffering quoi ...
Que cache le pays des Dieux ? -
Forum Ghibli -
Forum LittéraireLa fin d'un monde souillé est venue. L'oiseau blanc plane dans le ciel annonçant le début d'une longue ère de purification. Détachons-nous à jamais de notre vie dans ce monde de souffrance. Ô toi l'oiseau blanc, l'être vêtu de bleu, guide nous vers ce monde de pureté. - Sutra originel dork.
Admettons que je développe une focntion en ASM, qui efface octets par octets un buffer, c'est très lent?
geogeo, regarde un peu la doc de movem... movem #0,(a0) n'est pas une instruction valide...
Pour t'aider, voici le source de ClearGrayScreen2B_R d'ExtGraph (version __regparm__). On pourrait faire un peu mieux en utilisant plus de registres et en faisant un petit movem supplémentaire à la fin (pas tous les multiples de quatre ne sont diviseurs de 3840).
| void ClearGrayScreen2B_R(register void* lightplane asm("%a0"),register void* darkplane asm("%a1")) __attribute__((__regparm__(2))); // C prototype
.data
.globl ClearGrayScreen2B_R
.even
ClearGrayScreen2B_R:
movem.l %d3-%d7/%a2-%a4,-(%sp)
lea (0xf00,%a0),%a0
lea (0xf00,%a1),%a1
moveq #0,%d0
moveq #0,%d1
moveq #0,%d2
moveq #0,%d3
moveq #0,%d4
moveq #0,%d5
moveq #0,%d6
moveq #23,%d7
movea.l %d0,%a2
movea.l %d0,%a3
movea.l %d0,%a4
0: movem.l %d0-%d6/%a2-%a4,-(%a0)
movem.l %d0-%d6/%a2-%a4,-(%a1)
movem.l %d0-%d6/%a2-%a4,-(%a0)
movem.l %d0-%d6/%a2-%a4,-(%a1)
movem.l %d0-%d6/%a2-%a4,-(%a0)
movem.l %d0-%d6/%a2-%a4,-(%a1)
movem.l %d0-%d6/%a2-%a4,-(%a0)
movem.l %d0-%d6/%a2-%a4,-(%a1)
dbf %d7,0b
movem.l (%sp)+,%d3-%d7/%a2-%a4
rts
Si t'as vraiment besoin d'une vitesse incroyable, déroule la boucle en passant par une var pour sauvegarder tous tes registres.
godzil> c'est celles que tu m'avais passé, je pense ?
nan c'est les sources correspondantes a la version DLL, je t'avait passé la derniere version avant la DLL
La normalement tout y est..
Proud to be CAKE©®™
GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.
> Si t'as vraiment besoin d'une vitesse incroyable, déroule la boucle en passant par une var pour sauvegarder tous tes registres. (#17)
J'avais essayé ce style de programmation sur une routine d'effacement d'un seul plane (__stkparm__ à l'époque, ça fait longtemps). J'avais utilisé 15 registres. Je savais bien que ça ferait du code horriblement gros, mais je voulais voir.
Résultat: amélioration vitesse très faible (quelques pourcents), alors que la taille a été augmentée dans des proportions inacceptables (3840/60 = 64 movem -> 256 bytes, plus l'effacement / restauration des registres)... Donc, poubelle.
Morale: faire le bourrin en déroulant les boucles n'est pas toujours intelligent... Si on est obligé de dérouler ses boucles pour arriver à faire ce qu'on veut, c'est peut-être qu'on veut faire trop sur une machine pas adaptée...
XDanger: Lorsque sBibi a fait trinity, je pense que bcp de personnes disaient comme toi, ce n'est pas adaptés ... moralité, il a réussi a faire un moteur 3D certes non complet (mm s'il gere les arbres bsp, les textures etc.) mais qui est pas mal pour un 68000 a 10MHz ...
Des lors, cette méthode est, heuremsement, pas adaptée a presque tous les jeux etc., mais des fois, c nécessaire de passer par des méthodes bourrains.
