jackiechan: OK. Il n'en reste pas moins que je pense que ça n'est pas la peine de le faire pour une routine générale (ou alors proposer deux versions, une petite et plus lente, et une plus rapide mais beaucoup plus grosse - ce que je pense qu'on va faire dans ExtGraph pour certains types de routines, car ni Kevin ni Tom n'ont vraiment hurlé, il faut que je redemande confirmation, je demanderai en même temps pour le format de sprite optimisé)...
euh ouais, mais il y a déjà pas mal de fonction à écrire comme ça...
Ah, non, il est absolument hors de question d'écrire des versions optimisées vitesse mais très grosses de toutes les routines !
Les GraySprite16 en __regparm__, ça devrait suffire, non ? D'après ce que je peux voir, ce genre de trucs est surtout utilisé pour des Sprite16 en grayscale, et là, le mode __stkparm__ n'a aucun intérêt car il donnera une routine plus lente et plus grosse...
OK, ben j'ai déjà fait tous les GraySprite16 en __regparm__, les versions clippées, avec tous les modes possibles.
Faudrait que je fasse les 32 et les 8... mais bon, j'ai un peu la flemme...
Au fait, Ximoon m'a envoyé ses SpriteX8_OR/XOR/AND
OK. Merci à Ximoon et à toi.
Il n'est pas du tout prioritaire de réécrire les GraySprite32 / 8. Mieux vaut d'abord:
* finir toutes les routines de sprite B/W en __stkparm__ et en __regparm__, clippées ou pas (pour autant qu'il me semble, c'est fait ?).
* des routines additionnelles B/W (lignes - c'est à peu près fait, rectangle plein - je m'en charge, rectangle vide - je m'en charge).
* finir les GraySprite16 (c'est fait, et il n'y a pas besoin de __stkparm__ pour les versions clippées: pas de compatibilité antérieure à maintenir).
* faire des GraySprite16 avec format de sprite optimisé (il me semble que tu en as fait pour geogeo ou d'autres).
* intégrer les SpriteX8 de Ximoon + réécrire les SpriteX8 qui manquent (ça, je peux a priori le faire, il faut que j'apprenne comment on fait la transparence):
- MASK et Get, il y en a besoin dans la démo n°6.
- BLIT qui est une MASK avec le même masque pour toutes les lignes, c'est facile une fois qu'on a la MASK.
- TRAN.
* faire les versions __regparm__ d'un certain nombre de routines qui sont en __stkparm__ uniquement actuellement.
* Eventuellement, une ou deux lignes de la todo list, notamment "FastCopyGrayScreen (one line of plane 0, one line of plane 1, ...)" - je peux le faire.
Quand on aura fait ça, ça sera déjà très bien, et on pourra songer à une bêta de la 2.00. Il faudra bien entendu updater auparavant les exemples (et peut-être en faire de nouveaux, y a-t-il des idées) et la documentation. Il est probable que TIGCC 0.95 Beta 1 arrive avant, mais on se basera uniquement sur la release de 0.94, comme d'habitude)...
OK. Je vais voir ce qu'il reste à faire pour boucler toutes les fonctions B/W.
Si tu veux, j'ai écrit une fonction de ligne très rapide, mais il serait compliqué de lui faire supporter tous les modes d'affichage.
> Si tu veux, j'ai écrit une fonction de ligne très rapide, mais il serait compliqué de lui faire supporter tous les modes d'affichage.
Dommage... C'est une fonction générale de dessin de lignes ?
oui, et elle est plus rapide que celle d'extended
Enfin, je pourrais rajouter le support de tous les modes, mais ça impliquerait pas mal de changements entre chaque mode (surtout pour le mode reverse en fait).
En effet, le mode A_REVERSE est différent des autres, il n'y a pas le même nombre d'instructions... Mettre des nop est stupide...
Non, je ne crois pas qu'il y aurait un nombre d'instructions différent, mais beaucoup de changements seulement.
Enfin, je peux le tenter, si tu veux.
Par contre, les lignes ne sont pas exactement les mêmes qu'avec AMS... (mais personnellement, je ne trouve pas ça hyper important...)
Si le nombre d'instructions n'est pas différent, ça n'est pas du segmenté, donc ?
Peux-tu me l'envoyer, s'il te plaît ?
Non, ce n'est pas du segmenté.
Je pense que le segmenté n'est pas adapté pour les TI-68k.
Je te l'envoie tout de suite.
de totue maniere c'et pas la tict team qui va nous apprendre a programmer des troutines graphique ...
2 remarques en retard:
1°/ Pourquoi garder (et réecrire) des routines avec les arguments sur la stack? c'est juste pour la compatibilité ou ça présente un interêt par rapport à dans les registres?
2°/ Kevin (membre de la TIGCC Team) à contesté le remplacement de mulu 30,x par quatres instructions. Je signalerais juste que dans les progs compilés du C avec TIGCC (.94 et les options par défaults), toute multiplication par 30 se fait de la sorte!
Seb C bien
C bien, C beau, C ni Bosch ni Bush: C ++
1- Oui, c'est pour la compatibilité
1°: Les routines __stkparm__, c'est surtout pour la compatibilité ascendante.
2°: Oui, mais il n'en reste pas moins que c'est plus lent que la suite de quatre instructions, même si ça fait 4 octets de moins. 4 octets n'est pas grand chose dans un programme, même multiplié par 100 routines qui utilisent cette optimisation...
JackosKing, "De toute manière c'est pas la TICT qui va nous apprendre a programmer des routines graphiques ..." (nombreuses fautes corrigées, notamment "tict team", complètement stupide, comme le post lui-même d'ailleurs)
On verra bien...
ExtGraph est open-source, ne fait pas n'importe quoi avec les routines de gray de TIGCC, est plus flexible (hauteur variable, pas besoin de mettre et enlever un environnement).
Je me suis mal exprimé dans le #43,2°, "de la sorte" faisait réference à la suite de quatres instructions
Seb C bien
C bien, C beau, C ni Bosch ni Bush: C ++
Ah, d'accord.
Oui, c'est vrai, ça me revient maintenant: Kevin avait dit qu'à son avis, GCC devrait générer un mulu, au moins en mode -Os, ce qu'il ne fait pas (du moins ne faisait pas à l'époque où il en avait parlé).
Comme j'ai déjà dit, 4 octets est peu... c'est moins que la place perdue par d'autres choses de toute façon.
Notamment, n'y a-t-il pas moyen de faire comprendre à GCC qu'un tableau fait moins de 32767 octets, et qu'il n'est donc pas nécessaire qu'il génère une grosse séquence d'instructions ? Un exemple typique est HeapDeref d'AMS 2.xx (ce que TIFS et TIGCC font), à comparer avec HeapDeref d'AMS 1.xx (ce qu'il serait possible et parfaitement sûr de faire, "HeapTable" faisant 8000 octets). C'est en assez grande partie parce que je ne sais pas faire comprendre à GCC ce que je veux faire (si d'ailleurs il sait faire ce que je veux) que j'ai mis tant d'assembleur inline dans TIGCC...
Un autre exemple très sympa est
if(a&(1<<b)) ...
Il est pas fichu de me faire un btest, et il fout b dans un registre, il le shift left, et il fait and. LOL.
Pour ton tableau, qu'est-ce qu'il fait comme instructions bizares? avec moi en général il fait juste par exemple move.b (d0.w,a0)... pour array[n] avec array dans a0 et n dans d0
T'as essayé avec tous les types possibles et imaginables pour voir s'il faisait mieux? (par exemple en signé, en non-signé...)
C'est koi la différence entre ces deux HeapDeref? Il y a un, plus lourd, qui verifie des valeurs impossibles?
Seb C bien
C bien, C beau, C ni Bosch ni Bush: C ++
1ère partie: je suppose que a est dans un registre ? Parce que sinon, ça pourrait expliquer en partie...
> Pour ton tableau, qu'est-ce qu'il fait comme instructions bizares? avec moi en général il fait juste par exemple move.b (d0.w,a0)... pour array[n] avec array dans a0 et n dans d0
Dans ton exemple, c'est un array d'éléments de 1 octets, donc il n'y a même pas besoin de faire un shift de d0... Essaie avec un array d'éléments de 4 octets (j'utilise -O2)...
> C'est koi la différence entre ces deux HeapDeref? Il y a un, plus lourd, qui verifie des valeurs impossibles ?
Non, AMS ne vérifie rien de ce côté-là... AMS alloue des handles au-delà de la limite des 2000 sans aucun problème, aussi.
Le HeapDeref de AMS 1.xx est optimisé, pas celui d'AMS 2.xx.
1ère partie: je suppose que a est dans un registre ? Parce que sinon, ça pourrait expliquer en partie...
Dans ton exemple, c'est un array d'éléments de 1 octets, donc il n'y a même pas besoin de faire un shift de d0... Essaie avec un array d'éléments de 4 octets (j'utilise -O2)...
> C'est koi la différence entre ces deux HeapDeref? Il y a un, plus lourd, qui verifie des valeurs impossibles ?
Non, AMS ne vérifie rien de ce côté-là... AMS alloue des handles au-delà de la limite des 2000 sans aucun problème, aussi.
Le HeapDeref de AMS 1.xx est optimisé, pas celui d'AMS 2.xx.
Là, c'est un problème dû au double post... J'ai reposté le suivant en le modifiant, ça a fait disparaître la page d'erreur... Pas grave.
XD>je suppose que a est dans un registre
Heuh non, btest marche qu'avec les registres? Alors il a qu'à faire un move avant.
>Dans ton exemple, c'est un array d'éléments de 1 octets
J'ai simplifié. En général j'ai des arrays de structures de 12 octets, il fait
move.w d1,d0;add.w d0,d0;add.w d1,d0;lsl.w #2,d0;move.b (#3,d0.w,a0),dx
pour prendre le troisième bit de la d0ième structure du tableau en a0. Je vois pas comment faire mieux.(je suis par défault en -Os)
Seb C bien
C bien, C beau, C ni Bosch ni Bush: C ++
> Heuh non, btest marche qu'avec les registres ?
Non.
A propos de ton exemple: tu utilises quelle version de GCC ? J'utilise la version de GCC qui est en standard dans TIGCC 0.94 Beta 20, c'est un GCC 3.2. Et le code généré ressemble beaucoup à celui de HeapDeref d'AMS 2.xx...
Mon exemple c'est avec TIGCC v.094 (SP1) et tout par défault.
A mon avis c'est surtout une question de type des index, selon qu'ils soient signés ou non.
Mais c'est koi tes instructions bizares? Une subroutine pour la multiplication?
Seb C bien
C bien, C beau, C ni Bosch ni Bush: C ++
KK>Tu considère que la non-utilisation de mulu est un "bogue". Au contraire!
Celui qui a implémenté ce "bogue" a très bien fait, même si je suppose que c'est pas toi!
Enfin si un jour vous voulez supprimer ce "bogue" quand on met -Os, est-ce que vous pourriez mettre -O2 ou -O3 par défault au lieu de -Os?
Seb C bien
C bien, C beau, C ni Bosch ni Bush: C ++
Non, je ne veux pas de -O3 par défaut. -Os est très bien.
Si tu veux tu pourras mettre -O3 toi-même.
bah, a la limite, l'idéal est l'utilisation de fichiers séparés...
un en Os pr les menus, un en O3 pr le moteur, par exmepple..;
