Speed of ticks after timescale change?

Hello, I'd like to ask a quick question if possible.

I'm trying to workout if ticks is effected by timescale,

so for a test I had it create an object every 300 ticks.

I counted to 10 while timescale was at 1 to try and get

the rhythm, then changed timescale to 0.2, and it seemed

to then only take myself to count to 7 before a new

object was created.....How does that work?

If it is affected, shouldn't it slow down, not be faster?

Is there any way to stop it being affected, or a method

I can use to make events occur based on time in an easy

manner, unchanged between timescales?

Because I want to use timescale as part of the game, but

I want some events to occur after the same amount of time

without scaling because of timescale,

I'd greatly appreciate any help I can get for this.

The tickrate not affected by timescale.

Counting is not very accurate. Here is an example that measures the time over 180 ticks with switching timescale between 0 and 1:

profiling.cap

While the tickrate is not affected by timescale, it is affected by your system, by anything that detains Construct from getting processing time, and by a huge amount of events/tasks (e.g. drawing 20000 lines in the canvas object per tick, or creating 30000 sprites per tick, etc.)

Thank you very VERY much for taking such time to create such a fantastic

example for me, it really helped clear things up and I greatly appreciate it.

I wouldn't have a clue make an example such as that so all I could do

was try and estimate by counting.

So would running an event 'every x miliseconds' be more accurate if I

were trying to have something run consistently (say every 20 miliseconds),

or would that be affected by the timescale, or would ticks be fine for

something like that?

"Every X ms" would certainly be affected by timescale.

I think tulamide or Ash or someone said before not to use "Every x ms" since its not actually accurate.

Can't find it on here, but there is THIS interesting thread regarding 'Every X ms' issues from the old forum.

These 2 pages from the wiki are probably essential to read as well:

Time scaling

Time delta

Thank you very much for all your additional replies with further help.

It's just a shame it has to be so complicated to run games successfully

across different computers with different framerates/refresh rates,

and that timedelta confuses the hell out of me.

It makes it more 'programmer-skill-memory-independent',

and I've read the wiki link about it multiple times and I still don't

really understand how it's used/where it's used.

If timedelta is FPS independent, how do I do something simple like I would

with ticks, where I want to make an object after 100 ticks,

an amount of time that would be consistent across varying framerates?

Also in this example,

"Note that at 100 FPS, TimeDelta = 0.01 and 200 * 0.01 is 2: that's the 2 pixels per tick we needed. And at 50 FPS, TimeDelta = 0.02 and 200 * 0.02 is 4. In general, to move an object at a rate of pixels per second, simply use:

Set X to .X + (r * TimeDelta) "

What is the "r" in "(r * TimeDelta)"?

Also from what I understand, if TimeDelta becomes necessary to swap with

all my events currently using ticks, what would be the best way to have

things consistent in their time when I'm using timescale? Have seperate

trees with different times set based on the timescale at the time?

Every ms is not accurate at small levels, like 10 ms. For larger values, like 1000ms, it's plenty accurate, so using an every 1000 ms event to create something will work fine.

Timedelta is a measurement of time. It returns, in seconds, how long the previous frame took to calculate and render. So if you're getting 1 frame per second, timedelta returns 1. If you are getting 10 frames per second, it returns 0.1, as each frame is taking a tenth of a second for the computer to make.

Set X to .X + (r * TimeDelta)

So at 1 fps, to the computer, it becomes:

Set X to .X + (r * 1)

At 10 fps:

Set X to .X + (r * 0.1)

r is the rate. That's the value you choose for the speed. 100 will move it 100 pixels per second, regardless of the frame rate.

Set X to .X + (100 * TimeDelta)

If the current x position is 0:

At 1 fps:

Set X to .X + (100 * 1) = 100

At 10 fps:

Set X to .X + (100 * 0.1) = 10

Then after one second, the sprite will be in the same position regardless of the framerate.

Did that make sense?

Arima described TimeDelta perfectly, which should help you get started with time-based developing.

Just make sure, you stick to one method, either time based or pixel based. Trying to combine those will only give you headaches.

If timedelta is FPS independent, how do I do something simple like I would

with ticks, where I want to make an object after 100 ticks,

an amount of time that would be consistent across varying framerates?f working time-based, you have to remember that the shortest interval you have still is one tick. If your game runs at 60 fps v-synced, the fastest your code is triggered is every 16.67 ms (1/60). Every time-based condition will trigger either exactly at the given time or as close as possible to it afterwards. For example, every 1 milliseconds will trigger at tick 1, tick 2, tick 3, etc., because the game doesn't run at 1000fps (which would be needed for 1ms).

To have an object being created after a certain amount of time, there are several methods:

• You could use the wait object, delaying the creation
• You could use timer (a system expression). Set a variable 'timestamp' to timer, and compare 'timestamp' against timer and the desired timespan. For example, to create an object 2 seconds after 'timestamp' was set to timer:+ 'timestamp' less or equal timer - 2000

+ Trigger once

• You could use the timeline object

Also from what I understand, if TimeDelta becomes necessary to swap with

all my events currently using ticks, what would be the best way to have

things consistent in their time when I'm using timescale? Have seperate

trees with different times set based on the timescale at the time?hat confuses me. The whole purpose of timescale is to have an easy way to change the timing behavior of all time-based code at once. So why would you want to change timescale, without wanting to change the behavior of the time-based code?

Arima

So, from that example Arima as I now understand it thanks to your

fantastically layed out and simplified written view of how it works,

because at 1fps timedelta in that expression will result with 100,

and 10fps it will result with 10, the time passes as:

1 x 100 = 100,

and

10 x 10 = 100,

in other words it will end up traveling the same amount.

Thank you so much for that example, it really allowed it to make sense

for me, I greatly appreciate it!

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

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

tulamide

I'm not using this for movement, however I understand what you mean

by only using one method as it would easily unsynch the gameplay

if you were to use different methods in the same game.

Thanks a lot for that information, I hadn't recognized or thought

about that but that certainly makes sense how you put it. An event

can't run every 1ms if it can't register that amount of time passing,

and would make the event occur basically whenever it could, cause

at 60fps every frame that is registered would have passed a millisecond,

and it wouldn't know a millisecond had occurred between those frames

because it wouldn't have been there to find out.

wait

That I've found is next to useless, it constantly caused errors in

the event hierarchy because it would re-check the above variables

after the time had passed instead of only causing a delay before the

next action occurred.

For example, if you had it check if a private variable were equal to 0

before running some events, one of which would need to change that variable

to 1, when it reached the next action after waiting maybe 200 milliseconds,

the events condition wouldn't be valid anymore and it won't occur.

timer

that's what I've had to use for objects so far, but it becomes an issue

very easily.

#1 if there is more than one object on the screen (if it's an enemy in which multiple enemies would be created, you couldn't get a timer to

start on individual enemies without it occurring on others. For some objects that I have destroy after a certain amount of time, even if there are multiple you can use that timer by only setting the timer

when a condition that a variable is equal to 0 is met, then change that

to 1 after the timer is set in the same event. But that only works because you only need to use the timer once and it's an event based off the objects creation.

#2 if you want multiple areas of an object to be based off time, it'd very easily become a large hassle and difficult to manage if you kept having to create private variables and setting them to time and checking them.

Both of these issues are the reasons causing me to currently use ticks

for some events, but now I recognize that's certainly no safe option,

however you can't run events after 'x' timedelta or anything like that.

Even with a global variable if multiple objects/events used it it wouldn't help to set a single global variable to 'Time' and keep

setting and then checking after time has passed with that.

The timeline object would in a way share the problems described above

for the timestamp solution.

The reason I want some events to not be affected by timescale, is I want

to slow down the world by using timescale (all events/objects/etc), however

some things I don't want to slow down, for example how long a text object

spawned off an enemy displaying the damage they have taken would last

before being destroyed.

wait

That I've found is next to useless, it constantly caused errors in

the event hierarchy because it would re-check the above variables

after the time had passed instead of only causing a delay before the

next action occurred.

For example, if you had it check if a private variable were equal to 0

before running some events, one of which would need to change that variable

to 1, when it reached the next action after waiting maybe 200 milliseconds,

the events condition wouldn't be valid anymore and it won't occur.

I am no friend of the wait object, because it makes event sheets harder to maintain. That's why I never use it. I just proposed it, because quite a few people here swear on it, and I didn't want to hide it ;)

timer

that's what I've had to use for objects so far, but it becomes an issue

very easily.

#1 if there is more than one object on the screen (if it's an enemy in which multiple enemies would be created, you couldn't get a timer to

start on individual enemies without it occurring on others. For some objects that I have destroy after a certain amount of time, even if there are multiple you can use that timer by only setting the timer

when a condition that a variable is equal to 0 is met, then change that

to 1 after the timer is set in the same event. But that only works because you only need to use the timer once and it's an event based off the objects creation.

I'm not quite sure if I understand. PVs are unique to every instance, it is just a case of picking right. If I pick one instance and set 'timestamp' to timer, only 'timestamp' of that one instance is set. So, if you want to pick an instance at times, when it is not created, you can do so by picking based on oid or uid, or set an 'pid'-pv on creation.

For a situation, where one object would have to spawn a few instances delayed, there are objects like array or hash table, where you could store the timestamps, test against timer and clear/remove the cells, when creating the corresponding instance. Straightforward and easy to control :)

#2 if you want multiple areas of an object to be based off time, it'd very easily become a large hassle and difficult to manage if you kept having to create private variables and setting them to time and checking them.

I can't agree here. I use the 'timestamp' method in every project, sometimes on hundreds of sprites and instances. If you carefully prepare your project, you won't get into trouble. Instead, while using something like the wait object would really be a problem under such conditions, it is relatively easy to follow the logic behind the 'timestamp'-events.

The reason I want some events to not be affected by timescale, is I want

to slow down the world by using timescale (all events/objects/etc), however

some things I don't want to slow down, for example how long a text object

spawned off an enemy displaying the damage they have taken would last

before being destroyed.

I see. Well, this is a situation, where you have to decide, which one is more important to be time-based.

You could, for example, constantly check the framerate (e.g. through getting the mean of 1/TimeDelta) while timescale = 1. Then, when reducing timescale, you'd calculate the proper timing for the text boxes based on that framerate, and alter them tick-based until timescale = 1 again.

Or you could leave timescale untouched and slow the world down by changing all the timebased values, including animation speed, etc. But that would mean a huge effort to make.

I recommend to download Verve!, an example game that is completely time-based. There are a lot of the things realized that you are thinking of (For example, there's a commented volume fade over time, although timescale=0 at that time). I commented every single event, so it should be a good source of information.

I am no friend of the wait object, because it makes event sheets harder to maintain. That's why I never use it. I just proposed it, because quite a few people here swear on it, and I didn't want to hide it ;)

Ahhh no worries, well thank you for pointing out all the options

without limitation :)

I'm not quite sure if I understand. PVs are unique to every instance, it is just a case of picking right. If I pick one instance and set 'timestamp' to timer, only 'timestamp' of that one instance is set. So, if you want to pick an instance at times, when it is not created, you can do so by picking based on oid or uid, or set an 'pid'-pv on creation.

For a situation, where one object would have to spawn a few instances delayed, there are objects like array or hash table, where you could store the timestamps, test against timer and clear/remove the cells, when creating the corresponding instance. Straightforward and easy to control :)

OID?

I know UID is uniqueID, however that includes all objects in the scene,

and it would be impossible to know which instance of the object you

wanted as well.

I like to use a private variable 'states' to differentiate them somewhat,

so when a creature enters the 'attacking' state it would change to the

attack animation, and spawn a weapon/ranged attack/effects on frame 3,

it would know to check for frame 3 of an enemy instance in the attacking

state, however how would I get the weapon/ranged attack/effect to spawn

at that enemy specifically. Because it wouldn't know which of the enemys

positions to spawn at.

I've tried with the enemy damage text, when an object is overlapping it

I have the text spawn at the enemy once by using 'trigger once',

however if there are multiple enemies, it will cause it to only create

a text at one of the enemies you are overlapping.

I've tried using the 'for each' event condition, but it causes one enemy

to have the text created once like it should, but the other enemies that

are overlapped continuously spawn the object while they are overlapped.

No matter what I do I can't seem to have events run while considering

only the individual object they are running at and it's parameters/location, etc.

I can't agree here. I use the 'timestamp' method in every project, sometimes on hundreds of sprites and instances. If you carefully prepare your project, you won't get into trouble. Instead, while using something like the wait object would really be a problem under such conditions, it is relatively easy to follow the logic behind the 'timestamp'-events.

What happens when you need to know that one area of an object you need

a timestamp for won't overlap another area. You just make multiple timestamps?

I see. Well, this is a situation, where you have to decide, which one is more important to be time-based.

You could, for example, constantly check the framerate (e.g. through getting the mean of 1/TimeDelta) while timescale = 1. Then, when reducing timescale, you'd calculate the proper timing for the text boxes based on that framerate, and alter them tick-based until timescale = 1 again.

Or you could leave timescale untouched and slow the world down by changing all the timebased values, including animation speed, etc. But that would mean a huge effort to make.

While reading over that, thanks to it I was inspired to another possible

solution.

I could have a global variable that's set to 1, and have every event

where I use multiply by that global variable, and then with the events

where I cause the timescale to for example be set to 0.2, I could set

that variable to 5, automatically causing the time for those events

to balance out. Would that be a good solution?

I recommend to download Verve!, an example game that is completely time-based. There are a lot of the things realized that you are thinking of (For example, there's a commented volume fade over time, although timescale=0 at that time). I commented every single event, so it should be a good source of information.

Thanks for that recommendation, I've looked over it a bit and it's a

great example, I'll be sure to delve into it deeper before responding

again, and once again thanks so much for taking your time to help me like

this, I appreciate it so much! ^^