Accueil Ti-Gen Foire Aux Questions Chat sur le chan #tigcc sur IRC
Liste des membres Rechercher Aide
Bienvenue Invité !   Se connecter             Mes sujets   
Administrer
0 membre(s) et 1 visiteur(s) actif(s) durant les 5 dernières minutes Utilisateurs actifs : Aucun membre + 1 visiteur
Avant de poster sur le forum, il y a des régles de bases à respecter pour une bonne entente et un respect de tous.
Veuillez lire la charte du forum.
  :: Index » Forum Ti68K » News » Nostub rulezzzzzzzzzz (65 réponse(s))
./REPRISE DU POST PRECEDENT (post n°38)   Marquer comme non lu.
Kevin Kofler Ecrit le: Jeudi 19 janvier 2006 à 15:17 Déconnecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


Sasume :
Kevin> La synchro de genlib qu'utilise Martial a pour effet de rendre le fps constant à 30 fps. Sinon, il peut le rendre à 15 fps... Mais ça devient peut-être un peu lent pour ce qu'il veut faire.
Il faut aussi se soucier du matériel qu'on utilise : l'écran se rafraîchit à 90Hz, donc en nvg (avec 2 plans), on est obligé d'être bloqué à 30Hz (ou 15, ou 7.5, etc...).

Euh, avec du GrayWaitNSwitches(3);, on alterne entre:
  • attente du switch foncé->clair: 1/45 s
  • attente du switch clair->foncé: 1/90 s
  • attente du switch foncé->clair: 1/45 s

Total: 5/90 s
et:
  • attente du switch clair->foncé: 1/90 s
  • attente du switch foncé->clair: 1/45 s
  • attente du switch clair->foncé: 1/90 s

Total: 2/45 s
Donc en moyenne 4,5/90 s = 9/180 s = 1/20 s, c'est-à-dire 20 Hz.

Si genlib ne permet pas ça, c'est bien un défaut de genlib.
-Edité le Jeudi 19 janvier 2006 à 15:18 par Kevin Kofler-
Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!
    
./Post n°39   Marquer comme non lu.
Kevin Kofler Ecrit le: Jeudi 19 janvier 2006 à 15:18 Déconnecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


limmt :
Meme si ca ne se voit pas à l'oeil, au clavier ca pourra pas répondre pareil ça sera moins fluide

Tu peux calculer les plans sans les afficher (frameskip).
-Edité le Jeudi 19 janvier 2006 à 15:19 par Kevin Kofler-
Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!
    
./Post n°40   Marquer comme non lu.
Sasume Ecrit le: Jeudi 19 janvier 2006 à 15:29 Déconnecté(e)    Voir le profil de Sasume Envoyer un email à Sasume Visiter le site WEB de Sasume Envoyer un message privé à Sasume  

Kevin Kofler :
Si genlib ne permet pas ça, c'est bien un défaut de genlib.
Et pourquoi ce ne serait pas un défaut de TIGCCLIB de ne pas permettre une synchro à 30 Hz ?
    
./Post n°41   Marquer comme non lu.
Pollux Ecrit le: Jeudi 19 janvier 2006 à 16:18 Déconnecté(e)    Voir le profil de Pollux Envoyer un email à Pollux Envoyer un message privé à Pollux  

Kevin Kofler :
Pollux :
Dans un autre registre on a aussi la solution qui consiste à chercher des motifs correspondant à du 4 ndg / 7 ndg / 8 ndg, et ensuite faire une moyenne des 3/6/7 derniers écrans respectivement selon le mode détecté...

C'est ce qu'on fait, mais le problème est (enfin, je pense que ce soit le problème vu les caractéristiques des programmes affectés) que si on toggle entre 2 jeux de plans sans arrêt, TiEmu ne peut plus détecter le motif.

Pourquoi donc ? #confus#
Evidemment si on se contente de regarder si 2 frames consécutifs sont les mêmes ça ne marche pas, mais par contre si on regarde si, dans le cas où ils ne sont pas les mêmes, le frame courant et le frame avant le frame précédent sont les mêmes ça permet de couvrir tous les cas, non ? enfin, à condition que le jeu tourne à moins de 30 fps : c'est vrai que ça va continuer à poser problème s'il y a des pics à 45 fps ou plus... dans ce cas-là peut-être que quelque chose d'un peu plus général du genre
int test_rotated_pattern(CRC *history,int *pattern,int n,int s) {
    CRC matches[8]; // no more than 8 different planes
    int i,j;
    for (i=0;i<n;i++) {
        int k = pattern[(i+s)%n];
        if (!matches[k]) {
            matches[k]=history[i];
            for (j=0;j<n;j++)
                if (k!=j && matches[k]==matches[j])
                    return 0;
        } else if (matches[k]!=history[i])
            return 0;
    }
    return 1;
}
int test_pattern(CRC *history,int *pattern,int n) {
    int j;
    for (j=0;j<n;j++)
        if (rotate(history,pattern,n,j))
            return 1;
    return 0;
}

#define HISTORY (8+8)
CRC framecrc_history[HISTORY];
int current_blur,current_shift;
int current_nomatch = INT_MAX;

void update_gray_frame(int start,int num) {
    // ...blur all images from 'start+num-1' frames ago to 'start' frames ago...
}

void process_new_frame(SCREEN *scr) {
    for (i=HISTORY;--i;)
        framecrc_history[i] = framecrc_history[i-1];
    framecrc_history[0] = checksum(scr);
    current_shift++;

    const int pattern[8][8] = {
        {-1},
        {-1},
        {-1},
        {0,0,1},
        {-1},
        {-1},
        {0,0,1,0,1,2}, // FIXME?
        {0,0,1,0,0,1,2}, // FIXME?
    };
    int target_shift = current_shift%current_blur;
    int shift = -1;

    for (blur=8;--blur;) {
        if (pattern[blur][0]<0)
            continue;

        if (blur==current_blur && test_pattern(framecrc_history+target_shift,pattern[blur],blur))
            shift=target_shift;
        for (i=0;i<blur;i++)
            if (shift<0 && test_pattern(framecrc_history+i,pattern[blur],blur))
                shift=i;
    }

    if (shift<0) {
        current_nomatch++;
        if (current_nomatch>=10) // TODO: tweak it
            shift=0, blur=3;
    }
    if (shift>=0) {
        current_nomatch=0;
        if (shift!=current_shift || blur!=current_blur) {
            current_shift = shift;
            current_blur = blur;
            update_gray_frame(current_shift,current_blur);
        }
    } else if (current_shift!=target_shift) {
        current_shift = target_shift;
        update_gray_frame(current_shift,current_blur);
    }
}

pourrait résoudre ça ^^


Cela dit la solution qui donnerait l'émulation la plus fidèle ce serait quand même d'émuler la "bavosité" de l'écran...





Pourquoi pas? L'?il humain ne voit pas la différence entre 20 fps et 90 fps, d'autant plus que l'écran du vrai matériel est baveux.

A cause de l'aliasing temporel : pour un jeu un peu plus rapide que Backgammon, quand tu as des objets qui se déplacent sur l'écran, à moins de faire du motion blur logiciellement (ce qui serait *très* coûteux), c'est nettement plus efficace de faire un rendu du jeu sans motion blur mais avec un frame rate supérieur, et laisser l'écran baveux et/ou l'oeil humain faire le reste ^^

[EDIT : smileys]
-Edité le Jeudi 19 janvier 2006 à 16:24 par Pollux-
    
./Post n°42   Marquer comme non lu.
Kevin Kofler Ecrit le: Vendredi 20 janvier 2006 à 01:51 Déconnecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


Sasume :
Kevin Kofler :
Si genlib ne permet pas ça, c'est bien un défaut de genlib.
Et pourquoi ce ne serait pas un défaut de TIGCCLIB de ne pas permettre une synchro à 30 Hz ?

GrayWaitNSwitches(2) == 30 Hz
(Et GrayWaitNSwitches(1) == 60 Hz en moyenne. C'est le mieux qu'on puisse faire sur HW1 sans écrire sur un plan encore affiché, vu que le plan foncé reste affiché 1/45 s et le plan clair reste affiché 1/90 s.)
Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!
    
./Post n°43   Marquer comme non lu.
Kevin Kofler Ecrit le: Vendredi 20 janvier 2006 à 02:06 Déconnecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


Pollux :
Kevin Kofler :
C'est ce qu'on fait, mais le problème est (enfin, je pense que ce soit le problème vu les caractéristiques des programmes affectés) que si on toggle entre 2 jeux de plans sans arrêt, TiEmu ne peut plus détecter le motif.

Pourquoi donc ? #confus#

Parce que ça casse le motif.
On a besoin d'un affichage complet du plan foncé et un du plan clair, ou vice-versa. Donc:
foncé (affichage partiel) -> clair -> foncé -> clair (affichage partiel)
ou:
clair (affichage partiel) -> foncé -> clair -> foncé (affichage partiel)
TiEmu (une fois reconnu un motif "4 ndg" - cette détection peut aussi casser si le toggle va trop vite) jette les affichages partiels, puis garde seulement les 2 premières expositions (différentes), au cas où on a plusieurs affichages complets. (D'ailleurs, cette phase travaille avec des adresses de plans, on s'en fout complètement du contenu à ce moment-là encore.) Ensuite, il compare les temps d'exposition pour savoir quel est le plan foncé et quel est le plan clair. Et enfin, il jette toutes les autres mesures, va récupérer les buffers d'écran enregistrés pour chacun des plans (on faisait ça aussi avec des adresses au départ, mais ça faisait qu'on affichait souvent un plan déjà en train d'être redessiné avec le double-buffering, donc on utilise des buffers maintenant), et affiche une image en ndg se composant des 2 buffers détectés.
Comme tu peux voir, dans les motifs minimum, il y a 3 switches, c'est pour ça que je dis d'essayer un GrayWaitNSwitches(3).

Cela dit la solution qui donnerait l'émulation la plus fidèle ce serait quand même d'émuler la "bavosité" de l'écran...

Ça donnerait quand-même une image beaucoup moins nette que la détection de TiEmu (qui marche très bien sur la plupart des jeux: depuis qu'on utilise les buffers, même le F-Zero de LionelA passe).

Pourquoi pas? L'?il humain ne voit pas la différence entre 20 fps et 90 fps, d'autant plus que l'écran du vrai matériel est baveux.

A cause de l'aliasing temporel : pour un jeu un peu plus rapide que Backgammon, quand tu as des objets qui se déplacent sur l'écran, à moins de faire du motion blur logiciellement (ce qui serait *très* coûteux), c'est nettement plus efficace de faire un rendu du jeu sans motion blur mais avec un frame rate supérieur, et laisser l'écran baveux et/ou l'oeil humain faire le reste ^^

En général, cet effet de blur est plutôt un problème qu'une solution.
Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!
    
./Post n°44   Marquer comme non lu.
Kevin Kofler Ecrit le: Vendredi 20 janvier 2006 à 02:16 Déconnecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


Voilà l'algo de gris utilisé par TiEmu: http://svn.tilp.info/cgi-bin/viewcvs.cgi/tiemu/trunk/src/core/ti_hw/gscales.c?rev=1811&root=tiemu&view=markup.
Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!
    
./Post n°45   Marquer comme non lu.
Pollux Ecrit le: Vendredi 20 janvier 2006 à 03:50 Déconnecté(e)    Voir le profil de Pollux Envoyer un email à Pollux Envoyer un message privé à Pollux  

Kevin Kofler :
Parce que ça casse le motif.
On a besoin d'un affichage complet du plan foncé et un du plan clair, ou vice-versa. Donc:
foncé (affichage partiel) -> clair -> foncé -> clair (affichage partiel)
ou:
clair (affichage partiel) -> foncé -> clair -> foncé (affichage partiel)
TiEmu (une fois reconnu un motif "4 ndg" - cette détection peut aussi casser si le toggle va trop vite) jette les affichages partiels, puis garde seulement les 2 premières expositions (différentes), au cas où on a plusieurs affichages complets. (D'ailleurs, cette phase travaille avec des adresses de plans, on s'en fout complètement du contenu à ce moment-là encore.) Ensuite, il compare les temps d'exposition pour savoir quel est le plan foncé et quel est le plan clair. Et enfin, il jette toutes les autres mesures, va récupérer les buffers d'écran enregistrés pour chacun des plans (on faisait ça aussi avec des adresses au départ, mais ça faisait qu'on affichait souvent un plan déjà en train d'être redessiné avec le double-buffering, donc on utilise des buffers maintenant), et affiche une image en ndg se composant des 2 buffers détectés.
Comme tu peux voir, dans les motifs minimum, il y a 3 switches, c'est pour ça que je dis d'essayer un GrayWaitNSwitches(3).

Ce qui sux... Et mon code il est pas bien ?


Pourquoi pas? L'?il humain ne voit pas la différence entre 20 fps et 90 fps, d'autant plus que l'écran du vrai matériel est baveux.

A cause de l'aliasing temporel : pour un jeu un peu plus rapide que Backgammon, quand tu as des objets qui se déplacent sur l'écran, à moins de faire du motion blur logiciellement (ce qui serait *très* coûteux), c'est nettement plus efficace de faire un rendu du jeu sans motion blur mais avec un frame rate supérieur, et laisser l'écran baveux et/ou l'oeil humain faire le reste ^^

En général, cet effet de blur est plutôt un problème qu'une solution.

Et alors ? Le but de mon paragraphe n'était pas de dire que l'effet de blur est bien (il est de toute façon inévitable à moins de changer tes yeux #triso#), mais de dire que restreindre un programme à 20 fps est stupide parce que ça créera forcément de l'aliasing temporel (une balle qui traverse l'écran en un quart de seconde ne rend pas du tout pareil à 15 fps et à 90 fps, il faudrait du motion blur pour que ça rende à peu près pareil dans les deux cas) à moins d'y consacrer un temps de calcul gigantesque...
    
./Post n°46   Marquer comme non lu.
Kevin Kofler Ecrit le: Vendredi 20 janvier 2006 à 10:57 Déconnecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


Pollux :
Ce qui sux... Et mon code il est pas bien ?

Tu fais des checksums sur les contenus des plans, ce qui est très coûteux, et risque de ne pas marcher vu que pas mal de jeux dessinent directement sur les plans en train d'être affichés.
Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!
    
./Post n°47   Marquer comme non lu.
Pollux Ecrit le: Vendredi 20 janvier 2006 à 16:22 Déconnecté(e)    Voir le profil de Pollux Envoyer un email à Pollux Envoyer un message privé à Pollux  

- "très coûteux", un checksum sur le contenu des plans ? http://pwic.info/v31/gfx/s2/lolpaf.gif 3840*90 = 350 ko/s, et sur mon PC on peut faire 50 Mo/s d'un hash ultra-coûteux comme md5... (enfin sachant que TiEmu consomme "seulement" 25% du CPU chez moi, on peut dire que le budget est "seulement" de 12.5 Mo/s de MD5, soit nettement plus [facilement 10x plus] avec un hash plus rapide... 350 ko/s, c'est une goutte d'eau dans la mer)

- "pas mal de jeux dessinent directement sur les plans en train d'être affichés" : euh, il doit bien y avoir un moment où vous savez ce qui va être affiché, non ? http://pwic.info/v31/gfx/s3/trifus.gif il suffit d'appeler process_new_frame() que quand le frame est connu, pas avant, ça me paraissait assez évident #triso# (si par contre tu parles de la nécessité de faire un backup des N derniers écrans : oui, c'est évidemment nécessaire, sinon update_gray_frame() ne pourra pas faire son boulot)
    
./Post n°48   Marquer comme non lu.
Kevin Kofler Ecrit le: Vendredi 20 janvier 2006 à 18:45 Déconnecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


1. Je fais un checksum.
2. Le programme fait un Sprite16, DrawLine ou je ne sais pas.
3. Je refais un checksum.
=> Les checksums diffèrent, ton algo va prendre ça pour 2 plans différents et foirer totalement.
Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!
    
./Post n°49   Marquer comme non lu.
Pollux Ecrit le: Samedi 21 janvier 2006 à 04:39 Déconnecté(e)    Voir le profil de Pollux Envoyer un email à Pollux Envoyer un message privé à Pollux  

OK, j'ai regardé le code de TiEmu, vous utilisez un hack qui cherche les adresses des plans utilisés... Ce n'est pas un problème, il suffit de combiner checksum et adresse de plan pour avoir le meilleur des mondes :
- avec les adresses de plans, on peut déterminer la profondeur des niveaux de gris à coup sûr même dans le cas que tu cites
- une fois la profondeur déterminée, ma méthode de checksum permet de détecter, si le programme est synchronisé à une fréquence donnée (par exemple 30 Hz), les plans qui "vont ensemble" et ainsi éviter le clignotement. Dans l'exemple que tu donnes, il n'y a pas de synchronisation, donc mon programme répond simplement "je ne sais pas" et continue sur la lancée de la dernière synchronisation qu'il a réussi à détecter ^^


Enfin, à moins que je rate qqch #confus#
    
./Post n°50   Marquer comme non lu.
Kevin Kofler Ecrit le: Samedi 21 janvier 2006 à 05:11 Déconnecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


Comment veux-tu détecter les plans qui "vont ensemble" avec une checksum? A priori, on a 4 plans (2 actifs, 2 cachés) et 4 checksums différents. Et si le toggle est à un intervalle de moins de 3 switches, ça donne une séquence assez arbitraire de ces 4 plans (et donc de ces 4 checksums), qui ne permet pas de savoir quels plans "vont ensemble" ou même quels sont (de manière fiable) les plans foncés et lesquels les plans clairs.

Le seul moyen que je vois pour trouver le rôle des plans à coup sûr est de détecter individuellement la routine de double-buffering et d'aller voir le contenu des pointeurs de plans directement en mémoire. Il faudrait donc une version de ce code pour TIGCCLIB, une autre pour genlib etc.
Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!
    
./Post n°51   Marquer comme non lu.
Pollux Ecrit le: Samedi 21 janvier 2006 à 17:09 Déconnecté(e)    Voir le profil de Pollux Envoyer un email à Pollux Envoyer un message privé à Pollux  

Ah effectivement si le programme tourne rigoureusement à 30 fps sans jamais descendre en-dessous il y a un cas qui posera problème : si la séquence des plans est (AAB)(aab)(AAB)(aab)(AAB)(aab) il n'y a aucun moyen de la distinguer de AA(Baa)(bAA)(Baa)(bAA)(Baa)b :( Oui je crois que y a pas le choix, il va falloir détecter le double-buffering...

[mode=troll size=huge]
Mais la solution est simple, il suffit d'adopter la convention de genlib : accoler plan de poids fort et plan de poids faible dans un ordre précis, ce qui permet de déterminer à coup sûr si deux plans font partie du même buffer :D (d'ailleurs c'est peut-être ce que fait aussi tigcclib sur hw2 ? peut-être pas dans le même sens par contre :-/)
[/mode]
    
./Post n°52   Marquer comme non lu.
Kevin Kofler Ecrit le: Samedi 21 janvier 2006 à 17:40 Déconnecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


Tes 2 séquences ne sont pas le plus grand problème, ça permet de voir au moins quels sont les plans clairs et quels sont les plans foncés. Le problème, c'est plutôt des trucs comme ça:
AaBaAbAaBaAb...
On ne voit rien du tout dans ça. Et certes, une synchro est censée éviter ça, mais c'est bien en théorie. En pratique, les séquences bien synchronisées dégénèrent forcément en des séquences comme ça parce qu'il y a forcément des cycles CPU entre le toggle et la synchro (ou entre la synchro et le toggle si on fait les choses dans l'autre sens - sur HW1, c'est obligatoirement synchro après toggle, sur HW2, les 2 ont leur justification).
Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!
    
./Post n°53   Marquer comme non lu.
Pollux Ecrit le: Dimanche 22 janvier 2006 à 19:45 Déconnecté(e)    Voir le profil de Pollux Envoyer un email à Pollux Envoyer un message privé à Pollux  

Kevin Kofler :
Tes 2 séquences ne sont pas le plus grand problème, ça permet de voir au moins quels sont les plans clairs et quels sont les plans foncés. Le problème, c'est plutôt des trucs comme ça:
AaBaAbAaBaAb...
On ne voit rien du tout dans ça.

Ben si, b et B apparaissent 2 fois, a et A apparaissent 4 fois, on en déduit immédiatement quels sont les plans clairs et quels sont les plans foncés (en fait le raisonnement est un petit plus subtil que ça si on veut être correct même dans le cas où un certain buffer {clair+foncé} est utilisé nettement moins souvent qu'un autre : il faut alors quotienter le temps par les classes d'équivalences modulo 3, et dans ce cas-là on aura deux classes où il n'y aura que des plans foncés, et une classe où il n'y aura que des plans clairs)

Il faut bien voir que le seul problème, c'est de déterminer quand on change de buffer, pas le poids des plans individuels. Et pour déterminer quand on change de buffer, il faut impérativement l'aide de la lib graphique puisque les deux cas pathologiques dont je parlais avant sont *mathématiquement* indistinguables l'un de l'autre avec la seule donnée des adresses/contenus des plans...
    
./Post n°54   Marquer comme non lu.
Kevin Kofler Ecrit le: Dimanche 22 janvier 2006 à 19:53 Déconnecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


Pollux :
Kevin Kofler :
Tes 2 séquences ne sont pas le plus grand problème, ça permet de voir au moins quels sont les plans clairs et quels sont les plans foncés. Le problème, c'est plutôt des trucs comme ça:
AaBaAbAaBaAb...
On ne voit rien du tout dans ça.

Ben si, b et B apparaissent 2 fois, a et A apparaissent 4 fois, on en déduit immédiatement quels sont les plans clairs et quels sont les plans foncés (en fait le raisonnement est un petit plus subtil que ça si on veut être correct même dans le cas où un certain buffer {clair+foncé} est utilisé nettement moins souvent qu'un autre : il faut alors quotienter le temps par les classes d'équivalences modulo 3, et dans ce cas-là on aura deux classes où il n'y aura que des plans foncés, et une classe où il n'y aura que des plans clairs)

Si tu as AABAABaab, B et a apparaissent le même nombre de fois, donc ton algo foire.

Bref, GrayWaitNSwitches(3); rulez. :p
Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!
    
./Post n°55   Marquer comme non lu.
RHJPP Ecrit le: Dimanche 22 janvier 2006 à 20:50 Déconnecté(e)    Voir le profil de RHJPP Envoyer un email à RHJPP Envoyer un message privé à RHJPP  


Et si on utilise une autre technique : on sauvegarde les n derniers plans avec n=nombre de trames par image.

Ensuite, on fait une addition pour chaque pixel des n plans et on obtient les niveaux de gris (de 0 pour blanc à n pour noir).
    
./Post n°56   Marquer comme non lu.
Kevin Kofler Ecrit le: Dimanche 22 janvier 2006 à 21:58 Déconnecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


Ça ne va pas marcher parce que les temps d'exposition entrent aussi en jeu. On connaît seulement:
  • sur HW1, un relevé périodique de quel est le plan courant (on pourrait aussi intercepter les écritures dans le registre contenant l'adresse à lire, ça nous mènerait au même cas que pour les HW2)
  • sur HW2, les changements de plan (recopie)
Sur HW2 au moins, on ne peut donc pas distinguer les plans clairs des plans foncés sans connaître les temps d'exposition. Or, les changements de buffer trop rapides en double buffering font justement foirer cette mesure des temps d'exposition, donc inversion occasionnelle des 2 plans, d'où les clignotements que vous voyez.
Ton idée est l'idée de base de laquelle on est partie et qui a abouti à ce qu'on a maintenant.
-Edité le Dimanche 22 janvier 2006 à 21:59 par Kevin Kofler-
Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!
    
./Post n°57   Marquer comme non lu.
Pollux Ecrit le: Dimanche 22 janvier 2006 à 23:57 Déconnecté(e)    Voir le profil de Pollux Envoyer un email à Pollux Envoyer un message privé à Pollux  

Kevin Kofler :
Pollux :
Kevin Kofler :
Tes 2 séquences ne sont pas le plus grand problème, ça permet de voir au moins quels sont les plans clairs et quels sont les plans foncés. Le problème, c'est plutôt des trucs comme ça:
AaBaAbAaBaAb...
On ne voit rien du tout dans ça.

Ben si, b et B apparaissent 2 fois, a et A apparaissent 4 fois, on en déduit immédiatement quels sont les plans clairs et quels sont les plans foncés (en fait le raisonnement est un petit plus subtil que ça si on veut être correct même dans le cas où un certain buffer {clair+foncé} est utilisé nettement moins souvent qu'un autre : il faut alors quotienter le temps par les classes d'équivalences modulo 3, et dans ce cas-là on aura deux classes où il n'y aura que des plans foncés, et une classe où il n'y aura que des plans clairs)

Si tu as AABAABaab, B et a apparaissent le même nombre de fois, donc ton algo foire.

Non, tu n'as pas lu ma parenthèse, mais maintenant tu as gagné le droit de la lire ^^
-Edité le Dimanche 22 janvier 2006 à 23:58 par Pollux-
    
  :: Index » Forum Ti68K » News » Nostub rulezzzzzzzzzz (65 réponse(s))
Pages : 3/4     « 1 2 [3] 4 » »|

.Répondre à ce sujet
Les boutons de code
[B]old[I]talic[U]nderline[S]trikethrough[L]ine Flip Hori[Z]ontallyFlip [V]erticallySha[D]ow[G]low[S]poilerCode [G][C]ite
Bullet [L]istList Item [K] Link [H][E]mail[P]icture SmileysHelp
Couleurs :
Saisissez votre message
Activer les smileys
     

Forum de Ti-Gen v3.0 Copyright ©2004 by Geoffrey ANNEHEIM
Webmaster: Kevin KOFLER, Content Admins: list, Server Admins: Tyler CASSIDY and Kevin KOFLER, DNS Admin: squalyl
Page générée en 60.17ms avec 18 requetes