C'est peut-être parce que sur ticalc.org, tout s'appelle "Assembly Games".
Le nouveau linker de TIGCC 0.95 saura faire ça aussi en _nostub.
Ca serait ridicule à mon sens.
Un site complet sur lequel vous trouverez des programmes et des jeux pour votre calculatrice TI 89 / Titanium / 92+ / Voyage 200 :
www.ti-fr.com.
Quelques idées personnelles
ici.
Pour les cas où on ne peut vraiment pas faire autrement (limite de 64 KO), il y a les DLLs _nostub.
Les libs dynamiques de quelques centaines d'octets où on ne fait que la sauvegarde du jeu ou celles où l'on réimplémente les fonctions d'AMS, c'est ridicule.
Les libs dynamiques de plusieurs dizaines de KO dans lesquelles on utilise énormément de fonctions (style Fatlib, pas GenLib ou XLib première version qui sont trop petites pour ça), ou les libs faites pour dépasser 64 KO, oui, et c'est déjà dans TIGCC.
> pour les niveau de gris je pense que la routine de GX permet de gagner 5 a 10 % de rapidité par rapport a celle de tigcc...
Sauf qu'à ma connaissance, à moins que ça ait changé, le doublebuffering est obligatoire avec les routines de gray de GraphX, il ne l'est pas avec les routines de gray de TIGCCLIB...
> donc bon en plus tigcc il permet pas d'allouer les 2 plans a la suite ce qui est grave relou
"Grave relou" pour les merdes, c'est sûr. La différence de vitesse entre deux plans séparés et deux plans consécutifs en mémoire est absolument négligeable. Et faire des plans séparés ajoute de la flexibilité à la librairie...
Tous les arguments sont bons pour casser TIGCCLIB et ExtGraph, n'est-ce pas ? Surtout les arguments pas valables (c'est gentil de ma part de considérer ce que tu as posté comme des arguments...), ce sont les mieux.
Du moins, ces arguments ne sont pas valables pour toi. Mais ils existent.
Et encore une fois, te crois-tu bien placé pour faire une quelconque remarque à quiconque ?
C'est vrai que c'est plus pratique de n'utiliser q'un bloc avec les deux buffers à la suite, mais c'est aussi bien plus souple de spécifier chaque plan.
Et surtout c'est une optimisation en consommation mémoire sur HW1.
#46, #47: eh oui...
#44: j'arrête la discussion. Il est impossible de discuter avec Thibaut, qui fait bien pire mais visiblement sans s'en rendre compte. Je suis très loin d'être le seul à le penser, mais lui n'a pas l'air de se rendre compte de la façon dont il se comporte. Il risque pourtant des ennuis !
Tu oses dire que TiMad (ça fait longtemps qu'on ne l'a pas vu, quelle paix on a !) fait des arguments ? Ce qu'il fait, c'est de la provocation presque systématique, il a des opinions ultra-tranchées et ne donne pas souvent des arguments ! Sur les deux premiers points, je ne suis pas irréprochable, mais sur le troisième, il ne faut quand même pas exagérer.
#45:
> tant qu'on y est la diff de vitesse entre X et l'ams est negligeable
Tu te fous de nous ! On n'a jamais dit ça !
Jusqu'à ExtGraph 1.02, presque aucune boucle n'est déroulée et ExtGraph est faite presque exclusivement en C, alors que XLib et les autres sont faites en ASM et utilisent des boucles déroulées. La comparaison est stupide, mais certains la font dans un but de propagande: "ma lib est vachement plus rapide qu'ExtMerde" (sauf qu'elle est bien plus grosse, moins flexible, ne fait pas n'importe quoi avec les grays de TIGCCLIB... mais ça, on ne le dit pas).
> heu ya pas mal de bon programmeurs dans la commu ti qui on utiliser la methode des buffers alloué en 1 bloque...
Et alors ? cf #47, le faire en deux blocs permet de gagner de la mémoire sur HW1.
> mais bon bien sur l'equipe de tigcc va nier le fete que ca permet de gagner de la vitesse... et de la place
Je n'appartiens pas à la TIGCC Team, contrairement à ce que beaucoup croient...
Et puis, donne toi-même des arguments: gain chiffré de vitesse et de place (quelles instructions remplacées, etc.). Sinon, je vais encore dire à juste titre que tu n'y connais rien...
Pour le gain de place sur HW1 de faire deux planes en un bloc, déjà, tu pourras repasser: LCD_SIZE de mémoire superflue consommée, ça fait déjà pas mal, environ 2% de la RAM libre totale, et ça n'est pas l'optimisation minime des routines due aux deux planes en un bloc qui va changer la donne.
genre si tu recupere pas le lcdmem ca c'est ton probleme... mais bien sur l'equipe tigcc par souci de simplicité n'a pas fait l'otpimisation voulu.
heu et puis tu juge n'mporte quoi, les autres lib non pas de boucle deroulé, on divise juste par 2 ou 4 le nombre de dbra.. de plus par exemple pour Xlib, 3 voir 4 routines reprennet la boucle generale => pour un jeu qui utilise par exemple els sprite 8 et 16 et les pic, Xlib prend beaucoup moins de place que Extgraphlib... puis la preue que tu n'as rien compris a la programmation de routine graphique, c'est que la rapidité ne depend pas du deroulage des boucle (ca devient negligeable si on fait 2 ligne par boucle ou 4) mais d'autre chose #myster#...
Le déroulement des boucles permet quand même un gain, et tu le sais très bien.
Même en prenant une hauteur de sprite variable (ce qui complique très légèrement le déroulement, enfin, ça le ralentit un petit peu), en dérouant seulement x2 on obtient un gain de plus de 15%... Ce n'est pas négligeable du tout.
J'ai de plus en plus marre de la mauvaise foi de Monsieur Julien Sabatier (et aussi du fait qu'il n'arrête pas de changer de pseudonyme, d'ailleurs).
ce n'est pas le gain le plus important.
Au fait, y-a-t'il déjà une spécification du format exact employé? Et as-tu réussi à faire quelque chose pour l'implémentation dans le linker de TIGCC?
PpHd Le 12/07/2003 à 16:27 Pour le format, je reprend celui de Fargo. Il est tres bien, permet de depasser les 64Kb sans probleme. Et ca evite de refaire sans arret la meme chose.
D'ou mon probleme pour l'integration dans le linkeur de tigcc sans changer beaucoup de trucs...
> Un shift par la gauche ou par la droite selon la valeur de x&15.
Sur quelles routines ? Sprite8, je suppose ?
> Et bien fait ca ne multiplie pas la taille par 2.
Non, en effet. Il y a un peu d'overhead pour tester si 8 - x&15 >= 0, pour faire le branchement et pour remettre le shifting correct avec un neg si 8 - x&15 < 0, mais ça ne multiplie pas la taille par deux, c'est sûr. Il n'y a pas deux fois le calcul de l'adresse, etc. En revanche, ça améliore assez significativement la vitesse moyenne de la routine, et la rend carrément plus rapide pour x&15 petit.
(Là, je parle d'une Sprite8).
pour toutes les routines de sprites... mais bon ay encores d'autres astuces..
Tu critiques les arguments de TiMad alors que tu en as des aussi minables, voir des plus minables, très souvent.
)
.
