I've been having this exact problem with IE9 on the WP7 Mango Beta. Here's to hoping it gets sorted out quickly.

You might want to take a look at my MagiCam plugin; it features pretty much exactly what you're wanting, and it comes with examples demonstrating a similar effect.

MagiCam Plugin

I hope you find this of use!

It's from Nichijou. The world would be a better place if everybody watched it.

That's correct.

As for what's high, 1024MB is definitely a sizable amount. It would probably be wise to keep VRAM usage under 256MB if you're targeting a large amount of computers.

Many lower end graphics chips, especially those by Intel, don't have dedicated VRAM, and instead share the main system RAM. This generally reduce the amount you have available for graphics, and even if there is a large amount available, it's still much slower than dedicated VRAM.

Just a heads up.

To figure out how much VRAM an image will use, you multiply the width and height together, multiply that by 4 to get bytes, then divide that by 1024 to get kilobytes. So a 32 x 32 image would be:

(32 * 32 * 4) / 1024 = 4KB

Transparency doesn't matter when considering VRAM, as the images are stored uncompressed.

Also keep in mind that most video cards will store the image in a texture that is rounded up to the nearest power of 2 size, so for example, a sprite that is 280 x 280 pixels would be stored in a texture that is 512 x 512, taking up a much larger amount of VRAM.

The background color for sticky topics should probably be something other than the default. As it is, it's hard to discern where the stickies end and the regular topics start.

I also think pretty much all of the text should be made smaller, and the text shadows on the home page should go away -- they look like some relic from the turn of the century.

One more thing, and I don't know if you can change this, but the edit post button should probably be on the quick access bar rather than hidden in a menu.

Wow... this makes me feel really stupid. I didn't link to the latest version of the plugin when creating this thread, and it just so happend to include this:

[quote:138jgkl0][FIX] - Inputting an index of "1" in the "Get argument", "Get argument name", and "Get argument value" expressions would return "NULL".

I changed the link to the newest version, so go ahead and download that and your problem should be fixed.

Sorry about that...

The developers have said before that they have no plans to port the Construct 2 editor to Linux.

The games themselves can be played in any HTML5 capable browser regardless of OS, though.

Sorry it took me a while to answer these, but here I go:

Is it possible to zoom AND move towards an objects at the same time, in 1-, 2- or 3000 ms?

Right now I only can make it do either one, followed by the other one. I would like to see it moving and zooming simultaneously, in about 2000 ms.

edit: 2 more questions

2- If you would want to always show something on screen (for example a healthbar), when the Magicam is zooming. How do you do that?

3- I would like to see the condition "when motion has stopped". Is that possible?

1. You should be able to both at the same time. If you can, send me a CAP file showing me what you're trying to do, and I'll help you out.

2. Put your health bar on a separate layer and set the X and Y zoom-rates to 0.

3. You can invert the "While motion in progress" action and add a "Trigger once while true" action to the event. This will cause the event to trigger once at the start of the layout, but only upon the completion of a motion after that.

I have a problem with "Shake Camera". I have it shake at ANY magnitude and it goes fucking NUTS. But when I have smoothness set to 100 AND NOTHING ELSE, it doesn't do ANYTHING.

What do I have to do to get it working? (I wont upload a cap, as I am working on a closed project, but an example would be nice )

The camera shake feature was something I never got working in quite the way I want. I was working on getting it to shake in a more controlled fashion, but never got it right. The way you see it is the way it works, and that's all I can say. I'll look into redoing that at some point.

It's because of all the solid objects you're platform object is having to check for collisions with. With thousands of objects, that's thousands of collision checks every frame, which can be incredibly taxing.

What you need to do is optimize your terrain generation. It would be best to only generate solid blocks in spots where it will be possible for the player to collide, and have the rest be non-solid blocks.