Optimisation taille des projets en plusieurs .c (switch ?) - Page 4

Kevin Kofler :

?

M. V. (parce que si je fait une faute d'orthographe je vais etre kick.. super raisonnement).

Vu que c'est systematique et que ça doit bien faire 10 posts que je te fais la remarque, là c'était la dernière. Et j'ai pas dit kick j'ai juste parlé de corriger ton post. Remarque si tu veux aussi un kick ça peut s'arranger sans trop de problèmes.

Tiens t'as plus répondu à la phrase que tu me repond pourtant dans chacun de tes posts, le "fais d'abord ce que j'ai fait et après on parlera"

D'ailleurs je conseille à TiMad d'éditer son post parceque j'ai cru y voir ladite faute

Ah oui exact. Bon bah j'avais prévenu cette fois.

le code de Xllib au niveau des routines de transparence est nikelle (les 4), meme si certains on des versions buguées, ce qui n'est pas le cas de tous.. et la simple raison pour laquelle je peux afficrmer cela sans savoir le code des routines, c'est que ca depend du format du sprite et qu'il faut un format different selon le type de transparence.. et Xlib ne le gere pas => n'utilise pas l'optimisation sur le XGTB.
Pour le reste la qualité du code asm de Xlib est je pense plus que bonne, il y a certe qqs petits details, mais ils sont negligeables... et je sais tres bien ce qui merite d'etre déroulé ou non tout comme les shifts qui meritent d'etre traité ou non d'ailleur sasume ne me croyait pas au debut et disait que ct un abus.. mais les futures version de Extgraphlib utilise quoi? ...

je pense que j'ai passé assez de temps sur les routines graphiques (preshifting/ semipreshifting/ routines crées en ram..) pour savoir ce qui est bon ou non...
pour ce qui est de la rapidité des routines en C, oui c'est possible mais certainement pas en déroullant... ya bcp d'autres methodes et d'ailleur je vais cesser de dires les methodes parce qu'apres on les repique et dit Xlib c'est de la merde.

Tiens en parlant de la transparence... (arrête-moi si je me trompe) J'étais en train de faire un convertisseur de sprites (original n'est-ce pas? ) alors je me suis renseigné sur les formats de ceux utilisés par XLib.... Si tu utilises des formats différents pour tes fonctions de transparence, pour moi ce ne sont plus des vrais fonctions de transparence car un même sprite ne peut plus être affiché indifféremment par chacune des routines... Donc forcément c'est plus rapide, mais il y a un abus de langage (ou de format ?) quelque part ...

JackosKing
: le code de Xllib au niveau des routines de transparence est nikelle (les 4), meme si certains on des versions buguées, ce qui n'est pas le cas de tous..

Alors il y a moyen d'avoir une fonction GTB qui marche ? Parceque j'ai du d/l toutes les versions dispo, et elle n'a jamais fonctionné.

et d'ailleur je vais cesser de dires les methodes parce qu'apres on les repique et dit Xlib c'est de la merde.

Ça fait plusieurs fois que tu répete ça. Tu pourrais aller citer le post stp ? Parceque selon mes souvenirs je n'ai jamais dit d'XLib "c'est de la merde"...

JackosKing
: tout comme les shifts qui meritent d'etre traité ou non sasume ne me croyait pas au debut et disait que ct un abus.. mais les futures version de Extgraphlib utilise quoi? ...

Ben, la version qui sera intégrée dans TIGCCLIB n'utilisera certainement pas ça. Si la version qu'on m'envoie pour l'intégration utilise ça, je la patcherai pour le virer.

Tu peux y voir un abus de langage si tu veux, le resultat etant que niveau rapidité, ya pas photo..

Oui mais quand tu dis à l'utilisateur que tu va lui faire tel transparence c'est complètement faux!

Kevin> C'est bien ça ton problème ... D'un côté du essaie d'argumenter en faveur de l'intégration de ext dans tigcclib et de l'autre tu veux bousiller le travail de ceux qui la développent... C'est petit...

Moi, je veux des routines qui remplissent certains critères. S'ils ne les remplissent pas, je compte les corriger pour que les critères soient remplis. Avoir une routine de taille multipliée par 2 pour gagner quelques cycles n'est pas conforme aux critères dont je parle (et ça fait longtemps que je vous dis ça).

Sauf que comme ce qui est (était?) prévu est de faire des fonctions normales non déroulées et des fonctions plus optimisées (en vitesse évidemment ce sont des routines graphiques...) à côté, je ne vois pas pourquoi tu te permettrais de priver l'utilisateur lambda de routines potentiellement plus performantes pour de futils motifs que tu es le seul à avoir, alors que c'est une lib statique... C'est purement égoïste de ta part.

Si vous voulez mettre des routines pessimisées (mais légèrement plus rapides) à part, c'est bon, à condition que les routines standard (de taille raisonnable) soient là.

Tu n'as toujours pas compris... "Pessimisé" selon toi, et toi seul! On parle de routines graphiques bon sang! Dans ce cas si c'est vraiment une pessimisation, pourquoi inclure ça à tigcclib, puisque de toutes façons intégrer l'une de ces routines prendra toujours plus de place que l'appel à la rommcall correspondante? Tu n'est pas cohérent Kevin...

N'oublie pas que la ROM_CALL doit être appelée 2 fois pour chaque plan (une fois pour le masque et une fois pour le sprite), avec en plus les PortSet. Je pense qu'une routine de sprites masqués en gris bien optimisée en taille peut donner quelque chose de plus petit.
Et puis BitmapPut est beaucoup trop lent pour une animation rapide (mais pas pour afficher juste une image statique!). Aucun rapport avec les quelques cycles de différence que donne le shifting dans les 2 sens.

"quelques cycles"? Ah nan désolé on peut gagner*un peu plus* que ça.
Sinon pourquoi ne pas faire une fonction qui appelle justement la romcall sur les deux plans? On gagne en place, on perd en vitesse, ça devrait te convenir?

Compare la taille de la routine de sprites gris masqués avec la taille de 6 appels de ROM_CALLs (même par ligne F). Je ne suis pas sûr que les ROM_CALLs prennent vraiment moins de place dans ce cas particulier. Même pour des sprites non masqués (les icônes des commentaires _nostub), j'ai été obligé de faire (je n'ai pas utilisé la ligne F parce que c'est dans une librairie statique):

 pea.l (%a2) |save %a2
 move.w #1,-(%a7) |attr=A_NORMAL for DrawIcon
 pea.l (%a1) |icon for DrawIcon
 move.l 14(%a7),-(%a7) |x and y for DrawIcon
 pea.l 0xEF007F:l |239,127 for PortSet
 move.l 30(%a7),-(%a7) |plane for PortSet
 move.w #1,-(%a7) |attr=A_NORMAL for DrawIcon
 pea.l (%a0) |icon for DrawIcon
 move.l 32(%a7),-(%a7) |x and y for DrawIcon
 pea.l 0xEF007F:l |239,127 for PortSet
 move.l 44(%a7),-(%a7) |plane for PortSet
 movea.l 0xc8:w,%a2
 movea.l PortSet*4(%a2),%a0
 jsr (%a0)
 addq.l #8,%a7 |pop PortSet arguments
 movea.l DrawIcon*4(%a2),%a0
 jsr (%a0)
 lea.l 10(%a7),%a7 |pop DrawIcon arguments
 movea.l PortSet*4(%a2),%a0
 jsr (%a0)
 addq.l #8,%a7 |pop PortSet arguments
 movea.l DrawIcon*4(%a2),%a0
 jsr (%a0)
 lea.l 10(%a7),%a7 |pop DrawIcon arguments
 movea.l (%a7)+,%a2 |restore %a2

(et encore, c'est avec DrawIcon; pour du 32×32, c'est raté... un appel à BitmapPut prend encore plus de place)

Nous sommes donc d'accord: à la place d'intégrer ext à tigcclib, tu n'as qu'à écrire des fonctions qui appellent les rommcals, donc on appelle la fonction qui appelle la romcall qui font (lentement) le travail... Donc gain de place, perte de vitesse, et un "©Kevin Kofler" dans la doc, que demandes-tu de plus ?

Ximoon
: Nous sommes donc d'accord: à la place d'intégrer ext à tigcclib, tu n'as qu'à écrire des fonctions qui appellent les rommcals, donc on appelle la fonction qui appelle la romcall qui font (lentement) le travail... Donc gain de place,

As-tu lu ce que j'ai mis???
L'appel des ROM_CALLs prend vraisemblablement plus de place que la routine de sprites optimisée en taille... (Je pourrais me tromper, évidemment, mais je suis sceptique.) Le fait de mettre ces appels dans une fonction plutôt qu'inline ne change rien à ce fait.

Faut dire qu'on peut encore l'optimiser en taille ta routine, pas de beaucoup peut-êter mais on peut (ah zut ça risque de l'accélérer j'ai rien dit)

En effet, je me suis rendu compte en la postant que le deuxième pea.l 0xEF007F:l pourrait être remplacé par un move.l offset(%a7),-(%a7).

c'est des petites merdes dans certaines routines d'XLib.. (ya pas que ca.. mais je dout qu'il y a bcp de personne pour les remarquer..

Là par contre ça me fait franchement rigoler... Si pour toi gagner 8 cycles par ligne (pour le add.w, je ne parle pas des lea multiples qui font aussi perdre presque 4 cycles) c'est négligeable alors ne déroule pas tes boucles, comme ça plus personne ne te fera chier là-dessus... Dérouler ta boucle seulement 2 fois te fera perdre 2.5 cycles par ligne et gagner une place folle