PDA

View Full Version : Flush wall detection

DustyPorViva
12-23-2007, 03:22 AM
I'm messed around with walking systems before... but I figure I could learn something that still boggles me.
I've tried walking systems, and of course the hardest part is the wall detection... so my question is, how can you make a flush wall detection?
By flush I mean, as you run into a wall, you walk flush into it, not 3 pixels away, not 2 pixels in, right up against it. Add to this, walking any speed...(of course, not something ridiculous like a 5 tile walking speed... but 2 doesn't seem too bad).
I've been pondering this, and I've seen some pretty good walking systems out there, but not really function well over 1 tile/0.05sec... so maybe I thought we could all put our heads together on this.

EDIT:
Okay, so right after I posted this I figured something out... many times I see people using for loops to detect placements between the player and the next move... I've cultivated something similar. What I did was run a for loop as:
for (i=0;i<this.speed;i+=1/16) {}
This will create a loop between every pixel and the speed the player is going.
Then, do a wall check, incrementing the check by i:
this.testx=playerx+2.5+i;
This will check every pixel between the player and the next move. Now, instead of just writing a check that you're touching a wall, I did this:
player.x=this.testx-2.5;

This will set the player flush up against the wall, and I've done this going 5 tiles/0.05sec so far and it has worked flawlessly. I'd still love to hear more stuff about this as I'm sure everyone could benefit from it, and there must be better ways.

coreys
12-23-2007, 04:02 AM
I've found this works pretty well:

function movePlayer(dir, noblock) {
temp.nx = (player.x+1.5)+(vecx(dir)*(this.speed*2));
temp.ny = (player.y+2)+(vecy(dir)*(this.speed*2));
if (!onwall(temp.nx, temp.ny) || noblock) {
player.x += vecx(dir)*this.speed;
player.y += vecy(dir)*this.speed;
return true;
}
else return false;
}
Works as perfect as I've seen so far.

cbk1994
12-23-2007, 04:28 AM
I'm messed around with walking systems before... but I figure I could learn something that still boggles me.
I've tried walking systems, and of course the hardest part is the wall detection... so my question is, how can you make a flush wall detection?
By flush I mean, as you run into a wall, you walk flush into it, not 3 pixels away, not 2 pixels in, right up against it. Add to this, walking any speed...(of course, not something ridiculous like a 5 tile walking speed... but 2 doesn't seem too bad).
I've been pondering this, and I've seen some pretty good walking systems out there, but not really function well over 1 tile/0.05sec... so maybe I thought we could all put our heads together on this.

EDIT:
Okay, so right after I posted this I figured something out... many times I see people using for loops to detect placements between the player and the next move... I've cultivated something similar. What I did was run a for loop as:
for (i=0;i<this.speed;i+=1/16) {}
This will create a loop between every pixel and the speed the player is going.
Then, do a wall check, incrementing the check by i:
this.testx=playerx+2.5+i;
This will check every pixel between the player and the next move. Now, instead of just writing a check that you're touching a wall, I did this:
player.x=this.testx-2.5;

This will set the player flush up against the wall, and I've done this going 5 tiles/0.05sec so far and it has worked flawlessly. I'd still love to hear more stuff about this as I'm sure everyone could benefit from it, and there must be better ways.

Zero (zokemon) said in an earlier thread (I'll add the link here if I find it) that he had a wall detection system that was perfect for this.

Edit:

I have one if people would like to have it. It is more hardcoded into my "doMovePlayer()" function though. It has 100% perfect onwall checks and emulates the default Graal movement exactly with an added variable of speed (I tested it at a rate of 5000 tiles per second and did not cross a single wall).

Yeah, mine will butt you up right against the wall even at such speeds.

Oh, I didn't see your post. ^^
I'll post it in the code gallery and link it from here a little later after I spice it up (gotta remove some server specific things from the function first)

However, he never actually posted it.

coreys
12-23-2007, 04:42 AM
I have it.
It's extremely complicated, and it uses angles, rather than directions. It really just depends on your usage. For something like this I'd use something like what I posted. For angular movement, definately Zero's function.

cbk1994
12-23-2007, 06:10 AM
I have it.
It's extremely complicated, and it uses angles, rather than directions. It really just depends on your usage. For something like this I'd use something like what I posted. For angular movement, definately Zero's function.

Post it in code gallery please :(

coreys
12-23-2007, 05:27 PM
Zero's function?
That's up to him to post, not me!

cbk1994
12-23-2007, 06:22 PM
Zero's function?
That's up to him to post, not me!

Well poke him until he posts it! :cry:

Inverness
12-23-2007, 09:14 PM
Zero's function?
That's up to him to post, not me!If you're not going to post it you shouldn't be talking about it, thats rude.

coreys
12-23-2007, 09:34 PM
If you're not going to post it you shouldn't be talking about it, thats rude.

I didn't bring it up. >=(

DustyPorViva
12-23-2007, 10:14 PM
Well, I look back and my first post was very sloppy. I wrote it in a rush and it was late, yada yada. Anyways, I think I came up with another good theory. Only theory as I've yet to test it out in a script, but here it is:

for (i=0;i<speed;i+=1/16) {
runintowall=onwall(player.x+1.5+vecx(playerdir)*i, player.y+2+vecy(playerdir)*i);
if (runintowall==true) {
player.x+=vecx(playerdir)*i;
player.y+=vecy(playerdir)*i;
break;
}
}

This is a simple wallcheck, not really one fit for an actual walking system, but you should get the idea. If a wall is anywhere in the area of the next step, instead of just breaking the walk-cycle, add to the players movement the size of i. Since i is anywhere's between 0 and the players max speed, it will look flush and fluent, yet not go past the wall since i can not be further than it triggered the onwall.

EDIT: Well I have tested this method at 10tiles/0.05sec and it works perfectly... almost. Going down and right flushes you right against the wall, however up and left is a little offset. Nothing visually, but it shows in the player.x/y values as it has a semi-large floating value. I know why it's doing it, but it's an inconvenience. Either way, this method eliminates the need for pre-movement values and checks.

DustyPorViva
12-24-2007, 12:26 AM
Heh, I forgot how fun it is writing a movement system. This is what I've settled with and I'm pretty happy with it. It's not long, but the detects are a little more complicated than I had expected them to be. Ya, it's GS1, but I'll convert it to GS2 sooner or later, that's pretty easy.
:) Kick it up to 160/16(or higher, if you dare), the wall detection is flawless, and in my opinion, pretty simple. The higher you set it though, the larger the loop will get, so be careful with that.