DT is calculated by the C2 runtime every game tick by simply doing something like this: dt = time_now - last_tick_time

Construct users do not have to worry about factoring in the v-sync rate in their calculations. As I mentioned earlier, the underlying Construct 2 engine uses something called "requestAnimationFrame" which asks the browser to run the next game tick according to the refresh rate of the local display to smooth out animation.

Regardless of how often the game tick is run (whether its running 60 ticks or 120 ticks every second), dt will adjust accordingly.

—

Yeah, using dt to adjust the speed at which variables are modified is great. DT is there so that by saying Add (DT*X) to SomeVar, you can make sure that it is added at a total rate of X per second.

DT returns the elapsed time since the last game tick (basically the last time the event sheet was processed), and it usually hovers around 0.01667 on most 60hz systems (aka 1/60) because Construct 2 uses underlying v-sync related browser timing.

So for example, if you wanted a variable Life to gradually regenerate at 20 points a second. You would say: Add DT*20 to Life. If you test your game on a 60hz refresh rate display: Every game tick, you are adding dt (~0.01667) * 20, or approximately 0.334 life points every tick, after 60 ticks or approximately 1 second, it will have added 20 points to life.

When running same game on 120hz display rate, every game tick, you are adding dt (~0.0083) * 20, or approximately 0.166 life points every tick, and after 120 ticks or approximately 1 second, again it will consistently have added 20 points to life.

So no matter what your frame rate is, dt allows you to maintain consistent value ratios.

Just avoid using dt as a part of a time-dependent condition in an event, so for example, you wouldn't want to have:

Every DT*60 seconds: Add 20 points to Life.

On a 60hz system, dt is 0.01667, so in this case, the statement is roughly equal to: Every 1 second: Add 20 points to life.

But testing on a 120hz system, dt is ~0.0083, so the statement is roughly equal to: Every 0.5 second: Add 20 points to life. Completely different behavior.

Aurel

KaMiZoTo

Woah, you should definitely never have an event which runs as a factor of dt. The underlying Construct 2 engine uses something called "requestAnimationFrame" to attempt to peg the game tick at approximately 60 times per second, but it usually matches the display refresh rate of the browser/computer(nearly always 60hz except in the case of these new 120hz monitors).

This means that in most cases, dt ~= 0.0167 of a second (remember that dt is the elapsed time in seconds since the previous game tick). Obviously though, cpu intensive games and other things can cause the frame-rate to fluctuate. However, on a 120hz display, dt will average ~= 0.008, since the engine will attempt to run the game tick 120 times per second. So then, setting up an event which runs every 60*dt is going to run approximately once a second on a 60hz vsync, and once every 0.5 seconds on a 120hz vsync. Obviously not good, since the game behavior will be inconsistent depending on the hardware.

For setting up events that should run at specific times or intervals, either use the system expression "time" or events such as "Every X seconds". In this case, this event should just be "Every 1 second". For example, if you wanted to schedule a one-time event to run 5 seconds in the future, you could record a instance variable NextActionTime = time + 5. Then in the event:

If time >= NextActionTime & Trigger Once ---> Do something here.

You should use dt as a means of scaling movement/velocity/vectors/etc. So for example, let's say you have some Sprite1 with CustomMovement, and you want it to move approximately 100 pixels every second. Under an event:

Every Tick (aka every game cycle): Move Sprite1 by dt*100.

This way even if dt fluctuates because of slowdown or because of computers with different refresh rates, you are guaranteed a constant rate of movement.

Outside of using the stepping mode of the CustomMovement behavior, I run into collision problems with standard movement behaviors a lot because of the fact that the game loop is locked at a maximum of 60 ticks a second. The standard max fall speed of the Platform behavior is set to 1000 pixels per second, my frame-rate hovers between 50-60fps, which means anywhere from a 16 to 20 pixel Y-displacement on a single tick. It gets even worse if you're trying to determine if the collision was top-to-bottom, or a side-collision, etc. If you're doing a low-res pixel art game, a single character sprite might not be much bigger than 16x32.

Even resizing the browser or putting a different application's window in front of the active tab can cause it to dip by 5-10 frames. I don't know how internally how Construct separates rendering and logic loops but I really wish that the logic loop itself could run unrestricted.

MultipleChoice

Strange! I tried the web demo, jumping works flawlessly, no shaking. There's the "v-sync jaggy tearing" issue when moving left and right, but I think it's more related to the known Chrome/Firefox jitter issue that's been discussed in previous forum posts.

Aphrodite

Yeah, every object type is affected except for global types such as Function or Keyboard.

Near as I can tell, when a project is first opened by Construct, it stores an "archetype instance" of each Object Type in memory.

After some testing and from the way that the project file (*.caproj) XML is laid out, the archetype instance is simply the first instance (lowest UID value) on the first layer (bottom-most layer) on the first layout in order encountered that contains an instance of the object type (ordered from top to bottom in the Project Window Layout List) parsed by Construct.

Until a project is reloaded, the archetype instance assignment will not change. Even if you delete the archetype instance, Construct will continue to base new *EDITOR* instances on its properties/values. However, Construct on preview will reparse all layouts for the first archetype instances of all object types, which affects creation/spawn at run-time.

Also related to this:

https://www.scirra.com/forum/viewtopic.php?t=123150

I don't agree. The root instance is the one in the Project Object Type List, which is what I expect.

zenox98

I think you might be misunderstanding the issue. The Project Object Type List is not an actual instance, it is just the Object Type. As an example, remove all the instances of an Object Type off all layouts. Now click on the Object under the Project Object Type List. Notice that it doesn't show any actual properties? (No position, no instance variables, etc)

The default values for an object's instance variables don't work as expected.

Repro Steps

Create a new project with two layouts, Layout 1 and Layout 2. Create a new object type called Block.

1. Create first Sprite Block "Instance A" on top-level layout Layout 1

2. Add new instance variable, "PropValue", set to 10 for Block.

2. Create a second Block "Instance B" in Layout 2 (PropValue correctly initialized to 10 from "Instance A")

3. Delete top-level instance "Instance A" from Layout 1.

4. Set PropValue on Instance B to 20.

5. Drag new instance of Block onto editor from Project Object Type List (into either Layout)

6. New instance is incorrectly initialized with value 10 from previously deleted instance.

Expected Behavior:

New instance should have property values equivalent to only remaining instance since it is now the archetype template for Object Type Block.

Workaround:

Completely reload the project file in Construct 2. This will reset the "in-memory" prototype of Block and its associated instance variable's values.

See 1 minute video demonstration:

Not a huge deal, but if you're dealing with a lot of object types and lots of instance variables, you can easily make mistakes because of this.

MultipleChoice

Sure man, I'm happy to help. I just watched your video and definitely see what you're talking about. That's nuts. Unfortunately, it doesn't happen when I run the test_example from my system (chrome/firefox), it's silky smooth.

I'm on a:

Windows 7 64-bit

Intel i7 2.7ghz

nVidia NVS 5400M

I hope you're able to get this resolved!

P.S. If you get a chance to run it on a different system, let me know, I'll be curious to see what happens.

MultipleChoice

You need to record a video of this issue, because I cannot repro what you describe in your bug report. Movement with Pixel rounding on/off with your sample capx was *completely identical* on my system. I'm starting to wonder if this might be related to video drivers. I'd recommend testing this issue on a couple different computers.

EDIT:

Also check this on-going thread about jitter issues in general:

https://www.scirra.com/forum/r190-jerking-on-ie-chrome-firefox-opera_t119846

Everybody knows that Construct 2 requires a minimum of one actual instance of every sprite. This first instance is a sort of "archetype instance" for all new instances of that sprite going forward. If you redefine the values of some custom archetype instance's variables, those values are used as the defaults for new editor instances as well as dynamically spawned instances.

I looked through the manual and forums to see if there was any mention or detail about this and wasn't really able to dig anything up, so I'm presenting my findings for everyone.

Here is a video I made demonstrating some potential pitfalls and issues with creating archetype instances of sprites:

TLDW: If you want to setup a archetype sprite with default values for its instance variables and behavior properties, you should do two things:

• Create an Assets Layout whose sole purpose is to keep one of each archetype sprite
• Make sure the Assets Layout is FIRST in the list of Project Layouts

Just a heads up,

The "View All Alerts Page" at http://www.scirra.com/alerts still has the old HTML skinned theme and also shows Welcome Guest.