Double Buffering optimisé. - Page 2

> Je sens comme une pointe de sarcasme
non carement pas, en fait j'en c rien, g jamais matté la doc et en ai tj utilisé 2

> On peut copier ou faire pointer les images terminé vers la mémoire qui va à l'écran sans attendre quoique ce soit ?!
spiv ou don miguel (je c plus, surement spiv) change l'adresse du buffer qu'affiche la gp, pour faire du scrolling (donc il n'y a que le sdk qui te limite a 4 adresse de buffer primaire visiblement)
tu peut copier ce que tu veut qt tu veut ds le buffer d'ecran actuellement affiché, mais ca se vera au moment ou tu copie (a moins que tu matte ou en est le vblank..)

> Est-il possible d'utiliser l'espace des 2 buffers en trop pour avoir 2 buffers écran de + de 320x240 ?
j'avais trop mal lu ta question, je pensais que tu voulais 2 buffer d'ecran suplementaires
je c pas. essai de regarder du coté de gpdrawtag ds la doc (il me semble qu'il peut avoir une taille superieure a la taille affichée) ^^
si tu veut faire ca pour du clipping, tu peut dire aux fct de blit de gp de ne pas afficher tt l'image, tu defini la pos de debut du blit et la taille a copier

ce qui serais bien ce serais de pouvoir avoir un buffer ac une taille y de 256 on aurais plus qu'un decalage a faire au lieu d'un * pour calculer l'adresse d'un point du buffer ^^

Bon, il faut que j'arrête l'alcool et que je regarde d'un peu plus près les codes sources que j'utilise quand je fais des tests... une fois qu'on affiche un buffer, il reste bien affichuer jusqu'au prochain flip appeler par le programme.

Bon, ce soir, je teste un buffer video en 336x256 pour voir ce qu'on peut en faire.

Requiem, pour ton problème de clignotement, j'ai l'impression que tu n'écris pas sur la surface correcte.
Moi j'ai eu le même problème de clignotement lorsque je pensait que je dessinai sur la bonne surface alors que ça ne l'était pas.
Je ne sait pas si ça peut t'aider.

euh moi g deja eut un pb de clignotement!
et en fait c'était parce ke je changait la vitesse du proc mais comme un pied!
j'avais mis des mauvaise valeurs!

Pour réalisé un double buffering sans perte de temps (parce-qu'avec les fonction du sdk c'est du gachis pur et simple) il suffirait de faire pointer les images terminé vers la mémoire de l'écran au avant que l'écran ne soit raffraichit, non ?
Parce-que là ça ne sert plus à rien d'optimiser un programme. On sait que l'on est dans une fourchette de FPS : 60, 30, 15, 7.5, 3.25
Et la vitesse de rafraichissement de l'écran ne peut aps se modifer en software ? Il n'y a pas dees interruptions à bidouiller des fois ?

Raphaël, je ne comprends pas trop ce qui te choque dans le comportement du sdk.
Sdk ou pas, tu perds toujours du temps à attendre la fin de l'affichage pour mettre à disposition la nouvelle image à afficher.

C'est pareil sur n'importe quel autre hardware ? Il y a 50 % de la puissance du proc perdu en attendant pour rien... enfin l'écran ?
Il y a un truc que je n'ai aps compris. Si l'écra était plus rapide : 90 Hz, on aurait moins à attendre ?
Ce que je ne comprend toujours pas c'est que je passe de 60 à 30 FPS seconde sans intermédiaire.

geepee32 est pas top pour les tests ! attend d'avoir ta gp pour essayer, tu comprendra tout !

Ok, d'accord. Parce-que sur TI, tout le monde disait : "VTI est pas fiable du tout". Mais en réalité ça allait plutôt bien.
C'est vrai que je ne pas vérifier si l'émulateur fonctionnait comme la console... donc je vais attendre... patiement.

> Si l'écran était plus rapide : 90 Hz, on aurait moins à attendre ?
oui mais tu aurais a optimiser ton code bc plus vu que tu aurais moins de temps pour chaques frames

> Il y a 50 % de la puissance du proc perdu en attendant pour rien... enfin l'écran ?

g matté la doc, et tu peut mettre en place des timers qui vons lancer une fct a intervalle regulier, donc independament de l'affichage

voila un exemple :

#include "./Gdl/Gdl.h"

int count=0 ;
void test(void) { count++ ; }

void GpMain(void * arg)
{	initScreen();	setKeyEvent(kSelect,keyUp,GpAppExit) ;
	
	GpTimerOptSet(0,200,10,test);
	GpTimerSet(0);
	
	char nb[15] ;

	while(1)
	{
		updateKey() ;	flipScreen() ;	clrScr() ;
		
		sprintf(nb,"%i",count) ;
		GpTextOut(NULL, &gpDraw[nflip],30,30,nb,0x2A) ;
	};
}

le 0 c le numero du thread a utiliser
le 200 c visiblement le nb d'appel par secondes
le 10, c le temps max en tick que peut ocuper le thread durant un appel (ou au total par secondes, c pas presicé)

tu as en tout 4 thread utilisable, et pleins de fct pour changer les priorité mettre en pause ect .. c ds la doc, partie gpos ^^

suffit de faire un triple buffering:
E1,E2,E3 : Ecran;
E1 -> Ecran actif
E2 -> Ecran attendant la synchronisation
E3 -> Ecran de travail.

ensuite une fois que la synchro est attendu et qu'on souhaite afficher E3, ca donne:

E2 -> Ecran actif
E3 -> Ecran attendant la synchronisation
E1 -> Ecran de travail.

etc.. comme ca on attend pas la synchronisation. La différence sur ti est non négligeable.

suffit de faire un triple buffering:
E1,E2,E3 : Ecran;
E1 -> Ecran actif
E2 -> Ecran attendant la synchronisation E3 -> Ecran de travail.

Voilà ! C'est ce à quoi je pensais ! Et personne n'utilise ce mode de bouble buffering ?! C'est bien curieux.
Bon par contre ça va être cahaud vu que je ne connais pas l'adresse de l'écran.
Quelqu'un pourrait me donner l'adresse vers la mémoire vidéo qui va à l'écran ?

La différence sur ti est non négligeable.

J'ai pas bien compris ce que tu veux dire là...

oui mais tu aurais a optimiser ton code bc plus vu que tu aurais moins de temps pour chaques frames

Justement c'est ça qui me plaît !

moi je l'utilise pas, vu que je vois pas comment le mettre en place sans utiliser un thread
et si on met un thread je vois pas l'interet de mettre 3 buffer

> Justement c'est ça qui me plaît !
bah ca plait a tt les developeurs je pense

et si tu veut vraiment optimiser, decend en frequence cpu

J'ai pas bien compris ce que tu veux dire là...

>> on gagne pas mal en fps sur ti grace à cette methode. (j'ai dev une lib asm sur ti, et j'ai utilise le double puis le triple buffering, et j'ai constater la diff)

pour le thred, il est pas énormément compliqué, il se synchronise sur qqc (un port ou autre, je connais pas la GP), et il est pas super gros et long (en cycle), donc ne perturbe pas le comportement de la machine normalement.

un autre solution utilisé sur ti, c du double buffering, mais on attend la synchro en thread, et pendant ce temps on fait des calculs, mais non graphique... (methode genlib il me semble).