Question à propos de votre utilisation d'extgraph - Page 1

En fait, ces questions s'adressent également aux personnes qui n'utilisent pas ExtGraph (heureusement, sinon je n'aurais aucune réponse ) :
En ce qui concerne les fonctions de sprites masqués en niveaux de gris, est-ce que vous utilisez deux masques différents ?
Et pour ceux qui utilisent des libs qui ne permettent qu'un seul masque pour les deux plans, est-ce que cela vous gêne parfois ? Avez vous rencontré des situations où cela s'est avéré handicapant ?

En gros, est-ce que c'est utile qu'on garde 1 masque par plan dans les fonctions masquées d'extgraph (lent mais flexible) ou bien peut-on n'utiliser qu'un seul masque pour les deux plans (rapide mais moins flexible) ?

Moi je suis pour un masque pour les 2 plans.

En ce qui concerne les fonctions de sprites masqués en niveaux de gris, est-ce que vous utilisez deux masques différents ?

un seul masque pour les deux plans.
Je n'ai jamais utilisé deux masks différents (et ça ne m'a jamais géné, que ce soit sous extgraph ou sous autre chose)

Sasume :
En fait, ces questions s'adressent également aux personnes qui n'utilisent pas ExtGraph (heureusement, sinon je n'aurais aucune réponse )

C'est extgraph que j'ai le plus utilisé, devant Genlib.
(Et extgraph marche au moins, y'a pas de pb d'alignement incompréhensible
qui baise les sprites )

En ce qui concerne les fonctions de sprites masqués en niveaux de gris, est-ce que vous utilisez deux masques différents ?

Quand j'y suis forcé, mais on remarque généralement qu'un seul est
nécessaire, donc en Basic, où j'ai le choix, j'en utilise qu'un.

Et pour ceux qui utilisent des libs qui ne permettent qu'un seul masque pour les deux plans, est-ce que cela vous gêne parfois ? Avez vous rencontré des situations où cela s'est avéré handicapant ?

Non. Remarque, je n'y ai pas énormément réfléchi, mais je n'arrive pas à
trouver une situation où 2 masques seraient nécessaires. (Peut-être pour
un effet jouant sur les plans pour donner une sorte de transparence, mais
ne s'appliquant pas à tout le sprite. Faut dire que c'est vachement spécialisé et
je pense qu'on peut faire ça autrement)

Alors avec geogeo, ça marche très bien avec un seul masque.

de pb d'alignement incompréhensible qui baise les sprites.

Forcement genlib est une librarie a caractere sexuelle, qui n'a qu'une envie, c'est de baiser les sprites qu'on lui offre en pature.

Merde, PpHd écoutait.

PpHd >
il faudrait écrire "Parental Advisory - Explicit Content" sur le zip de genlib alors

Sasume > 2 masques : je n'ai pas une grande experience sur le sujet, mais ça me parait plutot rare comme besoin.
(à la rigueur vu que c une bibliotheque statique, tu peux te permettre de laisser les deux possibilités)

Je ne connais aucune application ou utiliser 2 layers de masques differents n'induit pas d'erreur.

deja qu'un mask c bcp mais alors 2...

PpHd > ??? Ben le cas où on veut faire d'impressionnants effets spéciaux (à peine visible) cf mon premier post.

...
faut laisser cette feature ! c'est le seul point fort d'extgraph, la flexibilité

Je trouve le mot flexibilité très abusé.
ExtGraph n'est pas flexible, elle est simplement normale,
et les autres libs sont spécialisées (tout le monde ne veut pas faire des graphismes
en tiles, ou en format carré 16x16, 32x32 ou 8x8, moi je fais du 16x21)

Je trouve le mot flexibilité très abusé.

Si tu trouves que pouvoir faire des sprites en x*y avec x=un multiple de 8 et y=ce que tu veux et que les plans n'ont pas besoin d'être continus n'est pas flexible, franchement....

C'est normal. Je dit pas ça pour tailler, justement j'adore ExtGraph.
Et je trouve que certaines libs n'ont justement pas ça, et qu'elles devraient.

C'est ridicule de faire une fonction qui prend deux plans séparés, parce qu'à ce moment-là autant utiliser une routine noir&blanc deux fois (quitte à la dérouler...)

Et c'est vrai que si Extgraph arrive à se débarrasser de cette "flexibilité" (comprendre : absence de la vitesse ou de la mémoire en tant qu'objectif de conception des structures de données), elle aura fait un grand pas en avant

Et ça sera un clone de Genlib, Xlib ou GraphX. Sacré pas en avant.

Pollux :
Et c'est vrai que si Extgraph arrive à se débarrasser de cette "flexibilité" (comprendre : absence de la vitesse ou de la mémoire en tant qu'objectif de conception des structures de données), elle aura fait un grand pas en avant

On peut faire mieux : garder la flexibilité, mais proposer des fonctions "pas flexibles" et plus rapides en plus des fonctions flexibles.

Oui, de toute façon ça doit être possible d'utiliser une vieille version en plus de la nouvelle, non? Parce que ces fonctions "flexibles" sont qd même assez mal foutues (genre, les dscreens...) et ne devraient pas être utilisées dans un nouveau prog, si Extgraph se veut une lib correcte, maintenant. Mais on peut toujours utiliser les vieux .a en plus des nouveaux...

Non, car les fonctions ont le même nom d'une version à l'autre.
Mais dans la v2, on proposera des fonctions classiques assez petites en taille, et des fonctions plus rapides qui utiliseront des sprites entrelacés avec un seul mask pour les deux plans.

Ca ne me paraît pas suffisant pour en faire une librairie puissante Et en plus le nb de fonctions croît exponentiellement avec le nombre de releases... (mais comme le n° de release est une fonction logarithmique du temps, ça devrait passer )

ExtGraph ne peut pas supposer que les plans de gris se suivent parce que ce n'est pas le cas sous HW1 avec les routines de TIGCCLIB (optimisation consommation mémoire).

Elle le pourrait en modifiant les routines de TIGCCLib. Tout le monde s'en tape de 3 ko de RAM sur HW1 (bien entendu, on n'utiliserait cette routine que si on utilise les routines de sprites d'ExtGraph qui gèrent les DScreen), et en plus ça réduirait la taille en ROM de la routine de gris (donc aussi en RAM).


(enfin bon, moi je m'en fous si ExtGraph est moins efficace )

lol

BlueSilk: Genlib gere les 16x21 sans probleme

Avec un gros halo blanc autour du sprite qu'on ne peut pas supprimer et que tu as mis parce que ça t'arrangeait pour SMA...

Et pour Cf aussi

Ah oui, et ça arrive, les big sprites sans halo et les vrais masques pour les sprites? ^^

Donc, pas très "flexible"...
Et pour des sprites 16x21, je crois que je préfère encore faire ma
propre routine en assembleur. (Après avoir fait le prog une première
fois avec une lib comme ExtGraph)

Kevin Kofler :
ExtGraph ne peut pas supposer que les plans de gris se suivent parce que ce n'est pas le cas sous HW1 avec les routines de TIGCCLIB (optimisation consommation mémoire).

Deux objections:
1) Pourquoi continuer à s'emmerder avec le HW1 ? Si qqun a une HW1
de toute manière, si j'étais lui je resterais à graphlib et je ferais du
Gray7.

2) Pourquoi le supposer ? Une routine permettant d'allouer 7680 octets
sur le Heap, comme un DScreen de genlib, et puis c'est bon.
Et juste une routine, pas obligatoire comme gl_init(), comme ça
les fonctions graphiques peuvent rester compatibles avec PortSet.

oui mais toi tu es pas un modele a suivre