hahaha, that'd be so cool if you did it. mine's going for gameplay, where the graphics are pretty simple. you run on a line that can have a +1 slope, -1 slope, or no slope. and then of course there's some blank spaces so you have to jump etc.

Sorry DJ. i meant "In what way" as an actual opening to suggestions, as i do not know how i might implement grayscale into a tilemap editor. I want to know what exact type of grayscale support graphmastur means, to see if it would be a useful feature to the program.

i mean, if you need a 16KB tilemap to be decompressed on a calculator there are a few issues. 1) it would take awhile to decompress, leaving your user waiting. not good. 2) i doubt there's enough room for an uncompressed version of the map on a calculator. so you'd need to decompress the map on the fly while executing the game. this would be very difficult with RLE. making RLE not a realistic compression choice, aka "not for you". "you" being whoever wants to decompress 16KB maps with RLE on a calculator.

lol i see. and yeah, if you're wondering if you could use it to scroll on the fly, i highly doubt it. it'd be better to decompress the whole map into a free RAM area, then scroll off the RAM area.

i sent you my axe parser contest entry awhile ago, didn't i? it uses a similar algorithm, modified because of the tile size. i'd say the maps loaded pretty fast. my newly improved contest entry has the slightest pause between levels.

thanks. it's 85-ish bytes with the for( loop at the beginning, which isn't really necessary just makes it start off cleanly. without the for loop it's 73.

thanks DJ. i like the assigning specific tiles idea, though i'm not sure how the keypad hardware will cope with it. i'll experiment. also, i plan on not limiting to 3 maps. for now, how many maps do you suggest i permit? 1) later on i'm going to RLE compress all the maps in the appvar so you can have more maps. 2) once you can export maps into strings this program will become MUCH more useful. i'm planning on there being options to  have 1 byte = 1 tile in the map, have it half-byte compressed (limit on the tiles though), have it RLE compressed where 1 half byte is the frequency and another half byte is the tile number, and lastly have it RLE compressed where 1 byte is the frequency, and the next byte is the tile number (which would allow for 255 tiles to be fit into two bytes... imagine that.) if anyone has any other preferred compression algorithms i would love to hear them. especially pucrunch. all i need is a commented example of pucrunch and i can hopefully try to implement it.

just so i know where i'm headed, i'm going to make a quick checklist here. they're prioritized:

Tileset.
[] fix looping bug. use the max() command. add some bytes in the appvar.
[] export tiles as hex string
[] load tiles from within the tileset to another tile to make slight variations.
[] set specific tiles as corresponding keys for the tilemap editor
[] allow editing of 16x16 tiles.

*note: allowing more than 15 tiles isn't on here because that's really easy to implement. i'm keeping it basic for now.

Tilemap.
[] export map as hex string
[] compress the hex string in various ways
[] placing tiles via pressing specific keys (such as 1-9, though it may be sin, cos, tan, ",", "(", and ")".)
[] tilemaps greater in size than the screen.
[] 16x16 tile placement.

as soon as 4.0 comes out with BASIC vars, i'll crack away at this. until then, im going to work on my axe contest project (:

If ReturnIf is in a subroutine, it will just exit the subroutine. do you need to have the pause menu in a subroutine? if the subroutine isn't being called more than once, you could just have the subroutine's code in the main program. otherwise, using calcdude4se's method is probably best.