I can't wait to receive your programs.

J'avoue que ce n'est pas très clair, mais c'est un brouillon pour la suite : je compte d'abords faire le moteur de déplacement des worms et le système de visé qui ne nécessite pas de gravité. Après viendra le moteur avec les sauts et les chutes, puis le reste coulera plus "facilement" une fois qu'on aura une bonne organisation.

Ou sinon, voici l'éditeur de dessin avec le bug des 7 dernières lignes corrigé.

Le tout n'est pas de finir le premier, mais de faire le meilleur programme.

Cependant vous pouvez mettre une première version sur le site, puis mettre à jour autant de fois que vous voulez.

Currently written:

• Fixed-Memory Flood Fill (needs optimization)

"Fixed-memory" means there is no risk for stack overflow AT ALL. However, the routine is subsequently very slow, so it will not be suitable for games or anything that needs fast dynamic area filling. It would be fine for a "paint bucket" tool in most on-calc graphics programs though. This will *hopefully* support grayscale filling as well.

Is this feature released ? Which command do that ?

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), et je me suis amusé à faire une map en cours (plus ou moins réussi) en même pas 15 minutes j'ai fais ça. C'est très efficace. 

Après je suis en train de penser au fonctionnement du jeu principale, ça pourrait prendre cette forme :
:Lbl Initialisation
:.Chargement de la map dans l'appvar (sauf si on garde celle déjà présente dans l'appvar)
:.Apparition des worms aléatoire sur le terrain (partie blanche de la map) + gravité (voir moteur physique)
:
:Lbl déplacement
:.caméra centré sur un worm
:.gestion des sauts à l'aide du moteur physique (seulement lors d'un saut)
:.Visé avant de tirer (on pourra utiliser des cos et sin préalablement enregistrés dans une liste)
:
:Lbl phase de tire
:.Explosions, flammes
:.Bref, tout ce qui risque de lagger :)
:
:Lbl caméra
:.S'occupe du déplacement de la map
:
:Lbl Moteur physique
:.Caméra centré sur l'action
:.Gravité + chute
:.frottements
:.Gestion des dégâts (sauf à l'initialisation)
:
C'est assez approximatif, mais c'est un début. Je serait intéressé d'avoir tes conseils là dessus (même si tu as le TI-Concours).

Ou sinon, j'ai eu la remarque que la map était un peu trop grande en hauteur...

Comme l'a dit torio, le problème vient très probablement de ton code. Pt-Change() inverse tous les pixels, Pt-On() affiche seulement les pixels noir, et Pt-Off() affiche le blanc et noir.

Si le bug persiste, il faut reporter le bug avec un code et un screen si tu veux que ce soit traité rapidement.

Or can the projects be about everything.

You got the answer.

Plop,
I want to compress my bitmap (monochrom) 256*256 pixels (8192 bytes). I tried to make my own rle compression in this way : the first bit to determinate state (1 = pixel on, 0 = pixel off) then 7 bits are used to indicate number of pixels to fill with this value.
eg. this code :
[FFFFFFFFFFFFFFFF0000]Should be :
[C010]
Here my code, it leave program without reason. That's probably due to a corrupted RAM (each time it display ARC>7500Ko ).