Grib - Page 9

Non, je suis sur Paris :/
Dommage. Je vais essayer de continuer à debugger grâce à hibou...
D'ailleurs je ne comprends pas vraiment pourquoi la nouvelle version ne corrige que partiellement le problème (elle aurait pu le corriger complètement ou pas du tout, ça aurait simplifié les choses).

oui pour etre plus rapide il faut utiliser a7.

Une date de sortie pour ta lib Martial ??

Sasume :
Non, je suis sur Paris :/
Dommage. Je vais essayer de continuer à debugger grâce à hibou...
D'ailleurs je ne comprends pas vraiment pourquoi la nouvelle version ne corrige que partiellement le problème (elle aurait pu le corriger complètement ou pas du tout, ça aurait simplifié les choses).

ca ce trouve c'est mon optimisme qui fait que ca a "mieux" marché.

je ne pensais pas que les placebos marchaient aussi pour les beta-tests

Tu savais pas ? ben maintenant si

Martial: c'est toujours quand on est proche de la fin que quelque chose se passe (projet abandonné, tout es faux faut tout recommencer, etc...)

Une nouvelle RC vient de sortir : http://perso.wanadoo.fr/jackiechan68k/download/grib.zip
Changements :
- Correction de la routine de détection de HW
- Optimisation de la recopie de plans

Je ne pense pas que cette version résolve le problème des HW1, mais j'aimerais bien que ceux qui ont des HW1 testent tout de même pour m'indiquer s'ils constatent des changements.

Youpi un nouveau test pour les HW1 : http://sasume.free.fr/bordel/demo2.89z !

Je suis rentré depuis un mois (cf ./225)
Mais j'avais pas mal de trucs qui m'ont empêché de m'y remettre.

Bon, contrairement à ce que je disais en #183, et donc confirmant #186, le port brutal de Seven Tiles pour utiliser Grib plutôt que les fonctions de tigcclib permettent effectivement un gain d'environ 400 octets (6593->6177). J'avais bêtement oublié un _GrayIsRealHW2 qui faisait à lui tout seul la différence de 700 octets, allez savoir pourquoi. Peut-être que d'autres optimisations du code sont possibles à partir de là.
Je pense que je vais rester sur cette version, en ce qui me concerne, bon travail

J'ai pas trop suivi l'histoire, mais une intégration dans TIGCCLib serait possible/une bonne idée ?

Pour autant que je me souvienne, Kevin est plutôt contre
Rapide recherche, cf ici : http://www.tigen.org/pws/forum/index.php?action=sujet&forum=5&cat=10&topic=1926&page=3

Ok, dommage. Mais il a pas trop tord pour la compatibilité.

Bof, les APIs ne sont vraiment pas les mêmes. Et j'avoue que je n'ai pas tellement envie de wrapper mes fonctions pour fournir la même API que TIGCCLIB.

Mais là, j'aimerais vraiment régler le problème de synchronisation du double-buffering pour les HW1 (cf ./251)

Hmmm j'ai pas de hw1 avec câble juste là maintenant sous la main, je dois avoir ça à Paris, je verrai quand je rentrerai.
Là je veux juste dire que (comme c'était un peu prévisible ) ça marche pas sous Fargo, l'adresse de l'écran (dans GribOff) n'étant pas la même et la routine de détection du HW étant fausse. Bon à la fois c'est pas comme si ça avait été écrit pour, avec ton autorisation, je vais modifier un peu ça pour voir ce que ça donne (le portage vers Fargo en utilisant une compatibilité au niveau sources était un cauchemard avec les ngv et le double buffering de tigcc, ça devrait aller mieux là).

OK, tiens moi au courant de tes modifs, que je les merge avec la version "officielle"

Ou peut-on dl la dernière version ? (j'ai pas du tout suivi le topic)
J'ai juste trouvé une version datant du 29/09.

A propos, ce n'est pas écrit dans la doc pourquoi il faut utiliser:
GribMakePlanes(bloc + 2 * GRIB_BUFFER_SIZE,&display->plane0,&display->plane1);
plutôt que:
GribMakePlanes(bloc + GRIB_GRAY_BUFFER_SIZE,&display->plane0,&display->plane1);

Jyaif :
Ou peut-on dl la dernière version ? (j'ai pas du tout suivi le topic) J'ai juste trouvé une version datant du 29/09.

La dernière version est celle disponible sur mon site.

A propos, ce n'est pas écrit dans la doc pourquoi il faut utiliser:
GribMakePlanes(bloc + 2 * GRIB_BUFFER_SIZE,&display->plane0,&display->plane1);
plutôt que: GribMakePlanes(bloc + GRIB_GRAY_BUFFER_SIZE,&display->plane0,&display->plane1);

Parce que
J'ai un peu la flemme d'expliquer, mais si tu veux vraiment savoir, regarde le code des macros.
Mais en fait j'avoue que cette macro (GribMakePlanes) n'est pas terrible. En fait, je voulais que le programmeur ne s'embête pas à calculer à la main les adresses de début des plans (qui doivent être des multiples de 8 sur HW1). Je pense que je trouverai une macro plus élégante pour la prochaine version.

j'ai pas le header sous la main, mais je suppose que:
2*GRIB_BUFFER_SIZE == 2*LCD_SIZE+2*8
tandis que: GRIB_GRAY_BUFFER_SIZE == 2*LCD_SIZE+8

Non, GRIB_BUFFER_SIZE = LCD_SIZE et GRIB_GRAY_BUFFER_SIZE = GRIB_BUFFER_SIZE * 2 + 8.
Après il y a GRIB_GRAY_DBUFFER_SIZE qui vaut GRIB_BUFFER_SIZE * 4 + 8.

Au fait, la doc est en ligne : http://perso.wanadoo.fr/jackiechan68k/doc/grib/

Oui, mais en C c'est moins agréable.

SAsume > tu fais aussi un Sudoku ???

Martial Demolins> Pourrais-tu m'envoyer par mail GFA Editor.

anoul :
SAsume > tu fais aussi un Sudoku ???

Non