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

cette technique n'est pas nouvelle.....

Mais le probleme des lib comme gen et graphx c'est que si il y a changement de ams etc... avec des restrictions ou tout autre chose, il faut modifier ces lib.. alors que X utilise les routines de tigcc. ce qui la rend compatible a chaque fois que tigcc est porté....

Manque de bol, GraphX utilise grayde TIGCC (c'est dans le readme, section "remerciements" : http://alineasofts.free.fr/graphx/A_LIRE.htm)

>> cette technique n'est pas nouvelle...
J'ai l'impression d'avoir écrit pour rien un message en gris dans le premier post du topic...

Thibaut a écrit :
Manque de bol, GraphX utilise grayde TIGCC (c'est dans le readme, section "remerciements" : http://alineasofts.free.fr/graphx/A_LIRE.htm)

Mais avec un hack affreux pour implanter un double-buffering avec des buffers plus grands que l'écran.

Tu as une meilleure idée ? non.
Alors pouêt pouêt

Un buffer plus grand que l'ecran ne sert a rien... d'ailleur Xlib utilise maintenant un buffer directement compatible TIGCC.

Ecoute TiMad, tu fais comme tu veux.
De la façon dont j'affiche les sprites, la méthode la plus rapide et demandant le moins d'instructions c'est d'élargir le buffer en haut et en bas (pas sur les côtés).

Je te comprend, tu as envie de faire ta pub ici, mais si tu commence moi je ne vais pas me gêner dans les topics parlant de Xlib
(heu bon oui j'aurais du mal ma lib propose encore trop peu de fonctions par rapport à la tienne )

NON je ne veux pas faire de pub.
D'ailleur Genlib n'utilise pas de buffer plus large il me semble.. c'est juste pour te dire que si tu veux plus tard optimiser tes routines, il faut que tu changes de format de buffer.. car sinon tu veras plus tard que c'est chi** de changer le format meme quand les fonctions sont deja programmées..

lol pas du tout, j'aurais juste une constante à mettre à zéro arrête de parler du fonctionnement interne de ma lib sans avoir vu les sources, stp.

héhé tu veras bien petit venard le clipping sans marge de buffer c'est completement différent!

Il me semble que tu n'as pas bien lu.

Thibaut a écrit :
De la façon dont j'affiche les sprites, la méthode la plus rapide et demandant le moins d'instructions c'est d'élargir le buffer en haut et en bas (pas sur les côtés).

lol vous ne comprenez pas tanpis...

>Timad: Mais le probleme des lib comme gen et graphx c'est que si il y a changement de ams etc... avec des restrictions ou tout autre chose, il faut modifier ces lib.. alors que X utilise les routines de tigcc. ce qui la rend compatible a chaque fois que tigcc est porté....
N'importe quoi.Genlib a deja prouve ca portabilite totale avec le passage hw1 a hw2 (Les jeux deja fait avec gen pour hw1 fonctionnaient a l'epoque fonctionne aujourd'hui aussi pour hw2 !)

Et le jour ou tu ne develloperas plus Genlib?

Xlib sera toujours compatible tant que tigcc sera porté sous les nouvelles version...
meme si je ne prog plus ce qui va bientot etre le cas.

Je vois que tu n'as pas changé TiMad. Arrête de nous dire que ta lib est mieux, que ta façon de procéder est la meilleure... c'est lourd toutes ces vantardises.

Ptin mais arrete de faire un complexe thibeau, c'est juste un conseil rien d'autre... de toute maniere si je voulais vraiment ridiculier tas lib je l'aurais deja fait!

Excuse-moi, mais la façon dont tu t'exprimes te fait passer pour un vantard.

La n'est pas le sujet, mais de mauvais a prioris sur une personnes mettent souvent du temps a partir, ...

C'est vrai.

>Timad: Le jour ou j'arrete Genlib, je file les sources a un mainteneur.

Et cela suppose que tigcc soit maintenu, ton affaire.

Oui mais bon de toute maniere je vais arreter bien avant que TIGCC sorte sa prochaine version...

PpHd
a écrit : >Timad: Le jour ou j'arrete Genlib, je file les sources a un mainteneur.

Et ce sera qui?
Parce que pour le moment, je ne vois pas grand monde qui est à la fois intéressé par l'idée et capable de maintenir une librairie comme GenLib.

PpHd
a écrit : Et cela suppose que tigcc soit maintenu, ton affaire.

En effet, le futur de TIGCC n'est pas aussi certain qu'il pourrait sembler. En ce moment, on est 2 personnes à nous occuper du travail central de maintenance: Sebastian et moi. Et Sebastian a de moins en moins de temps, donc c'est de plus en plus le projet d'une seule personne.

Quant aux niveaux de gris de TIGCCLIB, c'est depuis longtemps le projet d'une seule personne, qui de plus a très peu de temps libre: Thomas Nussbaumer.

Et au fait, PpHd, au lieu de gaspiller ton temps à recoder une ROM, tu ne pourrais pas plutôt nous aider à documenter celle qui existe déjà? Pour l'instant, il n'y a que XDanger qui fait tout ce travail.

Bon finalement je vais adopter le swaping mode, puisque ma methode n'as plus aucun avantage

Pour la maintenance de TIGCC: c'est sûr que ça devient un problème... Je ne peux pas vraiment aider pour le gros travail central sur GCC (peu d'expérience en C, notamment, il n'y a qu'à voir comment j'ai fait mes wrappers). Pour la doc, je peux faire quelques trucs, mais ça reste limité...
Thomas et Zeljko ont peu de temps, donc ça pourrait devenir dur...

> Et au fait, PpHd, au lieu de gaspiller ton temps à recoder une ROM, tu ne pourrais pas plutôt nous aider à documenter celle qui existe déjà? Pour l'instant, il n'y a que XDanger qui fait tout ce travail.
Je ne savais pas que PpHd recodait une ROM...
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 ?

Et sinon, ce n'est pas bientôt fini ces petites querelles entre librairies concurrentes ? Est-ce vraiment impossible de ramer tous dans le même sens, en essayant de passer par-dessus les problèmes de personne (je sais très bien que ce n'est pas facile) ? Si par exemple j'avais mis dans une librairie propriétaire, dont les sources sont privés, les fonctions d'AMS que j'ai documentées, de quoi aurais-je l'air ?

nan mais si il fini la rom on s'en fout de l'ams et des rom call

XDanger
a écrit : Pour la maintenance de TIGCC: c'est sûr que ça devient un problème... Je ne peux pas vraiment aider pour le gros travail central sur GCC (peu d'expérience en C, notamment, il n'y a qu'à voir comment j'ai fait mes wrappers).

Heureusement qu'il y a moi qui m'occupe de GCC et Binutils en ce moment et que je n'ai aucune intention d'arrêter.

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 ?

Entièrement d'accord.

gugusg a écrit :
nan mais si il fini la rom on s'en fout de l'ams et des rom call

Pas moi.
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. )

si tu veux tu peux insérer ma fonction de fondu dedans (mais ds ce cas faut ré-enrouler la boucle principale)
++

C'est vrai ???????????????

Génial !!!!!

Et quand sera-t-elle finie, cette ROM ? Ca risque de faire comme GTC, comme Calcux...
C'est pas sérieux. De toute façon, la calculette est en fin de vie (AMS 2.07 est assez probablement l'avant-dernière version, si ce n'est pas la dernière)...