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.
[QUOTE=sparkfeather]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?[/QUOTE]If 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:[code]+ 'timestamp' less or equal timer - 2000
+ Trigger once[/code]
- You could use the timeline object
[QUOTE=sparkfeather]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?[/QUOTE]That 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?