So how's the progress on this nameless beast?

* noahbaby94 pokes metagross111 for progress.

?

It's going alright so far. No name and no story, but everything is going well so far.

Syntax for xLib/CelticII versions of MAPDRAW for reference (ripped from the README by Iambian):-----------------------------------------------------------------------------
|04             | identity(4,"BINSTR",xPos,yPos,Width,Height,StartX,EndX,
|               | SStartY,SEndY,Pic#,Logic,TileSize,Update_LCD,2ByteMode)
|  STRINGTILE   |
|               | See xLIB command "DrawTileMap" for information regarding
|               | the inputs. The only difference is that "Matrix_name" is
|               | replaced with "BINARYSTRING". For this, you supply a hex
|               | string converted to binary with the HEXTOBIN command.
|               | The Height and Width property of the command is used to
|               | provide a two-dimensional matrix feel to an inherently one-
|               | dimensional structure that is a string.
|               |
|               | If 2ByteMode is set to something other than 0, then the
|               | input string is considered words instead of bytes. This
|               | allows the user to use 4 hex ditgits (two bytes) per tile
|               | so up to 65536 different tiles can be accessed using this
|               | command.
|               |
|               | All other arguments function as they do with the xLIB
|               | command.
|               |
|               | As a developer, you should develop your tilemaps in hex
|               | and then use the HEXTOBIN command to convert it to the
|               | format required by this command. To edit this tilemap, you
|               | should use the EDIT1BYTE command while this tilemap is in
|               | its binary format.
|               |
|               | Note that any missing arguments will default to the value
|               | of zero (0) instead of 32 as in xLIB.
-----------------------------------------------------------------------------
|02             | real(2,Matrix_name,x_offset,y_offset,Width,Height,SStartX,
|               |      SEndX,SStartY,SEndY,Pic#,Logic,TileSize,Update_LCD)
|  DrawTileMap  |
|               | Probably the most complicated function. I don't understand
|               | it fully, so I'm just gonna copy out of the manual, with a
|               | bit of paraphrasing to fit the line limits. Later, I'll
|               | revise this section with my findings.
|               |
|               | Matrix_name: Name of matrix with map data. 0=[A], 9=[J]
|               | x_offset: x-offset for the part of map you want to draw.
|               | y_offset: y-offset for the part of map you want to draw.
|               | Width: width of the tilemap
|               | Height: height of the tilemap
|               | SStartX: column to start drawing. 0-12 (8x8) or 0-6 (16x16)
|               | SEndX: column to end drawing. 0-12 (8x8) or 0-6 (16x16)
|               | SStartY: row to start drawing.  0-12 (8x8) or 0-6 (16x16)
|               | SEndY: row to end drawing.  0-12 (8x8) or 0-6 (16x16)
|               | Pic#: Pic file to start looking for tiles from.
|               | Logic: 0=Overwrite; 1=And ; 2=Or ; 3=Xor
|               | tile_size:set to 16 for 16x16 tiles. Otherwise, it's 8x8.
|               | Update_LCD: If this is !=0, the screen updates.
|               |
|               | The SStartX, SEndX, SStartY, and SEndY allow you to draw a
|               | "windowed" map so you can fit things on the side, like an
|               | HUD or something. Drawing will also be accelerated for
|               | smaller maps. For example, if you wanted to draw an 8x8
|               | tilesized map with a 1 tile blank border on all sides...
|               | SStartX : 1
|               | SEndX   : 11
|               | SStartY : 1
|               | SEndY   : 7
|               |
|               | This routine supports up to 65535 tiles, each starting from
|               | the Pic number you specified and following to each
|               | numerically adjacent Pic # for each overflow. lolwut?
|               |
|               | Let's say your starting Pic# is 5 and you want to access
|               | tile 4324. There are 96 tiles per pic on 8x8 mode, so...
|               | (4324 / 96 ) = 45.04...
|               |
|               | In order to access that tile, Pic50 must exist on the calc,
|               | else all will be drawn is a BLANK tile.
|               |
|               | Just like any of the useful functions, Pic data will be
|               | read from archive if need be. It'll be slower, though.
|               |
|               | An additional feature added into the sprite routine is the
|               | ability to invert the sprite prior to displaying. To do
|               | this, add 4 to whatever you use for LOGIC. For example, to
|               | invert a sprite and use XOR display logic, use 7 since 3+4
|               | is 7.
|               |
-----------------------------------------------------------------------------
Well, let's break it down a bit. It seems to use a binary string from the hex map code. It seems to read tiles from a PIC tile sheet system the same way as the xLib incarnation does. Most of the commands are exactly the same, but if you are wondering how the STRINGTILE version works, I'll explain it the best I can.

Basically, lets say I want to display a map of 8x8 tiles (from the top to the bottom and from left to right, no borders). Instead of having a matrix stored to read from, they use a binary string, a long row of tokens that will make no sense to the user read. Ever unlock an ASM program file to see what the inside looked like? It's a bunch of tokens, denoted from 00 ("?") to FF ("LinReg(ax+b)"). Confused yet?

Well, don't be. The binary string is only a format that "identity(4" needs. We don't need to make sense of it. The hex is what is important, and I'm gonna get into that.

Now, we can fit a 8x12 grid map onto the screen with 8x8 tiles (however, I'm doing a 6x12 with a blank top and bottom border, don't forget this. I know we can fit 8 tiles from top to bottom ). The overworld tiles are located in, say, PIC1 and PIC2. Let's say we have a grid map of:

LLLLLLLLLLLL
TTTTT  PTTTT
    Y       
LLL      LLL
LLLLH  HLLLL
LLLLH  HLLLL
It is not to scale of course, a fault of the font. But we can live with it. It's a half-assed piece of a dungeon map anyway. Instead of thinking of ASCII, see each character space as an 8x8 tile. Let's pretend the below is our tile sheet thing.

PIC1         PIC2
 XXXXXXXXXXL XXXXXXXXXXXX
XXXXXXXXXXXX XXHXXXXXXXXX
XXXXTXXXXXXX XXXXXXXXXXXX
XXXXXXXXXXXX XXXXXXXXXXXX
XXXXXXXXXXXX XXXXXPXXXXXX
XXXXXXXXXXXX YXXXXXXXXXXX
I left most of the "tiles" as Xs to denote it being some random sprite not used in the above map. Now, in the xLib version, the tiles in a tile sheet were normally labled decimally, so their identifiers on a tile sheet could be:

00 01 02 03 04 05 06 07 08 09 10 11
12 13 14 15 16 17 18 19 20 21 22 23....
...and so on. Once all the tiles in Pic1 are labeled, you continue on in Pic2 from 72 to 143. And if you have more than 143 tiles, you can continue up to the next pic and the pic after that, all the way up to the 65535th tile. So, in the xLib command, you would have a sample matrix that looks like this:

[[  11,  11,  11,  11,  11,  11,  11,  11,  11,  11,  11,  11]
 [  28,  28,  28,  28,  28,  00,  00, 125,  28,  28,  28,  28]
 [  00,  00,  00,  00, 132,  00,  00,  00,  00,  00,  00,  00]
 [  11,  11,  11,  00,  00,  00,  00,  00,  00,  11,  11,  11]
 [  11,  11,  11,  11,  86,  00,  00,  86,  11,  11,  11,  11]
 [  11,  11,  11,  11,  86,  00,  00,  86,  11,  11,  11,  11]]
In which 00=" ", 11="L", 28="T", and I think you get the rest. That is how the xLib command works.

Now, the "indentity(4" command is fundamentally different in two other ways besides using a binary string. For one, it is a string, with one dimension. The command will require you to set the physical parameters of the map (still 6x12). This will cut off the string after 12 tiles and start the next row. For two, this command will have a hexadecimal tile-counting system. So, their identifiers will look like this:

00 01 02 03 04 05 06 07 08 09 0A 0B
0C 0D 0E 0F 10 11 12 13 14 15 16 17....
...and so on. However, this will only allow up to the 255th tile (FF). There does exist an option to go as far as the 65535th tile, but more on that at the end. So, in matrix form, the above map could be depicted as:

[[ 0B, 0B, 0B, 0B, 0B, 0B, 0B, 0B, 0B, 0B, 0B, 0B]
 [ 1C, 1C, 1C, 1C, 1C, 00, 00, 7D, 1C, 1C, 1C, 1C]
 [ 00, 00, 00, 00, 84, 00, 00, 00, 00, 00, 00, 00]
 [ 0B, 0B, 0B, 00, 00, 00, 00, 00, 00, 0B, 0B, 0B]
 [ 0B, 0B, 0B, 0B, 56, 00, 00, 56, 0B, 0B, 0B, 0B]
 [ 0B, 0B, 0B, 0B, 56, 00, 00, 56, 0B, 0B, 0B, 0B]]
In which 00=00=" ", 11=0B="L", 28=1C="T", and I think you get the rest this time too, yay! However, it is not used this way! :O   Rather, the hex code will be condensed into a string, which looks like this:

"0B0B0B0B0B0B0B0B0B0B0B0B1C1C1C1C1C00007D1C1C1C1C0000000084000000000000000B0B0B0000000000000B0B0B0B0B0B0B560000560B0B0B0B0B0B0B0B560000560B0B0B0B"
AND! Once you use HEXTOBIN, you get the code that is compatible with "identity(4" to make such a map!

"°°°°°°°°°°°°R►PΘ(R►PΘ(R►PΘ(R►PΘ(R►PΘ(??DependAskR►PΘ(R►PΘ(R►PΘ(R►PΘ(????Trace???????°°°??????°°°°°°°V??V°°°°°°°°V??V°°°°"
The syntax for the map I described would be (if I stored that string to Str1):

identity(4,"BINSTR",xPos,yPos,Width,Height,StartX,EndX,SStartY,SEndY,Pic#,Logic,TileSize,Update_LCD,2ByteMode)

identity(4,Str1,0,0,12,6,0,12,1,7,1
The README explains in detail some of the arguements, but that's about all there is to it! I have one last thing to say, though. The last modifier, 2ByteMode, allows us to go into 2ByteMode when the value is one. This lets us use a word rather than a byte to denote a tile. Instead of 00-FF (256 tiles), we use 0000-FFFF (66536 tiles!). So effectively, you will need to treat the above hex tables like this:

0000 0001 0002 0003 0004 0005 0006 0007 0008 0009 000A 000B
000C 000D 000E 000F 0010 0011 0012 0013 0014 0015 0016 0017....
and...

[[ 000B, 000B, 000B, 000B, 000B, 000B, 000B, 000B, 000B, 000B, 000B, 000B]
 [ 001C, 001C, 001C, 001C, 001C, 0000, 0000, 007D, 001C, 001C, 001C, 001C]
 [ 0000, 0000, 0000, 0000, 0084, 0000, 0000, 0000, 0000, 0000, 0000, 0000]
 [ 000B, 000B, 000B, 0000, 0000, 0000, 0000, 0000, 0000, 000B, 000B, 000B]
 [ 000B, 000B, 000B, 000B, 0056, 0000, 0000, 0056, 000B, 000B, 000B, 000B]
 [ 000B, 000B, 000B, 000B, 0056, 0000, 0000, 0056, 000B, 000B, 000B, 000B]]
as well as this...

"000B000B000B000B000B000B000B000B000B000B000B000B001C001C001C001C001C00000000007D001C001C001C001C00000000000000000840000000000000000000000000000000B000B000B000000000000000000000000000B000B000B000B000B000B000B0056000000000056000B000B000B000B000B000B000B000B0056000000000056000B000B000B000B"
and finally this...

"?°?°?°?°?°?°?°?°?°?°?°?°?R►PΘ(?R►PΘ(?R►PΘ(?R►PΘ(?R►PΘ(?????DependAsk?R►PΘ(?R►PΘ(?R►PΘ(?R►PΘ(?????????Trace???????????????°?°?°?????????????°?°?°?°?°?°?°?V?????V?°?°?°?°?°?°?°?°?V?????V?°?°?°?°"
In which, the syntax is almost exactly the same, just the last 4 modifiers are shown with 1 for 2ByteMode:

identity(4,Str1,0,0,12,6,0,12,1,7,1,0,0,0,1
OK! Finished explaining it! I did some testing that supports all I've said, though I would appreciate anyone (particularly Iambian) to look at it and point out any errors. THIS is how "identity(4" works, and I hope you all find it useful!

On a final note, the map can really be any dimension as long as it isn't too big for the calculator. Just change "xPos,yPos" as needed, you can refer to the README. It will only show that portion of the map, since the entire thing cannot fit on the screen at times, obviously. This can be used with maps that move with you.

FEEL FREE TO ASK ANY QUESTIONS ABOUT MY EXPLANATION!

thanks. took a bit of my evening though, and i still have analytical trig to do

EDIT: on even another note, I should stress that I haven't TRULY tested the map routine. Most of this is educated guess and speculation. It makes perfect sense to me, though there could still be descrepancies.

IMO, it would be much slower to DEVELOP and program. however, as a program, i think it could be about as fast or faster than the traditional matrix method. in any case, this supports a much larger map than matrices ever could. also, in conjunction with other celtic commands, i think it will run just fine.

no, but i believe myself intelligent enough to do without

well, i was actually talking about much larger maps, since you would have to put it all in hex by yourself. at least, until i work on some sort of tile program to convert them automatically