game-editor.com

a quick demo on how to stop sliding through thin walls



use collision free to check the next x...number of pixels depending on your current speed

the demo has a 1 pixel thick wall, which "always" stops the actor even at velocities of 100 or more

the top demo shows the traditional x=x+10 movement

the bottom demo shows movement using xvelocity

if you have a lot of actors to check I suggest making up a function in the global code.

hope that helps
feral

ps: sorry if this has been done before but there still seems a lot of questions about it.

sorry small update,
I thought I had the traditional x=x+10 type movement in the first example, but i didn't

just uploaded new version awalls2.zip

feral
note xspeed is set in global ( for the x=x+xspeed example)

nice code, i had him well up in the 500 velocity range (edited) and the pixel wall stopped him dead in his tracks!
good job on that part, now maybe i can make a sonic game, i couldn't before 'cause of speed restrictions

Very nice method! This will be useful for many people out there! +1 pt for you!

Thank you! For reminding people that there is a COLLISION FREE in GE!

Collision free is much closer to what is in professional games than physical response is. I wish more people would use it!

Went a bit further with this and discovered odd behavior. Created a clone of wall and changed movement via directional_velocity, set starting angle at 0. On collisionfree true section, altered angle+=180; then checked for greater than 180 angle and set back to 0. it starts out bouncing back and forth but speed begins to scrub off after a while until it stops on left wall. Checked collision multipliers and all are set to 1.0, so it should stay constant but it doesn't. Wondering if this happens for anyone else?

Here is the alterations in the code, along with cloning the wall and drag left side of player 2.
Create Actor code for player2

Code: Select all

directional_velocity=10;  //initial velocity ( can change in game and still work with collsion checker
angle=0;

Draw Actor code for player2

Code: Select all

int colcheck=directional_velocity;   ///collsions to check for = the velocity you are travelling at
int i;


for (i=1;i<=colcheck;i++) // for i=1 to current velocity
{
 if (CollisionFree("Event Actor", x+i, y)==0) //check for possible collisions before next redraw
 {
     angle+=180;
     if (angle>180)angle=0;
i=99; //stop checking this draw action
 }
}



***UPDATE****
on further examination and adding a text actor that reflects the directional_velocity of the player2 actor, it does indeed reduce itself. By incrementing it with +.5 to the directional_velocity, it keeps it hovering between 9 and 11, must be an invisible decrementation to the function of directional_velocity.

Here I added a Actor, made it text, initialized it with 000 when I made it, then used the following code to display it.
Setting the directional_velocity to 10 on the routine that bounces it, and you will see the initial deduction that is made to the value.

Code: Select all

int colcheck=directional_velocity;   ///collsions to check for = the velocity you are travelling at
int i;


for (i=1;i<=colcheck;i++) // for i=1 to current velocity
{
 if (CollisionFree("Event Actor", x+i, y)==0) //check for possible collisions before next redraw
 {
     angle+=180;
     if (angle>180)angle=0;
textvelocity.textNumber=player2.directional_velocity;
directional_velocity=10;
i=99; //stop checking this draw action
 }
}



*** Further UPDATE ****
It appears the phenom is caused by using physical response along with the collisionfree method. When removing collision event physical response, numbers stay true. Seems to be a result of mass calculation inaccuracy. I guess this is to perpetuate real world physics as any object over time will degrade its velocity if it has mass. So to have a perpetual machine velocity, don't use physical response collision at all.

Unfortunately, CollisionFree returns false if there is a wireframe region, too. Has anyone got a good work around for that?