AGS v2.7: Problem fading objects (SOLVED)

[strazer]

I must be doing something wrong here:

I want to fade in an object. I encountered a problem and tried this simple code

Code: ags

  object[0].Transparency = 100;
  while (object[0].Transparency) {
    object[0].Transparency--;
    Wait(1);
  }

in hi-color and in 32-bit. The object goes transparent, but doesn't fade in.
The transparency simply doesn't change and the game locks up.
32-bit background, 32-bit object sprite.

Try this demo.

Am I missing something?

I see no way this could be related to Linux, so I didn't boot Windows to check.
Forgive me if it works for you.

[Gilbert]

I'm not quite sure, seems that there're some problem with using general assignments, calculations, etc. with properties (tried adding a debugging Display(), the transparency was always kept at 100), if I changed the code to below it works:

   object[0].Transparency = 100;
   int a =100;
   while (a){
      object[0].Transparency=a;
      a--;
      Wait(1);
   }

EDIT: Ah I found out the problem now, seems that though the property took (0-100) as parameter, it doesn't actually have full 101 levels, maybe it's actually 64 levels only, hashed to 101 levels by the engine.
If you set the transparency to 99, the engine is actually setting it to 100, so when you retrieve back the property value it'll be 100, so it's always 100 in your case (if you make it fade faster, say, minus 2 each loop it'll get past the freeze then).
I think this should be clearly documented in the manual, moreover I don't really like the behaviour, setting the limit to 100 is just good to common people's eyes, in my opinion, if in reality it's not really 0-100 levels the parameter should just use the internal scale (0-63/64 probably).

EDIT2: The manual DID mention it, though it's not very detailed:

Some rounding is done internally when the transparency is stored -- therefore, if you get the transparency after setting it, the value you get back might be one out. Therefore, using a loop with object[0].Transparency++; is not recommended as it will probably end too quickly.

[strazer]

Thank you!
Well, a clear case of RTFM.

But I agree with

if in reality it's not really 0-100 levels the parameter should just use the internal scale (0-63/64 probably).

Edit:

Because since I want do it in the background, that means I need an additional global variable storing the actual transparency. Ah well...

[Pumaman]

As Gilbert says, this is mentioned in the manual. Looking back, it probably would have been a better idea to just expose the 0-63 scale directly, but what's done is done.