On a pas besoin de la hauteur pour la calculer ?
Besoin de la hauteur pour calculer la largeur ?
Non !
Sinon, geogeo, je n'ai pas compris pourquoi il faut passer par ta formule compliquée pour avoir le bytewidth. Je pensais que de simplement diviser la largeur en pixels par 8 suffirait...
moi aussi
ms je pense pas que c un problème de bytewidth...
Non tu as juste besoin de bytewidth qui correspond à la taille en octet de l'image en largeur et la hauteur tu entre le nombre de pixel quel fait donc pour une image de 17 pixels en largeur et 52 en hauteur tu fait:
SpriteX8_OR(0,0,52,sprite,3,LCD_MEM);
17-1=16
16>>3=2
2+1=3 octets
Bas le problème c'est quand divisant par 8 ça marche pas c'est d'ailleurs pour ça que je me suis cassé la tête à trouver cette formule qui marche niquel car si tu prend une image de 9 pixels en largeur il te faut 2 pour bytewidth mais si tu divise par 8; 9/8=1,125 or tu obtienderas 1 mais cela est faux.
Ou sinon, plus intuitif mais plus lent (quoique...) : largx/8+(largx%8 != 0)
par kontre g po l'impression que ça accélère énormément le jeu
Ça devrait quand même l'accélérer un peu et puis ça l'accélèrera encore quand tu changeras ta façon de stocker tes images...
ms pr ma façon de stocker les images, ya un pbleme avec les tableaux de pointeurs
si l'utilisateur crée une nouvelle image pour en remplacer une existante, l'adresse changera.
ou ptèt mème si il ya un reset
ou si il retransfère l'image...
Bon g modifié qqes trucs là c bcp plus fluide le curseur va bcp plus vite.
Par contre des qu'il y a une commande (un GO qui doit attaquer un autre GO, ou qui doit marcher), c'est hyper lent, et un peu destabilisant...
Il suffit qu'au lieu de stocker la largeur en pixels, il la stocke en octets...
Sinon, Amosé, je te conseille vraiment de changer ta méthode !
A la rigueur, je peux créer un piti programme qui convertit les PICs en un autre format plus rapide.
Ms à part ça, je ne vois pas trop comment je pourrais améliorer ma méthode...
Tu le rassembles tous dans un fichier !
Et au lancement du jeu, tu remplis un tableau avec l'adresse de chaque image.
oui, ms si les images réunies sont supérieures à 65535 Ko ?
soit tu compresse, soit tu fais deux fichiers
mouè
je pense plutôt ke je v procéder en sets d'images créables par l'user.
La méthode la plus rapide de calculer la largeur en octets est: (x+7)>>3.
La mienne est plus rapide parce qu'elle n'a qu'une addition et un décalage vers la droite. La tienne a un AND et une comparaison (BEQ) en plus.
Oups, désolé, non, celle avec le AND, c'est celle de jackiechan (#157). Mais la tienne (#152) a quand-même une soustraction en plus. Donc c'est bien la mienne la plus rapide.
Mais bon c'est toujours trop lent pour une image en plus au format PIC. Mais à ton avis (w+1)>>3 fonction ou pas? Car c'est celle que je viens de regarder dans pedrom pour la fonction BitmapPut et elle me semble fausse.
mais ça a été corrigé il me semble
warau kado niha fuku kitaru.
#trifouet#!!!
Oui (je viens de regarder), mais pas bien: il a mis ((w-1)>>3)+1 et pas (w+7)>>3 qui est plus efficace.
