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

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:

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.

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.

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.

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.

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. >_<

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™

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.

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.

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?