niveau de gris - Page 3

---

PpHd :
Pour le format, je reprend celui de Fargo. Il est tres bien, permet de depasser les 64Kb sans probleme. Et ca evite de refaire sans arret la meme chose. D'ou mon probleme pour l'integration dans le linkeur de tigcc sans changer beaucoup de trucs...

Le format entier? Y compris le header? C'est le header qui m'intéresse le plus. Le format des tables, je connais (à part le "nibble-encoding" que je n'ai pas réussi à déchiffrer). (D'ailleurs, on peut tout compresser en le format de Fargo sans utiliser le "nibble-encoding", ça sera juste plus gros.)

-

rectification, cette methode est plus lente que la methode traditionnel!

JackosKing> ?

Orion_ :
heu question, pour aller plus vite au lieux de recopier mes vscreen dans les plans de gray de tigcclib
j'ai voulu utiliser: GrayDBufInit, GrayDBufToggle et GrayDBufGetHiddenPlane
malheuresement lors de la compilation (j'inclus Tigcc.a)
il me dit: Error: 1 undefined reference(s) to 'GrayDBufToggle'.
Error: 1 undefined reference(s) to 'GrayDBufInit'.
Error: 2 undefined reference(s) to 'GrayDBufGetHiddenPlane'.

alors qu'il trouve bien GrayOn, pourquoi ?

Parce que ce sont des macros:

#define GrayDBufToggle() ((void)(__gray_dbl_offset=(__gray_dbl_offset?0:8)))
#define GrayDBufInit(p) ({void*aptr=(void*)((((long)p)+7)&0xfffffff8L);__gray_dbl_offset=0;__D_plane2=aptr;(void)(__L_plane2=aptr+3840);})
#define GrayDBufGetHiddenPlane(x) (GrayDBufGetPlane(GrayDBufGetHiddenIdx(),x))
#define GrayDBufGetHiddenIdx() (!__gray_dbl_offset)
#define GrayDBufGetPlane(i,x) ((i)?((x)?__D_plane2:__L_plane2):GrayGetPlane(x))
#define GrayGetPlane(x) ((x)?__D_plane:__L_plane)

le double buffering de la tigcc par la methode du swap est plus lente que la methode traditionnel, car il faut attendre la synchronisation, ce que graphx courcircuite

Il faut aussi le faire si on recopie si on n'a pas envie que ça clignote. La seule solution pour éviter ce problème est le triple-buffering à la Thibaut. Mais au revoir RAM libre...

Si GX est la seule à contourner ça, on se demande quelle méthode est la plus traditionelle

methode tradi = recopier buffer

-

JackosKing>
1- la méthode de tigcc propose deux fonctions/macros, l'une qui n'attend pas la synchro et l'autre qui l'attend
2- je ne vois pas pourquoi le recopiage brutal éviterait d'avoir à attendre la synchro ...

Si tu utilises la méthode de TIGCCLIB, il faut sur HW1 (ou VTI) obligatoirement attendre 2 cycles (GrayWaitNSwitches(2)) entre l'échange de pointeurs et l'écriture dans le buffer caché (parce qu'il n'est pas caché immédiatement), et il est fortement conseillé sur les 2 versions matérielles d'attendre le début d'un nouveau cycle avant d'échanger le pointeur pour éviter le clignotement. En tout, ça te fait jusqu'à 3 cycles des routines de gris à attendre.

Ximoon :
JackosKing> 1- la méthode de tigcc propose deux fonctions/macros, l'une qui n'attend pas la synchro et l'autre qui l'attend

Mais il faut obligatoirement attendre 2 cycles après l'échange des pointeurs sur HW1, quelle que soit la macro utilisée! (La macro "avec synchronisation" attend avant l'échange des pointeurs, ce qui réduit le clignotement, mais ne résout pas le problème des HW1.)

PS: Je parle évidemment de cycles des routines de gris ("switches"), pas de cycles du processeur.

et pour mon deuxième point ?

C'est vrai. Mais sur HW1, on évite quand-même les 2 switches d'attente en utilisant la recopie.

J'explique: Le code à utiliser pour l'échange de pointeurs est celui-ci:

  GrayDBufToggleSync();
  [b]if (!_GrayIsRealHW2()) GrayWaitNSwitches(2);[/b]

La deuxième ligne est obligatoire! La raison est que l'échange de pointeurs n'est effectif sur HW1 qu'au moment où l'interruption de gris effectue son prochain switch. Ça ferait au moins un switch à attendre, mais comme, pour réduire les clignotements, entre les 2 phases foncés, le switch n'est pas effectué, il faut attendre 2 switches. Sinon, on écrit dans le buffer "caché" avant qu'il soit effectivement caché.

-

Orion_ :
et en asm sa donne ?

C'est à ça que sert tigcc -S.

	move.l __switch_cnt,%d0
	move.l %d0,%d1
	addq.l #1,%d1
.L2:
	move.l __switch_cnt,%d0
	cmp.l %d0,%d1
	jbhi .L2
	tst.w __gray_dbl_offset
	jbne .L5
	moveq.l #8,%d0
	jbra .L6
	.even
.L5:
	clr.w %d0
.L6:
	move.w %d0,__gray_dbl_offset
	tst.w __gray_hw_type
	jbne .L1
	move.l __switch_cnt,%d0
	move.l %d0,%d1
	addq.l #2,%d1
.L8:
	move.l __switch_cnt,%d0
	cmp.l %d0,%d1
	jbhi .L8
.L1:

orion la seul avantage de swap buffer est de gagner de la place (pas de fonction pour recopier les buffer) mais c'est plus lent si t'as une fonction de recopiage de buffer optimisé, sinon the best is GXgray

Non, GenGray 0 Attente, moins de memoire consommee.

heu si c'est la meme routine qu'il y avait dans la version gen de qs temps je suis pas si sur qeu ca

Dans des conditions normales d'utilisation bien sur.

> Dans des conditions normales d'utilisation bien sur.
Quelles sont-elles ?

Un jeu, pas un bench.