Movment...

Started by
13 comments, last by walle 19 years, 4 months ago
the only issue with using sine and cosineto manage the pixel movement, would be how do you draw your object 0.707 pixels in either direction? would you round it up to 1 pixel, if that's the case then you're increasing speed, if you round down you're decreasing speed, unless of course you decide to just keep the position internally, and just draw it off by a pixel, but with the next calculation use the internal value and not the actual drawn value... of course i don't know if anything i said makes sence, but it is quite the problem if you lose your real location and start rounding up or down as your speed will increase or decrease accordingly...
Advertisement
btw, SQRT(2) actually == 1.414, however 1/SQRT(2) == 0.707
Quote:
the only issue with using sine and cosineto manage the pixel movement, would be how do you draw your object 0.707 pixels in either direction?


I think you'd go with a float for keeping track of the X & Y values, and then let the computer figure out the best place to plot it.

Quote:
btw, SQRT(2) actually == 1.414, however 1/SQRT(2) == 0.707

ah, something like that. ;P
1/SQRT(2) = sin(45) & cos(45). interesting :D
I forget the significance, though it has something to do with triangles...1-1-srqt(2) right triangle comes to mind
Quote:
the only issue with using sine and cosineto manage the pixel movement, would be how do you draw your object 0.707 pixels in either direction? would you round it up to 1 pixel, if that's the case then you're increasing speed, if you round down you're decreasing speed, unless of course you decide to just keep the position internally, and just draw it off by a pixel, but with the next calculation use the internal value and not the actual drawn value... of course i don't know if anything i said makes sence, but it is quite the problem if you lose your real location and start rounding up or down as your speed will increase or decrease accordingly...


Yup, you got it. Store location as floats (or whatever), but plot as integers. When you do 3D work, your floats will be transformed through a number of matrices first, but still end up getting turned into integers (as pixels).

This becomes more interesting when you try doing some other things. For example, if you want to plot a wall in 2D, then if it runs from (x, y) to (x, y+5), it's pretty easy. But what if you want the wall to run from (x, y) to (x+2, y+5). What pixels does it go through?

Here b is the beginning of the wall, and e is the end.

b o o o o oo o oo o oo o o o o e


Jim.
Quote:This is again where vectors come in useful. Both the wall and the ball's direction of travel during the last frame can be represented by 2 different lines (the wall by the 'w's in the picture above, and the ball by a line travelling from top-left to bottom-right corners). Each of these lines can be represented by a vector. We can immediately see that the 2 lines cross, and therefore that there must have been a collision during the balls travel. Using a neat bit of maths, you can also compare the 2 vectors and find out not only if the ball collided with the wall, but also at exactly what co-ordinates.


Yes. I found a tutorial on using lines in collision detection here on gamedev. But it was a little short in the explanations...I'll keep looking...

Quote:How could I find a solution to move the same speed in any direction? Heres where it becomes important to pay attention in math class, or you'll spend a year trying to figure it out like I did. :P


Only problem...I don't get to read any more math after this course...and trigonomi is in the nex or so course...have to lern this on my own.

//walle

This topic is closed to new replies.

Advertisement