The multi-movement routines were functions where you give it your x&y variables and a step size and it will check all arrow keys and move depending on what was pressed. There was another that would also check for tile collisions as well. This means that you can move a sprite depending on what keys were pressed, and if the position it moves to is walkable in 1 real( request. It saves a lot of extra code in your program.

The command takes a max walkable tile argument when you call it. So if you normally have tiles 0-31 and water from 32-37 then you can just set it higher later on.

Yes that should more than fine

EDIT - Also i added support for xLIB BG PIC's which are small res 80x60, 256 colour images that are scaled to fullscreen. These only take up 4800 bytes and could possibly be used for simple backgrounds, titlescreens or RPG battle backgrounds etc.

Here is a demo of a few strung together:



.

Yeah, currently the pixels are 4x4 and it is a pretty low resolution image. But with the addition of colour it can be used effectively. I still need to fix a small issue with them but for the best part they are good to go.

I am still wondering about the best way to store tilemaps, im still leaning towards HEX Strings. xLIB will have some support routines to make working with string tilemaps a little easier like:

getTile - return tile at x,y in Ans
setTile - set tile at x,y in tilemap
numToStr - convert number to string in Ans
strToNum - convert string to number in Ans
moveXYCT - adjust x,y depending on keypresses and check for tile collision

Any other ideas?

Seeing this developing, I wouldn't mind play a game with 4*4 pixel if I get a decent framerate!

Well the bgpic's are 4x4 pixels but you are correct about the 8x8 sprites.

Although you can draw sprites of any size, they are broken into 8x8 tiles when defining them.

I have managed to bring the code back up to speed since the data loss, and it is appropriately backed up .

So far the list is:

Tilemap 8x8, 256 colour tiles, tiledata stored as strings
Sprites any size, clipped with transparency
Custom tile/sprite pic's, 128x64, 256 colours stored as appvars, unlimited number (custom named), can be archived
Custom 'bgpic' 80x60, 256 colours stored as appvars, unlimited number (custom named), can be archived
getTile returns tile in Ans
getKey with flexibility routines, can test for multiple keys in 1 call, can check for tile collisions etc
User variables, 256 * 16-bit variables (or memory slots) that most functions utilise (can still use TIOS for calculations etc but will need to store in a user variable for some routines)

Planned:
Text routine
Line & shape drawing
ExecuteArchivedProg (just a copy+paste from old xLIB really)
More getKey support routines
Sprite collision routine
Other stuff ...

Now that I have some basic functionality, ill see if I can make a decent test program.

Add shape collisions and transformations such as rotation and resizing

Wait, I thought map data was in appvar format like Axe unless in use, in which case it was string-based?

IIRC your goal was originally to eliminate any need for program copying (archive to RAM) and the need to split map data into multiple sub-programs to temporarily fit in RAM at all.

If it's always in string, do you think the basic data could use base-37? That way each tile takes 1 byte (0 to Theta) instead of 2 (00 to FF).