IDENTITY(4) FAQ
This is an archived, read-only copy of the United-TI subforum , including posts and topic from May 2003 to April 2012. If you would like to discuss any of the topics in this forum, you can visit Cemetech's Your Projects subforum. Some of these topics may also be directly-linked to active Cemetech topics. If you are a Cemetech member with a linked United-TI account, you can link United-TI topics here with your current Cemetech topics.

This forum is locked: you cannot post, reply to, or edit topics. Celtic III => Your Projects
IDENTITY(4) FAQ
United-TI Archives -> Celtic III
 
    »
» View previous topic :: View next topic  
Author Message
JoeYoung


Advanced Member


Joined: 15 Nov 2008
Posts: 316
Posted: 18 Feb 2009 10:51:06 pm    Post subject:
I wrote this out on Omnimaga after some confusion on the topic arose. I was hoping that Iambian could check my conclusions and confirm or deny them.

Syntax for xLib/CelticII versions of MAPDRAW for reference (ripped from the README by Iambian):
Code:
-----------------------------------------------------------------------------
|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[color=#222])[/color]"). 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 Very Happy). The overworld tiles are located in, say, PIC1 and PIC2. Let's say we have a grid map of:


Code:
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.


Code:
PIC1       PIC2
XXXXXXXXXXXL 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 tile (first X is actually a blank space) 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:


Code:
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:


Code:
[[  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:


Code:
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:


Code:
[[ 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! Surprised Rather, the hex code will be condensed into a string, which looks like this:


Code:
"0B0B0B0B0B0B0B0B0B0B0B0B1C1C1C1C1C00007D1C1C1C1C0000000084000000000000000B0B
0B0000000000000B0B0B0B0B0B0B560000560B0B0B0B0B0B0B0B560000560B0B0B0B"


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


Code:
"°°°°°°°°°°°°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,Updat
e_LCD,2ByteMode)


Code:
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:


Code:
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...


Code:
[[ 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...


Code:
"000B000B000B000B000B000B000B000B000B000B000B000B001C001C001C001C001C000000
00007D001C001C001C001C00000000000000000840000000000000000000000000000000B000B000
B00000
0000000000000000000000B000B000B000B000B000B000B0056000000000056000B000B000B000B0
00B000
B000B000B0056000000000056000B000B000B000B"


(sorry, the format here on UTI seemed to butcher that string)

and finally this...


Code:
"?°?°?°?°?°?°?°?°?°?°?°?°?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:


Code:
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!

Last edited by Guest on 19 Feb 2009 09:32:00 pm; edited 1 time in total
Back to top
Iambian


Advanced Member


Joined: 13 Mar 2004
Posts: 423
Posted: 19 Feb 2009 09:10:16 pm    Post subject:
That ... is a pretty good explanation, though I'd prefer that you strategically place newline characters so as not to distort the layout of the forum. I'm pretty sure people will still understand.

I'd also like to thank you for extensively testing the command and making sure that it all works. I, sadly, neglected to fully test that command out prior to release...
Back to top
JoeYoung


Advanced Member


Joined: 15 Nov 2008
Posts: 316
Posted: 19 Feb 2009 10:48:34 pm    Post subject:
Iambian wrote:
That ... is a pretty good explanation, though I'd prefer that you strategically place newline characters so as not to distort the layout of the forum. I'm pretty sure people will still understand.

I'd also like to thank you for extensively testing the command and making sure that it all works. I, sadly, neglected to fully test that command out prior to release...



Actually, I'm not done. I've only done minor testing. Most of it was theorized out the a. Tonight I'm starting a program in which you walk around a 120x120 grid world while using identity(4 as a scrolling map.

I think this would be a great feature for games if it works. Let me try it out to see if I can figure it out. Hell, maybe I'll be the first person to utilize it Razz
Back to top
simplethinker
snjwffl


Active Member


Joined: 25 Jul 2006
Posts: 700
Posted: 24 Feb 2009 03:42:06 pm    Post subject:
After playing around with the string tilemapper, I want to point out a couple things that might confuse some people:
1) xPos/yPos are the offset in the tilemap to start (Iambian: In the readme you might want to call these x_offset and y_offset like in xLIB's)
2) Width is the number of columns and height is the number of rows, so they're written in reverse order than if specifying matrix dimensions (with a 4x6 tilemap, width/height would be "6, 4" and not "4, 6").

I also have one question that's always bugged me. With 8x8 sprites, the screen can fit 8 rows and 12 columns, so if they're numbered starting at 0, then the StartX/EndX would take values 0-11, not 0-12, and likewise for StartY/EndY.

[edit] I've tested it, and using column number 12 or row number 6 does nothing, so if you wanted to have the tilemap with a blank space on each side, it should be StartX=1, EndX=10, StartY=1, EndY=6.

Last edited by Guest on 24 Feb 2009 04:06:05 pm; edited 1 time in total
Back to top
Iambian


Advanced Member


Joined: 13 Mar 2004
Posts: 423
Posted: 24 Feb 2009 05:37:25 pm    Post subject:
Didn't truly understand xLIB implementation of the tilemapper very well and their inputs, so most of the coordinates that were used and their limits were designed to be "compatible," which doesn't make very much sense to me anyway.

The correct behavior still eludes me.
Back to top
simplethinker
snjwffl


Active Member


Joined: 25 Jul 2006
Posts: 700
Posted: 24 Feb 2009 05:43:36 pm    Post subject:
Iambian wrote:
Didn't truly understand xLIB implementation of the tilemapper very well and their inputs, so most of the coordinates that were used and their limits were designed to be "compatible," which doesn't make very much sense to me anyway.

The correct behavior still eludes me.

It always confused me as well until a couple hours ago. It seems like MapWidth and MapHeight were redundant since they could be determined from ScreenStartX/ScreenEndX and ScreenStartY/ScreenEndY.
Back to top
Iambian


Advanced Member


Joined: 13 Mar 2004
Posts: 423
Posted: 25 Feb 2009 12:37:57 am    Post subject:
Mapwidth and Mapheight are properties that are normally built into a matrix, but since strings are being used, the boundaries of the "matrix as a string" has to be defined.
Back to top
simplethinker
snjwffl


Active Member


Joined: 25 Jul 2006
Posts: 700
Posted: 25 Feb 2009 04:40:45 pm    Post subject:
Iambian wrote:
Mapwidth and Mapheight are properties that are normally built into a matrix, but since strings are being used, the boundaries of the "matrix as a string" has to be defined.


Yeah. The Mapwidth and Mapheight in xLIB always seemed redundant.
Back to top
Iambian


Advanced Member


Joined: 13 Mar 2004
Posts: 423
Posted: 25 Feb 2009 06:11:50 pm    Post subject:
simplethinker wrote:
Iambian wrote:
Mapwidth and Mapheight are properties that are normally built into a matrix, but since strings are being used, the boundaries of the "matrix as a string" has to be defined.


Yeah. The Mapwidth and Mapheight in xLIB always seemed redundant.

I once recalled in a discussion on IRC with tr1p1ea that the tilemapper in xLIB was once a string based tilemapper, so I'm led to believe that those properties were just artifacts of a previous incarnation of that app, and he never bothered to remove them for some odd reason.

In my app, they actually are used for something with respect to the string tilemapper...

Though I'd like to say that the mapheight property still isn't used in my app, since mapwidth is the only real important one. I believe it's up to the programmer to NOT go outside of the defined tilemap.
Back to top
simplethinker
snjwffl


Active Member


Joined: 25 Jul 2006
Posts: 700
Posted: 25 Feb 2009 06:27:25 pm    Post subject:
Actually, even if you did check to see if it went outside the map it wouldn't help much. The choice is between the OS giving an error or you giving an error, so either way the programmer would have to deal with it.
Back to top
JoeYoung


Advanced Member


Joined: 15 Nov 2008
Posts: 316
Posted: 26 Feb 2009 03:05:27 pm    Post subject:
actually, i never got an error message when overstepping the map. sure, weird things happened. but overall it was pretty stable.
Back to top
Display posts from previous:   
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
IDENTITY(4) FAQ
    »
» View previous topic :: View next topic  
Page 1 of 1 » All times are UTC - 5 Hours

 

Advertisement