• 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
Slider_SLO

Bullet animation

13 posts in this topic

Im just wondering if anyone could help me out a bit...
First of all im making topdown 2d shooter with C++ and SDL and iwe got a problem with the bullet animation...
Anyone knows what math code should I use that the ''bullet'' would follow the mouse coordinates and then acctually go in a straight line from char coordinates to mouse coordinates? Tnx for any ideas...
0

Share this post


Link to post
Share on other sites
[quote name='Xaer0' timestamp='1355247420' post='5009466']
Other people will probably have some better ways to go about it, but that should get you started
[/quote]I don't think there are other ways that make any sense, actually.
1

Share this post


Link to post
Share on other sites
Actually, depending on his needs, it may be better to use a discrete pixel by pixel method.

You can calculate the angle of the click and the mouse by using:
[source lang="cpp"]angle = atan2f(clickedPosition.y - currentPos.y, clickedPosition.x - currentPos.x);[/source]

Then use the angle to calculate a "final" position, given a maximum distance that a bullet shall move:
[source lang="cpp"]finalX = currentPos.fX + (cos(angle) * maximumMovement);
nextY = currentPos.fY + (sin(angle) * maximumMovement);

[/source]
And finally use the bresenham algorithm to find all the pixels the buttlet would move by:

[source lang="cpp"]void bresenham(unsigned x0, unsigned y0, unsigned x1, unsigned y1){


int dx = absolute(x1-x0);
int dy = absolute(y1-y0);

int sx, sy;
if (x0 < x1){
sx = 1;
}
else{
sx = -1;
}

if (y0 < y1){
sy = 1;
}
else{
sy = -1;
}

int err = dx-dy;
while (!(x0 == x1 && y0 == y1)){

int errTimesTwo = 2 * err;
if (errTimesTwo > -dy){
err -= dy;
x0 = x0 + sx;
}

if (errTimesTwo < dx){
err += dx;
y0 += sy;
}

}

}
[/source]
Of course you would need some adjusts if you want the bullets to be dodgeable/renderable projectiles.
The advantages of this method is that it is really easy to find the bullet path and check for collisions if you need it.

Hope this helps [img]http://public.gamedev.net//public/style_emoticons/default/biggrin.png[/img] Edited by KnolanCross
1

Share this post


Link to post
Share on other sites
The first section there calculates the same location as Xaer0's simple approach, but does it in a more complicated and less efficient manner, thus does not make sense.

Bresenham's algo is almost completely unrelated to the question, and likely does not make sense for him to use in collision detection.
0

Share this post


Link to post
Share on other sites
Thanks guys im going to try em all to see what I get...
First just one question from Xaer0 what is that direction.normalize() and how do I use it?
0

Share this post


Link to post
Share on other sites
normalizing a vector makes the sum of all the components (x and y in this case) = 1,

http://www.fundza.com/vectors/normalize/index.html

that can explain it MUCH better than I can, very helpful and good to know for future use
0

Share this post


Link to post
Share on other sites
[quote name='Stroppy Katamari' timestamp='1355271932' post='5009605']
The first section there calculates the same location as Xaer0's simple approach, but does it in a more complicated and less efficient manner, thus does not make sense.

Bresenham's algo is almost completely unrelated to the question, and likely does not make sense for him to use in collision detection.
[/quote]

That was a bit rude, but let me clarify:

1) It doesn't do the same thing, it calculates a starting point and a predicted end point. His method calculates a direction and will interpolate it.
2) Atan2f is implemented uses a few ifs and atan, while the normalization uses sqrt, no one is "faster" in this point.
3) Breseham will interpolate using integer operations only, while Xaer0's approach used float point math that is slower.
4) The method Xaer0 suggested may move the bullet several pixels at each time the formula is executed, which may lead the bullet to bypass something it shouldn't (such as a wall). The method that I suggested will give the bullet trajectory, pixel by pixel.

Don't get me wrong, both methods will work, it is just a different approach for the same problem, the advantage is that it gives the tragetory, the disadvantage is that it is slower and a bit harder to use.
0

Share this post


Link to post
Share on other sites
[quote name='Slider_SLO' timestamp='1355305483' post='5009761']
Thanks guys im going to try em all to see what I get...
First just one question from Xaer0 what is that direction.normalize() and how do I use it?
[/quote]
Normalizing takes any length of vector and turns it into a "unit" vector, with length 1. This is mostly helpful when calculating things like direction (your case, perfect!), because if you then want to use that direction along with a speed or velocity variable, you don't want the "length" of the direction to interfere with the calculation. For example:

If I click on a point all the way across the screen, the initial vector calculated will be incredible long. That represents both the direction and the distance from the player/vehicle to my clicked point. If I used that vector in a multiplication with my bullet's velocity, it would be magnified by how far away the point was (and therefore, I could fire much faster bullets by clicking far away, and slower ones by clicking near myself). By normalizing it, the distance of that vector is changed to 1, while preserving the "direction" value. Multiplying anything by 1 doesn't change your outcome, so it's safe to use in your bullet velocity and travel case.

Edit: forgot to add, it's also crucial when trying to do other vector math like dot and cross products. Without normalized vectors in those instances, your results will be skewed and/or represent different properties of their related data than what you intended. Edited by BCullis
1

Share this post


Link to post
Share on other sites
[quote name='KnolanCross' timestamp='1355319181' post='5009816']
4) The method Xaer0 suggested may move the bullet several pixels at each time the formula is executed, which may lead the bullet to bypass something it shouldn't (such as a wall). The method that I suggested will give the bullet trajectory, pixel by pixel.
[/quote]

This might be a good place to point out that if you do collision detection in "pixel space", you are doing it wrong and should have a close look at why proper collision detection is very different from "checking for intersections every frame". After that you will realize why brute forcing collision detection by moving stuff in a painful pixel by pixel fashion to check every single one along the way is getting you down voted.

Sorry, but every time someone is throwing trigonometry at trivial problems it's making me cry.
1

Share this post


Link to post
Share on other sites
[quote name='KnolanCross' timestamp='1355319181' post='5009816']
1) It doesn't do the same thing, it calculates a starting point and a predicted end point. His method calculates a direction and will interpolate it.
[/quote]???
There's no interpolation of any kind in Xaer0's code. The only thing it does is directly calculate the end point. The same end point whose components are curiously named "finalX" and "nextY" in your code.
0

Share this post


Link to post
Share on other sites
[quote name='Trienco' timestamp='1355376855' post='5010079']
[quote name='KnolanCross' timestamp='1355319181' post='5009816']
4) The method Xaer0 suggested may move the bullet several pixels at each time the formula is executed, which may lead the bullet to bypass something it shouldn't (such as a wall). The method that I suggested will give the bullet trajectory, pixel by pixel.
[/quote]

This might be a good place to point out that if you do collision detection in "pixel space", you are doing it wrong and should have a close look at why proper collision detection is very different from "checking for intersections every frame". After that you will realize why brute forcing collision detection by moving stuff in a painful pixel by pixel fashion to check every single one along the way is getting you down voted.

Sorry, but every time someone is throwing trigonometry at trivial problems it's making me cry.
[/quote]

Sorry I wasn't clear, but I never said he should use pixel by pixel approach on colision, just that this will give him the trajectory that he could use to calculate the collision in a simple way (not using vectors, which is way more complex).

[quote name='Stroppy Katamari' timestamp='1355404703' post='5010191']
[quote name='KnolanCross' timestamp='1355319181' post='5009816']
1) It doesn't do the same thing, it calculates a starting point and a predicted end point. His method calculates a direction and will interpolate it.
[/quote]???
There's no interpolation of any kind in Xaer0's code. The only thing it does is directly calculate the end point. The same end point whose components are curiously named "finalX" and "nextY" in your code.
[/quote]

Every dt it will move the bullet, this will interpolate its trajectory.
I took it from a code I use on a game where nextX and nextY was used, it was just adapted to fill the post.

PS: Love how people negativate others without posting a reason around here. Edited by KnolanCross
0

Share this post


Link to post
Share on other sites
[quote name='KnolanCross' timestamp='1355261105' post='5009545']
Actually, depending on his needs, it may be better to use a discrete pixel by pixel method.

You can calculate the angle of the click and the mouse by using:
[source lang="cpp"]angle = atan2f(clickedPosition.y - currentPos.y, clickedPosition.x - currentPos.x);[/source]

Then use the angle to calculate a "final" position, given a maximum distance that a bullet shall move:
[source lang="cpp"]finalX = currentPos.fX + (cos(angle) * maximumMovement);
nextY = currentPos.fY + (sin(angle) * maximumMovement);

[/source]
And finally use the bresenham algorithm to find all the pixels the buttlet would move by:

[source lang="cpp"]void bresenham(unsigned x0, unsigned y0, unsigned x1, unsigned y1){


int dx = absolute(x1-x0);
int dy = absolute(y1-y0);

int sx, sy;
if (x0 < x1){
sx = 1;
}
else{
sx = -1;
}

if (y0 < y1){
sy = 1;
}
else{
sy = -1;
}

int err = dx-dy;
while (!(x0 == x1 && y0 == y1)){

int errTimesTwo = 2 * err;
if (errTimesTwo > -dy){
err -= dy;
x0 = x0 + sx;
}

if (errTimesTwo < dx){
err += dx;
y0 += sy;
}

}

}
[/source]
Of course you would need some adjusts if you want the bullets to be dodgeable/renderable projectiles.
The advantages of this method is that it is really easy to find the bullet path and check for collisions if you need it.

Hope this helps [img]http://public.gamedev.net//public/style_emoticons/default/biggrin.png[/img]
[/quote]
[quote name='KnolanCross']
PS: Love how people negativate others without posting a reason around here.
[/quote]

since you asked, I downvoted your first post because it's clearly above what the OP is attempting to do, and is imo quite a terrible method for doing collision checks. Xaer0 provided a great explanation about what to do, and is done in linear algebra.

you on the other hand used inconsistent naming convention(finalX, and nextY), didn't explain anything going on in the code you provided(you threw out a name of the algorithm, said what it does, but didn't actually explain how the algorithm achieves what it does, nor how to use it for anything.), that is why i down-voted you.
0

Share this post


Link to post
Share on other sites
[quote name='slicer4ever' timestamp='1355438574' post='5010360']
(snip explanation) ... that is why i down-voted you.
[/quote]
Knolan, you've been around here for a few months, so don't think I'm trying to be patronizing by explaining this. As a forum that does a lot of teaching to beginners and hobbyists in comparison to discourse between experienced programmers, we have to find a balance when sharing information. A negative vote covers areas that include "this is going to confuse the person asking for help, or over-complicates the provided solution scenario".

Just being skilled in a craft doesn't make for a good teacher, it's as important to know how (and how much) to share as knowing what the solution is. While you may be partial to your solution, just like anyone else, is it really, objectively, as easy to implement and straightforward to understand to someone asking for "any" math solutions to a common linear algebra problem? If the answer is honestly "no", then at least indicate as such ("this is another less common approach") and make sure to explain it.

(I minored in math with my undergrad and I have no idea who Bresenham is, it's a likely bet the OP doesn't either, so talking through the algorithm a little would have gone a long way)
1

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