1

re, encore moi avec mes questions a la ...

J'essaye de faire des sprites en mode literal de 2 pixel de large.
Par exemple le sprite ci-dessous (2 pixels de large, les couleurs de 1 a 16):

char spritedata[] = {2, 0x11, 2, 0x22, 2, 0x33, 2, 0x44, 2, 0x55, 2, 0x66, 2, 0x77, 2, 0x88, 2, 0x99, 2, 0xAA, 2, 0xBB, 2, 0xCC, 2, 0xDD, 2, 0xEE, 2, 0xFF, 0};

Je le copie plusieurs fois a la suite, voila ce que cela me donne dans handy :
snap02.jpg

Et ce que cela me donne sur la lynx:
CIMG3133.jpg

Je vois pas super bien sur l'ecran de la Lynx mais en gros j'ai l'impression que je me retrouve avec un sprite de seulement 1 pixel de large ...
En tout cas ca rend clairement pas comme je l'espere.

Je n'arrive pas a expliquer le phenomene, quelque chose que j'aurais rate sur le format des sprites ?
Des idees, pistes ?

Merci !

tromb Fichier joint : cart[1].lnx

2

Tu tes fais piéger par les sous pixels en fait. Si tu prends une "loupe", tu verras que les pixels de la lynx sont divisés en sous pixels rouge, vert, bleu.

Si tu veux, dans Handy, tu peux utiliser le mode "Lynx LCD Emulation" pour te faire une bonne idée.


PS : en fait avec un sprite aussi "fin", tu tombes peut être sur le bug documenté... http://devlynx.ti-fr.com/?pag=9&cat=43 (Il y a un bug dans le matériel qui impose que le dernier bit représentatif d'un bloc de données à la fin d'une ligne ne soit pas dans le dernier bit d'un octet (bit 0). Ca veut dire que la création des blocs de données doit valider cette condition, et quand elle intervient il faut compléter le bloc par un octet remplit de 0. N'oubliez pas d'ajuster le décalage pour inclure ce complément. Comme ça ne surviendra que sur une ligne sur 8, ça ne justifie pas de me forcer à passer du temps à essayer de corriger ce bug, désolé.
)
avatar
Webmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

3

Ca ne m'affiche vraiment qu'une seule colonne de pixel sur 2.

C'est vrai qu'on ne se rend pas bien compte sur les screenshots.
J'ai refais la meme avec des colonnes de la meme couleurs pour voir mieux. Et en mode lcd emulation tu as raison.
snap03.jpg
CIMG3142.jpg

Si on verifie les colonnes roses, tu peux en voir 2 (mes deux pixels) sur handy, mais une seule sur la photo sur la lynx.
Ca se voit pas trop mal sur le materiel reel.

4

(cross), j'ai édité mon message entre temps
avatar
Webmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

5

Oui j'ai vu ca mais je n'ai compris ni la version anglaise, ni la version francaise ... confus
Si quelqu'un comprends et peux traduire ca avec des mots comprehensibles ...

6

en gros, de ce que j'en ai compris, il a un bug qui se pose sur le fins de lignes dans les structures de sprite. il faut que le dernier bit soit un 0 sinon il faut ajouter un octet complet.


pour faire simple : tu as une ligne dont la valeur est impaire, tu dois alors ajouter un octet à 0 et augmenter l'incrément (le début de la ligne) de 1.

J'ai jamais réussi à reproduire de manière systématique le bug. Même avec un sprite fait de {2,0xFF,2,0xFF,0}... (sprite qu'il aurait fallu écrire {3,0xFF,0,3,0xFF,0,0} en suivant le contournement de bug suggéré)
avatar
Webmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

7

Je viens de tester, tu avais raison vince !
Ajouter un pixel vide m'a resolu le probleme.

Par contre ca va augmeter d'1/3 la taille de mes sprites et j'imagine que ca prend plus de cycles pour afficher ca aussi :'(

Merci pour le coup de main.

(
Si quelqu'un a envie de tester et trouver une autre solution moins couteuse je suis ouvert wink
Je vais essayer sur AA voir si quelqu'un a deja rencontrer le meme truc.
)

8

Ok je pense enfin avoir finalement compris exactement la phrase sur le bug de la doc.
En gros un ligne de pixels ne peut JAMAIS (totally literal, packed/literal) finir par un bit utile a l'affichage, 0 ou 1...
Il doit obligatoirement avoir au moins un bit de padding.
Pfff j'ai eu du mal a comprendre ca. Bon beh je suis foutu alors.

9

Marrant cette histoire.
Maeel (./8) :
Bon beh je suis foutu alors


Tu voulais faire quoi ?

Mon site sur la LYNX :ZoneLynx

10

RYGAR (./9) :
Tu voulais faire quoi ?

Toujours sur le meme projet, j'essaye de gagner quelque cycles cpu ou je peux...

11

Maeel (./10) :
RYGAR (./9) :
Tu voulais faire quoi ?

Toujours sur le meme projet, j'essaye de gagner quelque cycles cpu ou je peux...

Pour le coup, c'est pas grave, le moteur de sprite est sur le copro, donc ça ralentit pas le cpu
avatar
Webmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

12

Bah je suis arrive a un point ou meme Suzy est a bout de force ... :/
Je m'en sers aussi pour les maths.