Fluid simulation is very expensive and complex, even in 2d engines. People have done it with box2d physics, but I doubt it can be accomplished in C2 without custom code. You might be able to get some sort of primitive looking slime -- primal ooze anyone? -- with box2d as it is, but I really don't know.

—:

Interesting. Thanks for sharing your experiences. Has your team built any games with C2 as full team (ie, more than just 1 coder/and or artist)? I think many come to C2 with the background of doing visual art...but I don't. I've been thinking about trying to find an artist to collaborate with once I've got a couple prototypes together, and I've been curious about how C2 works for teams.

So...no one else thinks this is a good idea?

Or, if you want some lag in the camera's response, you could only run the distance events every 0.x secs?

Well, would be nice to have a capx to grab, but it looks like the problem is the distance<4 statement. Try increasing it, or, if you don't need a deadspace, just delete that second distance test and use an else. Also, if you are trying to do a camera, have you taken a look at Magicam by linkman2004?:

scirra.com/forum/plugin-magicam-for-c2alpha-65-1-8-14_topic57890.html

I haven't looked at your capx, but I can give one piece of advice on using line of sight: if possible, ditch it for your enemies and just put it on your player. Then test every 0.1 seconds (or every 4-6 ticks if doing framerate dependent) to see what enemies the player can see, and activate them(use an instance var). If the player can't see them (else), deactivate.

On the other hand, if you want them to flee from approaching bullets, then you will need LOS on each enemy...but if you just want them to REACT to the players attacks, you can use the bullet's vector of motion to figure where it came from, and tell the enemy to flee in the opposite direction.

This approach should let you get away with a lot more on-screen enemies (and/or a lot less cpu usage).

Yeah, if you are trying to do something while a button is down, that's the way to go.

Ainxty

Glad you figured it out. Thanks for posting your solution; no matter how trivial/simple it may seem to you now, it really helps others who might come across your post later. <img src="smileys/smiley20.gif" border="0" align="middle" />

Trigger once while true has to be tied to something. What is making it run? An object being created? Well then, anytime an object is created, it will be destroyed, it's opacity will be set, etc.

Would be nice to have a checksum for releases, so those of us with bad connections can make sure everything downloaded all right. <img src="smileys/smiley1.gif" border="0" align="middle" />

iceFlashEX1

To answer your second question:

Debug is always a little slower than normal preview. Generally, it's a small difference though. Your finished project will be a little faster still, if the java minifier is working.

Much depends on whether your cpu usage is going towards graphics or event logic. Event logic will run a bit faster, but you won't notice if it's only a small percentage of your cpu usage.

bertie Booster

Thanks for all of those! Curious about a couple:

A 32px square with collisions set to bounding box causes much more stress on the fps rate than the same square with the collision boundary set to (1,1),(31,1),(1,31)(31,31).

???

Try rotating a square 45 degrees if it doesn't affect the objects interaction it can reduce collisions.

Why would this be? Maybe because there are generally more vert/horz surfaces than diagonal, and rotating the square means you touch most objects with just the tip of your col poly?

Collisions really do eat up a lot of cpu. Col cells really help, but if you have a lot of moving objects in a small space, it can still get very laggy, very quick. However, with some thought, there are usually optimizations that can be done (many involving checking cols less often).