extern float woozy; extern float blackout;
I think this about sums it up.
Posted by CombatWombat on 21 October 2013 - 07:22 AM
extern float woozy; extern float blackout;
I think this about sums it up.
Posted by CombatWombat on 31 August 2013 - 02:09 PM
If I understand your problem correctly:
You want to generate a random point (x,y) for a player that owns the chunk of circle between 0deg-15deg and your circle radius is 1 unit...
Randomly generate a vector as a length of 0-1 and an angle between 0-15deg.
The end point of that vector will be
x = L * cos(angle)
y = L * sin(angle)
You need to watch the convention of the sin/cos function you are using with regards to degrees vs radians.
Posted by CombatWombat on 11 August 2011 - 03:53 PM
So how exactly would I go about writing this. I need to figure out where the horizon is relative to the screen position I guess? So I first need to calculate the position of the horizon and then transform that to screen space (I know how to do that second part). Any idea how to do the first?
Posted by CombatWombat on 22 July 2011 - 10:22 AM
Strictly speaking "you" don't do anything explicitly in your code to compress the spring. The motion of the bodies should do this automagically.So if I understand you correct, I should not add a collision force/impulse to keep the car from the ground. Rather, I should just compress the spring. Next, this will result in the two masses connected to the spring each getting a force directed from each other, which should be equal in magnitude.
You should be worrying about "the equal and opposite" on a per joint basis.Hmm, or perhaps not? The spring can store potential energy (like gravity) so it doesn't completely obey newton's third law. At least on some level of abstraction, if I understand it correct.
This is true of about any spring simulation. Doubly true where you have a maintained collision (resting contact). I would suggest using RK4 integration with a suitably small timestep, and using a damper (shock absorber to us 'mericans) along with your spring. Maybe someone can come along and make suggestions on how to make the collision response more robust.The wheel will get the most acceleration because it is the lightest of the two bodies, so it will probably collide again. I suspect this will result in jittery motion. Maybe I should do the same calculations several times each frame to reduce this?
Springs don't work perpendicularly. You need another constraint to handle this. IE: Model a linkage that actually holds your wheel to the car, and then let the spring just worry about springynes. So when your wheel runs into this perpendicular surface, then load goes into this new constraint (and then into the body of the car, probably stopping it abruptly). The spring likely never deflects.With the springs having only one freedom of movement, the spring length will in some cases have to become infinitely long to get out of the ground. That is when the car is colliding with a surface perpendicular to the spring axis. What is the best way to deal with this? I am thinking in the lines of having an angular spring as well.
You put energy into your car to move it in the first place. Or it had some, as a byproduct of elevation. The spring is just storing some of this temporarily, and will give it back (minus any absorbed by the dampers) to the car body when it extends to original length.When compressing the spring, this will add energy to it. And since this energy is not based on the mechanical energy of the car, isn't there a danger for unstable and somewhat random motions? Proposed solution: Take the desired absorbed energy of the car, and use the spring constant to calculate the distance based on this energy. Artificially move rest of the car out of the collision area.
Posted by CombatWombat on 20 July 2011 - 10:33 AM
Posted by CombatWombat on 11 June 2011 - 03:56 PM