Speed of ticks after timescale change?

This forum is currently in read-only mode.
From the Asset Store
Have you ever dreamed of playing in a Speedball game or tournament?
  • 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?

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • 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! ^^

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)