• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
prushik

2D driving physics woes (problems) 2D Vector Math questions

9 posts in this topic

Hi, I am working on a driving game at the moment, and I am having some serious problems with getting the physics to work right. Not just minor problems, I mean, I am having trouble keeping the numbers from ending up at -NaN within like 5 frames.
I have been following a tutorial that I found here on gamedev.net, but it is written in C#, and I am using C, so I am trying to translate everything into C. The tutorial I am following is here: [url="http://www.gamedev.net/topic/470497-2d-car-physics-tutorial/"]http://www.gamedev.n...ysics-tutorial/[/url]
I did the first part and got what looks like a working rigid body simulator, I could apply a force vector and an offset vector and it moved in a way that looked sane. So I moved on to the rest of the tutorial, and I think I translated all the code pretty well, but then as soon as I ran my executable, everything went crazy.
I spent all of 3 days of free time (not that much with class and both of my jobs) looking for bugs. And I can't seem to find any. I found some discrepancies with the vector math in the tutorial and what I read, so I changed my functions to match the ones on the tutorial, and it almost worked, till I tried to use an angle other than 0.
Oh, I'm also using Linux and SDL2. It should compile easily on Windows if you have SDL2, my code is pretty portable.
Anyways, I'll attach the code, take a look at it and see if you can find any problems with my math. You should probably check my rigid body code, just in case I did something wrong but it just looked right to me.
Thank you in advance, I love you.

EDIT:: I posted updated code. The size is also smaller since I left out some unnecessary images. but the other file (a few posts down) has some code I left out before (accidentally) and includes a makefile so it should be enough to compile if you have SDL2. Edited by prushik
0

Share this post


Link to post
Share on other sites
Not sure if this fixes it but it looks like you are passing your angles in degrees and in physics.c you apply [b][i]radians to degree[/i][/b] instead you should be using [b][i]degree to radians[/i][/b] (angle / 180.0 * PI)
0

Share this post


Link to post
Share on other sites
[quote name='Scorpie' timestamp='1350664662' post='4991817']
Not sure if this fixes it but it looks like you are passing your angles in degrees and in physics.c you apply [b][i]radians to degree[/i][/b] instead you should be using [b][i]degree to radians[/i][/b] (angle / 180.0 * PI)
[/quote]
Thanks, I always mix those two up. Somewhere I put a comment in there about being confused as to which is should be. I found some type conversion problems as well, the degrees to radians problem might be the one final bug that I am looking for, I will let you know.
0

Share this post


Link to post
Share on other sites
Its true that my degree/radian conversions were wrong, however, seems that wasn't the only problem. Moving forward in a straight line seems to work ok now after some corrections, but turning still doesn't work correctly, and braking is even worse.
I added some code to draw lines representing force vectors so I could see what is happening and I am seeing some strange results.. Sometimes the front wheel force vectors point in the way I am trying to turn, sometimes they point straight ahead instead, and the back wheels tend to go in opposite directions when I try to turn. I can't understand why this happens.
I will attach my updated source to this reply, this time I will include my makefile and a source file that I forgot last time (sdl.c) which contains all the drawing functions.
Let me know if you see any more problems, I'm sure there are more...... Thank you for the help.

[attachment=11839:car.zip]
0

Share this post


Link to post
Share on other sites
Found another problem. I assumed that the tutorial used degrees and not radians, so I assumed that the value calculated by CalculateForce was in degrees, multiplying it by (180/PI) gives much better results, now moving straight looks fine, and turning works up to about 45 degrees, turning left can never exceed 90 degrees now and turning right past 45 degrees results in the car accellerating and rotating out of control.
0

Share this post


Link to post
Share on other sites
Ok. I got it all working pretty much. In the pointvel function, my tangent was not at all a tangent, it was pointing the wrong way. and more importantly, I had forgotten to convert back to relative coordinates in the calculate forces function. After fixing those, it looks much more realistic, and probably good enough for my game, since my game won't have really high speeds or racing or high speed turning (at least not too much). I just need to play with mass and friction and tire radius to get what I want now.
However, there are some things I am confused about. For one, in the tutorial, the author uses the dotproduct of the forward vector and the difference between the ground and the wheel velocity, but calls it the magnitude of the forward vector. Why do we not use the magnitude of the forward vector here? (I tried, it doesn't work well)
0

Share this post


Link to post
Share on other sites
Also, the vector projection implementation using in the tutorial (which I implemented in C) is different from all other sources I looked at (yet, it works).
I originally implemented vector projection based on what I read about vector projection, but I later changed it to match the tutorial.

Here is my original implementation:

[CODE]
void projectVEC(VEC2 *a, VEC2 *b, VEC2 *out)
{
double mag,tmp;

mag=magVEC(a);
tmp=dotVEC(b,a)/(mag*mag);


multiplyVEC(b,tmp,out);

return;
}

[/CODE]

and the one I translated from the tutorial:[CODE]
void projectVEC(VEC2 *a, VEC2 *b, VEC2 *out)
{
double tmp;

tmp=dotVEC(a,b);
multiplyVEC(b,tmp,out);


return;
}
[/CODE]

Which one is correct?
0

Share this post


Link to post
Share on other sites
I guess you want to project a onto b?
The second implementation works if b is normalized.
Your implementation is for the general case, however you have to divide by the squared norm of b, not a.
0

Share this post


Link to post
Share on other sites
Silly author, Y u no explain things?

The reason the dot product is used instead of the vector magnitude, is because we are looking for the magnitude _in the forward direction_. Which means the result is signed. You could have a velocity _not_ in the forward direction, for which the dot product result would be negative. In other case, you may have some gigantic relative velocity, magnitude 1000, but if the vector is perpendicular to the forward direction, the dot product, and forward velocity magnitude, will be zero.

Sorry, this article is extremely dated. Good to see it's still got some legs though!

The correct projection is

Vec Project( Vec a, Vec onto )
{
Vec norm = onto.Normalized( );
return norm * Dot( a, norm ); //dot product against normalized "onto" vector.
}

You likely _dont_ want to use the magnitude of this vector, you likely just want the dot product result which is signed. (positive if vectors originally pointed in same direction, negative if not, zero if perpendicular)
1

Share this post


Link to post
Share on other sites
[quote name='bzroom' timestamp='1351515041' post='4995034']
The reason the dot product is used instead of the vector magnitude, is because we are looking for the magnitude _in the forward direction_. Which means the result is signed. You could have a velocity _not_ in the forward direction, for which the dot product result would be negative. In other case, you may have some gigantic relative velocity, magnitude 1000, but if the vector is perpendicular to the forward direction, the dot product, and forward velocity magnitude, will be zero.

Sorry, this article is extremely dated. Good to see it's still got some legs though!
[/quote]

Great, thanks so much for the explanation!
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0