Did you miss your activation email?

• February 24, 2018, 12:14 AM
• Proudly celebrating 10 years online.
• Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.

### Author Topic: Writing a simple driving game (help!!)  (Read 8209 times)

#### chedabob

• Participant
• Joined in 2006
• Posts: 34
• C# Master (if only!!!)
##### Writing a simple driving game (help!!)
« on: October 09, 2007, 09:50 AM »
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

• Supporting Member
• Joined in 2007
• Posts: 927
##### Re: Writing a simple driving game (help!!)
« Reply #1 on: October 09, 2007, 10:07 AM »
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

• Participant
• Joined in 2006
• Posts: 34
• C# Master (if only!!!)
##### Re: Writing a simple driving game (help!!)
« Reply #2 on: October 09, 2007, 10:17 AM »
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

• First Author
• Joined in 2005
• Posts: 38,003
##### Re: Writing a simple driving game (help!!)
« Reply #3 on: October 09, 2007, 10:22 AM »
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

• Charter Honorary Member
• Joined in 2005
• Posts: 9,100
• [Well, THAT escalated quickly!]
##### Re: Writing a simple driving game (help!!)
« Reply #4 on: October 09, 2007, 10:37 AM »
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.
- carpe noctem

#### chedabob

• Participant
• Joined in 2006
• Posts: 34
• C# Master (if only!!!)
##### Re: Writing a simple driving game (help!!)
« Reply #5 on: October 09, 2007, 11:01 AM »
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

• Supporting Member
• Joined in 2007
• Posts: 927
##### Re: Writing a simple driving game (help!!)
« Reply #6 on: October 09, 2007, 11:40 AM »
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

• Participant
• Joined in 2006
• Posts: 34
• C# Master (if only!!!)
##### Re: Writing a simple driving game (help!!)
« Reply #7 on: October 09, 2007, 12:14 PM »
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

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

• Charter Member
• Joined in 2005
• Posts: 13,249
• Tell me something you don't know...
##### Re: Writing a simple driving game (help!!)
« Reply #8 on: October 09, 2007, 04:52 PM »
And yes, my motto really is "fix it even if it's not broken".  :-)
-Ralf Maximus

Oh don't say that!

At least call it refactoring!
Slow Down Music - Where I commit thought crimes...

Freedom is the right to be wrong, not the right to do wrong. - John Diefenbaker

#### f0dder

• Charter Honorary Member
• Joined in 2005
• Posts: 9,100
• [Well, THAT escalated quickly!]
##### Re: Writing a simple driving game (help!!)
« Reply #9 on: October 09, 2007, 05:05 PM »
Ralf Maximus: lookup tables were indeed faster back in the old days, but have you timed it on a modern processor?
- carpe noctem

#### Veign

• Charter Honorary Member
• Joined in 2005
• Posts: 993
##### Re: Writing a simple driving game (help!!)
« Reply #10 on: October 09, 2007, 06:30 PM »
Information on Game Physics:
http://www.gamedev.n...st.asp?categoryid=28

Especially the The Physics of Racing series.

« Last Edit: October 09, 2007, 06:32 PM by Veign »

#### tinjaw

• Supporting Member
• Joined in 2006
• Posts: 1,927
##### Re: Writing a simple driving game (help!!)
« Reply #11 on: October 09, 2007, 06:43 PM »
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

• Supporting Member
• Joined in 2007
• Posts: 927
##### Re: Writing a simple driving game (help!!)
« Reply #12 on: October 09, 2007, 08:59 PM »
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

• Charter Honorary Member
• Joined in 2005
• Posts: 9,100
• [Well, THAT escalated quickly!]
##### Re: Writing a simple driving game (help!!)
« Reply #13 on: October 10, 2007, 08:18 AM »
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
- carpe noctem