Tilemapping in Axe

[zeldaking]

I know there are specific tutorials out there for tilemapping in axe, but they don't help if you can't ask questions about them. I am trying to learn tilemapping, but it is pretty confusing. Can someone give a small example and we can go from there?

[yunhua98]

Do you want smooth scrolling?
I can write a simple example. 

[zeldaking]

Well considering I understand that part, sure. Nothing to complicated (hint: 1 or 2 character sprites)

[yunhua98]

For in-depth explanations of any of this code or questions or bugs (I haven't tested this. ), just post'em. 

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49

:.TILEMAP :[0000000000000000]->Pic0 :[FFFFFFFFFFFFFFFF] : :[010101010101010101010101010101010101010101010101]→GDB1 :[010101010101010101010101010101010101010101010101] :[010101010101010101010101010101010101010101010101] :[010101010101010101010101010101010101010101010101] :[010101010100000000000000000000000000000101010101] :[010101010100000000000000000000000000000101010101] :[010101010100000000000000000000000000000101010101] :[010101010100000000000000000000000000000101010101] :[010101010100000000000000000000000000000101010101] :[010101010100000000000000000000000000000101010101] :[010101010100000000000000000000000000000101010101] :[010101010100000000000000000000000000000101010101] :[010101010100000000000000000000000000000101010101] :[010101010100000000000000000000000000000101010101] :[010101010100000000000000000000000000000101010101] :[010101010100000000000000000000000000000101010101] :[010101010100000000000000000000000000000101010101] :[010101010100000000000000000000000000000101010101] :[010101010101010101010101010101010101010101010101] :[010101010101010101010101010101010101010101010101] :[010101010101010101010101010101010101010101010101] : :0->P->Q  \\P and Q are the coordinates of the corner of the screen relative to the entire chunk of level data : :Repeat getKey(15) : :getKey(3)-getKey(2)+P->P :getKey(1)-getKey(4)+Q->Q  \\I didn't code in collision detection, if you need that too, tell me : :sub(MAP) : :Pt-On(40,24,(your sprite here) : :DispGraph : :End : :Lbl MAP :ClrDraw :For(B,0,7) :For(A,0,11) :Pt-On(8*A,8*B,{Q+B*24+P+A+GDB1}*8+Pic0 :End :End

[zeldaking]

Thanks, that is exactly what I need to get started.
for the map drawing .sub(map. is it A*8 because of 8x8 tiles? Also what is {Q+B*24+P+A+GDB1} can you give me answer in depth?

[chattahippie]

Thanks, that is exactly what I need to get started.
for the map drawing .sub(map. is it A*8 because of 8x8 tiles? Also what is {Q+B*24+P+A+GDB1} can you give me answer in depth?

I think it just locates the data located in a specific point of GBD1, so that only the data needed is displayed on the screen, and not the entire GBD1, if I'm not mistaken.

I say this because I know the {} mean to load a point in data, and it has the pointer for the data, GBD1, which says that it loads from a point inside GBD1.

I'm sure yunhua will correct me if I'm wrong, but that is my answer

[yunhua98]

What he said.
the A*8 is indeed because of the 8x8 tiles, and in {Q+B*24+P+A+GDB1}, Q+B*24 is interpreted as (Q+B)*24 because of left to right order of operations.  The width of the map is 24, so to get to the next row, you add 24, in this case, you add Q+B number of rows.  Add one to go one byte to the right, so P and A are added, plus the original pointer, GDB1.

[chattahippie]

What he said.

Woot! I figured it out!

[LincolnB]

also, if it clarifies anything, given an array GDB1 with n number of columns, you can access the yth element down and the xth element over via the following formula:

{y*n+x+GDB1}

keep in mind this returns one byte, a value between 0 and 255. to do other things like access nibbles and two-byte integers (between 0 and 65,535) it gets slightly more complicated, but retains the same idea.

[chattahippie]

also, if it clarifies anything, given an array GDB1 with n number of columns, you can access the yth element down and the xth element over via the following formula:

{y*n+x+GDB1}

keep in mind this returns one byte, a value between 0 and 255. to do other things like access nibbles and two-byte integers (between 0 and 65,535) it gets slightly more complicated, but retains the same idea.

But 256 tiles is a lot of sprites to choose from, and I can't think of many, if any, projects that use anywhere near 65,536 sprites, although I would love to see such a behemoth project that uses all of them!
That would be monstrous

[LincolnB]

right, that would be pretty epic but hard to do it well in a game, and not make it look like you just crammed as many tiles as you could without considering actual content

[Eiyeron]

What he said.
the A*8 is indeed because of the 8x8 tiles, and in {Q+B*24+P+A+GDB1}, Q+B*24 is interpreted as (Q+B)*24 because of left to right order of operations.  The width of the map is 24, so to get to the next row, you add 24, in this case, you add Q+B number of rows.  Add one to go one byte to the right, so P and A are added, plus the original pointer, GDB1.

Hem... Is it normal? IRL, or in C, the * operaotr has more priotiy than +...

[zeldaking]

Well, I am making a game with about 160 grayscale sprites (called condor) and I think it isn't too hard.

[Eiyeron]

For a C project, i made the references intuitives: In a sokoban, if box = 3 and dot = 2, then box on a dot = 3+2

[Ashbad]

What he said.
the A*8 is indeed because of the 8x8 tiles, and in {Q+B*24+P+A+GDB1}, Q+B*24 is interpreted as (Q+B)*24 because of left to right order of operations.  The width of the map is 24, so to get to the next row, you add 24, in this case, you add Q+B number of rows.  Add one to go one byte to the right, so P and A are added, plus the original pointer, GDB1.

Hem... Is it normal? IRL, or in C, the * operaotr has more priotiy than +...

In Axe, yes it's normal, since that's how math is defined in it.