Ecran qui saute!! - Page 2

Laisse tomber graphlib! Ma librairie statique marche très bien, et sera intégrée à TIGCCLIB, donc supportée officiellement par TIGCC, ce que graphlib ne sera jamais.

./30 --> tout le monde devrait avoir le reflexe google !

bon, en ce qui concerne les dll sur ti, leurs gros désavantages, c'est que bien souvent (meme toujours...), on n'utilise pas toutes les fonctions quelles possedent, alors pourquoi on les divise pas en fonctions élémentaires ?
On aurait des dizaines de fragments de dll, mais aucunes ne seraient inutile.

jfg :
./30 --> tout le monde devrait avoir le reflexe google !

Réflèxe qui mène soit vers rien du tout, soit (si on est assez malin pour rajouter "TI-89") vers une version totalement obsolète. La seule version mise à jour est livrée avec PreOs. C'est le cas pour presque toutes les libraries kernel.

et ouai ce ke je peut trouver graphlib???

cherche sur le site de la T3

tu prends PreOS et dedans tu as la plupart des libs, en plus de PreOS et de la documentation

Kevin :
(alors que mes routines contiennent une version adaptée du double-buffering de TIGCCLIB).

C'est nul quand même gray.h devrait permettre également de choisir les 2 plans, ça éviterait que GX et xlib "hackent" pour autoriser le TSB.

GraphX et XLib devraient s'adapter aux routines de gris, pas l'inverse.

gray.h devrait s'adapter aux demandes des utilisateurs, et pas répondre uniquement aux idées des mainteneurs.

Franchement je trouve qu'un peu de flexibilité de ce côté ne ferait pas de mal non plus
D'une, ça coûterait pas grand chose à modifier, de deux ça permettrait plein de trucs sympas (prendre deux plans consécutifs, à tout hasard).

Tu veux ouvrir un troll sur la propriété intellectuelle des niveaux de gris de tigcclib? y'a à dire

Ouai en plus...
Mais de toute façon Martial délire un peu :/

Enfin bon au pire elle sont données les sources je crois, donc un particulier peut sûrement les modifier pour son propre programme (comme X et GX je crois) après avoir bien lu la license (j'imagine) donc finalement c'est pas la mort. Mais perso je verrai bien une fonction GrayOn qui prend les deux plans déjà alloués en paramètres

Ximoon
: D'une, ça coûterait pas grand chose à modifier, de deux ça permettrait plein de trucs sympas (prendre deux plans consécutifs, à tout hasard).

C'est justement ce que nous ne voulons pas permettre, parce que c'est un gaspillage de 3840 octets sur HW1.

parce que c'est un gaspillage de 3840 octets sur HW1.

tu es à 3840o près, dans tes programmes ?

Et dans le cas de compilation ciblée, si la calculatrice est détectée comme étant une v200 ou une 89 titanium, tu ne penses pas que ça permettrait de gagner en place et en vitesse d'avoir ces plans consécutifs ?

Il n'y a pas de compilation ciblée pour la Titanium (à part pour le lanceur ExePack).

Kevin Kofler
:

Ximoon
: D'une, ça coûterait pas grand chose à modifier, de deux ça permettrait plein de trucs sympas (prendre deux plans consécutifs, à tout hasard).

C'est justement ce que nous ne voulons pas permettre, parce que c'est un gaspillage de 3840 octets sur HW1.

...
Quand certains programmes en ont besoin, ils sont obligés de hacker. Autant rendre facultative l'allocation des buffers de gray.h, par exemple avec une fonction DoNotAllocateBuffers qu'on appelle avant GrayOn. Si cette fonction n'est pas appelée alors le fonctionnement de gray.h ne change pas (compatibilité totale avec les sources existantes).
Ensuite, on donne l'adresse de nos buffers avec SetDarkBufferAdress et SetLightBufferAdress.
Tout le monde serait content et il n'y aurait plus de hacks quand certaines applications doivent imposer leurs buffers.

Albert Instinct
: Quand certains programmes en ont besoin, ils sont obligés de hacker.

Non, ils sont obligés de corriger leurs algorithmes, parce que c'est là que se trouve le problème, pas dans nos routines de gris!!!

... ben voyons.

Il a décidé de rester trisomique à vie on dirait :/

Tu gardes tes commentaires inappropriés pour toi la prochaîne fois...
Si les programmes dépendent d'une assertion incorrecte, ce sont des programmes bogués!

... ben voyons.

Kevin je t'aime tu es trop intelligent

kevin, ça fait un peu cross entre plusieurs discussions du WE mais, 92 sur HW1, pourquoi avoir mis une routine de Gray à TiGCC (gray.h avec fargo.a j'entends) plutôt que d'utiliser la routine interne déjà existante ? parcque c'est du doublon que tu condamne, ça te fait perdre la taille du code de gray (qui n'est pas négligeable) et que c'est à ton application(tigcc en l'occurence) à s'adapter au hardware officiel...

des choix que vous prenez délibérément pour tigcc, pourquoi les autres codeurs ne pourraient pas en faire autant ? faites ce qu'on dit pas ce qu'on fait ?

* Il n'y a pas encore de routine de gris dans fargo.a (mais ça va venir).
* Il n'y a aucune routine de gris dans Fargo lui-même. Il y en a une dans flib (Fargo Library), mais la librairie est optionnelle, et peut être effacée! Par exemple, Backgammon n'en a explicitement pas besoin. Idéalement, si on n'utilise que des programmes TIGCC, on pourra effacer flib et gagner de la place par conséquent.

mais si on veut utiliser les niveaux de gris, pourquoi TIGCC ne donne accès qu'à flib et pas plutôt au driver lcd ?

Ah, la méthode "hardware"? Si je me rappelle bien, il y a eu une longue discussion ici, et la conclusion était que c'est inutilisable en pratique, il y a trop de contraintes.
Mais de toute façon, il n'y a encore rien pour les niveaux de gris dans fargo.a, donc tu utilises strictement ce que tu veux. Et même si on met une routine de gris logicielle, rien ne t'empêche d'utiliser la méthode matérielle avec les pokeIO qu'il faut.