timedelta

So i ran my game in unlimited fps mode and it went to around 2000fps and my custom movements and fx were all over the place.

I've started coverting things over to timedelta and switching between vsynced and unlimited to test things. For the most part things now work the same at 60fps as they do at 2000fps except some small inaccuracies which is apprently to be expected.

My main problem is with opacity.

I'd like my object to fade on when it's created, so i do

for each object

+every tick

set objects opacity to objects opacity + 800 * timedelta

At unlimited around 2000fps the fade on is at a nice looking speed before its opaque, but vsynced to around 60 fps and it happens so fast the object instantly appears opaque with no gradual fade visable, i guess it happens too fast.

I can't seem to find a balance, shouldnt it appear the same regardless, or have i got the code wrong?

Thanks.

It looks like it should work, but opacity has a rounding problem which might affect this. Because opacity is really stored as an integer 0-255, Construct's opacity values (0-100) will round to about the nearest 0.4. This can affect timedelta'd stuff involving opacity. You can either store the opacity in a private variable and set it from that, or (much easier) use the Fade behavior which does not suffer this problem.

So setting the opacity to 41% does the same thing as setting it to 40.8% ? Can you set it to a non-integer value like that?

Okay I don't think that was clear. Is it like example #1 or #2 ... or neither?

Example #1:

attempt:

Set opacity to 40.3%

result:

opacity is rounded to nearest .4 and set to 40.4%

Example #2:

attempt:

Set opacity to 40.3%

result:

Can only use an integer value so 40.3 gets rounded down to 40.0

opacity is rounded to nearest .4 and set to 40.0%

It rounds down. Construct allows a floating-point value 0-100 for opacity (which is more sensible for the end user than 0-255). When you set opacity to 40.3, it multiplies it by 2.55, rounds it down, and stores as an integer (= 102), then when you next retrieve it, it divides by 2.55 and returns a float (= 40). This is one of a few annoying design mistakes which is difficult to correct, but will be sorted out in the next major revision of Construct (some way off).

Okay, just wanted to make sure it didn't get rounded twice.

...

I'm gonna go click on the scrollbar now.