Author: Xeda112358
Posted: 14 Mar 2013 01:01:27 pm (GMT -5)
Luckily, I just explained a technique to The_Warlord this morning. However, I will expand on that a little more here.
You may have noticed the DataSwap option for drawing tiles with Pt-On(. That will be very useful. In Grammer, the built in tilemap command uses 8x8 tiles, so I will assume that is what you will need. The hex for one tile is 16 characters long, so it is 16 bytes. If you put each tile on a new line, the newline token is an extra byte, so in all, it is 17 bytes per tile for accessing it. Now you need to create an appvar of a given size If you have 32 tiles, you will need 32*8 bytes (so 256):
Code:
So now we have created the appvar named Tiles and Z has a pointer to its data. The next step is to draw each tile and then copy its data to the appvar. To do this, we will use the DataSwap option in a clever way-- we will swap the null data in the appvar with the data just drawn on screen. So to put it all together:
Code:
Another way you can do it is with a similar trick but might be a lot easier for you. You can draw 7 8x8 sprites in a column on the graph screen, so you could copy it to the appvar using the DataSwap method as if it were a 56-pixel tall sprite.
If the pointer to the appvar holding the sprites is in Z, then to display sprite N at X,Y:
Code:
However, Pt-On( is typically used for tiles. It doesn't draw to pixel coordinates, which makes it faster than Pt-Off(, and often better for use with tilemaps. It uses X coordinates 0~11 (like how Output( in BASIC uses 1~16).
If you want to draw a tilemap to these aligned coordinates, there is a pretty high-level command (meaning it makes it easy for the end user to do something complicated):
Pt-Change(0,MapData,TileData,MapWidth,MapXOffset,MapYOffset,TileMethod
You can check out the details in the readme and command reference, but it does all of the math for computing where the tilemap data is, given the offsets into the data and then it draws them to their correct location. On top of that, it is a lot faster than doing it purely in Grammer code.
As a note, Grammer tilemaps are stored by column first, then row. So the first bytes make up the first column, then it moves right, to the next column.
If you have the data stored in a tilemap, you can compute the location in the tilemap of the corresponding byte. So say your tilemap has a height H and you want to read the tile at Y,X and the tilemap is pointed to by T:
The offset to the column is at X*H
The offset in that column to the row is just Y
So put it all together:
T+Y+X*H
And to read the byte, you simply use:
Code:
Continuing from the last question, you can change the tile by doing this:
Code:
Posted: 14 Mar 2013 01:01:27 pm (GMT -5)
| hellninjas wrote: |
| Now to tile-mapping, which i'm sure is going to be difficult x_x How would I create the data for multiple tiles in one Hex string and compress it into an OS variable? |
You may have noticed the DataSwap option for drawing tiles with Pt-On(. That will be very useful. In Grammer, the built in tilemap command uses 8x8 tiles, so I will assume that is what you will need. The hex for one tile is 16 characters long, so it is 16 bytes. If you put each tile on a new line, the newline token is an extra byte, so in all, it is 17 bytes per tile for accessing it. Now you need to create an appvar of a given size If you have 32 tiles, you will need 32*8 bytes (so 256):
Code:
Send(256,"UTiles→Z
So now we have created the appvar named Tiles and Z has a pointer to its data. The next step is to draw each tile and then copy its data to the appvar. To do this, we will use the DataSwap option in a clever way-- we will swap the null data in the appvar with the data just drawn on screen. So to put it all together:
Code:
:Send(256,"UTiles→Z
:Lbl "TILES→P
:For(A,0,31
:Pt-On(8,P,0,0,1,8 ;draw the hex sprite
:Pt-On(4,Z,0,0,1,8 ;Use DataSwap to swap the sprite on screen with the data in the appvar
:Z+8→Z ;next sprite in the appvar
:P+17→P ;next hex sprite
:End
:Stop
:.TILES
:0000000000000000
:3C4281818181423C
:...
Another way you can do it is with a similar trick but might be a lot easier for you. You can draw 7 8x8 sprites in a column on the graph screen, so you could copy it to the appvar using the DataSwap method as if it were a 56-pixel tall sprite.
| hellninjas wrote: |
How would I display that onto the screen using the different tiles? |
If the pointer to the appvar holding the sprites is in Z, then to display sprite N at X,Y:
Code:
Pt-Off(0,Z+N*8,Y,X
However, Pt-On( is typically used for tiles. It doesn't draw to pixel coordinates, which makes it faster than Pt-Off(, and often better for use with tilemaps. It uses X coordinates 0~11 (like how Output( in BASIC uses 1~16).
If you want to draw a tilemap to these aligned coordinates, there is a pretty high-level command (meaning it makes it easy for the end user to do something complicated):
Pt-Change(0,MapData,TileData,MapWidth,MapXOffset,MapYOffset,TileMethod
You can check out the details in the readme and command reference, but it does all of the math for computing where the tilemap data is, given the offsets into the data and then it draws them to their correct location. On top of that, it is a lot faster than doing it purely in Grammer code.
As a note, Grammer tilemaps are stored by column first, then row. So the first bytes make up the first column, then it moves right, to the next column.
| hellninjas wrote: |
How would I check for collision with the different tiles? |
If you have the data stored in a tilemap, you can compute the location in the tilemap of the corresponding byte. So say your tilemap has a height H and you want to read the tile at Y,X and the tilemap is pointed to by T:
The offset to the column is at X*H
The offset in that column to the row is just Y
So put it all together:
T+Y+X*H
And to read the byte, you simply use:
Code:
(T+Y+X*H
| hellninjas wrote: |
How would I change certain tiles to a new value? (Changing the tile in-game?) |
Continuing from the last question, you can change the tile by doing this:
Code:
int(T+Y+X*H,newvalue