Grib - Page 4

moui, si ça sert à aller au-delà des 90fps j'ai effectivement beaucoup de mal à saisir l'interet ... pour le "limité au Ti", non, certainement pas, mais est-ce que c'est vraiment utilisé ? j'ai pas l'impression :/

Oui c'est utilisé a partir du moment ou tu ne peu savoir quel sera le framerate et que tu veux pas fixer ton soft a la fréquence d'affichage. Imagine que ton processeur aille a 200 a l'heure, mais que la carte video rame comme pas possible. Si tu utilise un procedé comme le double buffering, des que ta rempli le buffer de travail, tu doit attendre que la carte l'ai affiché (attente de vsync) avant de pouvoir rendre dans le premier. Avec le triple buffering tu as une frame d'avance (1 frame affiché, 1 en attente d'affichage et 1 que tu dessine)

Voila en gros. Dans un cas tu doit te syncrhoniser avec l'affichage, le second tu peut t'en passer

Vertyos>
ben nan

t'as un programme qui tourne sur HW1 et HW2, par exemple. Sur HW2, le moteur peut tourner à 50 fps, avec des pics dans les niveaux compliqués à 33 fps. Avec le double buffering, tu attends la synchro, paf l'affichage est à 30 fps dans tous les cas, nickel. Mais sur HW1, le moteur tourne à 41 fps dans les niveaux simples et 27 fps dans les niveaux complexes; donc avec le double buffering, le frame rate sera 2x plus faible dans les niveaux compliqués (15 fps, puisqu'on ne pourra pas tourner à 30 fps), donc ça ramera énormément. Alors qu'avec le triple buffering, le frame rate aurait été en moyenne de 27 fps dans les niveaux compliqués

Martial Demolins :
Alors Sasume, des nouvelles de Grib?

Oui, je viens de sortir une v0.2. Vous pouvez tester si vous voulez, elle est sur mon "site" : http://perso.wanadoo.fr/jackiechan68k/download/grib.zip
Elle fournit des outils de synchronisation très ressemblants à genlib. Voir la demo2 pour voir comment s'en servir.
J'ai aussi revu mes objectif, et mon code en conséquence qui se trouve nettement plus petit. Un même programme codé avec Grib prend environ 230 octets de moins que s'il avait été écrit avec TIGCCLIB (pour un comportement strictement identique).
Il est possible que l'API change d'ici une vraie beta.
Il est (fort) possible qu'il y ait des bugs.

JackosKing :
1. Exporter ta fonction FastCpyPlan like (comme le faisait Xv2).

Pourquoi pas. Sauf que je copie un tier de plan à chaque fois. Donc je pourrais exporter une fonction qui utilise cette sous-fonction 3 fois...
Je ne sais pas si vaut vraiment le coup...

2. Ajouter le TripleBuffering.

Bof, ça ne sert pas à grand chose avec le système actuel il n'y a aucune attente si on s'y prend bien.
J'ai cependant quelques détails à approfondir : sur HW2 je ne constate aucun problème de synchro en utilisant le double-buffering : avant de swaper, je ne vois aucun intérêt à attendre que la frame en cours ait été complètement affichée avant de swaper (j'ai fait un test simple et je ne vois pas de différence). Ensuite, après avoir swappé, on peut écrire immédiatement dans le nouveau buffer de dessin (qui était affiché) puisque l'interruption ne copiera plus que le nouveau buffer d'affichage vers LCD_MEM.

Il n'y a finalement donc que sur HW1 qu'il y a un tout petit problème : si au moment où on swape, le contrôleur LCD est en train d'afficher le milieu d'un plan, tant qu'il n'aura pas fini de l'afficher, ce sera toujours l'ancien buffer d'affichage qui sera affiché (pas le nouveau qu'on vient de définir en swapant), donc si on dessine dessus, les modifications seront visibles (par exemple, si on l'efface, ça fera un petit clignotement).
Donc à priori, il y a juste une petite attente à effectuer avant de dessiner à nouveau. Attente d'au maximum 1/90 seconde.

Je n'oublie rien ?
Si c'est le cas, il faudra que je revoie mon système

Pollux :
Vertyos>
ben nan

t'as un programme qui tourne sur HW1 et HW2, par exemple. Sur HW2, le moteur peut tourner à 50 fps, avec des pics dans les niveaux compliqués à 33 fps. Avec le double buffering, tu attends la synchro, paf l'affichage est à 30 fps dans tous les cas, nickel. Mais sur HW1, le moteur tourne à 41 fps dans les niveaux simples et 27 fps dans les niveaux complexes; donc avec le double buffering, le frame rate sera 2x plus faible dans les niveaux compliqués (15 fps, puisqu'on ne pourra pas tourner à 30 fps), donc ça ramera énormément. Alors qu'avec le triple buffering, le frame rate aurait été en moyenne de 27 fps dans les niveaux compliqués

Heu... Rien capté, je relirai demain

()

Sasume
:

JackosKing :
1. Exporter ta fonction FastCpyPlan like (comme le faisait Xv2).

Pourquoi pas. Sauf que je copie un tier de plan à chaque fois. Donc je pourrais exporter une fonction qui utilise cette sous-fonction 3 fois...
Je ne sais pas si vaut vraiment le coup...

2. Ajouter le TripleBuffering.

Bof, ça ne sert pas à grand chose avec le système actuel il n'y a aucune attente si on s'y prend bien.
J'ai cependant quelques détails à approfondir : sur HW2 je ne constate aucun problème de synchro en utilisant le double-buffering : avant de swaper, je ne vois aucun intérêt à attendre que la frame en cours ait été complètement affichée avant de swaper (j'ai fait un test simple et je ne vois pas de différence). Ensuite, après avoir swappé, on peut écrire immédiatement dans le nouveau buffer de dessin (qui était affiché) puisque l'interruption ne copiera plus que le nouveau buffer d'affichage vers LCD_MEM.

Il n'y a finalement donc que sur HW1 qu'il y a un tout petit problème : si au moment où on swape, le contrôleur LCD est en train d'afficher le milieu d'un plan, tant qu'il n'aura pas fini de l'afficher, ce sera toujours l'ancien buffer d'affichage qui sera affiché (pas le nouveau qu'on vient de définir en swapant), donc si on dessine dessus, les modifications seront visibles (par exemple, si on l'efface, ça fera un petit clignotement).
Donc à priori, il y a juste une petite attente à effectuer avant de dessiner à nouveau. Attente d'au maximum 1/90 seconde.

Je n'oublie rien ?
Si c'est le cas, il faudra que je revoie mon système

En fait dans un sens, le fonctionnement video des HW2 est proche du triple bffering

Martial Demolins :
Et pourquoi recopier tout sur HW1? Je croyais qu'une simple redirection de l'adresse de l'écran suffisait? (mais bon, je n'y connait presque rien au fonctionnement du hardware alors...)

C'est le contrôleur LCD qui se charge de ce boulot. Au début de chaque frame il va lire l'adresse de l'écran (que j'ai redirigée soit vers le dark_plane, soit vers le light_plane bien sûr), puis il copie LCD_SIZE octets petit à petit à l'écran. Cette copie prend un certain temps.

Martial Demolins :
Kevin vient de merger des optimisations de Lionel qui font gagner 40 octets aux routines de TIGCCLIB.

OK, donc je n'ai plus que 200 octets d'avance

Perso le triple buffering, je comprends le principe mais je n'ai jamais vu l'interet (sauf pour des demos pures et encore).

Pour la synchro, il y a les deux solutions: attente active, attente semi-active (on peut faire encore quelques calculs pendant ce temps).

Limiter le framerate est une bonne chose, puisque l'écran des TI-68k est assez mauvais. Avoir plus de 30 FPS ne sert à rien, et on se contente souvent d'une quinzaine (Ice Hockey 68k, FAT dans les meilleurs cas).

Au fait, je constate un léger clignotement sur ma TI-89 HW2 au niveau des délimitations des tiers de l'écran, sur une ou deux lignes seulement, régulièrement (toutes les secondes environ).
Cela se produit que je fasse du double-buffering ou non. Et avec la routine de TIGCCLIB ça fait la même chose.
Je ne vois pas trop à quoi ça peut être dû.

Lionel Debroux :
Pour la synchro, il y a les deux solutions: attente active, attente semi-active (on peut faire encore quelques calculs pendant ce temps).

Limiter le framerate est une bonne chose, puisque l'écran des TI-68k est assez mauvais. Avoir plus de 30 FPS ne sert à rien, et on se contente souvent d'une quinzaine (Ice Hockey 68k, FAT dans les meilleurs cas).

Et attente évênementielle en multitâche, mais bon faut un noyau là pour le coup #pub#

la fonction de copie de buffer est plutot longue (groumande en octets). Si tu l'exportes, tu gagnes qqs centaines d'octets (d'ailleur j'ai jamais compris pourquoi KK a jamais voulu le faire quand je lui ai proposé -> fork pour X :/).
Si si le triple etait utilisé dans X, perso je vois pas l'interet de perdre du temps alors qu'on peut faire bosser le proc...

JackosKing :
la fonction de copie de buffer est plutot longue (groumande en octets). Si tu l'exportes, tu gagnes qqs centaines d'octets (d'ailleur j'ai jamais compris pourquoi KK a jamais voulu le faire quand je lui ai proposé -> fork pour X :/).

Hum, je ne gagne quelque chose que si l'utilisateur copie quelque part dans son programme un buffer de la taille de LCD_SIZE. Je ne sais pas si ça vaut vraiment le coup...

JackosKing :
Si si le triple etait utilisé dans X, perso je vois pas l'interet de perdre du temps alors qu'on peut faire bosser le proc...

Sauf que si tu avais lu le topic, tu saurais qu'on peut se débrouiller pour qu'il n'y ait pas de temps d'attente justement...

Martial Demolins :
Tiens au fait c'est marrant, tu compiles avec GNU as, mais tu ne fournis que le header de A68k.

Non, je fournis aussi un header pour GNU AS, dans le répertoire include/S.

Martial Demolins :
Comment doit être le buffer fourni à GribOn? Il doit être aligné précisément sur une adresse paire, je suppose, mais peut-être multiple de 8 ou autre? (je demande ça car il me semble avoir un pb, l'écran commence quelques octets trop loin en fait...)

Il fauteffectivement lui passer une adresse multiple de 8. Je fournirai sûrement une macro qui s'occupe de ça pour simplifier le job de l'utilisateur. En tout cas, pour l'instant je te conseille déjà d'allouer des buffers de taill GRIB_GRAY_BUFFER_SIZE ou GRIB_GRAY_DBUFFER_SIZE (si tu fais du double-buffering).

Cool
Je me dépêche de finaliser la nouvelle version

Non, normalement la documentation doit suffire, dans un projet bien foutu.
Il faut donc que je fasse une vraie doc.

Sauf que si tu avais lu le topic, tu saurais qu'on peut se débrouiller pour qu'il n'y ait pas de temps d'attente justement...

... mdr

Sauf que si tu avais lu le topic, tu saurais qu'on peut se débrouiller pour qu'il n'y ait pas de temps d'attente justement...

Si tu lisais, tu verrai qu'en moyenne on attend jamais...

En moyenne... donc en gros ca sert a rien..;

Mias oui bien sur. Fais donc ton idiot je ne le remarquerai pas

Non non il fait pas son idiot, il fait son JS

(tiens marrant j'était en train de me dire que j'avais pas vu PpHd poster un c'est chose faite ^^)

bon alors j'ai une routine de sprite qui affiche a 1000sp/s et 9000sp/s ca fait une moyenne de 5000, super et alors... le jour ou certains comprendront que la moyenne a ce niveau veut rien dire...

JackosKing> Evite de poster pour rien s'il te plait.

Bon, je suis en train de rédiger la doc, je ferai une nouvelle release bientôt. L'API est en train de se stabiliser

./116: Aveugle Tu es, pauvre padawan.

bon alors j'ai une routine de sprite qui affiche a 1000sp/s et 9000sp/s ca fait une moyenne de 5000, super et alors... le jour ou certains comprendront que la moyenne a ce niveau veut rien dire...

> Bon, je suis en train de rédiger la doc, je ferai une nouvelle release bientôt. L'API est en train de se stabiliser.
C'est bien. Où en es-tu en taille par rapport à la routine de TIGCCLIB ?

FMI, c'est le temps des boulets, en ce moment ? Il y a aussi nEUrOO qui s'y met.