Those are two excellent answers.

Construct's coordinate system is a bit unusual, but you are on the right track with sin/cos.

You can use cos(angle) to get the horizontal offset and sin(angle) for the vertical offset. Put them together and you have an x,y coordinate for your sprite. Construct uses clockwise angles in degrees, so your A point is actually at 90 degrees and the B point at 180 degrees. If you set your sprite to cos(90),sin(90) it will be at the A point. Set it to cos(180), sin(180) and it will be at the B point. Note that sin/cos return values between +1 and -1. By multiplying the values you can make the circle larger or smaller: cos(90)*50, sin(90)*50 will be on a circle with radius of 50 pixels for example.

To get some movement you need to animate between those two angles over time. I.e. calculate the position for angle=90..91..92..93 and so on until you reach 180. Construct has an anglelerp function to help you with that. You would stick that inside your equation like this and update your sprite position every tick: cos(anglelerp(STARTANGLE,ENDANGLE,CURRTIME))*RADIUS, sin(anglelerp(STARTANGLE,ENDANGLE,CURRTIME))*RADIUS

The remaining task is to update the CURRTIME variable so it goes from 0 to 1 over the course of time. You can just declare a variable in the event sheet that starts out at 0 and then every tick increase it by "dt * SPEED". With SPEED=1 it would take 1 second to move from A to B. With SPEED=1/4 (that's 0.25) it would take 4 seconds to travel that distance.

Thank you, Zathan. I am looking at Magicam. My question though was more about using built-in functionality.

siks I think this would run into the same bug/limitation that I am talking about. Let's say you want to have the camera 40 pixels in front of the player. If you add an event "every tick: camera.x = player.x" this will exhibit stutter for integer views.

If the camera and player are linked via a Pin it works, however.

EDITED: Never mind. I must have had a stray event somewhere. I recreated the event sheet and now it's behaving as expected.

A bit of background: I am trying to create a retro side-scrolling platformer. For this I am using a Platform behavior on my player character, and enabled Integer coordinates in the view properties. Platform max speed is set to 80. Acceleration & deceleration are set to huge values like 1000 to get instantaneous speed changes. If I also add ScrollTo behavior to the player everything works fine.

Now I want to do some fancy custom scrolling and that's where things are breaking. I removed the stock ScrollTo behavior and added a very simple event to the bottom of the sheet:

Every tick: Scroll To X= Player.X

This almost works except scrolling stutters by 1 pixel. I see the player move past the center by 1 pixel and then he snaps back to the center one frame later. My theory is that the Platform behavior updates the Player.X after my events are run.

Can anyone confirm that is the case? If so, what are some workarounds to do custom scrolling without relying on ScrollTo ?

Read the page that Yann linked. The original Pac-Man is not using pathfinding; as a ghost approaches an intersection it merely measures the distance to its target location and then picks one direction.

and during "long" sessions, it gets slower over time.Define long.

Played it for 3 minutes on a PC with powerful CPU and a slow graphics card. In Chrome the FPS alternated between 49 and 51 with no problems.

Just tested it with Chrome and built-in graphics card. Graphics seem to be okay. There's an occasional stutter (garbage collection?) but it's not too noticeable.

Other layouts do not impact performance (much). Only the current one is being processed (unless there are global objects in other layouts).

Off-screen sprites do not affect graphics performance since they will be culled by WebGL. However, C2 is still processing them so there is a CPU cost for each instantiated sprite.

There's an article about CAs for water & fire in the book "Game Programming Gems 3". Get the book or ask the author Tom Forsyth (tomf_at_muckfoot.com) for a PDF.

Found it:

home.comcast.net/~tom_forsyth/papers/cellular_automata_for_physical_modelling.html

If I set full screen mode to on, the screen size no longer seems to stay to 640x960.

What does this mean? Of course it will be bigger or are you talking about the layout being stretched/cropped ?

Thank you R0J0hound for taking the time to explain this! Now it makes perfect sense.

I thought there was some special trick going on in the destruction part, but we just destroy arbitrary healthbars/shadows and then grab whichever one is available for display purposes during the next tick.

Does C2 maintain one SOL per object type?

Line3 sets the Sprite SOL to the one we clicked on. So that array will usually only contain one Sprite.

Line4 checks that picked Sprite (array) against Health<=0. So far so good. Then we have the ForEach condition which according to the manual does not reset the SOL, thus by doing ForEach Sprite we would only iterate over that one sprite coming from line 3.

Then we get to line 5 which is System.Pick Healthbar instance 0. So far we have not filtered any healthbars so I would expect System.Pick to operate on ALL healthbars in the layout, and instance 0 of all healthbars could be any which one not necessarily the instance we are looking for <img src="smileys/smiley5.gif" border="0" align="middle" />