Writing a simple driving game (help!!)

[chedabob]

Right, so I'm trying my best to write a simple driving game in XNA (that's not important). Basically, it's a 2D top down game, but I'm struggling to get the vehicle to move in the direction it is facing. Does anybody have a formula that would give me the new coordinates based on the source position, rotation, and the distance to travel? I did try:

X = distance * cos(rotation)
Y = distance * sin(rotation)

but I just ended up with a vehicle that would rotate around the point, and sometimes it might just travel in the direction it was facing :p

[Ralf Maximus]

COS and SIN functions return a decimal value between -1 and 1, which is probably too miniscule to do what you want without additional multiplication.  I see "distance" up there, but that doesn't tell me much.  Distance in pixels?  Sectors?  Miles?

Generally what I do is keep separate fp variables to hold the accumulated "speed" of the vehicle and add that to the x/y coordinates periodically to generate motion.  Don't modify the x/y position directly -- only modify the vectors (call them vx/vy).

Does that help? 

[chedabob]

Distance is the amount in pixels it should travel.


I can move the vehicle about in any direction I want, but calculating how far X and how far Y to travel based on the rotation is the bit I'm struggling with.

[mouser]

I'm just so happy to hear that some dc members are coding some games! 
I hope you will share them with us.  I think actually i'm going to go create a special games section for the Programming School to encourage more of this.

[f0dder]

Sounds a bit like the trigonometry math involved in good old turtle graphics

You should add the cos/sin(angle)*dist to the curx/cury variables, btw.

[chedabob]

After hours and hours of swearing at the screen, poring over numerous tutorials and source files, I finally got it to work. Using degrees instead of radians was one problem, but also rotating around the wrong origin was the main issue.

[Ralf Maximus]

Excellent!  Nothing better than the feeling one gets after solving a brain-buster.

Now that you have the thing working (grin) it's time to rip it all out and replace it with this:

I've found that performance can be enhanced greatly in these kinds of games by precalculating all the SIN/COS values for each possible direction of movement and storing them in lookup tables.  RAM is cheap, the data we're talking about is not huge (assuming something like 5 or 10-degree increments), and the performance improvements can be breathtaking.  Integer lookups are nearly instantaneous, unlike SIN/COS calculations.

And yes, my motto really is "fix it even if it's not broken".  :-)

[chedabob]

Excellent!  Nothing better than the feeling one gets after solving a brain-buster.

Now that you have the thing working (grin) it's time to rip it all out and replace it with this:

I've found that performance can be enhanced greatly in these kinds of games by precalculating all the SIN/COS values for each possible direction of movement and storing them in lookup tables.  RAM is cheap, the data we're talking about is not huge (assuming something like 5 or 10-degree increments), and the performance improvements can be breathtaking.  Integer lookups are nearly instantaneous, unlike SIN/COS calculations.

And yes, my motto really is "fix it even if it's not broken".  :-)

-Ralf Maximus (October 09, 2007, 11:40 AM)

I'm writing a simple driving game, no proper physics or anything, so performance isn't really an issue :p

And whatever you posted, I can't see it 

[Renegade]

And yes, my motto really is "fix it even if it's not broken".  :-)

-Ralf Maximus (October 09, 2007, 11:40 AM)

Oh don't say that!

At least call it refactoring!

[f0dder]

Ralf Maximus: lookup tables were indeed faster back in the old days, but have you timed it on a modern processor?

[Veign]

Information on Game Physics:
http://www.gamedev.n...st.asp?categoryid=28

Especially the The Physics of Racing series.

Maybe something in there will help you.

[tinjaw]

When you are ready to take a break, grab some food and a beverage and watch this video. It is about an hour and fifteen minutes long. It will blow your mind. If you thought flight simulators were difficult to program?! Pishaa!!! Automobile racing is muuuuuuuuuuuuuuuuuch tougher.

[Ralf Maximus]

f0dder: Yep, and lookups are still faster, especially when managing hundreds of vectors simultaneously.  The FPU can also introduce bottlenecks and is somewhat immune to out-of-place executuion.  Simple integer functions stay in the registers and benefit from all processor optimizations.  (I speak from experience with Intel iron; dunno about AMD.)

If you can offload some of that to the GPU, then yeah, hardware translation makes sense.  But if the target system doesn't support whatever wacky graphics calculation you're attempting, then Windows' HAL kicks in and you're right back to overloading the processor with emulation.  So why not cut to the chase and do as much with integers as possible up front?  If you can keep everything in the registers and internal cache, even better.

Eventually my wrinkly old ideas WILL be obsolete, and we're almost there.  But not quite.  :-)

[f0dder]

I guess it depends on what kind of precision you need - just a few taylor iterations should give you a decent cos/sin approximation, dunno how big a LUT that would correspond to, but "more than a few cache lines". Friend of mine says that a 4096-entry LUT was too small for his 3D engine, it was too jerky (and when dealing with 3D operation, the sin/cos calls aren't too costly compared to the matrix operations anyway).

4k LUT table of single-precision floats = 16kb, or 256 x 64-byte cache lines (and still not good enough accuracy). Cache misses are pretty expensive. And especially if you're dealing with "hundreds of vectors simultaneously", my guess is that SSE code with a few taylor iterations would be faster than using LUTs.

As for GPU offloading, you obviously design the code for the GPU generation you're targetting; texture lookups for older generations, calculations for newer. But I have no experience with GPU programming, so the above is basically all I know about it