Getting involved

[Aravi]

How might I go about getting involved as a developer?

I may soon have a fair amount of free time and I would like to help out. I am a moderately skilled C/C++ programmer and I have limited skill in the map and model-making department.

Basically want to start with simple coding tasks (eg. synchronising the walk animation to walking speed), and work my way up.

[Kiern]

check out the main page under help us! and recruit for info!  

[Aravi]

Hmmm....

What happened to the old \"Anonymous CVS\" system that most projects use?

Oh well, code submission from me

Code: [Select]


/*
===========================================
  takes the stride length and movement rate
  in units per second.
===========================================
*/

//Count of frames in walk animation
const int WalkFrames = 4

[b]float[/b] GetFrameDelay(int Stride_len, int MRate)
{
return (1000/MRate)/(WalkFrames*StrideLen));
}


Quite simple, just calculates the delay between animation frames.

Eg, moving at 200 units per second with a stridelength of 50 you would have to take 4 strides (of 4 frames each) and therefore would have to advance the animation 1 frame per unit moved.

You move 1 unit per 5ms, so the model frame would have to advance frame at that rate. Hmm, my example runs pretty fast.

I\'ll send in an application soon.

[Vengeance]

Aravi,

Thanks for the code submission but that isn\'t how it works at all.  

First of all, the frame rate of the game is not constant.  Depending on the complexity of the scene being rendered, it can change drastically from one frame to the next.

Secondly, how you walk should be independent of framerate, or else people with slow framerates will walk more slowly than people with fast framerates.

If you would like to download and build Planeshift yourself, you are welcome to do so.  Search on planeshift at sourceforge.net.  Then in the CVS archives, under /docs/compiling.txt there are instructions on how to do it.

Once you see the code, I think you\'ll have a better idea of what we are up against with regard to this walk synchronization problem.

Thanks,
Vengeance

[Maskil]

How the hell did you learn that stuff?

[Cthulu]

read books, take classes, talk to people.

[Aravi]

The \"frame-rate\" that code snippet is meant to control is the animation frames for the model, not the framerate of the game.

The idea is it works out how long each animation frame for the model has to be.

[Vildaar]

Just a little helpful advice, Vengeance knows what he is doing...arguing with him has about as much usefulness as trying to mate a tree with a cat. The point is, is that that was not impressive at all, I don\'t think 4 lines of code can even be considered a submission

[Maskil]

wow, a Tree Cat, does that mean that everytime you would want to see your cat you\'d have to call the fire department to get your cat out of the tree?

[Aravi]

Originally posted by Vildaar
Just a little helpful advice, Vengeance knows what he is doing...arguing with him has about as much usefulness as trying to mate a tree with a cat. The point is, is that that was not impressive at all, I don\'t think 4 lines of code can even be considered a submission

When reading his post I got the impression he had mis-interpreted how that snippet was meant to work.

I didn\'t submit it to show off, it was very simple. I just felt like adding it as a thought.

[Vengeance]

Sprite animations are defined as a series of key frames, each separate by a number of milliseconds.  Currently, Planeshift sprites are using 30 keyframes per animation, with 66msec between each one.  This yields a 2 second loop.

Based on the exact timing of the frame when it is rendered, Crystal Space interpolates between key frames.  For example:

Time 0msec:  Key Frame 1 is rendered exactly as is.

Time 100sec:  A new frame is rendered which is interpolated to be halfway between what frame 2 looks like and frame 3 looks like, because frame 2 is at 67msec and frame 3 is at 133msec.

In other words, rendering and key frame delays are only partially related.  The real issue is that our frames are just too slow for how fast our players walk.  That is easily changed in the sprite definition file--no code required.  However, it is pointless to change those until someone decides once and for all how fast everyone will walk/run.

Hope that helps clear it up.

- Vengeance

[Aravi]

Ok, but why can\'t you vary the time between keyframes in the code?

That way it could be done dynamically.