Mulkaccino - That's weird. I archived the plugin in a 7zip file, so maybe you can try that:

7Zip Advanced Camera Archive

If you don't have 7zip, I can try getting something that will allow me to compile a RAR file.

I'm still running the release candidate from back in March, and before that I was using the beta, so I've been using it for almost a year now. Freaking love it; I'm hoping I'll be able to pick up the retail version at some point.

The debugger always does this when there are no instances of an object where the "Count" expression is used. It's normal behavior and doesn't cause any problems.

Using "../" will take you back a folder. I just tested it, so it should work.

I've setup my camera similar to the area example .cap you posted.

Although when I 'reset' my layout, the camera stops working?

Would you mind posting a CAP with the problem so I can take a look at it? I couldn't reproduce it.

bariscigal - Thanks. Here's a little diagram I whipped up to show how the offset system works:

<img src="http://dl.getdropbox.com/u/917406/diagram.png">

How this works is that, given an offset angle, the camera will be displaced from the followed object at the given angle to a point X pixels out from the object(X being the offset distance). So given an angle of 42 degrees at a distance of 50 pixels, the relative X and Y positions of the camera from the followed object would be:

X = 37.16

Y = 33.46

If you want to set the offset to a specific X and Y offset, you can use the following method:

Offset distance = distance(0, 0, RX, RY)

Offset angle = angle(0, 0, RX, RY)

Where RX is the relative X value of the camera from the followed object, and RY is the relative Y value.

Hope that clears things up.

PS 0.0 effects don't slow down games and can be abused.

Actually, this isn't entirely true. Sprites with PS 0.0 effects do take longer to render. I've done some tests and I've found that the engine can render on the order of about 2.5 times more sprites without effects before the framerate drops below the VSYNC rate.

But as Newt suggested, why not just use the timer behavior? The timer behavior does what you're looking for without the hassle of doing this manually.

Very nice! I'm glad you switched libraries; Wiiuse was slow as Hell. Do you have any plans to implement motion plus support since this library supports it?

Keep up the good work.

I was wondering if that might be the case, but I don't think that explains why there are no problems when the game is running at native resolution in fullscreen, even with large projects.

There was a while ago, but it was closed because you couldn't reproduce it and the poster never posted a CAP file demonstrating the problem.

I was doing some testing earlier, and I've found that a basic CAP file that closes on the escape key will lock up Construct for about a minute, but then it will recover. Larger CAPs seem to have no such luck.

EDIT: Here's a mostly blank CAP that demonstrates a temporary lockup on my computer

If the game resolution is lower than that of your monitor's normal resolution, Construct will lock up after closing the game. So to keep it from locking up, you'll have to go with a higher fullscreen resolution or use windowed mode instead.