Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: zeldaking on August 02, 2011, 01:39:46 pm
-
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?
-
Do you want smooth scrolling?
I can write a simple example. ;)
-
Well considering I understand that part, sure. Nothing to complicated (hint: 1 or 2 character sprites)
-
For in-depth explanations of any of this code or questions or bugs (I haven't tested this. :P), just post'em. ;)
:.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
-
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?
-
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
-
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.
-
What he said.
;D Woot! I figured it out!
-
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.
-
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 :D
-
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
-
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 +...
-
Well, I am making a game with about 160 grayscale sprites (called condor) and I think it isn't too hard.
-
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
-
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.
-
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 +...
Axe uses left to right order of operations. I would guess that the number one mistake beginner axe programmers make is forgetting this.
-
Its done in Axe because its faster to compile and it forces you to write more optimized code (not necessarily more readable) since accumulators in assembly are naturally computed left to right.
-
It's a bit of a necro :P but I'm having some problems with this.
For a level stored column-by-column instead of row-by-row, what changes would be made to the formulas? Would I switch the part where it multiplies width to multiplying my height? Switch x- and y-coordinates? Both?
-
For nibbles, cant you just do this?
:For(A,GDB1,GDB1+length(GDB1)-1)
:2*A->Z
:nib{Z}->M
:nib{Z+1}->N
:.display sprite M
:.display sprite N
:End
-
For nibbles, cant you just do this?
:For(A,GDB1,GDB1+length(GDB1)-1)
:2*A->Z
:nib{Z}->M
:nib{Z+1}->N
:.display sprite M
:.display sprite N
:End
optimized with explanation ;)
:For(A,GDB1,GDB1+length(GDB1)-1)
:Z/16->M //gets only the first 4 bits 'cause it rounds
:Z^16->N //gets only last 4 bits(modulo)
:.display sprite M
:.display sprite N
:End
-
Cool thanks. should help me now.