> Tant pis pour ExtGraph, il y a d'autres bibliothèques graphiques moins volumineuses
Mais y a-t-il d'autres libs qui offrent une souplesse d'emploi pareille (les deux modes de passage de paramètres, 6 types de routines: OR/XOR/AND/Get/MASK/BLIT, pour chacune des largeurs 8, 16, 32 et multiple de 8, et toutes ces routines en deux versions, l'une clippée et pas l'autre...) ? Bon, OK, pas toutes ces routines ne sont implémentées/refaites (il manque les SpriteX8 et les SpriteX8 clippées). jackiechan et Ximoon ont fait et font un boulot formidable.
> Pour TIGCClib, il me semble que Pollux a recodé une partie des fonctions en ASM : elle a beaucoup maigri
J'espère vivement qu'il va les contribuer à TIGCCLIB et je l'y encourage. Ca fera bénéficier toute la communauté de ses améliorations.
XDanger, si j'ai bien compris, ton code marchera sous AMS 1 et 2, mais plantera sous Pedrom. Ceci est un problème. Les solutions que je vois à ce problème sont:
Pourquoi c'est un problème de ne pas supporter un système limité, dont l'auteur ne veut pas faire un tout petit truc trivial à coder, ne prenant que quelques instructions, que je lui demande ?
* ignorer le problème.
Non, je suis aussi contre. Ignorer le problème n'est pas une bonne idée.
* ne rendre disponible ces fonctions qu'avec MIN_AMS>=105 ou 200, alors que 101 suffirait.
Je suis totalement contre. Ces fonctions marchent sous tous les AMS avec 0x3CC ROM_CALLs ou plus (et peut-être même AMS 1.00 92+, je ne peux tester car je n'ai pas cette ROM).
* rajouter du code à tipatch.lib pour rejeter Pedrom.
Je suis absolument contre. C'est à PedroM de rejeter les programmes qu'elle ne supporte pas (sortir proprement quand un ROM_CALL non implémenté est appelé). PedroM ne concernera de toute façon qu'une minorité de programmeurs, ça serait bête de faire pâtir les autres d'un patch supplémentaire, et qui plus est inutile.
* détecter Pedrom séparément dans les fonctions en question. Pas pratique vu qu'elle n'est même pas disponible publiquement.
Je suis contre.
Je ne proposerai, pour la contribution à TIGCCLIB, que la version utilisant OO_CondGetAttr (une version très similaire à ce qu'il y a actuellement dans TI-Chess, qui ne marche pas sous PedroM, puisque aucune des deux méthodes, pas plus celle d'AMS 1.xx que celle d'AMS 2.xx, ne marche). J'ai déjà accepté de laisser, dans les programmes comme ebook, les deux versions, alors qu'absolument rien ne m'y oblige. Je vois difficilement pourquoi je contribuerais l'ancienne version, qui nécessite un backbuffer, qui est beaucoup beaucoup plus lente à initialiser (plusieurs ordres de grandeur que la version améliorée, aux alentours de 4 ordres de grandeur pour AMS 1.xx) et qui est un code plus gros.
Uther Lightbringer, neurOne: NON, TIGCC Team != TICT. Les deux teams n'ont pas les mêmes personnes.
> Je continue a penser qu'il [GTC] sera une révolution pour moi qui est intéréssé par le on-calc.
Eh bien nous aussi, nous pensons la même chose ! Il n'existe aucun compilateur de la classe de GTC on-calc. CC, c'est bien mieux que rien, mais c'est quand même nettement moins bien que GTC. GTC n'a pas d'équivalent on-calc. Suis-je clair ?
PAR CONTRE, TIGCC reste meilleur que GTC sur un certain nombre de points, dans les versions comparables, à savoir les versions on-PC. Les extensions que Pollux juge intéressantes le sont effectivement pour certaines d'entre elles (notamment __attribute__((__regparm__(data registers,address registers))), que Kevin ajoutera dans TIGCC. Mais pour des trucs comme #macro ou #asmmacro sont plus discutables, en plus de leur incompatibilité avec TIGCC...
Vark: tu es légèrement lourd...
[dernier post lu: #705, Vark]
