Open Surge Forum

A fun 2D retro platformer inspired by Sonic games and a game creation system

You are not logged in.

Announcement

Our community has moved to Discord! https://discord.gg/w8JqM7m

#1 2009-02-23 10:03:45

Celdecea
Member
From: Southern Oregon
Registered: 2009-02-23
Posts: 147

Slope Physics Suggestion

I am using the SVN Revision 12 and I have a small physics suggestion that improves walking on slopes.

Currently, if you ease up to a U or V shaped slope the player will fly up the other side faster than coming down.  I was playing around and came up with the following changes:

[Replace lines 666-699 of player.c with the following lines which are modified from the original code.]

            /* slopes / speed issues */
            if(!act->is_jumping) {
                double mytan, super = 1.2, push = 25.0;
                if(ang > 0 && ang < 90) {
                    mytan = min(1, tan( ang*PI/180.0 ));
                    if(fabs(act->speed.y) > EPSILON)
                    {
                        if (act->speed.x > 0)
                            act->speed.x = (was_jumping && act->speed.x>0 && ang<45) ? act->speed.x/2 : max(-super*maxspeed, -3*mytan*act->speed.y);
                        else
                            act->speed.x = (was_jumping && act->speed.x>0 && ang<45) ? act->speed.x/2 : max(-super*maxspeed, -1*mytan*act->speed.y);
                    }
                    else {
                        factor = (!(act->mirror & IF_HFLIP) ? 0.8 : 2.0) * mytan;
                        if(player->braking && ang<45)
                            factor *= 8.0 * (act->speed.x<0 ? -1.0/2.0 : 1.0/0.8);
                        else if(fabs(act->speed.x)<5) {
                            factor *= sin(ang*PI/180.0)*push;
                            player->lock_accel = LOCKACCEL_RIGHT;
                        }
                        if (act->speed.x > 0)
                            act->speed.x = max(act->speed.x - factor*700*dt, -super*maxspeed);
                        else
                            act->speed.x = max(act->speed.x - factor*235*dt, -super*maxspeed);
                    }
                }
                else if(ang > 270 && ang < 360) {
                    mytan = min(1, -tan( ang*PI/180.0 ));
                    if(fabs(act->speed.y) > EPSILON)
                    {
                        if (act->speed.x > 0)
                            act->speed.x = (was_jumping && act->speed.x<0 && ang>315) ? act->speed.x/2 : min(super*maxspeed, 1*mytan*act->speed.y);
                        else
                            act->speed.x = (was_jumping && act->speed.x<0 && ang>315) ? act->speed.x/2 : min(super*maxspeed, 3*mytan*act->speed.y);
                    }
                    else {
                        factor = ((act->mirror & IF_HFLIP) ? 0.8 : 2.0) * mytan;
                        if(player->braking && ang>315)
                            factor *= 8.0 * (act->speed.x>0 ? -1.0/2.0 : 1.0/0.8);
                        else if(fabs(act->speed.x)<5) {
                            factor *= -sin(ang*PI/180.0)*push;
                            player->lock_accel = LOCKACCEL_LEFT;
                        }
                        if (act->speed.x > 0)
                            act->speed.x = min(act->speed.x + factor*235*dt, super*maxspeed);
                        else
                            act->speed.x = min(act->speed.x + factor*700*dt, super*maxspeed);
                    }
                }
            }

As you will see, the changes in the above block give uphill runs a little less boost than downhill.  You can see what I mean in the tutorial in the very first dip near the level start.

I am no expert, this took me awhile!

Last edited by Celdecea (2009-02-23 13:09:06)

Offline

#2 2009-02-23 12:35:52

Neoblast
Member
Registered: 2009-02-11
Posts: 46

Re: Slope Physics Suggestion

This might actually do it, the player acts weird on slopes, but on long term I'd suggst using classes ( C++ ) so it would be way easier to modify anything, this way if you hard code everything into the player it'll get more tedious to make changes...

Offline

#3 2009-02-24 02:57:49

Celdecea
Member
From: Southern Oregon
Registered: 2009-02-23
Posts: 147

Re: Slope Physics Suggestion

Neoblast wrote:

... but on long term I'd suggst using classes ( C++ ) so it would be way easier to modify anything ...

You totally have my agreement there. :-D  I should have mentioned that the above code was modified from the original source, so I went ahead and edited the post a bit.  Someday I will probably contribute original code and I am sure it will pass the test. :-)

I am also looking at slope jumping but I am sure the developer is as well.

Offline

#4 2009-02-24 16:58:49

Alexandre
Administrator
From: Brazil
Registered: 2009-01-27
Posts: 3,300
Website

Re: Slope Physics Suggestion

Your modifications are nice, but there's one problem: the player doesn't stop when he/she is inside an U-shaped slope (see it in the tutorial level). I'll try some more tweakings in there too. I'll also play some more Sonic CD to look more carefully at the physics engine smile

To get the physics working exactly as the original games, Open Sonic will require months or years of extensive testing. Since we have to adjust the physics algorithm, using classes or other programming language would be of no help at all, because these adjustments must be done in the algorithm level.

Offline

#5 2009-02-25 19:25:48

Neoblast
Member
Registered: 2009-02-11
Posts: 46

Re: Slope Physics Suggestion

Ussing classes would make it actually esier to modify those algorithyms, instead of hardcoding it, anyway it's just my opinion as a programmer, object oriented modules are easier to modify.

Offline

#6 2009-02-26 08:21:06

Celdecea
Member
From: Southern Oregon
Registered: 2009-02-23
Posts: 147

Re: Slope Physics Suggestion

Neoblast wrote:

Ussing classes would make it actually esier to modify those algorithyms, instead of hardcoding it, anyway it's just my opinion as a programmer, object oriented modules are easier to modify.

On-the-fly coding goes faster without classes, which is why I suspect this project is written as such.  Until recently, all gaming platforms have been procedural (most of the time using assembler!) so I was not surprised at all to see the code.

If you are serious about submitting changes for the project, lets try to collaborate a bit.  The developer will listen better to good ideas when they have been carefully constructed by the community, and code changes are implemented faster with patch files.

Offline

Board footer

Powered by FluxBB  hosted by tuxfamily.org