TI92+ en C - Page 2

squale >> le double buffering est donc une autre façon de gérer les niveaux de grix ? ou çà améliore l'affichage ?

Thibaut >> mais je l'attends avec impatience : tu m'as dit cet après-midi arff

j'ai jamais testé ce que ça donné
en gros, si c comme pr les écrans virtuels, ça permet d'améliorer l'affichage, je penses

Ca permet d'avoir un affichage instantané, et en plus tous le sprites sont affichés d'un coup, tous en même temps.

Une écriture simple directement à l'écran comme le fait syb_yd provoque des scintillements car les sprites apparaissent l'un après l'autre et à tout moment, donc même lorsque le LCD est en train de dessiner un frame => une partie de l'écran contient la nouvelle image, et l'autre l'ancienne...

La solution : le double buffering de gray.h ou alors GraphX/Xlib/GenLib

Apres faut distinguer le SwapBuffering et le ''CpyBuffering''...
Mais ca ca depend des personnes, car pero je prefere le CpyBuffering

Au fait Thibeau, ta routine de sprite maské 16x16 fait combien en octet?

Aucune idée ! Tu veux que je compte ?

vi

compile un exemple avec et un sans l'utilisation de ta routine et fait la difference entre les 2 ... (on est pas a qqs octets pres donc on s'en fou si l'apelle prend de la place...

t1 fait chier c'est long ! je vais compter, attend.

long? ca prend 1 minute.. il suffite de faire 2 projets

Comment je pourrais faire pour valider un seul appui sur une touche avec rowread quel que soit le temps de pression ?

Euh attend c'est pas si simple, l'assemblage fait plus que convertir le code ASM en binaire, il y a pas mal de choses ajoutées autour, qui dépendent du code ! on ne peut pas regarder comme ça la taille du .89z ou du .o

Sinon je peux foutre un label au début de la fonction, puis à la fin, et soustraire les deux à l'exécution, c'est peut-être ça que tu voulais dire ?

je sais pas debrouille toi, mais moi quand j'utilise la fonction d sprite Maské, il n'y a que ca de linker, donc c'est pas trop dur a calculer...
(j'ai bien dit que je voulais pas le resultat exacte, mais une approx a plus ou moins 100 octets pres..)

oulà t'y vas à la louche toi

Nan je refuse autant d'imprecision, 100 octets c'est quand même ~50 lignes d'ASM !

bein amuse toit a calculer

Pas besoin de s'amuser, cf deuxième ligne du post #40

Mais il faut que tu fasses pareil, je ne veux pas comparer si tu es si imprécis

si si..
de toute maniere Xlib est énorme au niveau de cette routine...
d'ailleur il serai interessant de comparer avec Genlin (pphd??)

GX_PutSprite16_MS : très exactement 340 octets.

???
et tu fais une boucle de combien avec ca? parce que ca fait pas grand chose il me semble...

La boucle d'affichage du sprite en entier est déroulée de 2 itérations
Il y a 2 boucles d'affichage du sprite en entier (hé hé )

La boucle d'affichage du sprite clippé horizontalement n'est pas déroulée
Il y a 2 boucles d'affichage du sprite clippé (clipping à gauche et clipping à droite)

ca peut pas rentrer dans 340 octets!!

D'apres ce que tu m'as dit , tu es loin d'arriver au niveau de Gen et X .

Bah comme tu le vois, ça rentre dans 340 octets. Ou alors ma TI ne sait plus soustraire deux labels.

Dans XLib, il y a 3 cas developé a 50% et les cas de clipping. ca me prend 1 Ko (mais j'ai ps besoin d'un buffer plus grand...)

Le troisième cas c'est lorsque le shift est égal à 16 je parie

J'avais pensé à le traiter, mais je me suis dit que ça nuirait à la qualité graphique : lors d'un déplacement de sprites tous les 16 pixels il y aurait un sursaut dû au gain de vitesse trop important apporté par ce troisième cas (swap au lieu de lsl/lsr).

Donc si on retire le troisième cas et les clippings verticaux de ta routine, on arrive peut-être à une taille équivalente (n'oublions pas que ta mesure de taille est imprécise)

Faut pas raisonner comme ca..
les trois cas sont:
x%16=0
x%16>y
x%16<=y;

faut penser a faire une moyenne des différents cas...

x%16=0 : ha j'ai perdu mon pari

bof bof... ça ne doit pas faire un défilement très régulier agréable à l'oeil :/

dans K2, ca doit faire un gain de pas mal de fps...

Et une image qui sursaute régulièrement lors du déplacement de beaucoup de sprites...

je confirme, c pas top, à moins d'avoir vraiment bcp bcp de sprites tous indépendants, ou à moins d'avoir une synchro suffisamment élevée pour gérer le cas où pour à peu près tous les sprites, x%16=8

c'est carément top...
je sais pas si vous avez remarké, mais K1 (par exmple) affiche sont decors en x%16=0
donc imaginé un jeu comme K1 ave un scroll diff.. le gain est carement non négligeable...
Et arretez de dire que ca nuit a qqc...
Il faut raisonner en terme de moyenne, si il y a des sprites qui sont afficher en x=0(16), alors il seront afficher plus vite, et dans ce cas la, ca laisse plus de temps pour afficher les autres... Le blocage du fps permet justement d'éviter les desagréments.
En revanche .. avec une routine de XLib, on poura augmenter le fps..

Je pourais dire le meme argument pour ta routine. La différence c'est que toit ce sera du a une lenteur et non une rapidité!
tu a deja bencher la diff entre ta routine en {1,0,-1}%16?? fait le tu veras...

Et puis Genlib prend aussi ce cas en cause il me semble... alors bon.

bof bof, généralement les décors avec des abscisses multiples de 16 sont générés au commencement d'un niveau, après les absisses sont différentes à cause du scollaingue !