Grib - Page 3

Quelqu'un a testé l'un ou l'autre ?

Au fait, en utilisant le compteur de frame sur grib, je me retrouve avec des scintillements sur HW2. J'ai dû me planter quelque part...
Sinon, je vais essayer de trouver un moyen de réduire le plus possible l'attente de la synchro : voici à quoi devra ressembler la boucle principale des programmes pour cela :

while(!quit)
{
  faireDesCalculs(objets);
  buffer_dessin = obtenirBufferDessin();
  dessinerLesObjets(objets,buffer_dessin);
  afficherBuffer(buffer_dessin);
}

Sauf que la fonction echangerBuffers ne prendra pas effet tout de suite, elle demandera simplement à la lib qu'au prochain cycle d'affichage il faudra échanger préalablement les buffers, cela fait qu'il n'y a aucune attente. Ensuite, le programme fait ses calculs (pendant ce temps la frame a le temps de finir d'être affichée, et le buffer affiché est remplacé par buffer_dessin), puis la fonction obtenirBufferDessin renvoie le nouveau buffer de dessin (qui est l'ancien buffer affiché) et on peut dessiner dessus immédiatement.
En fait la fonction obtenirBufferDessin pourrait bloquer, elle, tant que la frame n'a pas fini d'être affichée.

Sasume :
En fait la fonction obtenirBufferDessin pourrait bloquer, elle, tant que la frame n'a pas fini d'être affichée.

Tu peut l'appeleer "WaitForVSync" ou plus simplement "vsync" alors ^^

Pourquoi V ?

Sur HW2, l'interruption est cadencée à 256 Hz et elle recopie 1/3 de plan à chaque fois. Un cycle complet doit afficher 2 dark_plane et 1 light_plane entiers, soit environ 9 fois l'interruption (3 planes à copier en 3 fois), donc le compteur de cycles complets d'affichage s'incrémente à une vitesse de 30 Hz environ, c'est une vitesse tout à fait suffisante pour les jeux
Sur HW1, l'interruption est cadencée à 350 Hz environ, mais n'est utilisée qu'une fois sur 4 ce qui fait qu'elle est utilisée à 90 Hz environ, le cycle d'affichage (2 light + 1 dark) est lui aussi cadencé à 30 Hz.

V comme Vertical

vsync est souvent utilisé pour syncroniser avec la fin d'affichage d'une frame

Au fait, j'ai oublié de le préciser dans mon post 61 : je remercie Nu de m'avoir soumis cette idée.

Marrant ce ./62 me rapppelle une autre lib

lol

Ah ? J'ai les sources en plus je pourrais repomper
Cela dit, si tu parles bien de genlib, je ne me souviens pas que l'API permet de faire ça (enfin, j'avais aussi oublié le genlib::frame_timer...)

technic/archives/Doc/genlib.html#GLAUX-Functions

(oui bon c'est pas forcement le bon topic, mais c'est la faute a martial ) PpHd : Comment marchent Wait15 et Wait30 ?

./ 70 > OK
Bon, bah messieurs, je n'ai qu'une chose à dire : utilisez genlib

(oui bon c'est pas forcement le bon topic, mais c'est la faute a martial ) PpHd : Comment marchent Wait15 et Wait30 ?

Utilisation de genlib::timer et genlib::frame_timer, pourquoi ?

PpHd> Dans glaux_swap, tu ne te préoccupes pas de ne pas échanger les DSCREEN même si une frame est en cours d'affichage ?

En fait, après réflexion, on peut faire comme ça :

void gl_main()
{
  while(!quit)
  {
    // calculs
    glaux_ready();
    // affichage
    glaux_synchro();
    glaux_swap();
  }
}

Non ce n'est pas necessaire.

./77: tout a fait!

1. Exporter ta fonction FastCpyPlan like (comme le faisait Xv2).
2. Ajouter le TripleBuffering.

triple buffering ?
on peut le faire à partir du double non ?

pas forcement,

1 plan affiché
1 plan a afficher
1 plan sur lequel on ecrit

Ca peut permettre un poil plus de fluidité

Sinon ya d'autre systemes de triple buffering, mais celle que tu propose est plutot complexe :/

heu nan j'avoue j'aimerais bien savoir aussi à quoi ça correspond le "triple buffering", vu qu'en-dehors du petit monde de la Ti j'ai jamais vu, et que j'ai du mal à comprendre ce que ça peut apporter

Allegro (par ex) en propose du triple buffering

normalement, en double buffering, il faut que tu attendes la synchro des grays avant de swapper ton écran affiché et ton écran de dessin => tu perds du temps
en triple-buffering, tu dois pouvoir éviter ce temps d'attente, je suppose (vu que pendant le temps d'attente pour le swap écran affiché / écran à afficher, tu dessines déjà le troisième écran)
enfin, je pense que c'est en rapport avec ça

(sinon, je veux bien une explication aussi ^^ )

bah c'est simple, si tu fais du double-buffering, tu dois attendre sans rien faire le prochain frame... c'est pas du tout gênant si ton jeu est conçu pour tourner à un frame rate constant connu que tu es sûr de pouvoir atteindre, mais si le frame rate est variable c'est très utile de pouvoir aller le plus vite possible sans perdre 1/90è de seconde (ou pire 1/30è de seconde) à chaque frame...

[méga-cross] et oui le fait qu'il y ait un article sur wikipedia tend à montrer que c'est loin d'être limité aux TI...

Bon le plus simple etant encore de faire du 42th buffering