Grib - Page 6

Ben, je pense que ce sera surtout lancer les programmes de test, le mieux étant de le faire sous différents types de lumière: naturelle, lampe à incandescence, tube fluorescent.

hibou> J'aimerais bien que tu testes les deux programmes de démo : demo1 et demo2 (surtout le 2).
Merci si tu peux faire ça, ça m'aidera baucoup.
Essaie de comparer avec les nvg de tigcclib, pour voir si ceux de grib ne sont pas moins beaux.

Pour information (mais je souhaiterais que le topic ne dévie pas):
http://tigen.org/pws/forum/index.php?action=sujet&forum=5&cat=10&topic=1926&page=3&p=53#53

KK inside
tigcclib va bientot vous faire le cafe du matin. Italia of course. KK. tu connais mon mail.

Une optimisation tout à fait mineure que j'ai vue hier soir: dans allocplanes.s, en utilisant a0 ou a1 au lieu de a3 pour stocker l'adresse du ROM_CALL, on peut ne pas utiliser a3, et donc ne pas le sauvegarder/restaurer.

Une autre optimisation, qui gagne 2 octets sur la routine mais consomme 8 octets de RAM en plus (!), toujours dans allocplanes.s, est:
bsr GribIsHw1
pea.l (3840+8).w | Le deuxième est alloué sur le tas
move.b %d0,%d3 | isHw1
bne.s 0f
add.l #3840,(%a7) | Pour les HW2, les deux plans sont alloués sur le tas
->
bsr GribIsHw1
pea.l (3840+8).w | Le deuxième est alloué sur le tas
move.b %d0,%d3 | isHw1
bne.s 0f
lsl.w 2(%sp)

[EDIT: corrigé une erreur]

J'ai testé :
- demo1 : nickel
- demo2 : quelques trucs bizarres, je m'explique :
* Il y a quelques fois des clignotements, la fréquence de ces clignotements est différente à chaque lancement. Ces clignotements apparaissent périodiquement, et sont de 1 toutes les 2s environ. Donc c'est de l'ordre de l'imperfection, je trouve cela tout à fait acceptable, il faudrait qu'effectivement je compare aux routines TIGCCLIB.
* Bien plus gênant, ie bug : pour certains lancement seulement, un certain nombre de lignes horizontales sont moins rafraichies que d'autres : elles sont toutes dans le bas de l'écran : conséquence visuelle, léger clignotement constant dans cette partie de l'écran et les pavés gris clair sont encore plus clair, pour les gris foncé, je ne vois pas de conséquence visuelle.

Sasume :
Essaie de comparer avec les nvg de tigcclib, pour voir si ceux de grib ne sont pas moins beaux.

Désolé de faire la grosse feignasse, mais si tu pouvais directement me les compiler comme il faut

Je vais voir ça...
Si demo1 est triviale à convertir en TIGCCLIB, demo2 l'est beaucoup moins...

Encore mieux:
http://tigen.org/pws/forum/index.php?action=sujet&forum=5&cat=10&topic=1926&page=3&p=59#59

(put1 mais que
1 -> Kevin aille mourir
2 -> Tigen avec ces popups de merde aussi...)

Edite ça (solution 1) immédiatement ! On ne souhaite jamais ça à personne !

clair qu'on ne souhaite jamais ça à personne, mais je ne sais pas si ça vaut vraiment la peine d'un édit ^^

et c'est à prendre au sens figuré je pense, hein

oué aussi, c'est pour ça que je pense que ça ne vaut pas la peine d'un edit ^^

Pollux :
et c'est à prendre au sens figuré je pense, hein

#159: comme pollux le fait entendre c'est une facon de parler hein ^^ je lui souhaite pas de mourir quand meme

Pour flamer contre Kevin c'est pas les topics qui manquent, et sauf si Sasume pense que ça ne gêne pas trop dans son topic, j'aimerais autant que vous fassiez ça dans une catégorie plus dédiée.

Sinon, question à Sasume: penses-tu que Grib fonctionne sous Fargo ? (principaux problèmes: HW1, manque de certaines romcall) En effet le principal problème que j'ai rencontré en tentant de porter Seven Tiles vers Fargo venait des horribles macros du double buffering... (je ne parlerai pas des autres ici )

Evidemment que c'est à prendre au sens figuré - sauf qu'il est capable de l'interpréter au premier degré et de casser du sucre sur le dos de yAronet parce que ça n'est pas modéré...

Effectivement si ce que disent les modos n'est pas lu... J'ai pas été clair ? Si c'est le cas mmsg, sinon retour au sujet.

on s'en fout de ce qu'il interprète de travers, il est censé être banni, il a pas à lire ça, et même s'il le lisait il pourrait pas venir râler ici donc en fait on s'en fout ^^

(fin du HS j'espère )

EDIT : cross, dsl ximoon

Lionel Debroux :
Une optimisation tout à fait mineure que j'ai vue hier soir: dans allocplanes.s, en utilisant a0 ou a1 au lieu de a3 pour stocker l'adresse du ROM_CALL, on peut ne pas utiliser a3, et donc ne pas le sauvegarder/restaurer.

Ah, tu es sûr ? Je regarderai, mais il me semble que ce n'était pas possible parce que a0 et a1 sont utilisés pour stocker les adresses des planes. Cela dit, comme j'ai changé des trucs entre certaines versions peut-être que ça permet de nouvelles optimisations...

Lionel Debroux :
Une autre optimisation, qui gagne 2 octets sur la routine mais consomme 8 octets de RAM en plus [...]

Astucieux, merci. Je ne sais pas si je l'implémenterai parce que ça prend un peu plus de RAM... Enfin en même temps 8 octets ne sont pas grand chose.

hibou :
Désolé de faire la grosse feignasse, mais si tu pouvais directement me les compiler comme il faut

OK, mais c'est vrai que comme l'a dit Lionel, demo2 est un peu plus délicate à porter pour TIGCCLIB que demo1.
Et le vrai problème c'est que je n'ai plus le temps de m'en occuper, je pars demain matin (et ce soir je sors avec des potes).
Donc je pense que je m'occuperai de ça à mon retour (sauf si quelqu'un veut me relayer et le fait à ma place Lionel ?).

Ximoon :
Pour flamer contre Kevin c'est pas les topics qui manquent, et sauf si Sasume pense que ça ne gêne pas trop dans son topic, j'aimerais autant que vous fassiez ça dans une catégorie plus dédiée.

Moi aussi, ou mieux : ignorer Kevin.

Ximoon :
Sinon, question à Sasume: penses-tu que Grib fonctionne sous Fargo ?

Je n'ai pas testé, mais je ne vois pas ce qui pourrait poser problème. Je n'utilise aucune ROM_CALL, sauf pour la fonction GribOnAllocPlanes (l'équivalent de GrayOn de TIGCCLIB), où j'utilise HeapAllocHigh et HeapDeref.

Sasume :

Ximoon :
Sinon, question à Sasume: penses-tu que Grib fonctionne sous Fargo ?

Je n'ai pas testé, mais je ne vois pas ce qui pourrait poser problème. Je n'utilise aucune ROM_CALL, sauf pour la fonction GribOnAllocPlanes (l'équivalent de GrayOn de TIGCCLIB), où j'utilise HeapAllocHigh et HeapDeref.

Ok, je jetterai un oeil alors à l'occasion, j'avais de toutes façons déjà pas mal envie de passer à Grib pour Seven Tiles.

hibou :
* Il y a quelques fois des clignotements, la fréquence de ces clignotements est différente à chaque lancement. Ces clignotements apparaissent périodiquement, et sont de 1 toutes les 2s environ. Donc c'est de l'ordre de l'imperfection, je trouve cela tout à fait acceptable, il faudrait qu'effectivement je compare aux routines TIGCCLIB.

Bizarre, je ne vois pas trop d'où ça peut venir. Tu es sûr que ça ne le fait absolument pas avec demo1 ?

hibou :
* Bien plus gênant, ie bug : pour certains lancement seulement, un certain nombre de lignes horizontales sont moins rafraichies que d'autres : elles sont toutes dans le bas de l'écran : conséquence visuelle, léger clignotement constant dans cette partie de l'écran et les pavés gris clair sont encore plus clair, pour les gris foncé, je ne vois pas de conséquence visuelle.

J'ai l'impression que ça pourrait être la fonction de synchro qui ne fait pas bien son boulot...

Merci beaucoup d'avoir testé.
Je verrai sûrement tout ça à mon retour (enfin, de toute façon je pense que d'ici là Ximoon n'aura toujours pas retouché à Seven Tiles, donc ça ne l'amputera pas trop... ).
A bientôt.

C'est petit, mais tellement vrai... me donnerait presque envie de te donner tort, mais je ne pense pas que tu risques grand chose en fait

Sasume :
J'ai l'impression que ça pourrait être la fonction de synchro qui ne fait pas bien son boulot...

Juste un truc : hibou, est-ce que tu peux virer la ligne qui contient GribWaitToDraw(); dans le fichier demo2.c et lancer build.bat (j'espère que tu es sous win, j'avais la flemme de faire un makefile), puis retester ?
Ce serait vraiment sympa

Perso je vois pas l'interret de toujours inclure ton travail dans tigcc lib...
Si tu fais une bonne lib elle sera utilisée sinon non, pas besoin d'utiliser la methode tigcc pour imposer des routines.

Nan, l'idée c'est juste d'améliorer tigcclib. De toutes façons, avec Grib, le problème ne se pose plus, là ...

heu, ct pas une critique sur samsung mais sur tigcc (je previens parce que c pas evident apres relecture)

Sasume
:

hibou :
* Il y a quelques fois des clignotements, la fréquence de ces clignotements est différente à chaque lancement. Ces clignotements apparaissent périodiquement, et sont de 1 toutes les 2s environ. Donc c'est de l'ordre de l'imperfection, je trouve cela tout à fait acceptable, il faudrait qu'effectivement je compare aux routines TIGCCLIB.

Bizarre, je ne vois pas trop d'où ça peut venir. Tu es sûr que ça ne le fait absolument pas avec demo1 ?

Ce midi, j'ai fait les tests à la lumière naturelle.
La je viens de recommencer à lumière artificielle : en faisant vraiment vraiment attention, j'arrive à voir le clignotement du rafraichissement pour les deux démos pour les gris clair et un contraste pas trop élevé et la lampe directe dessus. Mais je ne vois pas les clignotements dont j'ai causé ce midi.
Pour la démo2, y'a toujours le deuxième problème.

Sasume :
Juste un truc : hibou, est-ce que tu peux virer la ligne qui contient GribWaitToDraw(); dans le fichier demo2.c et lancer build.bat (j'espère que tu es sous win, j'avais la flemme de faire un makefile), puis retester ?

nan, je suis essentiellement sous linux
mais de toute facon, mon tilp est cassé, donc faut de toute manière que je passe par win.

Ce serait vraiment sympa

d'accord, mais sans le bizoo hein, parce que moi... ca me branche pas trop

hum, c'est encore pire :/
avec GribWaitForDraw() y'a avait, pour certains lancement seulement les gris clair que se mettaient à clignoter dans un partie de l'écran.
sans, certains restent tout le temps gris clair, certains sont gris clair clignotant, et certains se mettent à clignoter à un certain endroit sur l'écran et reviennent à la normale à un autre. Et des gris clair et les gris clair clignotants pouvant se croiser.

Non non, c'est bien GribWaitToDraw.
Bon, en tout cas le fait que ce soit pire sans la synchro me rassure un peu...

hibou :
Ce midi, j'ai fait les tests à la lumière naturelle. La je viens de recommencer à lumière artificielle : en faisant vraiment vraiment attention, j'arrive à voir le clignotement du rafraichissement pour les deux démos

OK, si tu vois la même chose sur les deux demo, c'est que ce problème ne vient pas de ma gestion du double-buffering.
En revanche il reste l'autre problème
Je suis désolé, je ne verrai pas ça avant un bon bout de temps...
A+