Yeah ill be sure to update the wiki once its released. The bug fixing is going well, im nearly there i think .

Yeah that features should be handy although it will take some understanding of how sprites are structured in memory from a data perspective, but i can help out with that .

Also the conversion tool now does nearest colour matching with the xLIB palette as well.

I have also made the DRAWSTRING_VALUE function return the converted value as a string in Ans if anyone would find that useful.

I am busy testing everything as much as i can prior to release, if anyone has any other bugs etc can they please let me know. Also if anyone just wants to test out random functions to see if they work i would be grateful as well .

Tr1p1ea, I found a bug with DrawSpriteBGB

:real(0,1,1
:real(5,0,0
:
:"000102030405060708091011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859
:Ans+Ans+Ans+Ans+Ans→Str0
:For(Z,0,1
:real(3,0,0,0,20,10,0,0,19,14,1
:End
:real(1,1,0,76
:real(1,1,1,56
:While 1
:real(4,5,0,1,2,2,0,0,160,0,20,10
:real(2,2,0,1,1,1
:real(4,1,0,1,1,1,0,0,112,1,0,21
:End

Basically, no matter the value of uservar #1 (which I use as Y value), the background will always display the same row of tiles from the tilemap, like if the tilemap Y always started at zero. X works fine, though. When I use TI-OS values, I don't have this problem. For example, the following code works fine:

:real(0,1,1
:real(5,0,0
:
:"000102030405060708091011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859
:Ans+Ans+Ans+Ans+Ans→Str0
:For(Z,0,1
:real(3,0,0,0,20,10,0,0,19,14,1
:End
:real(1,1,0,76
:real(1,1,1,56
:While 1
:real(1,0,0->A
:real(1,0,1->B
:real(4,4,A,B,2,2,0,0,160,0,20,10
:real(2,2,0,1,1,1
:real(4,1,0,1,1,1,0,0,112,1,0,21
:End

EDIT: Nvm, fixed. It's because map width is an uservar too, but wiki didn't specify that.

Indeed, I was happy when I saw it was out.

Feature suggestion for the map functions: A mode which supports 1-bit tiles. That way, people who only uses two kind of tiles per map would have much smaller map data. There could be an extra argument allowing the use of three kind of tiles, where you would choose a 3rd tile for walls (rather than just floor and ceiling). Both the ceiling and floor would be 0, while the floor would be 1, and whether a wall or ceiling tile appears would be determined based on if the tile right below it is a floor tile.

Maybe an option to have a cliff tile instead of wall (displaying below the floors instead of above) would be nice too.

Illusiat 6, 7, 9, 10, 11, 12, as well as Mystique and many parts of Mana Force 2 and the Reign of Legends series used such map format and Illusiat 12/Mana Force 2/ROL series used the triple tiles trick. Most maps in those games were stored inside pictures (8xi files), in which each tile were 1-bit.

I would definitively be helpful, otherwise if me or someone was to ever port Illusiat 12 to the 84+CSE, for example, map data would be 8 times larger

It isn't really flooding as double (tripple, quadruple, ...) etc posts are allowed if the last post is more than a day ago, which is clearley the way in this case.

What Soru and Art said. You are beginning to sound trolling/provocative there (since it is the 2nd time in a week). I find it ironic that people who constantly double-post or get warned for spamming suddenly starts reprimanding others for doing the same thing. They should start improving first before telling others what to do.