Need help moving projectiles with math...

[orogamo]

If the object has a rotation and speed, do this:

1   2   3   4   5   6   7

double x = 0, y = 0; x += speed * (float) Math.sin(RAD(rotation)); y -= speed * (float) Math.cos(RAD(rotation)); public static double RAD(double VAL) {    return ((VAL * 3.14) / 180); }

EDIT:
if the object moves the wrong way, switch the + & - signs.

[Roquen]

@Varkas - yes I'm sure.  As I'm fond of say, you can't make generalizations about computer science techniques.  And as I said, java doesn't have real immutables, so the only reason to go that route is for some design purpose.  A pure functional language can leverage immutability, java never can (at least until it adds them).

@orogamo - see: complex multiply

[Varkas]

And as I said, java doesn't have real immutables, so the only reason to go that route is for some design purpose.

I don't understand your sentance, I'm afraid. You say, Java doesn't have immutables. The Java String class is considered to be immutable though, and the page that I've linked talks about immutable objects in Java.

How does that go together?

I understand that for games performance considerations may lead to the decision not to use immutable objects - but I still don't understand why you say Java does not have immutable objects?

Games published by our own members! Check 'em out!

[Varkas]

Ok so i felt like i should know how to do this using the formula y-y1 = m(x-x1)

Movement formulas:

p = projectile position
v0 = initial projectile speed
g = gravitational force (downwards acceleration)
t = the time which the projectile has travelled already

1) p = v*t

2) v = v0 + g*t

3) p = t*v0 + g*t*t

if you set gravity to 0, you get

4) p = t * v0

which was suggested before.

If you want to consider air resistance, you need to reduce v over time.

[Roquen]

Java the high level language has 'final' which disallows direct modification once initialized.  It also has (for instance) reflection which allows these final values to be modified at any time during runtime.  Since the JVM is a dynamic language that cannot know all code that will run, it cannot do treat final values as immutable.  (The decompilation framework does deal with some guesswork of this nature, but not for fields).  Off and on there's been talk of adding real immutables, but it hasn't happened yet.

[Riven]

Java the high level language has 'final' which disallows direct modification once initialized.  It also has (for instance) reflection which allows these final values to be modified at any time during runtime.  Since the JVM is a dynamic language that cannot know all code that will run, it cannot do treat final values as immutable.  (The decompilation framework does deal with some guesswork of this nature, but not for fields).  Off and on there's been talk of adding real immutables, but it hasn't happened yet.

HotSpot already treats final variables differently, and changing their value through reflection results in 'undefined behavior', in some cases, where the actual memory location is updated, but the old value may be 'cached' in certain expressions.

1   2   3   4   5

final int one = 1; public int addOne(int val) {    return val + one; // might be compiled to value+1 (compiled by HotSpot, not javac) }

IIRC erikd ran into this years ago.

[Roquen]

Different issue.

SEE: http://openjdk.java.net/jeps/169

[sproingie]

That's utter nonsense.  Stop listening to whomever told you that.  Beside java doesn't even have immutable object (no...it really doesn't).  The widespread usefulness of immutables took a huge blow in the 80s with the introduction of SSA form, but even before that this statement would still be nonsense.

SSA, Single Static Assignment, would seem to imply that it makes everything immutable.  Seems compilers have moved in the direction of immutable data even for modeling state.

Look, in terms of theory, referential transparency makes everything so much simpler.  Pure functions can be memoized without fear.  Evaluation can be done in any order and parallelized trivially.  Testing is a matter of plugging in inputs and checking outputs, no setup needed.  The list goes on and on. 

The fact is, we still use mutable vectors and matrices because the garbage collector does not run at zero cost.  State might be useful for modeling other problems, but if not for the gc problem, most of us would rather be using actual math to describe math problems, not coaxing an automaton into simulating it.

[DrZoidberg]

Just thought I'd mention that from a computer science point of view, mathematical entities (e.g. Vectors, Matrices, etc) should always be represented by immutable objects ...

That's utter nonsense.  Stop listening to whomever told you that.  Beside java doesn't even have immutable object (no...it really doesn't).  The widespread usefulness of immutables took a huge blow in the 80s with the introduction of SSA form, but even before that this statement would still be nonsense.

SSA is just a technique used by compilers to optimize code. It has nothing to do with what I was saying. And it doesn't matter if Java has a keyword built in for defining immutable classes. You can still make objects de facto immutable.
I'm even gonna go a step further with my claims and say that making vectors mutable is a form of premature optimization and nothing else. Of course in game/graphic engines it may make sense to do that but unless performance issues force me to optimize my code, I'm gonna stick with immutablity.

[Roquen]

The point of SSA (indeed a backend compiler technique) is that transforms and analysis that were previously difficult to impossible for mutable values became possible and therefore made the argument for favoring languages and/or constructions that truly made usage of immutability less (or even much less) strong.  I have a reasonably firm grasp of issues related to mutable vs. immutable values (notice I'm talking about values rather than the more abstract notion of types).   Furthermore temporal coherency of memory accesses sticks yet another dagger into the heart of the importance of immutability.  But there's about zero reason to push this discussion into language design, type theory, lambda calculus and modern-esqe memory architectures, because it's moot. Java doesn't currently support immutable types in the sense that we are talking about. Back to the root of this,  DrZoidberg stated that "from a computer science point of view, mathematical entities (e.g. Vectors, Matrices, etc) should always be represented by immutable objects" to which I say is nonsense as you cannot make generalization of this kind, or at least worthwhile ones.  Besides computer science is a form of applied mathematics so really all types are mathematical and by this reasoning should be immutable.

I'm even gonna go a step further with my claims and say that making vectors mutable is a form of premature optimization and nothing else.

That's just silly.  This whole "premature optimization" garbage is really out of hand.  The important issue is opportunity cost.

Of course in game/graphic engines it may make sense to do that but unless performance issues force me to optimize my code, I'm gonna stick with immutablity

And, as I stated (or at least implied) there's not wrong with making the design choice of immutability (as long as it doesn't bite you in the butt), but that's a far cry from claiming that it's the "ordained true path" of computer science.

Games published by our own members! Check 'em out!

[wreed12345]

@varkas
If i were to use one of them, since p is the position would I set p to an x or y value? or something different?

[namrog84]

If the object has a rotation and speed, do this:

1   2   3   4   5   6   7

double x = 0, y = 0; x += speed * (float) Math.sin(RAD(rotation)); y -= speed * (float) Math.cos(RAD(rotation)); ... public static double RAD(double val) {    return (val * 3.14) / 180; }

EDIT:
if the object moves the wrong way, switch the + & - signs.

I think the cos and sin are backwards. I thought x always went with cos, and y with sin

[sproingie]

The fact that compilers are able to optimize mutability better is still very orthogonal to the fact that referential transparency is simply easier to reason about, both for the computer and the user.  Application is just textual substitution anywhere you want it to be.

But on the other side of the coin, the other unfortunate fact is that for a lot of games, we're still up against the limits of how well the machine can perform with immutable data. Since java has no concept of immutable values beyond primitives and some really basic optimizations on String, and therefore isn't going to bypass garbage generation very often, we're stuck with a lot of in-place modifications for matrix and vector ops done in bulk.

</derail>

[HeroesGraveDev]

If the object has a rotation and speed, do this:

1   2   3   4   5   6   7

double x = 0, y = 0; x += speed * (float) Math.sin(RAD(rotation)); y -= speed * (float) Math.cos(RAD(rotation)); ... public static double RAD(double val) {    return (val * 3.14) / 180; }

EDIT:
if the object moves the wrong way, switch the + & - signs.

I think the cos and sin are backwards. I thought x always went with cos, and y with sin

If 0 degrees is pointing along the y-axis, then x is sin and y is cos. If 0 degrees is pointing along the x-axis, you are right. It all depends on what system you use.

[Varkas]

@varkas
If i were to use one of them, since p is the position would I set p to an x or y value? or something different?

The variables are vector types, in 2D space, they will be (x,y) pairs.

Untested code, using java.awt.Point:

1   2   3   4   5   6   7   8

Point p = new Point(startx, starty); Point v = new Point(speedx, speedy); double time = (currentTime - timeWhenFired) * timeLapseFactor; // no gravity double actualx = p.x + v.x * time; double actualy = p.y + v.y * time;