C'est aussi à envisager... par contre il y a de grandes chances qu'on laisse la dernière MAP utilisée dans la RAM. En gros à chaque nouvelle partie on déplace la MAP choisi vers cet MAP temporaire (c'est à ce moment qu'il faut décompresser l'archive).

Seul l'éditeur de MAP pourra copier la MAP temporaire vers une appvars archivé (+ compression de l'image). Donc lorsqu'on édite une map on édite tout le temps la map temporaire (dans la RAM). De même lorsqu'on joue ce sera tout le temps la la map temporaire qui sera détruite.

@Hayleia : je viens de penser à un truc pour une option "annuler action". En gros on sauve l'écran dans l'appvar à un seul moment, c'est quand on appuie sur une touche pour déplacer ou dessiner ou faire apparaître le menu (une option que je viens d'inventer :p). Dans un code :
If touches de déplacement ou autre
:If A
:copier écran dans l'appvar
:0=>A
:End
:.code si touches de déplacement ou autre
:Else
:1=>A
:EndJe vais tester un truc pour copier l'écran dans l'appvar. (pas sûr que ça marche)

Le but de la variable A est une manière comme une autre pour ne pas sauvegarder l'écran à chaque boucle, mais seulement quand on commence à presser les touches.

Après la méthode que je pensais était d'utiliser un bitmap trafiqué de L6 dans l'appvar via une astuce simple : en utilisant {L6-1} et {L6-2} pour y rentrer des coordonnées. Je n'ai pas trouvé exactement à quoi servaient ces deux octets, mais ils ne m'ont provoqué aucun bug à l'extinction du programme. Au pire on peut restaurer les valeurs qui étaient en début de programme, mais c'est pas le plus important (moi elles était à 0).

Après je n'ai pas tout à fait idée de la manière à utiliser car la commande bitmap est faite pour afficher sur un buffer de 768 octets, donc est ce que cela pourrait marcher ? (il faudrait poser la question à runer :p )

EDIT : Après discussion avec runer, je pense qu'on a trouvé une solution pour
- éditer l'appvar via les explosions du jeu, en fait il faudra faire nos propres automates cellulaire qui modifient directement l'appvar. Il en faudra donc pour les explosions et les flammes (en gros un simple cercle ne suffit pas :'( ). De cette manière on édite même en dehors de l'écran, donc on peut faire pleins de belles explosions.
- pour éditer l'appvar via l'éditeur de map, le plus "simple" serait de copier l'écran vers l'appvars au bon endroit. De cette manière on peut faire "annuler action" mais l'éditeur empêchera d'éditer plus que l'écran. Le code que je pensais étais quelque chose comme Bitmap(0,0,L6,APPV,1), et ce en modifiant au fur et à mesure les 64 lignes de l'écran vers l'appvar. Un code prototype :
:getCalc("appvAPPV")=>APPV
:For(I,0,63)
:96*256+1=>{I*12-2+L6}r
:.Après comme on affiche l'appvar directement sur l'écran on verra pas les trucs modifiés
:Bitmap(0,0,I*12+L6,I+X*32+Y+APPV,1)
:End

N'oublie pas que c'est du pixelmapping, donc au bit près.
T'as raison sur un point, on se casse la tête pour faire un truc non optimisé. Si tu regarde le smoothscrolling de runer, il y a exactement  la même routine (DrawR) qui fais ce que l'on cherche, mais dans l'autre sens... à exploiter.


EDITtest :
C'est DrawY en fait qu'il faut regarder !
:Lbl DrawY
:Copy(→r1-Y*32+°IMG+2,L1+2,32)
:Fill(r1*12+L6,12,ᴱ0100→{L1}r)
:Bitmap(X,r1,L1)
:ReturnIl ne reste plus qu'à comprendre comment ça marche.

  Excale !
On te vois pas souvent sur omnimaga.


Bon hayleia, pour récapituler le moteur smoothscrolling pixelmapping de runer, j'ai tout compris et j'ai commenté en français à outrance (quitte à ce que tu comprenne, autant y aller à fond).
Donc à part le petit bilan sur les masques (mask en anglais), tu devrais déjà tout comprendre :

.PIXELM Map scrolling test
"|vSAVE"→^^oSAVE
L5→^^oIMG
Return!If GetCalc(^^oSAVE)
→IMG
DiagnosticOff
FnOff
ClrDraw
.Affichage de la map
Bitmap(~80→X,~64→Y,IMG)
...
Petites explications :
Les coordonnées X et Y sont compris entre ~160 et 0 (les deux)
Car 160+96=256
Y-1 c'est une ligne en dessous, et X-1 une colonne à droite
Autre optimisation
-X sera donc positif (de même pour -Y)
...

.Boucle principale
While 1

DispGraph

If getKey(1)
.Si il n'y a pas le bout de la map en bas
!If Y-1<~160
Y--
.On décale en bas
Vertical -

.Pour afficher la ligne 63 manquante
63:DrawY()
End
End

If getKey(2)
.Si il n'y a pas le bout de la map à gauche
If X
+1→X
.On décale à gauche
Horizontal +

.Pour afficher la colonne de gauche (L comme left) manquante
DrawL()
End
End

If getKey(3)
.Si il n'y a pas le bout de la map à droite
!If X-1<~160
X--
.On décale à droite
Horizontal -

.Pour afficher la colonne de droite (R comme right) manquante
DrawR()
End
End

If getKey(4)
.Si il n'y a pas le bout de la map en haut
If Y
+1→Y
.On décale en haut
Vertical +

.Pour afficher la ligne 0 manquante
0:DrawY()
End
End

EndIf getKey(15)
Return

.Affiche les lignes
Lbl DrawY
.On copie les 256 pixels d'une ligne de l'appvar dans L1+2
Copy(→r1-Y*32+IMG+2,L1+2,32)

...
On efface la ligne à remplacer
parce que la commande vertical +/- ne le fait pas
autant faire une optimisation pour remplir les deux premier octets de L1
correspondant à la taille de la bitmap à afficher
...
Fill(r1*12+L6,12,|E0100→{L1}^r)

.Et la c'est magique, la ligne s'affiche
Bitmap(X,r1,L1)
Return

.Pour la colonne de droite
Lbl DrawR
.Dans cette octet on est en haut à droite de l'écran (buffer)
11+L6→r3
.Ici le masque de l'écran est 00000001, parce que c'est bit tout à droite que l'on veut modifier
|E01→r4
95
Goto Draw0

.Pour la colonne de gauche
Lbl DrawL
.Dans cette octet on est en haut à gauche de l'écran (buffer)
L6→r3
.Le masque de l'écran est 10000000, parce qu'on veut modifier le bit tout à gauche
|E80→r4
and 0
 
 .Affiche les colonnes
Lbl Draw0
...
Rappel : HL-X vaut le nombre de colonnes
Optimisation assez tordue, nombre de colonnes^8 correspond au nombre de bits qui séparent le
dernier octet du bord de l'écran en valeur numérique
Donc quand ça vaut 0, r2 vaut le premier Masks10000000
Donc quand ça vaut 1, r2 vaut le deuxième Masks01000000
Donc quand ça vaut 2, r2 vaut le troisième Masks00100000
Donc quand ça vaut 3, r2 vaut le quatrième Masks00010000
Donc quand ça vaut 4, r2 vaut le cinquième Masks00001000
Donc quand ça vaut 5, r2 vaut le sixième Masks00000100
Donc quand ça vaut 6, r2 vaut le septième Masks00000010
Donc quand ça vaut 7, r2 vaut le huitième Masks00000001
...
Select(-X,{^8+^^oMasks}→r2)

.le nombre de colonnes/8 + le nombre de lignes (en octet) + le début de pointeur de la map dans HL
*32/256-(Y*32)+IMG+2

.Pour les 64 lignes
For(64)

...
Le plus chaud :
On masque octet trouvé dans l'appvar pour garder que le bit qu'il nous faut
Quand on soustrais par 1 et qu'on divise par 256 :
si aucun bit ne correspondait au mask, 0-1=65355 puis /256 ça fait 255
Si un bit correspondait au mask alors ça renvoie un nombre en 1 et 128 dans HL
HL-1/256 vaudra toujours 0 dans ce cas là (logique)
En inversé on créé un nouveau mask qui est soit 255 (un bit correspond au mask
soit 0 (aucun bit correspond au mask)
En fait cette manip sert juste à aligner le bit trouvé dans l'appvar, au bon
emplacement sur l'écran, donc là vient r4 le masque de l'écran
Ensuite un or logique permet d'ajouter le bit (ou non) dans le buffer (pointé par r3)
Et après il y a une dròle d'optimisation {r3}+12->r3 car ça fait r3+12->r3 en réalité o_o
...
not({→r1} and r2-1/256) and r4 or {r3}→{r3}+12→r3

.On passe la ligne suivante ^^
r1+32
End
Return


[8040201008040201]→^^oMasks

Generated by the BBify'r (http://clrhome.org/resources/bbify/)

Je me suis permis de modifier la taille de la bitmap en 256*256 pixels. La prochaine étape sera de faire 3 modes : 256*256, 512*128, 1024*64. Après cela je m'attaquerais à la sauvegarde dans l'appvar.


PS : t'as pas intérêt de pondre un truc comme ça au TI-Concours.

Bon, ça marche plutôt bien, j'ai optimisé quelques trucs et commenté le code comme promis. Un aperçu de ce que ça donne avec le moteur smoothscolling juste derrière.
Les ajouts que j'ai fait :

• Parcours de la pixelmap sans dépasser les limites de celle-ci.
• L'enregistrement dans l'appvar marchait très bien (bravo hayleia), mais maintenant c'est optimisé pour.
• Ajout de l'option "annuler dernière action" en appuyant sur le touche "del".

Bug trouvé :

• Lors du passage sous smoothscrolling pixelmapping il y a un décalage. Il est possible que l'éditeur de map n'édite et ne sauvegarde pas avec une bonne largeur (j'ai déjà repéré la ligne), mais j'ai pas le temps de faire ça ce soir.

edit : bug corrigé, tous marche à perfection.
Pour l'instant ça nous fais 2608 octet éditeur de map et 870 pour le smoothscrolling, il va falloir y aller molo quand même sur cet éditeur.
Par exemple : peut être que le lors du changement de pinceau on a pas besoin de centrer le pinceau dans un carré ?
Je regarderais plus tard, mais il me semble que les fonctions d'affichage sont pas très optimisées.

"L'enregistrement dans l'appvar marchait très bien (bravo hayleia), mais maintenant c'est optimisé pour. "
Optimisé pour... pour quoi ?

En gros maintenant ça édite l'appvar MAPTEMP au lieu d'en créer une à chaque fois, de plus il y a quelques optimisations de réduction du poids se font à l'aide de cette appvar, ainsi que la fonction "annuler action". Donc la sauvegarde de l'appvar est en temps réel.

"il me semble que les fonctions d'affichage sont pas très optimisées."
Celles que j'ai faites ou les fonctions de l'Axe ?

Je pensais aux fonctions, mais finalement ce n'est pas si simple. Donc je préfère laisser comme ça.

EDIT : pour l'instant je suis à 280 octets pour lister les maps. Voici le pastebin (commenté) et un screen + source.

EDIT 2 : à noter qu'il y a quand même une fail dans le screen, c'est qu'à la fin il cherche super loin donc il trouve une valeur plus loin que la VAT. Donc il faut rajouter une 3ème condition...

Après avoir testé pas mal l'éditeur de dessin, je me suis rendu compte qu'il n'éditais pas la map à cause de la barre d'option en bas (je vais donc régler ça).

Sinon, pour la map, je suis assez d'accord pour dire qu'on pourra faire plein de tests dessus dans la mesure ou elle est bien variee.

Quant au code, qu'est-ce qui est routine, et qu'est-ce qui est boucle ?
Sinon, pour l'organisation, le "code" parait correct