# Sonic and Sega Retro Message Board: Trying to implement physics from the Sonic Physics Guide... issue - Sonic and Sega Retro Message Board

• 2 Pages
• 1
• 2

## Trying to implement physics from the Sonic Physics Guide... issue Feel like a complete blooming idiot.

### #1Travelsonic  Posted 06 October 2013 - 02:41 PM

• Posts: 714
• Joined: 01-March 05
As the topic description says, I feel like a complete blooming idiot right now.

For fun I wanted to see if I could implement the physics as describe in the physics guide in a Megadrive era Sonic engine of my own using C++.

I made Sonic his own class. In the Sonic class, I have friction, max speed, acceleration, and deacceleration set up pre-defined [but not as constants, as underwater ALL OF these values are different if I recall correctly]. For movement, I have a function that takes in an integer representing the key pressed, allowing me to keep the class independent of the graphics/gaming libraries I am using for longer during testing.

[Basically, the "if the player is pressing left," " if the player is pressing right" is now down to a switch statement based on the integer passed as an argument]

The function then checks that code, and for left/right movement, handles it exactly like it was laid out in the guide for when Sonic is running on a flat surface:

the physics guide said:

```if the player is pressing left{
if X speed > 0{
X speed -= dec
}
else if X speed > -max{
X speed = X speed - acc
}
else{
X speed = -max
}
}
else if the player is pressing right{
if X speed < 0{
X speed += dec
}
else if X speed < max{
X speed = X speed + acc
}
else{
X speed = max
}
}

```

Only not pseudo code, of course, and with an additional condition where if the X speed is 0 then it adds [if moving right] or subtracts [if moving left] the acceleration, and if nothing is being pressed, the friction is applied appropriately.

Now the problem.

I wanted to test how, when implemented, how a change in X position would look [as opposed to just the X speed]. Like with the X speed being displayed on screen, I then made it so it also showed X position on screen, and I can't help but feel like I am doing something wrong, as the rate of change is absolutely insane.

Ugh.
This post has been edited by Travelsonic: 16 November 2016 - 08:36 AM

### #2Morph  Posted 06 October 2013 - 05:28 PM

• AKA SonicFreak94.
• Posts: 765
• Joined: 01-August 08
• Gender:Male
• Location:Utah
• Project:SA1/2 hax
• Wiki edits:11
Is it running above 60FPS without delta timing? Maybe a stupid suggestion, but if it's running at like, 300 frames per second, you're applying those changes at a rate of once per frame (about every 3ms at 300FPS, for example) without delta timing, and as you could probably guess, that means everything applies too quickly.

### #3JustinTU  Posted 06 October 2013 - 08:06 PM

• Posts: 5
• Joined: 06-June 09
• Gender:Male
• Location:Montgomery, Alabama
Like Morph said, the values for the various properties of the player's movement are in terms of displacement per frame, so if your values are increasing or decreasing too fast, then you simply need to lock your frame rate or lock just the physics to a certain frame rate. There many ways to do it, some of which are inefficient and effect the smoothness of the gameplay. I would recommend taking a look at this guide (link). My own engine uses a modified version of the method described in that guide that works pretty well for me.

### #4Travelsonic  Posted 07 October 2013 - 12:36 AM

• Posts: 714
• Joined: 01-March 05
Told you I feel like a blooming idiot. The framerate... fuck me....

For the time being, I merely moved the decimal point over one place for each variable's value [accel, deaccel, friction, etc] and that made things work beautifully until I can be arsed enough to do a better tweak should I actually need to do better as I will be busy as hell on my Android app development and whatever else thrown my way from working for my 'rents.
This post has been edited by Travelsonic: 07 October 2013 - 12:48 AM

### #5winterhell  Posted 07 October 2013 - 02:47 AM

• Posts: 1138
• Joined: 16-October 10
• Gender:Male
Can you just slap something like Sleep(14) for the time being? That'd stabilize your fps. Or activate vSync.

### #6Travelsonic  Posted 26 October 2013 - 01:57 PM

• Posts: 714
• Joined: 01-March 05
In the game loop I implemented some rest similar to what you, winterhell, suggested for the time being - works good now. :D

[Don't lock thread, powers-that-be, as I may still have plenty of questions going into all this.]

### #7kazade  Posted 20 February 2014 - 02:23 AM

• Posts: 64
• Joined: 16-March 10
• Project:A 2D Physics Engine

Travelsonic, on 26 October 2013 - 01:57 PM, said:

In the game loop I implemented some rest similar to what you, winterhell, suggested for the time being - works good now. :D

[Don't lock thread, powers-that-be, as I may still have plenty of questions going into all this.]

In my engine I've multiplied each constant by 60 (e.g. the change per second) and then each update add the value multiplied by a delta time value. Seems to work great!

### #8Travelsonic  Posted 16 December 2015 - 02:33 PM

• Posts: 714
• Joined: 01-March 05

For shits and giggles purely, I decided to see if I could make this using only HTML5, javascript, and JQuery - no libraries for sound, graphics, or game physics.

I have made it so Sonic's horizontal movement on flat surfaces works as it should. I also implemented jumping, falling, air drag, and variable jump height (ALL WITHOUT having to fudge the constants like with my last attempt at implementing this stuff :D ). I've also *sorta* implemented bumper collisions, though that still isn't quite right.

Now I gotta figure out the best way to handle tiles.

I've added, to my Sonic object, an array values, X and Y coordinate, representative of the positions of the sensors used in ground/wall collisions.

What is tripping me up is the best way to actually represent each tile, handle going through and checking collisions with the tiles, as I wanna follow the SPG as closely as I can, including the use of the height masks, and feel in looking at what I have to do, I may be overthinking the hell out of what I need to do. >_<

Maybe first I should figure out why my bumper objects are fubar.

EDIT: Derrr, bumpers work now, so nevermind. XD
This post has been edited by Travelsonic: 16 December 2015 - 03:19 PM

### #9winterhell  Posted 17 December 2015 - 01:52 AM

• Posts: 1138
• Joined: 16-October 10
• Gender:Male
The classics use a heightmap for the collision tiles. 16 adjacent values for the height of the pixel columns. This is for vertical collision. There is also a similar horizontal heightmap. They both represent the exact same 16x16 collision mask. If you expand the heightmap to a regular 16x16 boolean collision array you'll be fine. It doesn't really matter which way you implement it, you won't be able to measure a performance difference no matter how hard you try. So just do itâ„¢
This post has been edited by winterhell: 17 December 2015 - 01:53 AM

### #10Techokami  Posted 18 December 2015 - 05:03 PM

• For use only on NTSC Genesis systems
• Posts: 1286
• Joined: 19-November 05
• Gender:Male
• Location:HoleNet!
• Project:Sonic Edge
• Wiki edits:63
You could implement the collision mask as a 3D array; that is, an array of 2D arrays containing the boolean values for a 16x16 collision mask. Then you just use some division and the mod operator on the player's coordinates to figure out what tile the player is in; divide by chunk size to get the chunk position to pull from the level layout, which gives you the ID of the chunk, then mod by the chunk size, then divide by 16 to get the 16x16 tile in the chunk, which can be referenced from the chunk data, which gives you the 16x16 tile (and therefore the collision tile to reference), then mod by 16 to get the position in the tile to check.

Well, that's how I would do it. There's probably a smarter way to do it, but I'm not sure what it would be. It'd probably help if someone could unroll the loops from the disassemblies or something.

### #11Travelsonic  Posted 21 December 2015 - 02:47 PM

• Posts: 714
• Joined: 01-March 05
Another dopey Q:
This time, regarding bumpers:

Quote

The bumpers in Spring Yard Zone set Sonic's X speed to 7*cosine(p), and Y speed to 7*-sine(p), where p is the angle measured from the bumper's centre to Sonic's. This is regardless of Sonic's velocity when he hits the bumper.

So basically, this is irrespective of his x velocity, or y velocity? So basically, he could collide with whatever combination of X/Y velocities, and this formula will not change at all?

If so, time for me to look at my collision routine for the bumper, as something goes wrong. When I hit the bumper, it doesn't always bump me in the right direction, as in, hitting it from its right side works, but hitting it from its left side propels sonic in the same direction as if he hit it on the other side.

EDIT: Yay, post 666. :D
This post has been edited by Travelsonic: 21 December 2015 - 02:49 PM

### #12winterhell  Posted 22 December 2015 - 09:55 AM

• Posts: 1138
• Joined: 16-October 10
• Gender:Male

Travelsonic, on 21 December 2015 - 02:47 PM, said:

Another dopey Q:
This time, regarding bumpers:

Quote

The bumpers in Spring Yard Zone set Sonic's X speed to 7*cosine(p), and Y speed to 7*-sine(p), where p is the angle measured from the bumper's centre to Sonic's. This is regardless of Sonic's velocity when he hits the bumper.

So basically, this is irrespective of his x velocity, or y velocity? So basically, he could collide with whatever combination of X/Y velocities, and this formula will not change at all?

It certainly looks that way.

If you want to see if your values are correct you can print/log the character and bumper positions at the time of the collision and the calculated angle and new speed.

I imagine to get the angle you are using Atan2 of the character and bumper positions, right?
This post has been edited by winterhell: 22 December 2015 - 09:56 AM

### #13Travelsonic  Posted 22 December 2015 - 10:57 AM

• Posts: 714
• Joined: 01-March 05
Yes, measured from the middle of Sonic to the middle of the bumper, used atan2 to get the angle.

EDIT: OK, so I got it working at last. A logic error in my collision function.

Next question probably coming soon. :D :P
This post has been edited by Travelsonic: 22 December 2015 - 12:46 PM

### #14Travelsonic  Posted 24 December 2015 - 07:20 PM

• Posts: 714
• Joined: 01-March 05
OK, next question: on ground speed, and angles:

Quote

While on the ground, Xsp and Ysp are derived from Gsp every step before Sonic is moved. Perhaps a pseudo-code example is in order:

Xsp = Gsp*cos(angle);
Ysp = Gsp*-sin(angle);

X += Xsp;
Y += Ysp;

No matter what happens to the angle, Gsp is preserved, so the engine always knows what speed Sonic is "really" moving at.

Question is, what values would I use to get the angle that I use in calculating the x speed, and y speed? Of course, I assume like with bumper collisions, I am gonna use atan2.
This post has been edited by Travelsonic: 24 December 2015 - 07:25 PM

### #15Techokami  Posted 24 December 2015 - 09:30 PM

• For use only on NTSC Genesis systems
• Posts: 1286
• Joined: 19-November 05
• Gender:Male
• Location:HoleNet!
• Project:Sonic Edge
• Wiki edits:63
Angle data is... actually stored as part of the collision data. So instead of calculating the angle on the fly, it's done for you, and you just use a lookup table.

• 2 Pages
• 1
• 2