asin/acos issues

Apologies in advance if this is an embarrassingly simple problem. Complete newbie to game creation (and math).

I'm want to make a top down game where instead of the player moving on the screen, they stay static in the center and enemies on the screen move and rotate according the the player's virtual movements.

We find the virtual X and Y and hypotenuse like so:

set enemy.distanceX to enemy.virtualX - player.virtualX

set enemy.distanceY to enemy.virtualY - player.virtualY

set distanceFromPlayer to sqrt(enemy.distanceX^2 + enemy.distanceY^2)

From there I want to know how far the player (and therefore the whole screen) is rotated in relation to the virtual coordinates. I get that like so:

set enemy.virtualAngle to asin(enemy.distanceY/enemy.distanceFromPlayer)

set enemy.totalAngle to enemy.virtualAngle + player.rotation

Then to find the enemy's screen x and y coordinates:

set enemy.X to cos(enemy.totalAngle)*enemy.distanceFromPlayer

set enemy.Y to sin(enemy.totalAngle)*enemy.distanceFromPlayer

The problem is that when an enemy passes from one quadrant to another asin(enemy.distanceY/enemy.distanceFromPlayer) "bounces". I assumed because of the negative/positive values for enemy.distanceY that a value could be returned anywhere in the full 360 degree range. Instead, it rises to 90 and then bounces back.

My apologies again if this is a stupid question, or if I've explained it poorly. I didn't even know what the hell sine was until 3 days ago. Working at it though :p

You've provided a good explanation of what's going on here, but one of the great things about Construct is the ability to share your project with a single file.

If you save your project as a single file (.capx) and upload it to a free filehost like dropbox you can share your file here on the forum. (or recreate the problem in a smaller project if you don't want to share your entire game)

So instead of having to imagine everything that happens while reading your post, we can just see exactly what's going on, which makes helping you a lot easier and faster.

That being said, you should also have a look at the "System Expressions" in the manual. A lot of the math you've done can be simplified by using expressions like the distance expression, which returns a distance from one X,Y position to another:

distance(Player.X, Player.Y, Enemy.X, Enemy.Y)

Haha. I started reading about expressions almost immediately after I created that post. Appreciate the info just the same. Is there any advantage to using expressions beyond simplified code (such as running faster)? I ask because, at least for the time being, I prefer to do everything out the long way. I have absolutely no natural ability with math, and doing everything the long way helps me understand the math in an intuitive/visual way that is more easily processed by my mind. Obviously, I'll have to get more rigorous eventually. For now though, this is just a hobby, and I'm trying to get a good "feel" for what a program is actually doing.

I took your advice and uploaded a copy of the project to dropbox. It's bare bones right now, but I did manage to fix the bouncing-of-the-axis problem. I think my solution is clunky though. Perhaps someone has something more elegant.

Also, I've discovered my next problem. Even though the enemy is moving properly in relation to the player. I have no idea how to do the same for the ground as the rotation will never be right. Is there a way to animate the image point (I come from a motion graphics background in case it wasn't obvious from my mathematical illiteracy) over time?

dropbox.com/sh/jrusxacaq55o4n9/pjQ7A2xZ4j

The easier way would be to put everything but the player on it's own layer and just rotate the layer when the player turns.

I have absolutely no natural ability with math, and doing everything the long way helps me understand the math in an intuitive/visual way that is more easily processed by my mind.

I see, forgive me for assuming you'd want to do it the easiest way possible, it's quite common around here since C2 does such a great job of simplifying things. It's a really good idea to do it all from scratch to get a deeper understanding of things, I often do so myself.

Is there any advantage to using expressions beyond simplified code (such as running faster)?

Not at all, except you might get things done in fewer events, which would help people with the free version to keep their project under 100 events. It's pretty much doing the same thing you do with your own calculations, but even if there were a few more calculations to go through, it wouldn't affect performance in any noticable way.

I can't look at your .capx right now, but for ground rotation I would suggest you use ramones' solution, layer rotation has become much more viable (or at least easier) now that the collision rotates with it. (a few updates ago it didn't)

I tried out the rotating layer deal last night (I had no idea you could do that). Using that technique I'm still left with the problem of translating from one coordinate system (the enemy layer) to another (the player layer... haha, that sounds really funny :D )

To clarify, when the player presses the up key, the enemies should always move down on the screen, regardless of what the player's virtual rotation is (remember the world is supposed to move around them and they stay static). What happens instead is that, on pressing the up key, the enemies move "down" according to the coordinate system of their layer (not the player's). If the enemy layer is rotated 90 degrees then the enemy will be moving left to right on the screen (instead of down, like I want). Am I missing something?