Economiser de la place avec ses pictures ! (BASIC)
Posté le 10/07/2016 15:30
Messieurs-dames, je souhaitaient simplement vous faire part d'une astuce assez simple qui permet, sur deux pictures de 2 x 2048 octets, d'économiser 1024 octets.
Cette technique requiert l'emploi du
Picture 1024 ou d'un add-in remplissant la même fonction.
Le principe est simple. Mettons que nous avons deux pictures indépendantes faisant 2048 octets chacune. En fait, on va créer une troisième picture entre ces deux-là pour économiser de la place.
Un spectateur a écrit :
Mais c'est débile ! On veut économiser des octets et on fait trois pict au lieu de deux ?!
Eh bien c'est là que le picture 1024 de Purobaz entre en jeu. Nous avons en mémoire :
La picture 1 : contient la première image
La picture 2 : Une picture vide
La picture 3 : Contient la deuxième image.
Avec picture 1024, on réduit à 1024 octets la taille de chacune de ces pictures. En employant
RclPict-1, la calculatrice va ainsi lire 2048 octets de picture : soit la Picture 1 (qui en fait désormais 1024) superposée avec la 2 (qui est vide). Pour afficher la deuxième image, il suffit d'utiliser
RclPict-2, La machine va donc afficher la picture deux en premier (vide et qui fait 1024 octets ) et la superpose avec la 3 (notre image 2). Au final, on a le même résultat pour 2 * 2048 - 3* 1024 = 1024 octets de moins !
Voici un petit schéma explicatif :
L'inconvénient de la technique est qu'elle utilise 3 pictures pour le prix de deux. Pour les anciens modèles qui n'en n'ont que 6, c'est un problème. Pour ceux qui en ont 20, cela ne pose pas vraiment de problème.
En espérant vous avoir été utile ! à la prochaine !
Fichier joint
Citer : Posté le 10/07/2016 17:04 | #
Une application simple mais utile du principe de Purobaz. Un schéma peut-être ?
Citer : Posté le 10/07/2016 18:57 | #
C'est fait !
C'est effectivement une application simple, mais on n'y pense pas forcément !
Citer : Posté le 10/07/2016 18:59 | #
Sinon Bg-Pict ne lit que les 1024 octets
(sur 2 x 2048 octets on économise donc 2048 octets)
Citer : Posté le 10/07/2016 19:02 | #
Ohhh, mais c'est que nous avons un puits de science parmi nous
Ce qui signifie que si l'utilisateur ne veut qu'exploiter ses pictures en BackGround, il peut se passer de la picture vide !
Citer : Posté le 15/07/2016 13:09 | # |
Fichier joint
Alors si je fais RclPcit 1, est-ce que ça va m'afficher les pictures 1, 2 et un bout de la picture 3 ou quoi ? Ou bien aurai-je le droit à un "nuage" de pixels aléatoires ?
Citer : Posté le 15/07/2016 13:20 | #
Ça dépend si les Picture sont dans une zone mémoire continue. Vu que toutes les techniques de Remiweb fonctionnent, on peut penser que c'est le cas. Tu aurais alors la Picture 1, la Picture 2 et la moitié de la Picture 3 affichées lors de ton exécution.
Citer : Posté le 15/07/2016 15:33 | #
C'est ce que je pensais également. Je vais faire des essais, et je pense concevoir une grande carte sur mon rpg basic avec du scrolling vertical... ça va être mââââgic 8)
Citer : Posté le 15/07/2016 18:15 | #
Comme cela les maps pourons être carré.
- Kirby's DreamLand : Gobe , Gobe , Gobe !!!
- L'invasion Seanchans : Détruit la flotte ennemis a bord du "Danseur des vagues".
Citer : Posté le 15/07/2016 20:21 | #
Absolument, Fife ! Mais attention : ce sera la carte du monde consultable qui sera comme cela ! Pour ce qui est des maps où le héros circule, elles seront... "normales", si je puis dire !
Ainsi, je pourrai dessiner une carte du monde assez conséquente avec de bons détails, des graphismes plaisants et tout ! j'ai déjà pleins d'idées, c'est génial !
Ajouté le 23/07/2016 à 11:42 :
Encore une question qui me turlupine. Si on reprend cette technique et qu'on divise par deux la tailles des pictures, et qu'au lieu d'employer RclPict, on emploie BG-Pict ?! Cela fonctionne-t'il aussi ?!
Citer : Posté le 24/07/2016 10:12 | #
Remiweb a déjà répondu à cette question x)
Sinon Bg-Pict ne lit que les 1024 octets
Citer : Posté le 24/07/2016 12:36 | #
Non, ma question était plus exactement : Peut-on employer la commande "BG-Pict" à la place des "RclPict" de la même manière que celle que j'ai montré dans ce topic ?
Et la réponse est non. Après plusieurs essais et d'après ce que me dis Remiweb, BG-Pict ne lit effectivement "que les 1024 octets", mais plus précisément il n'affiche qu'une seule picture en fond d'écran, qu'importe sa taille. Si la picture ne fait que 512 octets, c'est-à-dire une moitié d'image, la commande BG-pict n'affichera en fond d'écran que cette "moitié" d'image, c'est-à-dire qu'il ne lira que les 512 octets de la picture renseignée.
Cela peut-être intéressant, pour celles et ceux qui désirent créer une side-bar, un menu ou autre en haut de l'écran (en combat par exemple) tout en ayant un truc bien fichu. Il suffit de l'enregistrer dans une picture, de réduire à la plus petite taille possible (256 octets voire moins, l'add-in de Purobaz offrant une très large gamme de possibilités de taille) et de l'afficher avec la commande "BG-Pict". Je ne sais pas si certains connaissaient cette astuce, du coup, mais il serait intéressant de la communiquer.
Tenez, par ailleurs, pour vous simplifier la tâche : BG-Pict (le lien vers BG-None de cette page ne fonctionne plus, par ailleurs.)
Citer : Posté le 26/07/2016 18:27 | #
Cette astuce est connue.
Ça permet plus généralement de réduire un peu le poids des images s'il y a du vide en bas.
J'ai coupé de cette manière chaque image utilisée dans mon Zelda.
D'ailleurs si tu avais lu la description et regardé l'image de l'add-in Picture 1024 tu aurais vu que tout ça est expliqué
Ajouté le 26/07/2016 à 18:36 :
Pour ce qui est du scrolling on peut tout à fait utiliser des images plus petites. Je m'étais amusé à le faire avec des images d'une 10e de pixels de haut.
Il faut juste créer les images d'une manière précise pour qu'on ai pas de chevauchement et toujours 2048 octets à lire :
J'avais déjà essayé d'expliquer ça rapidement ici et aux pages précédentes.
Citer : Posté le 26/07/2016 20:29 | #
Si, j'avais bien compris ce qui était expliqué avec ce schéma que tu me montres ! Seulement, je ne savais pas que le BG-Pict adoptait un comportement différent !
Maintenant que tu le dis, j'étais passé à côté de ceci :
BG-Pict lit seulement la picture désignée
Donc autant/au temps (choisissez) pour moi, trop d'informations et je passe à côté ! Tant de potentialités !
C'est émouvant...