You mean, switching the resolution from within a pause menu? I'd add a global variable that gets set to 1 if the pause menu is triggered, and disable input on the behaviors (if you use any). The rest of your events should be sub-events of a condition that tests against the global (so that you have two code parts, 0=no pause, everything works as planned, 1=pause, only for the events needed to do the pause menu)

EDIT: Damn, I hoped for a new video, saw that one before and was impressed...

Hihi, I know what you mean, I felt exactly the same just a few hours ago. But doesn't that make a good team? Helping each other, no matter what. <img src="smileys/smiley1.gif" border="0" align="middle" />

If you haven't done already, add the 'window' object to your project and use the various position actions of it (Set X, Set Y, Set position).

If you need to know the screen's size or color depth, add the 'sysinfo' object also. It has expression to access those informations.

Hmm, I might have been lucky before or have bad luck now, but I don't have any changes. 400 before, 400 now, 200 before, 200 now. But maybe they are much too small a project to get an advantage (no rpg, no adventure, you know).

It's just natural that you get much lower framerates in a project compared to a nearly empty project.

What basically counts is the balance between cpu and gpu usage.

Every event of a layout (+ the included event sheets) will be checked on every tick. If the condition results to true, the actions are performed, otherwise ignored. So even an event that has no actions costs cpu time. We are talking of microseconds, but overall it can sum up to a reasonable value.

It is common practice to just set values/colors/sizes/etc on every tick. This is ok, because most of the time the gpu needs far more time than the code. But when you are about to finetune your project it might help to group these actions under an event that results to true only when a change is needed. This way only the condition costs time (a much smaller amont of time) when there is no need for a change.

On the gpu side, the more shaders you use the less effective the card. A pixel shader applies its code to every pixel (even the transparent ones) of the object it is applied to. This costs a lot of the gpu's processing power. Gfx cards have a limited amount of shader units to prevent overloading, but even if you just use a few shaders they will drop the framerate at a high amount. (Just try a clean new cap and apply the warp fx to the layer)

So try to avoid to much shaders. If you need an effect for a few dozen of objects, it is the better way to group those on a layer and apply the effect to the layer, instead of having a few dozen effects applied to the objects.

That's what comes to my mind right now, maybe there's something I forgot.

Thank you ROJO.

That was one of the issues, we call 'den wald vor lauter b�umen nicht sehen' in germany. I believe it is translated to 'seeing the wood for the trees'...

/me feels dumb right now^^

Thank you very much ROJO! Works now.

Now there's one thing, I don't understand. Shouldn't the angle keep the same (reversed or right), if it is calling angle() with the same order on every frame?

I mean, the angle from center to x/y might be 10, then angle from x/y to center would be 190?. And that should be true for every frame, no?

EDIT: So it should just swap the angles once the first time it is called wrong.

So here's one for the experienced among us:

DOWNLOAD

It runs with fixed 1 fps on purpose. Run it and press 'space', until the text in the lower right changes to "Press 'space' to stop". (Be patient because of the low framerate)

You will now see that the angle of the circle of instances swaps 180? per frame. But there is no code telling it to.

It seems, that angle() reports two different angles on every other frame. Can you confirm this?

<font color="orange">*Fixed URL to be a nice link^^ <3 Sol</font>

That's just one of the many stunning examples, what sin and cos are good for, and why people should use events more often instead of restricting themselves to the use of behaviors :)

Create a global, e.g. 'quicktimeevent'

Create an event

    + 'quicktimeevent' Equal to 0

    and make all of the normal mouse&keyboard events sub-events of this one

Create an event

    + 'quicktimeevent' Equal to 1

    and make all the mouse&keyboard events, that control those short button sequences, sub-events of this one

Last but not least create events that set 'quicktimeevent' to 1 when such a sequence starts, and to 0 if it has ended.

A full featured DAW for free (as in free beer, not like reaper's 30-day-trial-not-expiring)

bedroomproducersblog.com/2010/06/26/zynewave-podium-free-released

tulamide, I don't understand why you did what you did when you set the 'angle' variable to:

".Angle < 'cone' / 2 ? .Angle + 360 : .Angle"

Isn't ".Angle + 360" and ".Angle" the same angle anyway?

Technically they are the same, but for Construct it would be a problem, if an angle becomes negative. Construct is designed for positive angles only (that's why there are extra expressions for testing anticlockwise and rotating anticlockwise)

This conditional expression is used to prevent that 'angleLeft' ever gets negative.

See this example:

The sprite's current angle is 5?. Without that expression 'angleLeft' would become 'angle' - ('cone' / 2) = 5 - 30 = -25?

Now with that expression, any angle below the threshold is added 360, which makes 5? become 365?, and 'angleLeft' is now calculated as 365 - 30 = 335?, which is the positive expression of -25?.