Une bibliothèque graphique puissante et pourtant simple d'utilisation - Page 7

Thibaut a écrit :
Bon je vire le MP3

Kevin : regarde le tag ID3 du mp3, y'a quelques chose pour toi dedans

En effet, à l'adresse 0x623b3, il y a: "Dédicacé à Kevin Kofler ".

Bob 64
>> Une erreur "incompatible pointer type" dont je ne suis pas arrivé à me débarasser, le prog fonctionne quand même Ce n'est pas une erreur, c'est un warning.

En effet.
Il y a des personnes qui n'ont toujours pas compris ce qu'est un warning.

Ce n'est pas de ma faute, c'est toi qui as mal déclaré ton sprite Il faut les déclarer comme ça :

GX_sprite_XX_TYPE  NomDuSprite=
  {
    {0b1111111111111111,  // ligne 1 plan foncé
     0b1111111111111111}, // ligne 1 plan clair
    {0b1111111111111111,  // ligne 2 plan foncé
     0b1111111111111111}, // ligne 2 plan clair
    ...
  };
où XX est 08 ou 16 ou 32 suivant les dimensions du sprite,
et TYPE est masqued ou nomask suivant le type du sprite.

Autre solution: tu transtypes ton sprite en GX_sprite_XX_TYPE * et il n'y a plus de warning. (Ça utilise le fait qu'un paramètre de type tableau est automatiquement interprété comme un paramètre de type pointeur vers un tableau, donc tu peux transtyper ton pointeur en un pointeur vers le type tableau demandé sans erreur ou warning.)

Bob 64
>> Des clignotements horribles sur VTI, rendant le jeu très désagréable à tester. Sur real Ti ça passe nikel par contre.
C'est gray de la TIGCC lib qui déconne sur HW1 et donc sur VTI quand on assigne nous-même les adresses des plans. Kevin, tu sais peut-être pourquoi ?

Non, il faudra que je regarde ça. L'adresse de tes plans est-elle bien divisible par 8?

>>PpHd: je ne te dis pas bravo. Je sais que tu es capable de réécrire une ROM, là n'est pas le problème, mais la documentation d'AMS laisse à désirer pour les fonctions d'AMS 2.xx (et même pour certaines de 1.xx). Quelqu'un d'aussi compétent en assembleur que toi ne pourrait pas aider à documenter AMS ?
Oué mais lire le code asm d'AMS me donne un putain de mal a la tete.
C'est tellement mal foutu.

>Je ne pense vraiment pas que sa ROM sera meilleure que AMS. Les ROM_CALLs seront peut-être légèrement plus rapides, mais il en manquera plein. (Je veux voir PpHd implémenter une version complète de NG_execute. )
Les rom_calls implantes seront la VAT, la Heap, les Error, quelques fonctions graphiques et c'est tout. J'ai dit qu'elle serait minimaliste.
NG_execute ne sera JAMAIS supporte !

erf, Genlib in ROM, cool non ?

Kevin : oui tu peux tester l'exemple sur VTI ou sur une vraie TI HW1, tu verras que ça scintille beaucoup, mais les plans ne sont pas décalés. Si les adresses n'étaient pas multiples de 8, les plans seraient décalés horizontalement.

C'est vraiment très bizarre ce problème ! peut-être que Thomas N. pourrait nous aider ? il est là en ce moment ?

Thibaut> Comme ca ressemble a XLib, tu peux utiliser l'editeur de sprite de XLib ...

Non si tout va bien, l'éditeur de sprites "officiel" de gaphX sera TI Paint Plus.

htibeau>Les rotoutines de grays de tigcc sont tres bien... d'ailleur aucun clignottement sous XLIb ni extgraphlib, c'est ton patch qui fou la merde.

Comme je l'avais dit, si qqn mettait une lib graphique en rom (rom tt) je l'utiliserai, et c'est une tres bonne idee. Dommage que ce soit prevu que ds la "prerom"..

Au fait:
Au niveau de la vitesse d'exécution, les fonctions de GraphX se veulent comparables à celles de GenLib (la fameuse bibliothèque graphique de PpHd, auteur de SMA, Chrono Fantasy, ...) et donc beaucoup plus performantes que celles d'ExtGraph (bibliothèque graphique de la TICT, auteur de TIchess, FATengine, ...).

Faut pas dire n'importe quoi dans les doc c'est pas tres catolique...
Sinon bravo.

PpHd a écrit :
>>PpHd: je ne te dis pas bravo. Je sais que tu es capable de réécrire une ROM, là n'est pas le problème, mais la documentation d'AMS laisse à désirer pour les fonctions d'AMS 2.xx (et même pour certaines de 1.xx). Quelqu'un d'aussi compétent en assembleur que toi ne pourrait pas aider à documenter AMS ?
Oué mais lire le code asm d'AMS me donne un putain de mal a la tete. C'est tellement mal foutu.

Normal, c'est écrit en C.

>Je ne pense vraiment pas que sa ROM sera meilleure que AMS. Les ROM_CALLs seront peut-être légèrement plus rapides, mais il en manquera plein. (Je veux voir PpHd implémenter une version complète de NG_execute. ) Les rom_calls implantes seront la VAT, la Heap, les Error, quelques fonctions graphiques et c'est tout. J'ai dit qu'elle serait minimaliste.

Et j'ai dit que comme qu'elle sera minimaliste, elle ne servira pas à grand chose.

NG_execute ne sera JAMAIS supporte !

Je me le disais bien...
Donc poubelle.
(Une calculatrice sans fonctions mathématiques est bonne pour la poubelle.)

Thibaut a écrit :
Kevin : oui tu peux tester l'exemple sur VTI ou sur une vraie TI HW1, tu verras que ça scintille beaucoup, mais les plans ne sont pas décalés. Si les adresses n'étaient pas multiples de 8, les plans seraient décalés horizontalement.
C'est vraiment très bizarre ce problème ! peut-être que Thomas N. pourrait nous aider ? il est là en ce moment ?

Je ne pense vraiment pas que le problème soit dans gray.s. Je pense plutôt que tu dois faire qqch. de pas bien. Je vais voir si je trouve le problème avec le débogueur de VTI.

TiMad >> Faut pas dire n'importe quoi dans les doc c'est pas tres catolique...
Mes fonctions dépassent considérablement celles d'ExtGraph. Elle ne doivent pas être loin de celles de GenLib.
Elles sont bien plus proches de celles de GenLib que d'ExtGraph quoi.

>> c'est ton patch qui fou la merde.
1) il n'y a aucun patch
2) on a déjà remarqué que ça vient de ma façon d'afficher, apprend à lire.

Kevin : merci mais il va te falloir du courage

Extgraphlib est plus rapide pour certaines fonctions.. et il est facile de la modifier pour quelle soit plus rapide encore..

Tu as testé cette nouvelle version de GraphX ?
Je te signale qu'elle n'a plus rien à voir avec l'horreur que tu avais pu voir sur le forum il y a un moment.

Je serais très étonné que certaines fonctions de ExtGraph soient plus rapides que celles de GraphX

erf certaines fonctions (ou pluto macro) de ext sont plus rapide que:
X,gen,gX.

Et si tu veux faire encore plus rapide, ce sera par des macro, car le compilo optimise tres bien certains calcules...

Quel comique ce TiMad. Il a perdu une occasion de se taire. Il est près à dire n'importe quoi pour laisser entendre que Xlib est mieux, Genlib, aussi, blabla...

Bref, GraphX a réellement une vitesse proche (je souligne pour Sir Patrick) de celle de Genlib.

Thibaut> t'as vérifié, sinon, fait un test

LOL ..

Si tu me crois pas que ext est plus rapide que toutes ls lib asm.. c'est que t'es entêté et j'y peut rien!

Pour ce qui est de la vitesse, perso je m'en fou, mais faut pas raconter de betise c'est tout.

Mais oui, mais oui.
Avec TiMad : apprenez l'art de comparer ce qui n'est pas comparable

Puisque t'es un triso, fait un bench entre extgraphlib et ta lib de m*** et tu veras que pour les fonctions de pxl ta lib c'est de la merde!

Franchement je sais que t'es neu² mais a ce point la, c'est grave!

oué oué je suis neuneu

Erf puis si tu me crois pas demande a pphd, ou alors regarde le code généré par le compilo... moi j'y suis pour rien, si tu veux pas me croir tanpis!

Mhhh je suis neu² c'est vrai : je n'arrive pas à comparer ce qui n'est pas comparable (fonction-macro) toi tu l'es moins : tu y arrives

Et en plus tu insultes ma bibliothèque, peut-être parcequ'elle te dérange ? c'est vrai, faut posséder une intelligence supérieure à la moyenne pour réagir comme ça

ta lib me derange pas...
d'ailleur pourquoi elle me derangerait?

Perso je m'ne fou qu'on utilise ma lib ou non, donc c'est que benef... mais ya des conneries qui ne passent pas!

Un macro et tout a fait comparable a une fonction.. pour l'utilisateur, il n'y a que le resultat qui compte.. et niveau resultat, Ext gagne un point c'est tout!

Comparable, en vitesse (quoique l'on perde du temps dans le passage des arguments à la fonctions) mais pas en taille

hehe en taille, tout depend l'utilisation, mais dans pas mal de cas, le macro ne prend pas plus de place que la fonction + l'appel!

zdr : C'est justement pour ça qu'on ne peut pas comparer d'après moi. Les deux produisent un code différent. Il est évident que toute fonction sera plus rapide si elle est définie comme macro.

si on compare les fonctions de GraphX avec les fonctions correspondantes de ExtGraph, on remarque que GraphX est plus rapide.

Le truc qui m'a le moins plu, c'est le post #190 de TiMad qui laisse penser à n'importe quel non-connaisseur que GraphX est moins rapide que ExtGraph/Xlib/Genlib. TiMad est très habile pour ça...

Je suis d'accord avec Kevin, une calculatrice qui n'a aucune fonction mathématique ne sert à rien !
C'est comme une voiture sans volant, ou sans moteur...

le jour où t'auras un compilo C sur ta GBA...

>Kevin / XDanger: La calc sera dans un prog independant. Mon but est de fournir une base scene pour des futurs ROM_CALLS.

Cf affiche par map : 800 sprites 16x16, 130 sprites variables moyenne 32x32, d'ou un surcout du au masques de 42K.
Voila la note culturelle.

qd tu scrolles tu réaffiches TOUT ça à chaque fois ?!!!!!
Ben chapeau !