A quick hack to solve it would be to create an instance variable on the family of objects you are using the editor to create. The variable would be a boolean IsPlaced (defualt is false). when you close a menu and hide the objects, check IsPlaced before setting their transparency. When you place an object set the flag to true. Does that make any sense?

There are no tutorials that I am aware of but the answer is quite simple.

You know the problem, so try and think how you would solve this. I know of several solutions.

The first thing you could do is create a family that contains all sprite graphics. At the start of a layout, for each object in the family you could set its z order based on it's y coordinate. Any object that moves around (such as the player) you could put in another family and label it mobile sprites. Every tick in the game you would change the z order of objects based on their y position.

The second method would be to have two layers surrounding a character layer. For every object that can be walked behind you would split in half, putting part of it in a layer above characters or below, depending on what part of the object it is. This works well for grid based games where you can never be in front of a part of an object that you could also be behind. I think older games used this method but I am not sure.

----------------------

As for collisions, you need to create a polygon that allows the player to walk behind an object if that is what you want. A tree, for example, that was 64 pixels high may only have a collision polygon that is 32 pixels high.

Hopefully this helped.

Is there a difference in the following events:

For Each BulletObject: ----------- Subtract dt from BulletObject.Life

...compared to...

Every Tick ---------------------------- Subtract dt from BulletObject.Life

They seem to do exactly the same, and in used in such a basic manner there seems to be no difference. Does one use more overhead? I always heard that "for each object" could take time to loop through, but isn't that the same as looping through the list of picked objects?

Hey Everyone,

I have been doing a lot of work to understand how physics works with construct. Basically trying to figure out all the things that the manual doesn't tell you. Things like this:

Velocity = Impulse/Mass * 2500

Velocity = Force/Mass * 2500 (time)

AngularVelocity = Torque/Mass * 648.78892733564 (time)

Change in velocity = -Current Velocity * Linear Damping Coefficient (time)

...and other stuff, such as the difference between "set velocity" and using forces or impulses. There is also some order and logic peculiarities due to the Construct 2 update cycle.

I wrote more about it here ->

https://www.scirra.com/tutorials/1135/physics-the-rest-of-the-manual

Thanks codah - This is good to know. I'll see if that fixes the problem

I spent several hours trying to recreate the problem, but I couldn't. It exists in my main project though. This is crazy. More digging around to do!

shinkan - HOLY FLIPPING Barbequed PANCAKES!!! YOU ARE right! I have been lamenting over that and struggling in the debugger for a while. Thanks for pointing that out.

do you know if you can control max fps? Most of the time my laptop caps at 40fps but for a while it was 60 off and on?

LittleStain -Small variations occur when using dt (Like really, really small). In a physics simulation puzzle game this small fluctuation in dt can produce a chain of events that compounds to produce a drastically different result than was acquired last time the exact same thing was done. In these types of games, using time frame independent physics doesn't make sense.

dt is calculated based on how long the last frame took. The current frame might not take that long - but in the end it averages out to 1 every second. The variation from frame to frame could yield results that vary, but we are talking minute fractions of 0.02 (depending on framerate). In reference to the above situation, this could be undesirable. But in a game such as asteroids with physics, this variation in dt is largely irrelevant. As far as the game goes and feels everything is still "predictable".

My tests involve a simulated force of gravity acting on an object and an impulse based jump. The degree of variation in using dt in time-frame independent physics in my test is relative to what dt is and not a small difference. In other words, as the framerate increase, the force of gravity acting on the object increases over time. As frame rate drops, the force of gravity lessons over time. This indicates that dt is already applied to the physics internally and needs not be applied again. If you cut frame rate in half, gravity decrease by half.

When running framerate dependent physics, frame rate only affects our perception of time passing but doesn't affect the actual game. If you apply dt to this model of physics you can get the same result as was described above, though "time" to reach max height after impulse was different, the height was still the same. I used impulse vs force to be able to compare maximum height obtained when applying a force in the opposite direction. I did this to take "human perception of what is happening" out of my experiment.

If you remove dt from timeframe independent physics calculations within the event sheet, you get the expected results; that is, regardless of framerate, the object reaches the same "highest point" in the same "real time" after leaving the ground under an impulse and affected everytick by a constant force.

This is in CONTRAST to what the manual states, indicating either an error in the manual, or an error in the implementation of physics in construct. My hunch is that the manual should be changed to reflect the actual state of box2d in construct.

....and by the way, just for clarification... I have worked with box2d outside of construct2 in other applications (XNA in C#, Unity in C#, Torque C++) and I have also read most of the box2d manual and understand the API in addition to reading a lot of the source code and understanding the theory behind collision detection in box2d. I have rolled my own collision detection before. Don't think I am speaking out of ignorance. I posed this problem as a question because I believe Ashley is a very competent programmer (and a wizard) and I looked for input and guidance before outright saying I found a discontinuity between Box2d/Construct2internal/Construct2 Manual in case I am wrong/confused. The more time passes and the more I tinker with this the more I believe that If Ashley says to use dt in events with timeframe independent physics then there is a "bug"; If he says not to use dt then the manual needs to be updated for clarification.

I would find it odd that I am the first to find this problem but it seems that may be. In any case it is really difficult to test due to lack of frame rate control. I had to spam thousands of objects in order to get a drop in framerate to test changes.

Also I may have found a bug in timescale and physics (when timescale is 0, force is still applied everytick in a building manner, such that when timescale becomes greater than 0 all the force added to the object over the last frames is added all at once in one frame... but I need to run further tests.

codah - that is a good workaround! ... I general I have tried to stray away from global constants as they can quickly bloat the editor with a lot of stuff. To keeps things organized I create holder objects for variables. I would probably create an object called Function strorage or something. I have alot of objects whose sole purpose is to aid in organization.

example:

Player_Physics (is the actual collision object with the physics behavior)

Player_State (tracks the players states such as in air, on ground, etc)

Player_Abilities (tracks the players upgrades and potential upgrades, like fireflower or star power in mario)

Player_Constants (a storage for unchanging variables such as walk speed, run speed, etc

Player_CurrentStats (a storage container for tracking variables such as current max speed, jump pwer etc)

Player_IsSwimming_collider

Player_inventory

Player_expandedMath (such as old position, vector maths, and so on - provides a way of knowing projection vectors and velocities in a direction other than x,y)

Global_PhysicsConstants

Global_currentPhysics

Global_GameManager

Level_State

...and on and on the list goes. Storing all those things as an event variable would be cumbersome to deal with. Keeping them all in one object, like all the player stuff in player would be a hassle too. Plus the player as well as many other in game objects are much more than one collision box.

— - Layers do affect performance. They affect it a lot.

Create a new project and run in debug mode. Don't add anything to the scene: no events, sprites, or anything. Note FPS and general CPU usage.

Now add 15 layers with no effects or anything: 15 simple default layers. Now run the debugger. For a real performance "Kick in the groin" try adding an event to rotate the layout every tick.

TLDR - Blank layers, without any FX, special blend modes, or objects, decrease performance markedly. Start doing things with those layers and the performance decline is sharp. The tests are easily created and I have made many of them.

Regardless of what you do with a layer, there is a performance overhead. I don't know why the engine works like this, but something is being done to those layers or calculated every tick that slows things down.

From the manual

Physics Actions

Set stepping mode

Choose whether the Physics time step uses dt (delta time, for Framerate independent) or a fixed value. By default it uses a fixed time step to eliminate any randomness or instability coming from dt, ensuring simulations are exactly reproducible every time. Set to Framerate independent to adjust the time step according to the framerate, which can cause the same simulation to have different results if run twice. Note even when in this mode, the behavior clamps the maximum time step to 1/30 (about 33ms, equivalent to 30 FPS) to prevent the instability that can result from large time steps. For more information see Delta-time and framerate independence.

Thanks, but if you read my post you would know I had read the manual. dt does not work as expected when used in a time-frame independent way. This means the manual is either right and I found a bug, or the manual is wrong and does not reflect how things are actually working. Either way it probably needs Ashley's attention. I cannot actually conduct a meaningful scientific experiment without being able to control max framerate and nobody has been able to tell me if that is possible.

Ashley ? could you help me out with this one? Do I use dt with physics? And... can I force a max frame rate. Why would my computer cap the fps to 40 most of the time but cap at 60 the other times. Can I set that cap manually?