[airstrike] Hi

[Dan]

Hey, I made my game called also called 'AirStrike' for my final year of
high school/HSC project, I lost my RPG for some reason, and panicked,
and made it in two hours, starting at ~12am on the day it was due in, so
the code is a mess, but it works, made in VB6 and DirectX -
http://www.drakkan.net/airstrike.html

Anyway, I can program in C++, been doing that a lot recently, and
working with SDL.

About friction, you can always fudge it to a scale, the ratio (not the
actual value you might use, or could be) could be something like
friction ratio = speed x mass x (acceleration + 1), but I guess you
probably wouldn't want to do that :)

-----Original Message-----
From: Ulf Ekström [mailto:ulfek at ifm.liu.se] 
Sent: Monday, 4 October 2004 11:16 PM
To: airstrike at icculus.org
Subject: Re: [airstrike] Hi

Hi!
 
Development has been sleeping for a while, but maybe it's time to start
it again. 

> I recently read that you were after some help with the collision
> detection. 

It's not the collision detection in itself, that is already working, but
rather the mechanics that need to be fixed a bit. 

> I'll say right out that I have never programmed a game before,
> nor have I ever written in C, but I figure I'll have to learn
sometime.  
> The one thing I have that might be useful is a background in maths, so
if 
> I could get a better idea of the problem I might have a chance at
finding 
> a solution.  

I think you could help as long as you can download the code
and compile it yourself. I will summarize the actual problem:

The collision detection code in the game gives us only one quantity: The
number of overlapping pixels (Let's call it A, for area). This means
that we do _not_ have the point of collision. This doesn't matter so
much since it's anyway hard to define a single point of collision in a
robust way (The objects are soft in reality, so they are colliding along
a surface). So what can we do?

If we have the overlapping area A between two objects we can calculate
the change in A with some small movement of the two colliding objects.
Since the grad A points in the direction where the overlap is increasing
fastest we can use -grad A as a collision normal. This works very well
in practice (You can download the CVS version and test for yourself),
but the problem is that in the current formulation rotation is not
included in collisions, or only included in an ad hoc way. For
non-rotating motion I have set up the following algorithm:

Determine the overlap gradient by finite difference, let n = - grad A.
Assume that the objects will change velocity only along n. Write down 
the change in kinetic energy for a change in velocity along n (with
conservation of momentum this gives a single parameter determining the
energy loss). It turns out that there is exactly two points for this
parameter where the energy is conserved, one trivial point with no
change in 
velocity (not what we want), and on point which is totally elastic
collision. Halfway between these two points there is the point of
maximum energy loss which is totally plastic collision.

Questions: 

1) How can rotations be included? The gradient can of course be 
computed also for rotation, but it get complicated further on. 

2) How can we add friction without knowing a point of collision?

If you have any simple technical questions please adress them directly 
to me instead of to the list.

Regards,
Ulf