Kevin Kofler
:

Pollux
: Oui, c'est pour ça que je trouve qu'Extgraph est "trop flexible" actuellement. De même que pour les sprites, on doit spécifier l'adresse des plans séparément... C'est un peu bête, parce que les routines ne sont pas assez flexibles pour permettre autre chose que deux plans totalement séparés, donc il n'y a grosso modo que trois possibilités : plan fort puis plan faible, ou bien plan faible puis plan fort (et àmha, c'est un peu dommage de pas standardiser ça, parce que ça peut être source d'incompatibilités), ou bien deux sources de sprites séparées (ce qui est largement la solution la moins efficace au niveau temps de calcul, et au niveau maintenabilité).

N'oublie pas qu'on peut utiliser ces routines avec ou sans double-buffering, ce qui fait déjà 2 méthodes différentes d'obtenir les plans. Et puis on peut utiliser ExtGraph avec n'importe quelles routines de gris. Si PpHd veut les utiliser avec graphlib, par exemple, il peut.

Ouah C'est vraiment _vachement_ utile
Tu crois qu'il y a ne serait-ce qu'une personne qui va utiliser sa propre routine de gris et pas Gray* ?

(Gray* ne désignant pas forcément TIGCCLIB, hein )

Tant que j'y suis dans les suggestions, ça pourrait être une bonne idée de se restreindre aux hauteurs multiples de 2, ou plutôt 4

Quel intérêt? Si c'est pour dérouler, va chercher "Duff's Device" sur le web. C'est bizarre en C, mais tout à fait naturel en assembleur.

Euh, tu as suivi la discussion? Ce qu'on se disait, c'est que justement ça permet d'éviter ça...
(et oui, je sais ce que c'est, va voir ma routine de memcpy pour t'en convaincre mais je ne connaissais pas le terme)

Sasume
: Pour ce qui est du format de sprite, on a effectivement l'intention d'écrire des fonctions qui gèrent des sprites dont les deux plans sont à la suite.

Sans intérêt (ou presque)! Votre target primaire (TIGCCLIB) ne le supporte pas et ne le supportera jamais. (J'ai rejeté toute suggestion à cette fin et je continuerai à le faire.) Donc si vous le faites, ça sera utile pour des targets secondaires seulement. Et en plus, vous encouragez à travers ça les programmes compatibles HW2 seulement (parce qu'il se trouve que l'implémentation actuelle de TIGCCLIB vérifie ces conditions si et seulement si on est sur HW2; mais elles ne sont garanties pour aucune version matérielle!).

Extgraph peut parfaitement overrider les définitions de TIGCCLIB en ce qui concerne les grays...

Pour ce qui est de restreindre la taille des sprites à un multiple de 2, j'en ai déjà parlé à XDanger, mais il n'est pas très chaud...

Je suis aussi contre, c'est stupide. Vous n'allez quand-même pas jeter á la poubelle toute la flexibilité qui a rendu votre librairie ce qu'elle est maintenant!

C'est vrai que ça gagne une place folle et que c'est significativement plus flexible d'avoir des sprites de hauteur 15 et pas 16

(pour ce qui est des risques d'erreur, un

#define _COND_FATAL(x,s) ((x)?({ST_helpMsg(s);_exit(0);}):0)
#define MySprite(x,y,h,s) ((__builtin_constant_p(h)?_COND_FATAL((h)&3,#h" is not multiple of 4"):0),_MySprite(x,y,h,s))

devrait suffire dans pas mal de cas...)