Welcome Guest. June 20, 2013, 02:29:53 AM

Or did you miss your validation email?

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.
 Check out and download the GOE 2007 Freeware Challenge productivity tools. Entire Forum This board This topic Members Help Desk Entire Site
Pages: [1]   Go Down
 Reply  |  New Topic  |  Print
 Author Topic: Writing a simple driving game (help!!)  (Read 3820 times)
chedabob
Participant

Posts: 34

C# Master (if only!!!)

 « on: October 09, 2007, 09:50:25 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
 Logged
Ralf Maximus
Supporting Member

Posts: 927

 « Reply #1 on: October 09, 2007, 10:07:53 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?
 Logged
chedabob
Participant

Posts: 34

C# Master (if only!!!)

 « Reply #2 on: October 09, 2007, 10:17: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.
 Logged
mouser
First Author

Posts: 31,096

 « Reply #3 on: October 09, 2007, 10:22:34 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.
 Logged
f0dder
Charter Honorary Member

Posts: 8,774

[Well, THAT escalated quickly!]

 « Reply #4 on: October 09, 2007, 10:37:22 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.
 Logged

- carpe noctem
chedabob
Participant

Posts: 34

C# Master (if only!!!)

 « Reply #5 on: October 09, 2007, 11:01:16 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.
 Logged
Ralf Maximus
Supporting Member

Posts: 927

 « Reply #6 on: October 09, 2007, 11:40:47 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".  :-)
 Logged
chedabob
Participant

Posts: 34

C# Master (if only!!!)

 « Reply #7 on: October 09, 2007, 12:14:39 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".  :-)

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
 Logged
Charter Member

Posts: 8,568

Tell me something you don't know...

 « Reply #8 on: October 09, 2007, 04:52:15 PM »

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

Oh don't say that!

At least call it refactoring!
 Logged

Slow Down Music - Super Simple - Where I commit thought crimes...

Freedom is the right to be wrong, not the right to do wrong. - John Diefenbaker
f0dder
Charter Honorary Member

Posts: 8,774

[Well, THAT escalated quickly!]

 « Reply #9 on: October 09, 2007, 05:05:08 PM »

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

- carpe noctem
Veign
Charter Honorary Member

Posts: 993

 « Reply #10 on: October 09, 2007, 06:30:03 PM »

Information on Game Physics:
http://www.gamedev.net/re...ce/list.asp?categoryid=28

Especially the The Physics of Racing series.

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

tinjaw
Supporting Member

Posts: 1,926

I'm so glad breakbeat techno isn't an illegal drug

 « Reply #11 on: October 09, 2007, 06:43:18 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.
 Logged

Ralf Maximus
Supporting Member

Posts: 927

 « Reply #12 on: October 09, 2007, 08:59:19 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.  :-)
 Logged
f0dder
Charter Honorary Member

Posts: 8,774

[Well, THAT escalated quickly!]

 « Reply #13 on: October 10, 2007, 08:18:35 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
 Logged

- carpe noctem
Pages: [1]   Go Up
 Reply  |  New Topic  |  Print