Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: BrownyTCat on December 19, 2012, 04:59:12 pm
-
I recently got help (http://ourl.ca/17798) with learning to tilemap, but all my attempts to add offsets to the mapper to make "smooth scrolling" (not just "jumping" 8 pixels at a time) have ended in failure or broken collisions. A lot of the tutorials don't look suited to exactly what I'm doing, or have just confused me as a newcomer to this concept. I've tried a LOT of fixes with collisions, but they never worked, so I have to ask anyone with experience for help if you have the time. Thank you.
Source is attached, all one program. Should have comments/labels in it to tell you what some parts are.
P.S. - Are there any IDEs that work with Axe under Windows? The only thing I have is the old TI Data Editor for OSX, and my old G4 absolutely loves crashing.
-
Id noone has solves it , i'll answer tommorow, now i can't do all of it out of my head (i actually can but it would take a long time to type on ipod + i can't see your source)
-
Id noone has solves it , i'll answer tommorow, now i can't do all of it out of my head (i actually can but it would take a long time to type on ipod + i can't see your source)
Thanks, I've been trying at this for days so I can wait.
-
Or if you could post the source in CODE block, then i could help now... I'm bored anyway xp
-
Or if you could post the source in CODE block, then i could help now... I'm bored anyway xp
Sorry, I'm really not in the mood to boot up my iMac and then restart it 7 times.
-
Ok np, then i'll do it 1) out of my head or 2) tommorow xp
Edit: does the character move and then map scroll, or does the character always stays on the same possition?
-
There are basically two ways to do it, one using your method where you keep track of the offset and tile separately, or a method where they are combined into one value. I've always used this latter method, which I'll try to briefly explain here.
The only value we'll bother keeping track of is absolute X and Y position, in pixels. If we're using 8x8 tiles, that means the tile coordinate of our point X,Y is the tile point X/8,Y/8. (Remember Axe division throws out the decimal/fractional portion). To find the pixel offset, we'll use the modulus operator ^8. Both of these operations are pretty fast since 8 is a nice power of 2.
Maybe we can make a routine that takes two coordinates for arguments, and returns what tile number that pixel lies in
Lbl getTile
{r2/8*tileMapWidth+(r1/8)+pointer}
Return
For optimization's sake, you can leave out the first r2 which is kind of nice. So anyway, now you can check collisions on any pixel-point you want-- for example, checking all 4 corners of a player sprite.
getTile(X,Y)+getTile(X+7,Y+7)+getTile(X,Y+7)+getTile(X+7,Y)
would add up the tile# of all 4 corners of your player; this is a nice way to check for collisions if 0 is the only traversable tile.
Now, how do we draw the tilemap with this scheme? It's pretty easy, we can start with pseudocode.
For(row,0,8)
For(column,0,12)
Pt-On(column*8-xOffset,row*8-yOffset,{yTile+column*tileMapWidth+xTile+pointer}*8+tileSprites})
End
End
I'll let you fill in the rest.
-
I wanted to explain :o xp
Btw: your for loops need to end with 7 and 11. Not 8 and 12
Edit: nvm i forgot about there have to be drawn 13*9 tiles when scrolling
-
Sorry for double-post
But i concider this an "update"
This is my way of doing it, it's kinda the same but not as optimised as squidget's code, and it's probably slower with some bugs cause it's out of my head
.smtscrll
.tiles (black and white)
[0000000000000000]-> pic0
[FFFFFFFFFFFFFFFF]
.sprite 8*8 stored in pic1
.map (15*10)
[010101010101010101010101010101]->GDB0
[010000000000000000000000000001] .this one 8 times
[010101010101010101010101010101]
.initialize vars (x=x-pos , y=y-pos , c=horizontal scroll, d= vertical scroll)
0->C->D+8->X->Y
.till [clear] is pressed
Repeat Getkey(15)
MOVE()
MAP()
.2 subroutines are called
Pt-on(X,Y,pic1)
DispGraph
End
Lbl MOVE
X+(Getkey(3) and (X<88))-(Getkey(2) and (X>0))->X
C+(Getkey(3) and (X=88))-(Getkey(2) and (X=0))->C
.only change X when it's on screen If it's on border of screen the change the scroll var (same for Y)
Y+(Getkey(1) and (Y<56))-(Getkey(4) and (Y>0))->Y
D+(Getkey(1) and (Y=56))-(Getkey(4) and (Y=0))->D
Return
Lbl MAP
For(A,C/8,C/8+12)
For(B,D/8,D/8+8)
Pt-on(A*8-C,B*8-C,{15*B+A+GDB0}*8+pic0)
.so this says: draw the map, where 15=the length of the map
End
End
Return
.end of program, no collision detection yet but easy to implement... Question? Ask me...
And this doesn't include collision detection yet, but it's easy to implement...
Edit1: forgot to paste code
-
And this doesn't include collision detection yet, but it's easy to implement...
Unfortunately, collisions are where I was having trouble. If you look on the old topic, it ended with me posting my attempted smooth scroll version of the mapper (I posted a new topic because the subject itself had changed). Is there something wrong with it?
-
@stevon8er, your method uses a different one than mine :) That code is good if you want the screen to scroll only if the player is near the edges; mine keeps the camera centered on the player. Also my code there is barely optimized lol, though I took the liberty of quick-optimizing yours for you (Didn't go crazy here, tried to keep the same overall layout and readability.)
...
0->C->D+8->X->Y
.till [clear] is pressed
While 1
MOVE()
MAP()
.2 subroutines are called
Pt-on(X,Y,pic1)
DispGraphClrDraw
EndIf getKey(15)
Lbl MOVE
getKey(3)-getKey(2)+X
!If +1 //if x = -1
->x //make x = 0, since the !If +1 statement left a 0 in hl
C-- //decrement C
Else!If -89 //otherwise, check if x is 88 (actually, we're checking if x+1-89=0, but it's the same thing right?)
C++
88->X
End
getKey(1)-getKey(4)+Y
!If +1
->Y
D--
Else!If -57
D++
56->Y
End //and same stuff for Y. Halved the number of getKeys here.
Return
Lbl MAP
.Okay, so the main driving force behind the optimization logic here is that we want to move as much stuff as we can outside of loops.
.So for example, C and D will never change while we're in the loop so...
.I made up some variable names but you can use whatever you want.
D/8->tileY*15+GDB0->tilePointer
C/8->tileX
-(C^8)-8->offX
-(D^8)->screenY
For(9) //for the 9 rows to be drawn
tileX->tileX0
offX->screenX
For(A,0,12)
Pt-on(screenX+8->screenX,screenY,{tilePointer+A}*8+pic0)
End
screenY+8->screenY //move the Y "pen position" down a row
tilePointer+15->tilePointer //next row of tiles
End
Return
-
Ok thx squidgetx
I'm rather new to axe so didn't come to much optimizing yet, but thx :p
-
Now I have to figure out how to get this into a platformer.. named variables in Axe hurt my brain.
-
As an IDE I'd suggest BexIDE. It's somewhere on this forum, just search for it
-
There is also TokenIDE that works great under Windows, that is what I use :)
-
It's worthy to note that smoothscrolling should not affect collision in any way, since scrolling is just a graphical effect.
-
The way I had the "smoother" set up in my original code was that it advanced the actual "X" by 1 once the offset reached 8 (or reduced it by 1 when the offset hit -8). I had problems with not being able to check horizontally and vertically, and everything eventually hit the fan. It should be obvious how poor I am at this if you check the original source at the end of this thread (http://ourl.ca/17798). My method was probably horribly incorrect, but I can't find a simple way to pull off movement that's not in multiples of 8, as I am the worst mathematician to exist.
Also, how do you actually display a variable in Axe? It just shows garbage symbols due to pointers, but I was sure a function existed to convert to string. I can just never find it. In BASIC, it's usually just:
Disp X
-
You should check out the command list for Axe, it has all sorts of useful information like that :D you can use the >Dec command to display the value of a number instead of a string