hi, am a new programmer and have been working with C++. I am planning on using Allegro for my first project. (SDL is an option as well...) Anyways, I have succeeded stage one of my project: Print sprite on screen (simple ship w/no rotation capabilities, ie always facing straight) Now it is easy to move using either "++" or "--" by writing a function (triggered by key press...) that does simple arithmetic on the x,y coordinates of the draw sprite function. ok... As a new programmer (about 5 weeks of hitting a couple different books) I am very confused how to implement a 'physics' system. I mean I want tweakable handling. Non-linear accelaration (gains momentum when moving forward), some drift when moving left to right etc... Almost like a hover effect. Structurally I am very confused how to approach this problem. This is vague but I would be thrilled to hear some ideas how this general concept might be tackled. ///////////////////////////// Getting that to work is my number one priority, if you know multiple ways of achieving this, here is some more context as to my long-term thinking. As exercise, I would like to write a scrolling, overhead shooter where the player can customize the ship's handling. (Most likely no rotation, just left right, back, forward) Customization would be implemented by a pop-up grid where player draws curves detailing acceleration, drift and brake rates... That's it, ideas and chapters to examine would be awesome.

Basically you want to stop thinking about using the keypress to actually modify the position, and instead use it as an idea of where the user is trying to move.

The first step is to create another variable for velocity. When the user presses the buttons, set the velocity.x and velocity.y to whatever speed you want them to move. The speed should be calculated in units per second (e.g., if you set velocity.x to 100, then the ship will move 100 pixels in one second).

Then, every frame of your game, calculate the amount of time that has passed since the last frame update, as a float in seconds. Update your position each frame with the velocity scale by time. In pseudo-code:

To do the gradual speed you want... when the keys are pressed, instead of setting the velocity to maximum immediately, increase it a bit at a time until it reaches the maximum. When they aren't pressing the key, instead of just setting velocity to 0 every frame, lower it gradually until it is zero.

[Edited by - SantaClaws on January 26, 2007 3:27:48 PM]

Exactly what the above poster suggested , just add Velocity in your program.But since you mentioned C++ I would suggest SDL , since I think it is very good and has very nice tutorials for someone completeley new to learn from scratch(assuming he has C++ knowledge)

Here you can find links to many tutorials.I would suggest 2 of those.

Suggestion 1
Suggestion 2

And for graphics :
Graphics suggestion

thanks for the info...
I guess I' having trouble wrapping my head around the architecture. Can anyone provide a good idea (using the OOP)(or maybe why not?)...approach, what a list of all classes, fucntions, and variables would look like? I guess a shell to work from would help me with attaining programmer's zen while trying to figure all this stuff out. I mean, I've seen examples that have a seperate graphics class, which I don't really understand. If I made a class with all the ship's info, why does it make sense that the function to draw the ship be somewhere else? Any help with the bigger picture would be awesome. In the meantime anyone else reccommend any good tutorials?

Quote:Original post by auric
I mean, I've seen examples that have a seperate graphics class, which I don't really understand. If I made a class with all the ship's info, why does it make sense that the function to draw the ship be somewhere else?

You would decide to move something into a helper class or function is for one main reason: so you don't have to repeat yourself.

If you have many types of objects in your world, and each of them goes through the same steps to draw itself, but only the sprite is different -- why not put this into a helper class or function instead of needlessly typing it over and over?

The side effects of this are that: it becomes faster to add new objects; if you want to change something in the way things are drawn, you only need to change it in the helper class, not the millions of objects; your code is more compact, approachable, and readable.

Don't overdo the design problems in your head at this stage. It's more important to get it working. If you start running into the problems I described (code is hard to follow, you're typing the same things over and over, etc.) then take a step back, and try to rethink your code design.