Author Topic: Problem (Read 8241 times)

mrmprog · « **on:** July 20, 2011, 11:45:09 pm »

I am working on my first axe program, and I have a problem. If you are falling, and you move into one of the outer walls, you can go through the wall. I know the code is badly written, and the collision testing only test 1 pixel. If someone could explain to me why my code is dying, that would be very helpful.

Code: [Select]

:.GAME
:DiagnosticOff
:ClrDraw
:[1824187E5A182442]→Pic1
:40→A
:1→B
:0→X
:1→C
:Full
:Line(0,63,95,63)
:Line(0,63,0,0)
:Line(95,63,95,0)
:
:For(15)
:rand^(95-0+1)+0→D
:rand^(95-0+1)+0→E
:rand^(63-0+1)+0→F
:Line(D,F,E,F)
:End
:
:
:Repeat getKey=15
:StorePic 
:Pt-On(A,B,Pic1)
:DispGraph
:

Problem may be here

A+pxl-Test(A+1,B+5)→A
:A-pxl-Test(A+6,B+5)→A
:A-getKey(2)→A
:A+getKey(3)→A
:If pxl-Test(A+4,B+8)=1
:B-(12*getKey(54))→B
:Else
:B+1→B
:End
:
:ClrDraw
:RecallPic 
:End

Explanation:
A and B are X and Y cords of the sprite
C is useless
X is useless

Scipi · « **Reply #1 on:** July 20, 2011, 11:57:20 pm »

Is the code zero based? I think the first row and column of the screen is 0 so it could be bypassing it entirely.

mrmprog · « **Reply #2 on:** July 21, 2011, 12:42:45 am »

The code works if you run to a wall, but if you fall and move in a wall, you go through.

Darl181 · « **Reply #3 on:** July 21, 2011, 04:04:55 am »

At any point do you move more than one pixel per frame? Which walls does it go through? Is collision handled differently when the character is not on solid ground?

mrmprog · « **Reply #4 on:** July 21, 2011, 10:16:20 pm »

I put walls on the outer edge of the graphscreen, just to test the collision testing. You never move more than 1 pixel in a certain direction, but if you move when you are falling, you can move 1 down and 1 to the side. Collision is handled the same way no matter what.

mrmprog · « **Reply #5 on:** July 21, 2011, 10:31:35 pm »

Ok, I tried that, but I can still fall through the walls. I will try to make a GIF of the bug in a few minutes.

Happybobjr · « **Reply #6 on:** July 21, 2011, 10:42:56 pm »

~~are you sure that didn't fix it?~~ anyways, that will still stop future problems, as you were doing collision checking after the sprite is drawn.
I reread it and now understand your problem. It isn't hard to fix, if i think i am right.

change...

:A+pxl-Test(A+1,B+5)→A
:A-pxl-Test(A+6,B+5)→A

to

:A+pxl-Test(A+1,B+5)-pxl-Test(A+6,B+5)→A
:A+pxl-Test(A+2,B+5)-pxl-Test(A+5,B+5)→A

it is a rather rude way to code it, but it should work. (if i understand the problem)

Darl181 · « **Reply #7 on:** July 22, 2011, 01:36:45 am »

It seems to only happen when there's a platform close to the wall, but not next to it (as in not wide enough for the sprite to fall through)
The way you handle platforms and walls is why. The char is moved both right, from the left pixel text; and left, from the right pixel test. These done at the same time will cancel each other out.
After that you have the key detection, and because the collision detection cancels itself out if the player happens to be holding the arrow key toward the wall, the char goes right through.

I might be completely wrong, but try something like this (and make some use of C and another coordinate)
It's a long way from optimized and such but you should get the idea =P

Code: [Select]

:pxl-Test(A+1,B+5)→C
:.if pixel test is false, it stores zero. if true, it stores 1
:pxl-Test(A+6,B+5)→D
:.C checks the left side, D checks the right
:A-(getKey(2)*(C=0))→A
:.only if C is zero, meaning the pixel test is false, will the char move left
:A-(getKey(3)*(D=0))→A

What you could do, for a somewhat-inefficient yet nearly foolproof solution, check the coordinates to see if the char is going into a wall.
This could be as simple as adding another check:
:A-(getKey(2)*(C=0)*(A>>0))→A
And (A<<56) for the right wall.

Hope this helps

Ashbad · « **Reply #8 on:** July 22, 2011, 08:51:37 am »

I think you actually will want an A+ in stead of an A- on the second long expression that stores to A. Also, somewhat optimized \o/

Code: [Select]

A-(getKey(2) and (A>>0) and not(pxl-Test(A+1,B+5→r1))?1,0)+(getKey(3) and (A<<56) and not(pxl-Test(A+6,r1))?1,0)→A

calc84maniac · « **Reply #9 on:** July 22, 2011, 08:29:54 pm »

I think you can actually get rid of the ?1,0 stuff since you're already working with booleans.

mrmprog · « **Reply #10 on:** July 22, 2011, 11:02:48 pm »

Thanks to all who helped! I am coding in changes now, but I may wait to compile until the Axe messing with flash problem is fixed.

Btw, Ashbad, your code is way beyond my puny Axe knowledge.

Munchor · « **Reply #11 on:** July 24, 2011, 09:33:45 am »

Just a question, why would you do:

Code: [Select]

A-getKey(A)→A
getKey(A) returns 1 or 0 (if A is pressed or not)...

mrmprog · « **Reply #12 on:** July 24, 2011, 09:34:42 am »

Is that in my code?

Munchor · « **Reply #13 on:** July 24, 2011, 10:10:20 am »

Code: [Select]

:A-getKey(2)→A
:A+getKey(3)→A

That is.

calcdude84se · « **Reply #14 on:** July 24, 2011, 06:58:45 pm »

That decrements A if the left arrow is being pressed and increments it if the right arrow is. Though, if it's exactly as ephan quotes it, you shouldn't have it in two lines.

Code: [Select]

A-getKey(2)+getKey(3)→AThis works just as well.
Edit: Woah, look at Ashbad's code

Author Topic: Problem (Read 8241 times)

mrmprog

Problem

Scipi

Re: Problem

mrmprog

Re: Problem

Darl181

Re: Problem

mrmprog

Re: Problem

mrmprog

Re: Problem

Happybobjr

Re: Problem

Darl181

Re: Problem

Ashbad

Re: Problem

calc84maniac

Re: Problem

mrmprog

Re: Problem

Munchor

Re: Problem

mrmprog

Re: Problem

Munchor

Re: Problem

calcdude84se

Re: Problem