Niveaux de gris - Page 2

Hum perso ça m'interesse si ça marche bien, comment on peut integrer ça à un projet ? (t'as fait une lib, ou qqchose ?)

c possible d'avoir une version 92+ ? m'en fou du mode anticlignotement, je veux voir ce que ça donne.

Je n'ai pas fait de lib. Pour l'instant c'est un fichier Gris.s qui vient s'ajouter au projet. Les définitions sont dans le fichier d'en-tête du programme. Mais ça prend plus de CPU qu'avec la routine de la TIGCC (j'ai remarqué jusqu'à 10% de CPU en plus)

non, c un .89z et il dit Wrong Calculator Model (ce qui est normal si tu lui a pas dit que c t compatible on calc)

Brunni
: Mais ça prend plus de CPU qu'avec la routine de la TIGCC (j'ai remarqué jusqu'à 10% de CPU en plus)

Aïe... Pas bon du tout ça

Comment tu calcules le CPU que ça prend ?

Ben j'attends sur l'AUTO_INT_5. Je sais le nombre de fois que je peux faire while(!OSTimerExpired) au max (4500 pour une HW2 et 3000 pour une HW1), et la fréquence que je dois régler pour une HW1 et une HW2. Donc après quelques calculs, mon jeu indique en bas dans la barre des scores (si désiré) l'utilisation courante du CPU. En plus il utilise également cette variable pour faire un frameskip si nécéssaire (bien que ce ne soit jamais nécessaire)

Pour que ça prenne moins de CPU, tu peux dérouler ta boucle de recopie de plans comme un bourrin. (c'est ce que fait tigcclib, je crois)

tiggclib?
dérouler une boucle
tu es fous, ce serait une optimisation en vitesse, ce serait proprement impensable!

Pour que ça prenne moins de CPU, tu peux dérouler ta boucle de recopie de plans comme un bourrin. (c'est ce que fait tigcclib, je crois)

Je vais optimiser un peu mais faut pas trop rêver. Ma routine doit bosser à 100% de ses AUTO_INT, alors que celle de TIGCC seulement à 66%... Je peux réduire à 80% mais pas moins. Ce sera déjà bien étant donné que la routine de TIGCC n'augmente déjà pratiquement pas l'util du CPU. Un peu plus... ca ne changera rien.

Qu'entends-tu par dérouler une boucle (des trucs comme ça?)
*(long*)addr^=(long)(*sprite++)<<cnt; addr+=30;
*(long*)addr^=(long)(*sprite++)<<cnt; addr+=30;
*(long*)addr^=(long)(*sprite++)<<cnt; addr+=30;
*(long*)addr^=(long)(*sprite++)<<cnt; addr+=30;
*(long*)addr^=(long)(*sprite++)<<cnt; addr+=30;
*(long*)addr^=(long)(*sprite++)<<cnt;
if (font!=6) {
addr+=30;
*(long*)addr^=(long)(*sprite++)<<cnt; addr+=30;
*(long*)addr^=(long)(*sprite++)<<cnt;
if (font==10) {
addr+=30;
*(long*)addr^=(long)(*sprite++)<<cnt; addr+=30;
*(long*)addr^=(long)(*sprite++)<<cnt;
}
}

oui

EDIT : Pas vu la deuxième page

EvaSDK
: non, c un .89z et il dit Wrong Calculator Model (ce qui est normal si tu lui a pas dit que c t compatible on calc)

[URL=http://www.ticalc.org/archives/files/fileinfo/284/28472.html]Sim[/URL] est là pour ce genre de problèmes.

Je ne sais pas trop... Comment on fait avec TIGCC pour le rendre compatible toutes TI?

#define USE_TI89
#define USE_TI92PLUS
#define USE_V200

Ah mais oui! Comme ce projet était à la base conçu pour TIGCC 0.93 et que j'ai passé récemment au 0.94 j'au oublié de rajouter ces définitions!

C'était exactement la même chose sous TIGCC 0.93. (Sauf que le code pour USE_V200 était bogué. J'ai mis un 3 au lieu d'un 2 à un endroit et ça a fait tout foirer. Mais au moins les programmes concernés devraient être utilisables avec v200exep. C'était avant la sortie officielle des V200, donc il n'y avait pas beaucoup de testeurs, ce qui explique pourquoi ce bogue a pu passer inaperçu.)

ExtendeD > merci pour le lien, j'avais pas assez de temps pour chercher

Kevin Kofler :
C'était exactement la même chose sous TIGCC 0.93. (Sauf que le code pour USE_V200 était bogué. J'ai mis un 3 au lieu d'un 2 à un endroit et ça a fait tout foirer. Mais au moins les programmes concernés devraient être utilisables avec v200exep. C'était avant la sortie officielle des V200, donc il n'y avait pas beaucoup de testeurs, ce qui explique pourquoi ce bogue a pu passer inaperçu.)

Heureusement effectivement!

Pour que ça prenne moins de CPU, tu peux dérouler ta boucle de recopie de plans comme un bourrin. (c'est ce que fait tigcclib, je crois)

La boucle est déjà déroulée:
movem.l (%a0)+,%d0-%d7/%a2-%a6
movem.l %d0-%d7/%a2-%a6,(%a1)
movem.l (%a0)+,%d0-%d7/%a2-%a6
movem.l %d0-%d7/%a2-%a6,(0x34,%a1)
...
etc. par cinquante-deux octets. Je ne sais plus où j'avais vu ça mais c'était une bonne idée. Enfin je crois.

Link :
tiggclib?
dérouler une boucle tu es fous, ce serait une optimisation en vitesse, ce serait proprement impensable

Oui ben pourtant c'est bien ce qu'ils ont fait apparemment (voir ci-dessus).

Vertyos
:

Brunni
: Mais ça prend plus de CPU qu'avec la routine de la TIGCC (j'ai remarqué jusqu'à 10% de CPU en plus)

Aïe... Pas bon du tout ça

Oui. Cependant la routine de TIGCC demande en fait un bon paquet de CPU. C'est horrible mine de rien. Alors un peu plus ou un peu moins... Tu vois ce que je veux dire.
Cependant (en tous cas sur ma TI) ça en vaut le détour! La qualité est vraiment MOOOORTELLE! Les niveaux de gris se distinguent vraiment mieux. Mais bon il faut rester SANS le mode anti-clignotement pour cela.

L'interruption de gris est optimisée en vitesse pour réduire au minimum les clignotements (et aussi la consommation CPU). On doit déjà maintenant se limiter à copier un tiers de l'écran à la fois. Si la routine était encore plus lente, ça serait pire.

C'est DEJA horrible. Ma foi! Je trouve que ça ne vaut pas la peine de créer un jeu en utilisant les routines de TIGCC, c'est une perte de CPU et en plus de mémoire. Au moins avec un système potable, j'ai moins l'impression de m'embêter dans le vide.

J'ai testé mario3, et même si les tons des niveaux de gris sont mieux que ceux de TIGCC, ça clignote beaucoup trop pour être utilisable. Dommage

C'est clair, mais bon, ça dépend des graphismes. Et essaye d'appuyer sur F2 (après tu remontes le contraste). Là c'est mieux.
Et par potable, j'entendais que les niveaux de gris soient distinguables.

Distinguable oui mais agréable à regarder c'est quand même beaucoup plus important. Pour l'instant même si le foncé des gris de TIGCC est trop foncé, ils restent la seule alternative.

Existe-t-il un autre système de gris qui tourne sur HW2 et qui ait un nivelage potable?

Aucune idée, mais pas à ma connaissance.

Mais genre les niveaux de graphlib, gray7lib, et toutes ces *** de librairies, il me semble qu'ils étaient mieux non? Est-ce qu'il y a un SDK pour gray7lib?