forums

TNT Basic Forums > Programming Q&A
ugly racer
< Last Thread     Next Thread >
Author
Thread        Post A Reply

09-30-2003 22:12

Posted by:
madscientist

Location:
n.ireland

Click Here to Email madscientist   Find more posts by madscientist

i have just started my a level project which will be a top down racer.
so far i have got a background map and a car that can rotate and move forward and back in the direction its pointing.unfortunatly if you try and change direcion it gets really ugly, especially if you change rapidly and is an s shape, as mostly you end up going in a semi random pattern in roughly the right direction and at other times just jumping a few tiles in a random direction.
heres the code im using

sprite 1,playerx,playery,000
if right then direction=direction+2
if left then direction=direction-2
set sprite rotation 1,direction


if direction >360 then direction = 0
if direction <0 then direction = 360

if up then speed=speed+(1/10)
if down then speed=speed-(1/10)
if pressed (49) then speed=0
if speed>20 then speed=20

if direction > 0 and direction < 89
xvel=(direction/90)*speed
yvel=((direction-90)/90)*speed
end if

if direction > 90 and direction < 179
xvel=((direction-90)/90)*speed
yvel=((direction-90)/90)*speed
end if

if direction > 180 and direction < 269
xvel=((180-direction)/90)*speed
yvel=((direction-180)/90)*speed
end if

if direction > 270 and direction < 360
xvel=((270-direction)/90)*speed
yvel=((direction-360)/90)*speed
end if


playerx=playerx+xvel
playery=playery+yvel


i dont quite know the physics of this entirely, so if anyone has a clue could they have a look?
andwhere would be a good place to look for physics info on collisions (ie: 2 cars hitting eachother)?

09-30-2003 22:41

Posted by:
buddy

Location:
Champaign, IL

Click Here to Email buddy   Find more posts by buddy

How I handle this is with sin and cosine.

Consider the car is moving "forward" at a rate "VEL".
What you need to do for your program is to resolve this into "xSPEED" and "ySPEED", so you know how far to move your sprite in the x and y directions, based on its current velocity (direction and speed.)

The "direction" should really be thought of as an angle.

So let's say your car is pointing directly right, and you call that "0 degrees".

If you rotate the car 33 degrees counterclockwise, we'll call that the positive direction (like on a protractor) and say the car is now pointing 33 degrees.

The xSPEED is:
cos(33) * VEL

The ySPEED is:
sin(33) * VEL

Blah blah...
Anyway, take it from there.

Hint: If you have pre-renedered your rotated images (i.e. you switch images for a sprite rather than do something like hardware rotation) then you can pre-figure the xSPEED and ySPEED for each angle of rotation.

That way, based on what angle (which will be in discreet amounts... each step of your car's turn might be 7.5 degrees, as in Maelstrom, or whatever...), you can just look up the speeds from an array, instead of actually doing the cos and sin in your event loop. This lookup should be faster than doing the math every time.

i.e. when you start your code, you could call a routine to populate:

float xMOV[42] 'stores x speeds for 42 different angles
float yMOV[42] 'stores y speeds for 42 different angles
(write a procedure to fill these in, based on a VEL of 1)

Okay blah blah I'm getting going again.
Post here if you need more help or example code.

09-30-2003 23:05

Posted by:
eekaydee

Location:
CA, USA

Click Here to Email eekaydee   Find more posts by eekaydee

Well, here's what I found:

quote:
if direction >360 then direction = 0
if direction <0 then direction = 360

This might cause a small problem: if you are at zero and turn left, you should face a few degrees left; however, the second line would make the direction equal to 360, so there will be a pause every time you cross the 0-360 line. Instead, try this:
quote:
if direction>360 then direction=mod(direction,360)
if direction<0 then direction=direction+360*(floor(abs(direction)/360)+1)


And Buddy post his reply as I typed this so I don't have to mention Sin and Cos.

quote:
you can just look up the speeds from an array

Hey I never thought of that! That's a good idea! I guess a lot of things can be done that way huh?

10-01-2003 02:14

Posted by:
buddy

Location:
Champaign, IL

Click Here to Email buddy   Find more posts by buddy

Optimizing for speed

quote:
you can just look up the speeds from an array
Hey I never thought of that! That's a good idea! I guess a lot of things can be done that way huh?


At the risk of going OT from the ugly racer...

Basically, try to think of anything you can to keep "work" out of your event loop.

1. Putting an actual value in your code should be fastest:
i.e. 736 or "Bill" or 88.393

2. Accessing a value from a variable is likely a tad bit more expensive... the runtime has to lookup the value of your variable, rather than just having it right there.

3. Accessing a value from an array is likely a tad bit more expensive than (2).

4. Doing any types of calculations in your loop will of course be expensive. If there is any way you can do calculations beforehand and reference them as needed in your event loop, then do it.

5. Conditional statements are expensive. Try to cut out the if/ else/ thens where you can.
Do this by nesting them where possible. If your left and right arrow keys rotate your character CCW and CW, respectively, then test like this:

if left
'do left stuff
else if right
'do right stuff
end if

That way, if your user is rotating left, the code never even has to check for rotating right.
NOTE the flipside, though... if the user is rotating right, then there is no savings here...

Another biggie I took out as far as conditionals go...
For topdowns...
I would move my character, then have to check to make sure he was not out of bounds. Can't get around that...

But I would then move my viewport to keep up with my character, based on the character's position. Well, then I would have to check to make sure my viewport was not out of bounds. D'ohh! Another nasty if/ then/ else...!

So, what I did was increase the size of my map by half the size of my viewport. That way, if I have the viewport centered over my character (who has already been checked for inbounds...) then there is NO WAY that my viewport can be out of bounds... I have "overhang" for my viewport to chill in... so I don't have to check anymore...

Sorry for rambling...
I should be working on sprites so I can finish this game! It has a halloween / Samhain theme, so I need to get crackin'...

All times are GMT        Post A Reply

Forum Jump:
< Last Thread     Next Thread >

< Contact Us - TNT Basic >

Powered by: vBulletin Lite Version 1.0.1 Lite
Copyright © Jelsoft Enterprises Limited 2000.