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

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.
Mais le problème, c'est que la lib atteint une taille monstrueuse.
Enfin, ce n'est pas vraiment un problème, mais ça me rebute. Et puis pour maintenir la lib, c'est assez galère.
Par exemple, si je trouve une optimisation sur la façon dont on affiche nos sprites clippés, je dois modifier une 40aine de fonctions...

Oui, perso ça me ferait affreusement chier En plus, pas question d'en faire une version compatible on-calc (j'ai déjà fait une version "allégée" d'une version assez vieille, et elle était déjà très lourde; je ne pense pas que ça soit possible avec les dernières versions...)
A votre place, je ferais du code auto-modifiant pour pas avoir à me trimballer toutes les fonctions AND, XOR & co (et, à la rigueur, tout supprimer pour ne garder que OR+AND+XOR pour le noir & blanc, MASK et BLIT pour les grays). Et puis ne plus supporter que Sprite8/Sprite16/SpriteNx16... (on peut passer de 8 à 16 par un simple patch) Bien sûr, ça demande un changement de l'API...

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...

arf, l'éternel pb...

Moi perso, je pense que c'est un bon choix. Ça permet quand même une certaine flexibilité à l'utilisateur. Au fait, cette restriction permet de dérouler la boucle interne d'affichage du sprite sans ajouter de code compliqué au début pour vérifier la parité de la hauteur du sprite. C'est bien pour ça que tu me le suggérais ou bien ça permet d'autres optimisations auxuqelles je n'ai pas pensé ?

Oui, c'est bien pour ça. Je ne vois pas trop ce que ça permettrait d'autre. A noter quand même que ça risque de poser des pbs avec le clipping vertical, parce que lui, il a lieu où il veut
Et en plus, ça sensibilise l'utilisateur de la lib au fait que les puissances de 2 (ou à la rigueur puissance de 2 fois 3), c'est Bien, alors autant en profiter

Ah oui, ça me paraît bien difficile de faire un portage pour GTC.

Pour le clipping vertical avec les sprites dont la hauteur est multiple de 2, il faut faire un petit bout de code pour prendre en compte ce cas particulier et brancher au milieu de la boucle si nécessaire, ce n'est pas super gênant, ça permet quand même d'avoir des bonnes performances pour le cas général (qui est bien plus fréquent que le cas où le sprite est partiellement visible)

Oui (mais le cas où le sprite est partiellement visible n'est qd même pas _si_ rare que ça [une chance sur 3], même si ça dépend évidemment des cas)

Une chance sur 3 ?
1 sur 6 plutôt (et sur TI-89, même)

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.

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.

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!).

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!

Pollux
: A votre place, je ferais du code auto-modifiant pour pas avoir à me trimballer toutes les fonctions AND, XOR & co (et, à la rigueur, tout supprimer pour ne garder que OR+AND+XOR pour le noir & blanc, MASK et BLIT pour les grays). Et puis ne plus supporter que Sprite8/Sprite16/SpriteNx16... (on peut passer de 8 à 16 par un simple patch) Bien sûr, ça demande un changement de l'API...

Mais j'ai peur que le linking conditionnel à l'utilisation réelle va en souffrir. Comme Sasume l'a déjà dit, le code auto-modifiant et les librairies statiques ne vont pas bien ensemble. Et puis ça sera aussi un problème pour l'intégration à TIGCCLIB, parce que Zeljko veut le moins de code automodifiant possible (il trouve que c'est sale, et il n'a pas tout à fait tort). (Cela dit, j'ai déjà réussi à faire rentrer plusieurs fonctions automodifiantes sans me faire attraper. Heureusement que Zeljko a autre chose à faire que contrôler tous les ajouts à TIGCCLIB, sinon il m'aurait déjà gueulé dessus. )

Et en plus, ça sensibilise l'utilisateur de la lib au fait que les puissances de 2 (ou à la rigueur puissance de 2 fois 3), c'est Bien, alors autant en profiter

L'utilisateur utilise ce qu'il veut! C'est ça le but d'une librairie flexible: c'est à la librairie de s'adapter à son utilisateur, pas l'inverse!

Un mask ça suffit (attention avis d'un pro là qui utilise ExtGraph depuis trois jours )

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...)

Kevin Kofler :
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.

Oui, c'est un très bon avantage d'extgraph.

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.

Oui, mais de restreindre la hauteur des sprites à un multiple de 2 permet de ne pas avoir à se soucier si on doit brancher au milieu de la boucle ou non, ce qui permet d'avoir des fonctions plus rapides et plus petites.
Et quant au fait que ça restreint la hauteur des sprites, je trouve que ce n'est pas trop méchant comme restriction, je suis quasiment sûr que la plupart des programmes actuels utilisent déjà des sprites dont la hauteur est paire.
Au niveau des performances, j'avais fait des tests, et en déroulant la boucle sans restriction sur la hauteur des sprites, la fonction était 6% plus rapide et prenait 20 octets de plus. Avec la restriction, la fonction devient 8% plus rapide, avec seulement 10 octets en plus. Ça vaut le coup à mon avis.
Couplé à une seconde boucle selon que le shift est >7, ça parmet d'accélérer de 15% au total.

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!).

Je parlais des deux plans des sprites à la suite.
Ça aurait deux avantages indéniables : moins de paramètres à passer à la fonction => plus rapide, plus court ; moins de registres à cloberrer => plus rapide (et peut-être plus court).

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!

Il est évident que si on fait ça, on gardera quand même les anciennes fonctions. Ça nous permettra de garder notre belle flexibilité qui rend la librairie impossible à maintenir
Il faut trouver une limite entre respecter tous les désirs possibles des utilisateurs, et imposer ses propres contraintes pour accélérer la lib.

Pollux
:

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...

Non, elle ne peut pas. Surtout si elle veut être acceptée dans TIGCCLIB dans le futur.

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

J'utilise des sprites de hauteur 15 (entre autres, il y a aussi par exemple 9 et 42) dans Backgammon. (La largeur est aussi arbitraire, mais je padde avec des transparences pour avoir des largeurs multiples de 8.) Donc ça existe bien en pratique!

(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...)

C'est nul. Et rajouter cela aux routines existantes serait est un changement incompatible, donc complètement hors de place pour ExtGraph! Heureusement que Sasume veut garder les "anciennes" routines...

Kevin Kofler
:

Pollux
:

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...

Non, elle ne peut pas. Surtout si elle veut être acceptée dans TIGCCLIB dans le futur.

Les "pressions" (re-)commencent

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

J'utilise des sprites de hauteur 15 (entre autres, il y a aussi par exemple 9 et 42) dans Backgammon. (La largeur est aussi arbitraire, mais je padde avec des transparences pour avoir des largeurs multiples de 8.) Donc ça existe bien en pratique!

Et ça te ferait perdre bcp de mémoire d'avoir une hauteur de 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...)

C'est nul. Et rajouter cela aux routines existantes serait est un changement incompatible, donc complètement hors de place pour ExtGraph! Heureusement que Sasume veut garder les "anciennes" routines...

Je ne parle pas de le rajouter "silencieusement", évidemment. Mais ça permettrait de gagner en vitesse.

Pollux
: Et ça te ferait perdre bcp de mémoire d'avoir une hauteur de 16?

Oui, surtout parce que ma routine, comme toute routine de sprites bien codée sur TI-89/92+/V200, s'en contrefiche de ce que la hauteur soit paire ou impaire. Je ne déroule pas mes boucles parce que c'est un gaspillage de taille.

...

Ça permet d'accélérer une routine que tu as des chances d'appeler plus de 1200 fois par seconde. La routine prend environ 350 octets (affichage en nvg de sprite clippé avec déroulage et 2 boucles différentes selon le shift), elle n'est copiée qu'une fois dans le prog.
Je pense que ça peut être intéressant à ce niveau de perdre une cinquantaine d'octets pour obtenir un affichage plus fluide...

./98.1: Oue moi.

Ben c pas compliqué de la faire utiliser 2 plans consécutifs, non? De toute façon tu es déjà obligé d'utiliser toutes les mêmes var internes que gray.s... Et puis ça fait gagner de la place sur la routine, en plus

Cela dit le vrai pb est la faisabilité au niveau d'Extgraph, puisque comme je l'ai déjà dit on pourrait pas réimplémenter les anciennes fonctions avec les nouvelles. Donc ça m'a l'air difficile à adopter, à moins de faire en parallèle une version refaite à partir de zéro.