Why not become a lifetime supporting member of the site with a one-time donation of any amount? Your donation entitles you to a ton of additional benefits, including access to exclusive discounts and downloads, the ability to enter monthly free software drawings, and a single non-expiring license key for all of our programs.

You must sign up here before you can post and access some areas of the site. Registration is totally free and confidential.

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

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).

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.

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.

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.

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.

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.

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. :-)

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