Actually it is easy... so nothing to dislike, I just did not get it, math classes are ages ago

If anyone is interested:

Since the solution is sin(pi*0.5*180/pi), which us equal to sin(x*90), just multiply any value x by 90 placed into the sin function to get the rad value...

It is nice to use instead of easing (e.g. a fade or motion) with a plain lerp function, since you can predetermine the exact time duration of the fading.

Just use

lerp (MinValue, MaxValue, sin(TimeEllapsed*90*1/FadeDuration_in_Sec))

Cheers

Kyatric True that, thanks.

To be honest, I don't like it this way too much. I still think it is most of the times way more handy the rad-way to be used as a math function...

However, most important is, it works. Thanks once again for the clearance!

Hi guys,

I am confused, since I would like to use a simple calculation sin(x), but it does not return the values I expect at all.

sin(1*pi*0.5) should be in my understanding (and is indeed on all calculators) 1.

If I let that calculate in construct, it gives me back an odd number: 0.0274121336

Please help me, whats going on. And why? How can be a common sin(x) function something different here?

Thanks.

Hi,

since my game is built of sprites and tiles, I wondered if it would run faster, if I convert it all to tilemaps.

An advantage seems to be some spritesheet optimization and less objects in the layout.

On the other hand - it seems - I cannot reduce collision-checks as much, as with separate sprites/tile-backgrounds.

The reason: Since tilemaps are checked for collisions each tile, as they have separated collision-polygons, the number of collision checks is just as high, as if each tile would be a separate object. But separate sprites/tiled-backgrounds can be turned off (solid and collision) when not in range, which cannot be done with separate tiles on one tilemap, or am I wrong?

So is it really worth using tilemaps instead of sprites/tilebgrs performance-wise?

Please give me some advice.

Getting better and better... makes me happy

animator :

Your question is a bit complex, because the solution depends on how you solve the ball.

Physical concept:

To make a ball drift in a curve, you need to hit it off-center (can be also angled). It gets a spin through that. The spin causes the sideways-offset, since the air flowing around the ball has different speeds (thus density) on each side, so like a plane takes off, the ball goes sideways, because of air pressure differences. The bigger the rotation, the stronger the curve. (If there is no wind and you hit the ball in the middle it will not spin much, and you shoot quite straight.)

So you could detect an offset of the hit from the center-point of the ball - the more offset, the more you let the ball fly sideways (You can also give it a rotation speed according to that, if you want realism.).

The only question is, how you let the ball fly? A behavior?

danuyos , — Like this basically...

One more lerping-trick on anlges, if anybody is interested:

It seems to keep it 0 to < 360 (like 359), since he accounts 360 for 0 thus not even managing a 360 turn /:

linkman2004 : did not know about that trick. Thanks a lot, that's exactly what I needed.

Great

Hi guys,

I have an issue with lerping rotations. When I let the rotation ease with lerp from 0 to 180 it rotates clockwise, when I do the same from 180 to 360, it changes to counterclockwise, as if I used 180 to 0. I tried to use anglelerp, but that did not help as expected.

That means I need the sprite spinning cw or ccw continuously, not swinging back and forth.

Please take a look. Thanks in advance!