Vous la voulez? - Page 3

TiMad >> y'aura t'il une fonction d'attente de pression de touche dans Xlib ??

ça serait fort utile, car lorsque qu'on a détourné l'AI1 et l'AI5, on n'utilise plus ngetchx(), et du coup on doit faire des routines foireuses à la main comme :

void presstou(void)
{
  unsigned long i;
  while(!(_89_KEY_ENTER))
  {
    i++;
  }
}

et c'est pas terrible si on attend vraiment trop, car i va devenir trop grand pour être sotcké sur 4 octets.

Bref, une touche bien foutu, qui attendrait la pression d'une touche (ou des touches "minimales" comme 2ND, ENTER, ESC, DIAMOND, et pavé directionnel) ça serait bien !!

Pim> il sert à quoi ton i ?
tu peux pas faire quelque chose de ce style :

while(!(_89_KEY_ENTER)); ?
en gros, une boucle qui fait rien...

sinon, pour attendre que n'importe laquelle des tocuhes soit pressées, il y a le rowread 0..
while(!_rowread(0));

errrff, ça existe _rowread(0) ???

ben je connaissais pas, merci !

neuroo: si tu veux qu'on la sorte un jour cette lib, il faudrai que l'on se voit un jour sur irc!!!!
parce que moi je part dans 2 jours...

oué ben ce soir car j'ai pas eut ton message a temps ....

Pim> de rien

Heu, alors, elle sort quand cette version de Xlib ??

Je suis rentrer plus tard que prevu de vacance pour cause (perso )
et je me remet au boulot pour la doc ce soir...

mes docs sont finies a l'instant TiMad

Bon j'ai presque terminé les fonctions.. me reste juste une question:
j'ai fait une routine de transparence avec la "couleur" blanche somme transparente.
Je pourais faire des routines pour la couleur Noir, est ce utile.
Je pourais faire aussi une routine pour les couleurs LG et DG, mais elles seraient plus lentes

NOIR, j'en vois pas trop l'interet mais LG oué ... (enfin .. ca parait la plus utilie apres le blanc)

sachant que c'est 1,7 Ko la routine en moyenne, je sais pas si c'est utile... ou alors ca sera pour ne plus enployer la fonction mask.

sans compter que je ne suis pas sur de pouvoir faire une routine L et D gray rapide..
car si LGray est transparent => white aussi
de meme pour dark... donc en fait ca doit se faire avec des cmp a la roulette , ce qui n'est pas derangeant sur les consoles, mais sur les ti si..

Au fait tu peux me passer le printf?

TiMad a écrit :
sans compter que je ne suis pas sur de pouvoir faire une routine L et D gray rapide.. car si LGray est transparent => white aussi

Au lieu de calculer le masque comme ça:
masque=~(plan_clair|plan_foncé);
c'est-à-dire:

 move.w %d0,%d2
 or.w %d1,%d2
 not.w %d2

tu le calcules comme ça:
masque=plan_clair&(~plan_foncé);
c'est-à-dire:

 move.w %d1,%d2
 not.w %d2
 and.w %d0,%d2

Je ne vois pas où est le problème. (C'est aussi valable pour PpHd et genlib d'ailleurs. )

Attention, il faut quand-même penser à ne pas afficher le gris clair lors du OR!

Pour éviter d'afficher le gris clair lors du OR, je propose de faire:
plan_clair&=plan_foncé
c'est-à-dire:
and.w %d1,%d0
après le calcul du masque et avant d'afficher plan_clair et plan_foncé sur l'écran.

Comme ça, on a:

* blanc:
plan_clair=0, plan_foncé=0.
Calcul du masque: masque=0&(~0)=0&1=0.
Correction du plan clair: plan_clair=0&0=0.
AND du masque sur le plan clair de l'écran: masqué_clair=orig_clair&0=0.
OR du plan clair du sprite sur le plan clair de l'écran: nouveau_clair=masqué_clair|plan_clair=0|0=0.
AND du masque sur le plan foncé de l'écran: masqué_foncé=orig_foncé&0=0.
OR du plan foncé du sprite sur le plan foncé de l'écran: nouveau_foncé=masqué_foncé|plan_foncé=0|0=0.
-> blanc

* gris clair:
plan_clair=1, plan_foncé=0.
Calcul du masque: masque=1&(~0)=1&1=1.
Correction du plan clair: plan_clair=1&0=0.
AND du masque sur le plan clair de l'écran: masqué_clair=orig_clair&1=orig_clair.
OR du plan clair du sprite sur le plan clair de l'écran: nouveau_clair=masqué_clair|plan_clair=orig_clair|0=orig_clair.
AND du masque sur le plan foncé de l'écran: masqué_foncé=orig_foncé&1=orig_foncé.
OR du plan foncé du sprite sur le plan foncé de l'écran: nouveau_foncé=masqué_foncé|plan_foncé=orig_foncé|1=orig_foncé.
-> transparent

* gris foncé:
plan_clair=0, plan_foncé=1.
Calcul du masque: masque=0&(~1)=0&0=0.
Correction du plan clair: plan_clair=0&1=0.
AND du masque sur le plan clair de l'écran: masqué_clair=orig_clair&0=0.
OR du plan clair du sprite sur le plan clair de l'écran: nouveau_clair=masqué_clair|plan_clair=0|0=0.
AND du masque sur le plan foncé de l'écran: masqué_foncé=orig_foncé&0=0.
OR du plan foncé du sprite sur le plan foncé de l'écran: nouveau_foncé=masqué_foncé|plan_foncé=0|1=1.
-> gris foncé

* noir:
plan_clair=1, plan_foncé=1.
Calcul du masque: masque=1&(~1)=1&0=0.
Correction du plan clair: plan_clair=1&1=1.
AND du masque sur le plan clair de l'écran: masqué_clair=orig_clair&0=0.
OR du plan clair du sprite sur le plan clair de l'écran: nouveau_clair=masqué_clair|plan_clair=0|1=1.
AND du masque sur le plan foncé de l'écran: masqué_foncé=orig_foncé&0=0.
OR du plan foncé du sprite sur le plan foncé de l'écran: nouveau_foncé=masqué_foncé|plan_foncé=0|1=1.
-> noir

Donc on est bien devant une routine qui affiche un sprite avec le gris clair transparent.

ma methode pour le blanc transparent:
move.w (%a1)+,%d0;
move.w (%a1)+,%d2;
not.w %d0;
not.w %d2;
and.w %d2,30*x(%a0);
and.w %d0,3840+30*x(%a0);
not.w %d0;
not.w %d2;
or.w %d0,30*x(%a0);
or.w %d2,3840+30*x(%a0);

a qqs petites modifs pres...

j'avais essayer en enleveant un not...
le probleme c'est que dans ce cas la, il y avait un probleme, car des que je faisait un shift, il apparaissait en Gris

Ceci etant dit je vais reflechir au probleme
merci

Exemple de probleme:

si on fait un shift du sprite (on est pas toujours en x%16=0):
le decalage est alors compté comme une couleur (ici blanc)
or si elle n'est pas transparente, cela impose qu'une trainé blanche se vera.

La solution serai alors de faire en plus sur le le point faible du sprite:
Pf|2^((shift)-1)
et alors la c'est posible car le decalage laisse un gris claire qui sera transparent...
Mais bon niveau cycle ca rajoute pas mal quand meme

TiMad a écrit :
ma methode pour le blanc transparent:
move.w (%a1)+,%d0;
move.w (%a1)+,%d2;
not.w %d0;
not.w %d2;
and.w %d2,30*x(%a0);
and.w %d0,3840+30*x(%a0);
not.w %d0;
not.w %d2;
or.w %d0,30*x(%a0);
or.w %d2,3840+30*x(%a0);

a qqs petites modifs pres...
j'avais essayer en enleveant un not...

Essaye ça:
move.w (%a1)+,%d0;
move.w (%a1)+,%d2;
not.w %d2;
and.w %d2,30*x(%a0);
and.w %d0,3840+30*x(%a0);
not.w %d2;
and.w %d2,%d0;
or.w %d0,30*x(%a0);
or.w %d2,3840+30*x(%a0);

TiMad a écrit :
Exemple de probleme:

si on fait un shift du sprite (on est pas toujours en x%16=0):
le decalage est alors compté comme une couleur (ici blanc)
or si elle n'est pas transparente, cela impose qu'une trainé blanche se vera.

La solution serai alors de faire en plus sur le le point faible du sprite:
Pf|2^((shift)-1)
et alors la c'est posible car le decalage laisse un gris claire qui sera transparent... Mais bon niveau cycle ca rajoute pas mal quand meme

Alternative: quand tu fais ton décalage du plan clair, par exemple:
lsl.l %d1,%d0
tu utilises ça à la place:
not.l %d0
rol.l %d1,%d0
not.l %d0

pourquoi rol!
lsl marcherais aussi bien!

quel est le nombre de shift du and.w?
and - 4/6(8) 8/12
ca ne me donne pas les dn,dn ?(

move.w (%a1)+,%d0;
move.w (%a1)+,%d2;
not.w %d2;
and.w %d2,30*x(%a0);
and.w %d0,3840+30*x(%a0);
not.w %d2;
and.w %d2,%d0;
or.w %d0,30*x(%a0);
or.w %d2,3840+30*x(%a0);


=>le gris transparent et le blanc => gris sur du noir.

a la limite, on peut mettre ca:
move.w (%a1)+,%d0;
move.w (%a1)+,%d2;
move.w %d0,%d3
not.w %d3
or.w %d2,%d3
not.w %d3
and.w %d3,30*0(%a0);
and.w %d3,3840+30*0(%a0);

ca donne du gris claire transparent.
et:
move.w (%a1)+,%d0;
move.w (%a1)+,%d2;
move.w %d2,%d3
not.w %d3
or.w %d0,%d3
not.w %d3
and.w %d3,30*0(%a0);
and.w %d3,3840+30*0(%a0);
ca donne du gris foncé transparent.
Mais bon niveau rapidité c'est pas le must quand il faudra en plus gere les shift!

bon le moyen le plus rapude que j'ai trouvé, c'est de faire les shift en 3 fois:
1 fois sur le mask (entre les 2 not apres le or.w) puis sur d0 et d1, mais ce sera toujours plus lent que la routine de transparence avec le blanc
Meme le noir et plus lent.

TiMad a écrit :
pourquoi rol! lsl marcherais aussi bien!

En fait, c'était totalement faux. C'est:
not.w %d0
lsl.l %d1,%d0
not.l %d0
qu'il faut mettre. Et là oui, on peut aussi mettre lsl et pas rol. Mon idée était qu'il fallait remplir avec des 1 et pas des 0 et donc qu'on ne pouvait pas utiliser lsl. Mais ce qui m'a complètement échappé est que je faisais 2 nots non seulement sur les données, mais aussi sur les pixels de remplissage, donc ça n'aurait pas marché. Là, je fais 2 nots sur les données et un seul sur les 0s de remplissage, donc c'est bon.

Ok, c'est lidee que j'ai repris pour faire les shifts (je le fait entre les 2 not apres le or...).

La beta, la beta, la beta !!!!!

m'enfin...
Pas de beta avant la gestion du double buf. toc

erf.
Combien de temps environs pour le double buffering ?

10 Minutes

Bon ce soir je la publie en version alpha, si j'ai le temps

la gestion est dialogues est faite ... enfin, la 1re version (sans les textures, pour ca, j'ai besoin de connaitres toutes les fonction de sprites )