Sonic style physics and collision code?

[skydereign]

You mean the code for what SuperSonic recommended? If so, it'd be something like this.

Code: Select all

switch(Dir)
{
    case 0:
    xv*=0.99; // this is the part that should make it decelerate
    break;

    case 1:
    if(xv < MaxSpeed)//If sonic is not going as fast as he can...
    {
        xv += IncrementSpeed;//...then speed him up.
        //You can also put animation code here ;)
    }
    break;

    case -1:
    if(xv > -MaxSpeed)
    {
        xv -= IncrementSpeed;//This will also speed him up. But in the opposite direction :D
        //Again, you can put animation code here
    }
    break;
}

x+=xv;

You need to have an xv variable.

The thing I mentioned was that you probably have a left or right side collision with the new tile (the one that causes the stop) that stops the actor. If you remove that, then you wouldn't need the above fix.

[CrimsonTheDarkBat]

Okies thanks a bunch. ^^

Now, where does that code go exactly? XD

[skydereign]

That's just the altered code that SuperSonic posted. Didn't you say you already set that up? That bit goes into the draw actor.

[CrimsonTheDarkBat]

Well yes, but now the player only runs on the one spot, neither left nor right :/

[skydereign]

This is the problem with being given code. You should instead of copying, learn what the code does, and how it fixes your problem. That way you learn more and are able to debug it yourself. If you know how it works, then it is a lot easier for you to debug it, then us trying to guess your game's setup. Did you add the the Dir=1 and Dir=0 events to the keydowns? That's the only thing that would cause the actor not to move. Dir has to be changed for when the actor is moving, and set back when the keys are released.

[CrimsonTheDarkBat]

I've done all of that but still Sonic won't budge. You mean Dir=1 and Dir=-1 for key downs, and Dir=0 for key ups, right?

[skydereign]

Ok then you probably made xv an int? If so then this won't work with 0.5, so xv needs to be a double, or IncrementSpeed needs to be a integer value (currently it is 0.5) so if you increase an int by 0.5, it won't change. Do you understand what the code is doing?

[CrimsonTheDarkBat]

Yes, I got the hang of it now - its working, thanks so much. ^^ But now there's one little side effect - the collisions are very "bumpy" or make the level seem to
shake when the player is running up a slope. Any ideas? Sorry for wrecking your heads with all
of this! ^^;

[skydereign]

Well, can't reproduce from what I have. It's very smooth. How are you controlling the view based off the player? I'm assuming the level itself is not shaking, so it might have something to do with the view.

[CrimsonTheDarkBat]

Okies, well the code I have in the view is: view > Draw Actor > Script Editor:

Code: Select all

x=max(player.x-320,min(x,player.x-310));
y=max(player.y-320,min(y,player.y-310));


[skydereign]

Well, it seems it would have to do with your collision events, as that is the only thing that is left. It works fine for me if I conserve only xvelocity, do you have left or right side collisions? It sounded like you didn't, but if you do, can you post the code you use? This is one of the problems with gE's collision system (the main reason why people end up creating their own custom systems).

[CrimsonTheDarkBat]

Sure, I've got left/right side collision code - I'll paste both the top or bottom and left or right just to show ya ^^;

Player > collision > Script Editor( Left or Right side of sloperight)

Code: Select all

double yvel = yvelocity;
PhysicalResponse(MOVE_EVENT_ACTOR_ONLY, USE_CALCULATED_MASS, 1.0, 1.0, 0.0, 0.0);
yvelocity=yvel;


Player > collision > Script Editor (top or Bottom side of sloperight)

Code: Select all

double xvel = xvelocity;
PhysicalResponse(MOVE_EVENT_ACTOR_ONLY, USE_CALCULATED_MASS, 1.0, 1.0, 0.0, 0.0);
xvelocity=xvel;


[skydereign]

Okay, well by your naming scheme can I assume you have a different actor for every type of incline? If so you can remove the left or right side collision from the actor. Another thing is you don't need to conserve xvelocity anymore, since you aren't using xvelocity. If that is all there is to the setup, then it should be exactly like I have, and work. Of course that will require you to have different actors for walls... which I personally don't like, but it should make this system work.

[CrimsonTheDarkBat]

Yep, that's how my setup works. Anyway, I've tried removing the left or right side codes - it didn't take any effect. Now I'm not entirely sure what you mean by "conserving xvelocity" but i assume that means removing the area of code except for PhysicalResponse, right? Well I tried that too, but to no avail. Or am I missing something else? ^^;

[skydereign]

Why do you keep deleting and reposting your posts? And, I forgot to mention making the PhysicalResponse for the left and right sides of the tile. Otherwise you will fall through the slope. But other than that, it should work (as that is all I have in my simulation of your setup).