Lua dcolor setting problem

  • Draco712
    7th Sep 2017 Member 0 Permalink

    I have a problem with setting dcolor (or dcolour, both are just the same) through tpt.set_property(). 

    dcolor is encoded as 0xAARRGGBB, where AA is the alpha (opacity) value, and RRGGBB are red, green and blue. The problem is, I can't set the alpha value greater than 7F, or let's say, I can't go beyond 0x7FFFFFFF, therefore we can't get full opacity. When any dcolor value is larger than this (like 0x80000000 or 0xFF000000), it becomes decimal -2147483648 (don't know hex for negatives).

     

    This ONLY happens in a lua script. Not in the console, PROP tool, or deco tools.


    Here's a sample lua script. Add it to the simulation, unpause, check the deco through console.
    Expected color: Full black ; Result: Dark magenta (black deco transparency + element color)

     

    elements.allocate("A", "TEST")
     elements.element(elements.A_PT_TEST, elements.element(1)) --just dust
     elements.property(elements.A_PT_TEST, "Name", "TEST")
     elements.property(elements.A_PT_TEST, "Description", "TEST")
     elements.property(elements.A_PT_TEST, "Colour", 0xBE33EF) --magenta element

    function tst(i,x,y)
     tpt.set_property("dcolour",0xFF000000,i) --here be deco
    end
    tpt.element_func(tst,elements.A_PT_TEST)

     

    TL;DR

     - In a lua script, setting dcolor greater than 0x7FFFFFFF fails.
     - dcolor -2147483648 results when this happens.

     - We can't set the dcolor to be fully opaque.

    EDIT:

     

    Problem solved, but just a workaround.

     

    To set dcolor to have full opacity, add -16777216 to a 24-bit color (0xRRGGBB).

    For example:

    tpt.set_property("dcolour", -16777216 , id)  --pitch black
    tpt.set_property("dcolour", -16777216 + 0xFF0000 , id)  --bright red (which 0xFFFF0000 or 0xFF0000 alone can't do)

    Edited once by Draco712. Last: 7th Sep 2017
  • jacob1
    7th Sep 2017 Developer 0 Permalink
    What OS and version are you on? I can look into it later
  • Draco712
    9th Sep 2017 Member 0 Permalink

    @jacob1 (View Post)

    It's 92.1, and I'm on Windows. I think this happened starting from version 92.0 onwards.

  • jacob1
    9th Sep 2017 Developer 0 Permalink
    I can't seem to reproduce this. I tried your script on Linux, Windows through wine on Linux, Windows 10, also on both 92.1 and 92.2 (92.2 uses luajit, 92.1 uses lua 5.1). I definitely notice differences for sure, with 32 bit / 64 bit. But I haven't seen it fail to set the color properly in any case.

    Maybe try using the gfx.getColors and gfx.getHexColor functions. The former converts a number into individual R G B A components, the latter takes 3-4 components and converts it into a number. Maybe you'll have more luck with those functions?
  • Draco712
    9th Sep 2017 Member 0 Permalink

    @jacob1 (View Post)

     Oh wait. It seems that previous versions of TPT used unsigned numbers (in this case, unsinged long), while newer versions used signed numbers (signed long). See edit from the first post, that's why adding -16777216 works. Signed long ranges from -2,147,483,648 to 2,147,483,647 (which is 0x7FFFFFFF, and that's why)

     

    Btw, I tried the gfx functions, and gfx.getHexColor is almost the same, like:
    gfx.getHexColor(0xAB,0xCD,0xEF) is the same as 0xABCDEF
    but not with alpha values. getHexColor(0xAB,0xCD,0xEF,0xFF) is (0xABCDEF - 16777216).

     

    So it's just the change in data types, eh? xD I'll just need to recompose the hex values in my autorun.lua file.

  • jacob1
    9th Sep 2017 Developer 0 Permalink
    I didn't change anything at all relating to this. It is also very 32 / 64 bit dependent. (but I was still unable to reproduce it, anyway, or think of any case where this would happen)
    If the gfx. functions work and basically do the -16777216 trick for you, use those instead.