Physics Dept.

[DigiTan]

This is the latest thing I'm working on. Earlier I mentioned each pixel was split into 256 sub-pixels. 256 was overkill, so I'm limiting it to way less. This will also make Sonic appear to jump much higher and run faster. My goal is to make normal jumps around 56 pixels (3 1/2 times Sonic's height) and the springs do up to x4 that height. Right now, the biggest jump possible is only ~32 pixels. (D'oh!)

[John Barrus]

It seems to me that for the majority of the game, horizontal speed and acceleration will apply only to drawing the background, instead of the character. Maybe you should look into that, too. Nice job, though, that looks awesome.

[MeltedIce]

a, I never thought about that. Sonic never moves around the screen, its the backround that moves.

[DigiTan]

Well, that's partly true. In our case, the physics code will control the tilemap's offsets and give the appearance of scrolling. This applies everywhere except when Sonic approaches an edge or corner of map; then we would need to disallow scrolling and let Sonic move off-center. So in summary, you either move the background, or you move the character. (But never both at the same time.)

I'll be able to do backgrounds as soon as we agree on a tile-mapper and draw a test map.

[DigiTan]

I'm having trouble visualizing the forces that make an object can go through these loops physically. It know it's a combination of gravity and the normal force from the surface--but beyond that, I'm uncertain.

Also, I'm not 100% certain about how an object gets driven "up" the loop if these are the only forces at work. Momentum was something to do with it, but that's not a force.

Anyway, I need to get this stuff to work before loops will be possible.

[CoBB]

Momentum is provided automatically if you maintain the position and velocity vectors. To go through a loop it's enough if you have a large enough initial horizontal velocity and simply bounce off the surface. That's practically a rotation whose angle can be calculated from the current direction and the surface normal, which is basically what AG does (it also places the ball a bit away from the wall to prevent it from getting stuck). You can also cheat a bit and add some extra velocity to Sonic at each collision, but I don't think that's necessary. If you do it properly, it will be possible to fall back from the top with too little initial speed.

[Adm.Wiggin]

Listen to CoBB, he's a genious... He already did it with AG.

That screenshot looked awesome... I loved how the slow screen update made the ball appear to stretch out when it moved. Way awesome, keep it up!

[DigiTan]

So I guess when Sonic rolls up a loop, it's sort of like he's like constantly colliding and bouncing off the the surface?

[CoBB]

That's how it works in a quasi-physical simulation. Of course sometimes hacks are better than the straight way, like getting the coordinates from a time function or a LUT for these special cases. But I'd deal with only those special cases that can't be handled by the general code, so my advice is to test first.

[Raiser]

I'm no physics expert, so I can't help much in this department, but I can give you something that can help.

http://www.hacking-cult.org/?disasm/x

It's a disassembly of Sonic 1 for the Genesis. Perhaps it can be used as a reference for programming Sonic's physics.

[DigiTan]

I just made a major breakthrough with the physics code. Now the code can redirect Sonic's path as he goes from one surface angle to another. This is the part that will make loops possible.



...the movie simulates what happens if you hit a 45° "ramp" with a speed of 100 (this is not jump like before). There are some aliasing problems due to rounding, but it's only a problem at long distances. I'll send the latest code to the key programmers and the member forum as soon as the code is generalized.

[Madskillz]

wow...sweet looks awesome!

[DigiTan]

I found a few problems involving the graphics vs. angles.

At first, I wanted to do angles in 22.5° increments, but it looks like we can reduce our tileset size if we stick to even numbers. Basically, I had two possiblities in mind for possible surface angles:

#1 {0°, 30°, 45°, 60°, 90°, 115°, 135°, and so on}
#2 {0°, 15°, 45°, 75°, 90°, 120°, 135°, and so on}

Basically he's how a quarter-pipe might look using system 1 and 2...



#1 used 7 tiles and #2 needed 11. Anyway, my trig codes use sine tables, so none of these will cost us any size or speed. Also, I'm being experimenting with tile masks, and #1 and #2 will require fewer masks.

[John Barrus]

What about just doing 15 degree increments? {0,15,30,45,60....}

[DigiTan]

I'm glad you brought this up because that will work equally as well. The problem with my previous 22.5 system was that angles not divisible by 15 would not "link" together (graphically) unless the sprites were 9 pixels wide instead of eight.

Here's how my physics code would draw a 22.5-degree angle...


And he's how that slope would look like if it were "stacked" to create a hill. Once I used the 15-deg increments this was no longer a problem with 8-pixel sprites.

[DigiTan]

Animated the rolling sprite for the physics prog. The rolling speed is adjustable on a 0-255 scale.

Also took CoBB's advice and added adjustable screen refresh rates now that will keep the graphics load from becoming excessive. Map-hit detection is in, but buggy at the moment.



[Update]

The friction code was finished this past weekend, making the physics package complete. I'll start documenting the code so the 83+ team can port it.

[DigiTan]

Trouble in the physics department, Batman. Because of school commitments, it doesn't look like I'll have much time to program without my GPA taking another hit. My report card already looks like it was wearing a 'kick me' sign, so I'm gonna have to buckle down and avoid these major projects.

Basically, what we've got is a finished physics engine, and the start of map collsions. I can work on collisions until the yeah gets started again, but I'll need someone to take over after that. Also, I think we need someone to handle map compression so we can expand our test areas to more than 32x32. Until then, I've got an update for the physics code in the works that ~should be a little easier to port than the previous one.

[Madskillz]

Digi...well I hope you get your grades up mate, school is always more important! I did get the second physics engine ported...But if you can make the next one even easier, I have no complaints here! :biggrin:

[kalan_vod]

Sorry to hear digi, but look on the bright side we do appreciate your work .

[DigiTan]

Thanks. It's not really the grades I'm worried about, I have a lot of doubts over whether I could add more code at a decent pace. I'll try a few ideas on the collision code to see if we can set left/right collisions to work. That might give us enough momentum to move on to level design.