I've been debating trying to make a Z80 CPU in Minecraft. It would be crazily difficult and probably run at most at a few cycles per second, but it would still be awesome.

As some may have learned from a poll I posted a while ago, I've been working on a sprite editor in Axe. Or at least I was working on it, but put it down for a while to work on other stuff. But I want to come back to it, and I want to make sure it's as feature-packed and awesome as it can be. So before I get back to work on it, I'd like to know: What features would you want to see in the on-calc sprite editor of your dreams? Did I miss any useful editing tools? Did I miss a file operations feature? Request any features that you don't already see in the list below, or tell me about features already in the list below that you would especially like to see implemented.

Potential features (some are obviously more fundamental than others and will definitely be implemented, whereas others would probably be ridiculously complex to implement):

• Black and white, 3-level gray, and 4-level gray sprites
• Masked sprites
• Sprites of any size
• Viewing and editing at any zoom level, including zoom levels that don't fully fit on the screen (scrolling will be necessary)
• Point tool
• Line tool
• Box tool
• Circle tool
• Variable pen size for drawing commands
• Fill tool
• Text tool
• Hex editing
• Area selection, transforming, cut, copy, and paste
• Palette transformations (e.g. changing the color of all dark gray pixels to light gray and all light gray pixels to dark gray)
• Sprite transformations (flip, rotate, shift)
• Sprite conversion/attribute editing (e.g. changing size, changing gray level)
• Tilemaps
• Animations
• A full filesystem (files, folders, shortcuts, etc. with names and attributes)
• A file explorer
• A menu system
• Shortcut keys for most menu items
• Search
• File sorting in folders by various attributes
• Importing data from and exporting data to pictures, strings, and Ans
• Undo/redo
• File selecting, moving, copying, and deleting from the file explorer
• Batch sprite transformations

Pour obtenir un pointeur à un appvar qui existe déjà et le stocker dans la variable VAR:
GetCalc("appvPLOP")→VAR
Pour récupérer seulement un ou deux octets de l'appvar, il est préférable et plus facile de ne pas utiliser Copy(). Si la variable P contient le pointeur à l'appvar, vous pouvez simplement récupérer un octet (0-255) de l'appvar comme ceci :
{P+OFFSET}Pour récupérer deux octets (un mot, 0-65535), ajoutez un ^r à l'accolade fermante. Et pour stocker cette valeur dans une variable, ajoutez →VAR.

Par contre, si ce post t'a pris 5 minutes, comment celui-là t'a pris???  

À peu près d'une heure.

EDIT: Le fait que j'ai écrit le message sur mon iPod n'a pas aidé probablement.

Let's see how bad my French is.

On peut utiliser des Lbls et des Gotos où on veut, bien qu'il faut qu'on s'assure que pour chacun appel de fonction pendant l'exécution, il y a un Return. Contrairement au TI-BASIC, dans lequel les structures comme les boucles utilisent de la mémoire donc le prochain End saura où à sauter (franchir?), les
boucles dans Axe sont comme là:

Code: (Une boucle dans Axe) [Select] While A<256 A*2->A End

Code: (Comment cela vraiment courrait, représenté dans TI-BASIC) [Select] Lbl A If not(A<256) Goto B A*2->A Goto A Lbl B

Parce que les boucles dans Axe sont comme ça, il ne faut pas qu'une boucle utilise de la mémoire donc la fin de la boucle sait où à aller. On ne peut pas causer une fuite de mémoire par sauter hors d'une boucle. On peut utilise des Gotos dans des fonctions aussi, bien qu'on doit faire attention que les nombres des sub() et des Return qui exécutent sont égals.

On peut faire un appvar comme petit ou comme grande comme on veut, tant que l'appvar va dans la mémoire vive. Le nom, cependant, est limité à huit octets. Pour créer un appvar de taille TAILLE des octets et à mettre un pointeur au début de ses données dans P:
"appvMONAPPVR"->Str1
GetCalc(Str1,TAILLE)->PPour trouver un appvar qui déjà existe et à mettre un pointeur au début de ses données dans P:
"appvMONAPPVR"->Str1
GetCalc(Str1)->P
J'espère que vous pouvez comprendre mon mauvais français.

It takes a pointer to a zero-terminated string that contains the name of the program.

Well actually it would be a bit more complicated than just multiplying by 2. For now, you would have to do something like this:
!If sin(A)→B<ᴇ80
B+ᴇFF00→B
End
.8.8 fixed point result in B
When the signed division auto-optimizations are fixed, a better way will be this:
sin(A)*256//256
EDIT: Disregard all of that, the number comes out as fixed point after all.

Would most maps be filled with mainly one tile like this?

---

EDIT: How about RLE? I made a program (ASHCOSRC) to compress nibble tilemaps with 4-bit RLE for you To use it, change the width and height variables present at the start of the source program to what you want and put the hex for the uncompressed tilemap under GDB0M. Then run the program and the hex for the compressed map will be put into Str1. Your example tilemap compressed very well, from 120 bytes to 24.

And of course, what compression algorithm is any good without the proper decompression algorithm? ASHDESRC is the decompression program. The part of it that is the actual algorithm, which is all you would want, is the code under the tag ".DECOMPRESSION" excluding the Disp "DECOMPRESSING..." line. The decompression algorithm is only 113 103 bytes.

F70002C11002E002F0F00AE00AF0F0F0F0F0F0F04003F060
I hope I made it straightforward and user-friendly enough that you can simply stick all your maps into ASHCOSRC one at a time and easily retrieve the compressed map data. If you have any questions, feel free to ask.

EDIT 2: Uploaded a new, further optimized decompression program. The algorithm is now 103 bytes instead of 113.