tulamide's Forum Posts

  • //object1.X <> ScrollX//

    set object1. X

        lerp(object1.x, destinationX, x*TimeDelta)

    set ScrollX

        lerp(ScrollX, destinationX, x*TimeDelta)

    How do I change x*TimeDelta for both objects so that no matter how different their X coords are, they'll still end in the same X at the same time?

    Please help?

    Don't think too complicated.

    So you want two objects with different distances to destinationX to reach that point at the same time. lerp is perfect for that, because wherever you start, as soon as the t-value reaches 1, both will be at destinationX. All you need to do is raising the t-value from 0 to 1 over the period of time you want.

    If you want a number to grow over time, you add n * timedelta to it. The maximum value of t is 1.0. How long do you want it last until 1.0 is reached? 'n * timedelta' equals 'amount per second'

    To have it last 2 seconds, you'd add 0.5 * timedelta (2 * 0.5 = 1)

    To have it last 5 seconds, you'd add 0.2 * timedelta (5 * 0.2 = 1)

    etc.

    + some condition

    -> myT = myT + 0.5 * TimeDelta

    -> lerp(object1.x, destinationX, myT)

    -> lerp(ScrollX, destinationX, myT)

    Just make sure, myT isn't raised anymore, after 1.0 is reached.

  • 321 downloads so far - and no comment for 7 month now.

    I guess it isn't as helpful as I thought <img src="smileys/smiley17.gif" border="0" align="middle" />

  • You wouldn't need something special for that. Just outsource your graphic/sound/music files and load them as needed while running the game. Then use an installer package and make sure to make an registry entry with the path to the game's data folder on cd/dvd. When starting the game from harddisc (where only the exe would be installed) you game uses the registry object to access the path information and load the data from there.

    Or if your installer package is able to create an ini file, just store the path in an ini file and use the ini-object to retrieve the path information.

  • 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.

  • 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?

  • Here is another one:

    Automatically loop-count x from 1 to n repeatedly

    x = (x % n) + 1

    EDIT:

    In C2 it says

     Type mismatch
= does not work with 'integer' and 'string' (use & to build strings)

    In CC it works when the testvar is a number, e.g.

    Text: Set text to global('test') = 0 ? "Value is zero" : "Value is non-zero"

  • That would be awesome!

    In the meantime, while you are optimizing your current plugins, I will start teaching myself javascript and test my capabilities. Kyatrics online version of the C2 SDK documentation is very useful, and from what I see it seems to be a straightforward adaptation of the C++ SDK for CC, so it shouldn't be too difficult.

    Then again, learning is much harder as you get older... :D

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • The size of the exported .exe grows with the assets and plugins you include (e.g. the physics behavior needs about 2 MB, a large 512x512 texture needs 1 MB, etc.).

    With this in mind, you could try to use smaller textures, less animation frames, or omit behaviors, if the same effect could be achieved with just a few events.

  • Thank you very much, Kya, that helps a lot. I always try to solve issues, but in cases like that, I need a starting point. You just gave me one :)

  • 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.)

  • Anyone?

    I'm not looking for a complete solution to this problem, just a description of the way it would have to be done, maybe with some keywords that I can then google for. Or a statement that it isn't possible.

  • From my very little tests with the avi object, I can confirm that it works, and that there is only one format supported (at least avi containers didn't work for me), and that's the primary avi uncompressed (don't know the exact name).

    But, the avi object just shows an avi player with all transport elements visible. If you don't want that, you need to use python. There is a solution from ROJOhound somewhere on the forums.

  • I'm not very good at explaining such very specific things in english, so maybe my words are imprecise.

    With 'fixed' I didn't mean a value that doesn't change, but a value known to and checkable for HLSL. The upper bounds check needs to be local (local to the effect function, defined within the effect function).

    clamp() is a function and that's why it is like a black box for HLSL, while modulo is a specific operator.

    radius is local, while radius2 is global.

    I hope you can follow the above, because I don't kow how to express it else <img src="smileys/smiley9.gif" border="0" align="middle" />

    EDIT: Maybe this makes it a bit more clear.

    radius = radius2; //sets radius = unknown

    radius = 15; //sets radius = known

    radius = clamp(radius2, 1, 6); // sets radius = clamp(unknown, 1, 6), which makes it still being unknown

    radius = clamp(radius, 1, 6); // sets radius = clamp(known, 1, 6), which makes it still known

  • If your code example is exactly what you've done, then you are setting an event with a condition and no action after the event where the bullets are spawned. That doesn't work.

    You need to have one event with 2 conditions, like so:

    + Hero: Value 'Weapons' Equal to 0

    + System: Bullet.Count Lower than 5

    This is one event with two conditions, and both of them need to be true, before the actions of that event (Creating the bullet and playing the sound) are performed.

    Edit: btw, you are generating one bullet per tick, when using the events without some timing. So the four bullets you allow, will be created within 4 ticks. If your game runs with 60 fps, that's a timespan of 0.067 seconds. It is most likely that you will see them very close to each other, if not one above the other (giving the impression of having only one bullet)

    If you want them to fire at a certain rate, you should consider adding a time counting method.