Author Topic: Help on collision for tilemaps (Read 14219 times)

Magic Banana · « **on:** June 07, 2010, 07:07:11 pm »

Hey guys. Decided to try out Axe seeing as how I'm going to be taking some math classes at college. Anyway, I read Sir_Coding_Knight's tutorial, which was very helpful, along with some other things as well as the documentation so that I can jump into this.

The problem I'm having right now is that the collision for the tiles below and to the right work fine, but the tiles above and to the left are a little funky. The guy collides into them, but not before 1 pixel of him goes into the tile, and the only way he can moves is if he backs up, so he can't walk along the walls like the other ones. I've tried to change the offset (you'll see in the code) with a negative number, which would make sense, but that just makes things even worse.

My code is a little messy and not optimized, because I'm focused on getting the thing to work first. Any feedback would be appreciated.

Code: [Select]

:.TEST
:Full
:DiagnosticOff
:0→K+2→Z+22→X→Y
:[222222222222222222222222→GDB1
:[221111111111111111111122
:[221122000011110000221122
:[220000001122221100000022
:[220000001122221100000022
:[220022000000000000220022
:[220000000000000000000022
:[222222222222222222222222
:[40A0040A205002057EC3BDA5A5BDC37E54FCFCEFFF4A14362A3F3FF7FF52286C22373F777F32684C44ECFCEEFE4C16320040484002000000000202020000000000021202200000000040484004000000]→Pic1
:ClrDraw
:Repeat getKey=15
:If getKey(1)
:12→P:sub(C
:!If {{L1}}=2
:!If {{L1}+3}=2
:Y+1→Y:2→Z
:End:End:End
:If getKey(2)
:0→P:sub(C     (<-Left it at zero because negatives mess it up more)
:!If {{L1}}=2
:!If {{L1}+1}=2
:X-1→X:5→Z
:End:End:End
:If getKey(3)
:1→P:sub(C
:!If {{L1}}=2
:!If {{L1}+1}=2
:X+1→X:4→Z
:End:End:End
:If getKey(4)
:0→P:sub(C     (<-Left it at zero because negatives mess it up more)
:!If {{L1}}=2
:!If {{L1}+3}=2
:Y-1→Y:3→Z
:End:End:End
:For(S,0,11
:For(T,0,7
:{T*12+S+GDB1}→P
:P^16→Q:P/16→P
:If P
:Pt-On(S*8,T*8,P-1*8+Pic1:End
:If Q
:Pt-On(S*8,T*8,Q-1*8+Pic1:End
:End:End
:Fix 5
:Text(70,44,{{L1}}►Dec
:Text(80,44,{{L1}+3}►Dec
:Text(70,50,{{L1}+1}►Dec
:Text(80,50,{{L1}+2}►Dec
:Pt-On(X,Y,Z*8+Pic1
:Pt-Change(X,Y,(Z+4)*8+Pic1
:DispGraph
:ClrDraw
:End
:Fix 0:Fix 4
:ClrHome:Return
:
:Lbl C
:For(R,0,1
:{{L1}+1}→{{L1}+3}
:For(O,0,1
:(O*7+X)/8→S
:(R*7+Y)/8→T
:T*12+S+P→Q
:If Q^2
:{Q+GDB1}^16→{{L1}+O+R}
:Else
:{Q+GDB1}/16→{{L1}+O+R}
:End:End:End

Also, can anyone tell me how to attach images or the program itself so that they don't have to copy the whole code to test it out?

jsj795 · « **Reply #1 on:** June 07, 2010, 07:11:05 pm »

Hi, welcome to Omnimaga!

and for your problem, well, I can't help with Axe much since I haven't really done much Axe yet.
There will be other more experienced Axe users that can help you.
And you can start attaching images or programs once your post count hits 5.

Magic Banana · « **Reply #2 on:** June 07, 2010, 07:32:53 pm »

Ah, well I better get my post count up then.

Yeah, Axe can be pretty crazy, but it makes more sense when you just keep at it. I've probably edited and recompiled this program over 100 times already, changing just a few things each time. Just wondering, is each compiled program supposed to be about 1.5x the size of the source? All of mine end up at about that size.

Quigibo · « **Reply #3 on:** June 07, 2010, 09:44:04 pm »

I don't understand why there are so many of these: {{L1}} a pointer in double brackets. If you really are using that as a pointer to a pointer, then you need to use the entire 16-bit pointer and not just read a single byte from it. But I don't think you're trying to double reference from what I see. Everywhere you have a {L1} should be just L1 I presume.

Also, it doesn't even look like L1 is initialized anywhere. You can't assume it starts out as all zeros, its usually random garbage.

Magic Banana · « **Reply #4 on:** June 07, 2010, 10:01:57 pm »

Oh, didn't notice that. It looks like Cemetech slapped all those extra brackets in there when I parsed it. I'll post another without all those extras.

Code: [Select]

:.TEST
:Full
:DiagnosticOff
:0→K+2→Z+22→X→Y
:[222222222222222222222222→GDB1
:[221111111111111111111122
:[221122000011110000221122
:[220000001122221100000022
:[220000001122221100000022
:[220022000000000000220022
:[220000000000000000000022
:[222222222222222222222222
:[40A0040A205002057EC3BDA5A5BDC37E54FCFCEFFF4A14362A3F3FF7FF52286C22373F777F32684C44ECFCEEFE4C16320040484002000000000202020000000000021202200000000040484004000000]→Pic1
:ClrDraw
:Repeat getKey=15
:If getKey(1)
:12→P:sub(C
:!If {L1}=2
:!If {L1+3}=2
:Y+1→Y:2→Z
:End:End:End
:If getKey(2)
:0→P:sub(C
:!If {L1}=2
:!If {L1+1}=2
:X-1→X:5→Z
:End:End:End
:If getKey(3)
:1→P:sub(C
:!If {L1}=2
:!If {L1+1}=2
:X+1→X:4→Z
:End:End:End
:If getKey(4)
:0→P:sub(C
:!If {L1}=2
:!If {L1+3}=2
:Y-1→Y:3→Z
:End:End:End
:For(S,0,11
:For(T,0,7
:{T*12+S+GDB1}→P
:P^16→Q:P/16→P
:If P
:Pt-On(S*8,T*8,P-1*8+Pic1:End
:If Q
:Pt-On(S*8,T*8,Q-1*8+Pic1:End
:End:End
:Fix 5
:Text(70,44,{L1}►Dec
:Text(80,44,{L1+3}►Dec
:Text(70,50,{L1+1}►Dec
:Text(80,50,{L1+2}►Dec
:Pt-On(X,Y,Z*8+Pic1
:Pt-Change(X,Y,(Z+4)*8+Pic1
:DispGraph
:ClrDraw
:End
:Fix 0:Fix 4
:ClrHome:Return
:
:Lbl C
:For(R,0,1
:{L1+1}→{L1+3}
:For(W,0,1
:(W*7+X)/8→S
:(R*7+Y)/8→T
:T*12+S+P→Q
:If Q^2
:{Q+GDB1}^16→{L1+W+R}
:Else
:{Q+GDB1}/16→{L1+W+R}
:End:End:End

There, that should do it. It's initialized after running sub(C) for the first time,so it does start as garbage, but gets set to normal numbers after the first step in any direction.

EDIT:Attached the program.

meishe91 · « **Reply #5 on:** June 07, 2010, 11:16:25 pm »

Hmmm, interesting. I don't know if this would be an issue with part of it but could possibly some of the detection be off since front and back are 8*8 while the side views are 7*8? I haven't gone over your code to see what kind of collision detection you're using but that might be part of it but I don't know. Other than that though I don't know, still need to look at the code.

Magic Banana · « **Reply #6 on:** June 08, 2010, 03:46:36 am »

Quote from: meishe91 on June 07, 2010, 11:16:25 pm

Hmmm, interesting. I don't know if this would be an issue with part of it but could possibly some of the detection be off since front and back are 8*8 while the side views are 7*8? I haven't gone over your code to see what kind of collision detection you're using but that might be part of it but I don't know. Other than that though I don't know, still need to look at the code.

Uh, I'm not sure what you mean by 7*8. The only time a 7 comes up is when I'm setting points on all four corners of the sprite. The original X,Y is pointing to the top left corner and the loops grab the other 3 corners of the same sprite. I'm pretty sure all of my sprites and collisions are 8*8, but there is still some reason why there's this strange error that I just can't put my finger on.

It's a lot easier to see what I mean if you test the program. I don't know how to make an animated gif, and I don't see any options for it in the TI Connect screen capture, just a single png.

Quigibo · « **Reply #7 on:** June 08, 2010, 04:51:56 am »

Hmm... I can't tell if the locations for collision detection are accurate... I would try using the method I used in AXERPG. I was able to get collision detection there pretty easily even with a 8x16 sprite. You would have to adapt it to half byte compression, but that's really not that difficult since you would only have to modify that one subroutine and it looks like you already understand the math behind it.

meishe91 · « **Reply #8 on:** June 08, 2010, 04:53:49 am »

To make a screen shot you need to have something like WabbitEmu, which is in the Downloads section.

What I'm saying about the 7*8 is that your side view displays 7*8 sprites instead of 8*8 like the front and back view.

Code: (Side Sprites) [Select]

1►███████
2►███████
3►███████
4►███████
5►███████
6►███████
7►███████
8►███████
  ▲▲▲▲▲▲▲▲
  12345678

Code: (Front/Back Sprite) [Select]

1►████████
2►████████
3►████████
4►████████
5►████████
6►████████
7►████████
8►████████
  ▲▲▲▲▲▲▲▲
  12345678

I know you are using 8*8 hex, I'm just saying what is being displayed isn't 8*8.

Magic Banana · « **Reply #9 on:** June 08, 2010, 05:04:58 am »

Quote from: meishe91 on June 08, 2010, 04:53:49 am

To make a screen shot you need to have something like WabbitEmu, which is in the Downloads section.

What I'm saying about the 7*8 is that your side view displays 7*8 sprites instead of 8*8 like the front and back view.

I know you are using 8*8 hex, I'm just saying what is being displayed isn't 8*8.

OH, I see what you mean now. Yeah, I only took up 7 of the 8 columns for the side sprites, but all of the sprites were made in HEXPIC, so they are all in the 8*8 format (or should be, might have to make a test sprite that takes up every column to see if it makes a difference for sure).

@Quigibo:Sure, I'll take a look at that. Just making sure, grayscale doesn't affect collisions in any way, right? I don't think it would. I guess I'll look into half-byte compression. I know I saw a topic about it somewhere.

EDIT: Tested with an 8*8 box sprite, still no luck.

EDIT2: The collision looks great on yours, but the format is different. It really shows what Axe can do. I'll see if I can work something similar into my code, as I'd rather not just copy the whole thing and just paste my sprites over it. (how am I supposed to learn from that?)

EDIT3: AH! Finally got it right! The problem wasn't in the offset, but the pixels I told it to check themselves! It was checking 7 pixels behind where it was supposed to because I put the same coordinates that checked the right side for the left and the same for up and down.

Code: [Select]

Old code
:If getKey(2)
:0→P:sub(C
:!If {L1}=2
:!If {L1+1}=2
:X-1→X:5→Z
:End:End:End
...
:If getKey(4)
:0→P:sub(C
:!If {L1}=2
:!If {L1+3}=2
:Y-1→Y:3→Z
:End:End:End

Code: [Select]

New code
:If getKey(2)
:-1→P:sub(C
:!If {L1+2}=2
:!If {L1+3}=2
:X-1→X:5→Z
:End:End:End
...
:If getKey(4)
:-12→P:sub(C
:!If {L1+1}=2
:!If {L1+2}=2
:Y-1→Y:3→Z
:End:End:End

Now I've just got to optimize it.

jsj795 · « **Reply #10 on:** June 08, 2010, 10:07:24 am »

I'm glad you got it to work!
I need to learn how to do the collision detection too

Hopefully these topics will help

DJ Omnimaga · « **Reply #11 on:** June 08, 2010, 11:54:34 am »

mhmm nice that could eventually be helpful. I never thought about looking at Axe RPG for help. I wonder if it can run much faster without grayscale?

Magic Banana · « **Reply #12 on:** June 08, 2010, 12:03:18 pm »

Quote from: DJ Omnimaga on June 08, 2010, 11:54:34 am

mhmm nice that could eventually be helpful. I never thought about looking at Axe RPG for help. I wonder if it can run much faster without grayscale?

Well, without grayscale, you can set it to Full, which would make it go about 2.5 times as fast. Also, I think that the Axe RPG is in grayscale-4, so putting it in grayscale-3 might make it speed up a bit as well.

EDIT: Just tested the demo in grayscale-4, grayscale-3, and monochrome. Surprisingly, they all seem to run at pretty much the same speed. They all took about the same amount of time to walk from one side to the other and back. Looks to me like the only noticeable thing between grayscale and monochrome is the support of Full. There might be a slight difference between each, but the program would have to be pretty big (graphics-wise) to notice.

DJ Omnimaga · « **Reply #13 on:** June 08, 2010, 12:05:55 pm »

Oh I mentionned about the grayscale removal because grayscale can slow down games a bit even in 6 MHz. I never tried 4 level myself, though.

One thing I wonder: is it possible to get decent speed off a smooth scrolling half-byte tilemapper with collision detection like in Axe RPG, assuming grayscale is removed and that when scrolling, only the edge of screen row/col of tiles are being updated?

Magic Banana · « **Reply #14 on:** June 08, 2010, 12:25:31 pm »

Yeah, 4 seems to have more flicker, but I think that just may be the demo. It flickered when I took it down to 3 as well. I haven't had the time to work with grayscale in Axe yet, so I don't know for sure.

Oh man, that is a tough one. I spent many hours last night getting acquainted with half byte, and it sure loves to mix things up. So far I got static maps with semi-collision detection going. I haven't even gotten to scrolling it yet. I think it's still being worked on, and nobody has a definite solution to it yet.

Author Topic: Help on collision for tilemaps (Read 14219 times)

Magic Banana

Help on collision for tilemaps

jsj795

Re: Help on collision for tilemaps

Magic Banana

Re: Help on collision for tilemaps

Quigibo

Re: Help on collision for tilemaps

Magic Banana

Re: Help on collision for tilemaps

meishe91

Re: Help on collision for tilemaps

Magic Banana

Re: Help on collision for tilemaps

Quigibo

Re: Help on collision for tilemaps

meishe91

Re: Help on collision for tilemaps

Magic Banana

Re: Help on collision for tilemaps

jsj795

Re: Help on collision for tilemaps

DJ Omnimaga

Re: Help on collision for tilemaps

Magic Banana

Re: Help on collision for tilemaps

DJ Omnimaga

Re: Help on collision for tilemaps

Magic Banana

Re: Help on collision for tilemaps