Math for Trigonometry Reflection --Most of it figured out (yay)

Started by Knox, Tue 10/04/2012 17:29:04

Previous topic - Next topic

Knox

Hi guys,

Ive been trying a few things (from this thread: http://www.adventuregamestudio.co.uk/yabb/index.php?topic=44508.msg610016#msg610016) and I though of something that I think would work...but not too sure of how to get the math for a trigonometry reflection on vectors:



It would go something like this:

0) Once the car walks onto the region before an intersection, we save/get some variables (speed, direction of car, current car sprite, if the light is green or red, if the turn indicator is set to turn right, left, or straight ahead ) and then move the car with blocking animation from point A to point B, while deccelerating to an almost stop (decceleration code taken from the Taxi Demo)

1) Once the car walks off the region, if one of the turn indicators on the GUI was set to "turn right", for example, the variable is read and start the procedure of turning the car right at the intersection: we save the current position of the car...then calculate the car's destination position using trigonometry math (reflection on the imaginary y axis that divides the intersection in 2, since we are turning right)

2) With blocking animation, move the car along a curved line from current position to the destination position, using an "x" amount of frames from a pool of sprites pre-rendered by increments of xº angles. The smaller the curve, the less frames the animation gets ("x" minimum), and the longer the curve, the more it gets ("x" maximum.) **Dont know what these "x" values should be  :P

3) Once  the blocking animation is done and the car is now at its destination position in the Destination Region (with proper direction angle + sprite), the car resumes its movement forward with the same speed settings that was saved when the car originally walked onto  the "Turn Region".

Could anyone be kind enough to workout some code to show how I could accomplish all this?
;D

--All that is necessary for evil to triumph is for good men to do nothing.

Knox

#1
Ill try to post a quick vid on youtube to show what Ive been able to figure out myself so far...maybe this will give a better idea!

**edit:

Ive got almost everything figured out myself (yay!) except for how to do the block animation of the car turning (getting the trigonometry math)...I'll still continue to fiddle away on that last part myself for now...but if I get REALLY stuck on it I'll post again here again to beg for help, hehe!

Here is another pic to help clarify what I mean:


How do I calculate the pivot point's position (x,y)...it seems by manual placing its something around (0, 3.25)...but how do I get to those numbers mathematically?

Also, Im not sure of the mathematic formula to get the waypoint vectors along the curves generated between points.

--All that is necessary for evil to triumph is for good men to do nothing.

Khris

Since it's an isometric view, the path you want is actually part of an ellipse, not a circle. What you do is calculate everything assuming a top-down view, then squash the result back into isometric by multiplying the y coordinates by sin(30°), ~ 0.454.

The circles center is the topmost of the four X's made by the four grey lines: (0; 1).
To get a smooth movement along the path, iterate through the angle, in this case from 45° to 135° (0° is east, 90° is south, etc.).

I'll probably post code later today as I'll be off to work now.

subspark

And this is in the beginner's forum? Sheesh!
This moves my code & math capacity all the way down to illiterate now. :-[

Knox

--All that is necessary for evil to triumph is for good men to do nothing.

Monsieur OUXX

Maybe you should just do a small transformation from isometric space to 2D "top view" space (by simply scaling up stuff vertically), then do all your angles calculations (using regular maths) then switch back to isometric.

In a far-fetched kind of way, that's what's done in hardware-accelerated 3D for rotations: Objects are moved to coordinates (0,0,0), then rotated, then moved back to their original position.

So it might consume a little bit more CPU time, but make your algorithms one billion times simpler -- and maintainable!

EDIT: Woops, I didn't see Khris' answer.
 

SMF spam blocked by CleanTalk