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

### #16Travelsonic  Posted 25 December 2015 - 01:34 AM

• Posts: 701
• Joined: 01-March 05

Techokami, on 24 December 2015 - 09:30 PM, said:

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.

oh. duh... XD been brainfarting my way through this project, guess this is one more example of that. :P

### #17winterhell  Posted 25 December 2015 - 03:34 AM

• Posts: 1036
• Joined: 16-October 10
• Gender:Male
The angle is the first and last value in the collision mask, for example FE. Its a number between 0 and 255. Then you convert it to radians.

### #18Travelsonic  Posted 02 January 2016 - 03:04 PM

• Posts: 701
• Joined: 01-March 05
Eh, rather than calculate it, just went into SonED, and looked at the collision arrays (and their respective angles), which will allow me to take an array of values and make a tile map before the level is initalized.

Now I have a stupoid not-sonic-specific problem that is puzzling the hell out of me.

In my Sonic entity, I have 12 values. 4 representing the X/Y of 2 ceiling sensors, 4 representing the X/Y of 2 horizontal / midline sensor bars, and 4 representing the X/Y of 2 floor sensors. (ceiling 1 X, ceiling 1 Y, ceiling 2 X, ceiling 2 Y, midline 1 X, midline 1 Y, midline 2 X, midline 2 Y, floor 1 X, floor 1 Y, floor 2 X, floor 2 Y, in that order)

I have it in my collision function for my tile object so if the X and Y of either floor sensor is within the tile, Sonic is stopped. Problem is, I am missing something, since after walking on a couple of tiles, sonic sinks into and through the tile.

Been trying to figure out how to remedy this, but to no avail. What would cause something like this, and what are some ideas that could help? >_< BTW: The tiles are 16x16, pretty much ensuring, I hope, that at least one sensor is in a tile.
This post has been edited by Travelsonic: 02 January 2016 - 03:11 PM

### #19winterhell  Posted 02 January 2016 - 03:23 PM

• Posts: 1036
• Joined: 16-October 10
• Gender:Male
To be sure, leave only the floor sensors. Are you able to record a log or gameplay video with values overlay? This would be the fastest way to determine what is going wrong.

Also at first maybe try with just 1 floor sensor in the character center. If that works, then work with 2 and take whichever is higher.

Wild guesses would be that you are getting below the recommended 16-20 pixel floor step, or most likely stepping on a FF tile and calculating its angle wrongly.

### #20Travelsonic  Posted 25 January 2016 - 09:16 PM

• Posts: 701
• Joined: 01-March 05
Seems my biggest issue might be with my collision functions, and transitioning from one mode to the other - and whether or not that is happening at the right time or not is perhaps one thing I need to look at so far as my issue, since Sonic's behavior **seems** to show a continuous changing between floor and air states even when one of the floor sensors is actually on the tile. Definitely got some investigating to do.

Stupid Q #X I've also been confused about x position for sensor placement, since it seemed to me that this info, unlike Sonic's heights, and his Y position being where it is, X pos, width stuff seems absent. For now, I had just been using an X pos, and a width based on Sonic's sprite width to derive an X midpoint, and using that to derive horizontal placement of my sensors relative to Sonic/some horizontal midpoint, but am not sure if this is accurate, or contributing to my sensor collision woes.
I feel stupid asking these Qs, though I really had made a shit tone of progress in implementing Sonic's physics - spikes, bumpers, springs, movement on a solid floor, jumping/falling, drowning, etc.

Also had what is either a stroke of genius, or a stroke of derpitude:
Sonic Sonic has slightly different constants for moving under water, versus on the ground, I decided to have 2 arrays.
- one with his above-water movement constant values,
- one with his under-water movement constant values

I have a third, which holds the "current" set of constants, and whose values get applied to xSpeed/ySpeed (or gSpeed if on solid ground), and gets switched from one set to the other when Sonic enters or exits the water. I did this so I can just have functions with values being applied, instead of wasting time checking for if Sonic is either above, or under water, further adding to function complexity, if that makes any sense.
This post has been edited by Travelsonic: 25 January 2016 - 09:19 PM

### #21winterhell  Posted 26 January 2016 - 05:07 AM

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

Travelsonic, on 25 January 2016 - 09:16 PM, said:

Also had what is either a stroke of genius, or a stroke of derpitude:
Sonic Sonic has slightly different constants for moving under water, versus on the ground, I decided to have 2 arrays.
- one with his above-water movement constant values,
- one with his under-water movement constant values

Do they have to be constants?
You can have a function that changes the values depending on if you are under of above water and if you are super or not super.
Well if you are using a pointer to an array and just changing the pointer, then I guess its the same.

### #22Travelsonic  Posted 26 January 2016 - 02:53 PM

• Posts: 701
• Joined: 01-March 05

winterhell, on 26 January 2016 - 05:07 AM, said:

Well if you are using a pointer to an array and just changing the pointer, then I guess its the same.

For whatever reason, I thought that it'd be less intensive (and less of a clutter) to have the array swaps (yes, by changing the pointer / I am using ptrs to arrays).

I mean, unless I am mistaken, the values (friction, accel, deceleration, grav, etc) for above water, underwater movement, and Super Sonic movement in of themselves don't change - just which particular set (Super Sonic, above water, under water, etc) is being used, so I'd figure that I'd do a swap when transitioning from above to under water, from under to above water, when going Super, when losing Super, etc, rather than cluttering my movement function(s)* with additional checks for these things, then acting based on those conditions.

* Since I broke up my movement into 5 separate functions, one for each of the 4 modes (floor mode wall mode, ceiling mode, and air mode), and one for when sonic dies/drowns. My Sonic object has a var that holds the current mode Sonic is in, and when it comes time to move sonic, the move function called calls one of these 5 functions based on what this variable's value is (= 0 dead mode, 1 = floor mode, 2 = wall mode, 3 = ceiling mode, 4 = air mode)
This post has been edited by Travelsonic: 26 January 2016 - 03:03 PM

### #23Travelsonic  Posted 29 January 2016 - 08:14 AM

• Posts: 701
• Joined: 01-March 05
EDIT: Nevermind, jesus christ, I gotta stop trying to do this while sleep deprived, I miss so much shit in the guide. -0_0-
This post has been edited by Travelsonic: 29 January 2016 - 11:58 AM

• 2 Pages
• 1
• 2