Drawing images unaffected by setColor

[raidho36]

In the default shader, first thing it does is multiplies pixel color by draw color component-wise. That should give you solid idea what it does.

[Dr. Peeps]

are you using the unreleased 0.11.0? Color ranges are 0-1 there. Since it clamps above the range, it looks the same at 1 and 255.

Good call, s-ol. I am indeed using 0.11. I didn't notice that one in the change list - my fault for using the bleeding-edge code and reading the old documentation!

I love the 0-1 colour/alpha ranges - much better than 0-255! Thanks guys.

[Dr. Peeps]

In the default shader, first thing it does is multiplies pixel color by draw color component-wise. That should give you solid idea what it does.

Yes, that makes perfect sense. With that in mind though, it might be nice to be able to do love.graphics.setColor(1.2, 1, 1) to give images a 20% red tint (i.e. boost the reds). Why clamp it to 1?

Currently, I could do love.graphics.setColor(1, 0.8, 0.8), but this is obviously not the same.

[Nixola]

I think you can do it when using HDR canvases

[raidho36]

Because output pixels will get clamped then - a monitor can't display a full red any redder. And it won't make blue sprite red, too. Plus, removing other colors is how tinting works, not by boosting target color.

The effect you're looking for is probably full desaturation followed by tinting. It recolors it into target color rather than dimming or boosting specific color channels.

[xNick1]

I'm a little worried about that 0-1 range change.
Why was that changed?
Does it bring any particular advantage?
Does that mean my 0.10.2 projects won't work on love 0.11 unless I "adapt" them?
Also I'm using simple game devkit to export to android, which targets love 0.10.1,
would it be ok to stick to love 0.10.2 for me?

Sorry for the stupid questions,
I don't really know much about graphics but I'm willing to learn

[MrFariator]

I imagine that the change was made to make setColor operate on percentages (or "fullness" of a given color channel), much like other engines (Unity for instance uses floats between [0.0f, 1.0f]).

However, if you want to upgrade to 0.11 and not have to go through rewriting all instances of setColor calls, you can just use something like the following:

Code: Select all

-- Store the original function
local originalSetColor = love.graphics.setColor 

love.graphics.setColor = function (r,g,b,a) 
  a = a or 255 -- if you want to do some parameter checking, like if you want to omit alpha in some calls
  originalSetColor ( r/255, g/255, b/255, a/255 )
end

Of course, this will create a "gotcha" for your love project's code base, where one needs to know to use the old style despite being on 0.11. There is also some impact on performance (the divisions every time you want to change colors), but it's basically negligible.

[raidho36]

I have to believe that main reason is because it's like this internally, on GPUs. Imagining blend modes operation is also less confusing this way. Finally, it saves some conversions here and there, giving tiny performance improvement.

The reason why 0-255 range was even used at all is because in integer color representation, as it is in absolute majority of image formats, you can read bytes directly from the image and they'll be in 0-255 range.

[s-ol]

I'm a little worried about that 0-1 range change.
Why was that changed?
Does it bring any particular advantage?
Does that mean my 0.10.2 projects won't work on love 0.11 unless I "adapt" them?
Also I'm using simple game devkit to export to android, which targets love 0.10.1,
would it be ok to stick to love 0.10.2 for me?

Sorry for the stupid questions,
I don't really know much about graphics but I'm willing to learn

Android 0.11.0 is going to work the same as desktop 0.11.0, so you can port all the same.
Yes, you will need to change your game to work with 0.11.0, but no you don't need to switch to 0.11.0 if you dont want to.
You can still download the old love binaries and distribute your game with them.

If you try to play any older löve game, you will probably see that it either bugs our or shows a version mismatch error when you try to run it with your current version too. When a game is done, there is no real reason to port it to a newer love unless you want to use new features (imagine love 0.14.0 has web export, then you would want to maybe make it work with that version too)

This is how all versions have worked, when the b part in love version a.b.c changes, backwards compability is allowed to be broken - it's the only way a small framework like löve can make progress.

[MasterLee]

I didn't know if setPixel is affected as well but i replaced it with getPointer

Code: Select all

      local ptr=ffi.cast('unsigned char*',data:getPointer())
      for c=0,3 do 
        for p=0,31 do
          local f=pal[p][c]
          data:setPixel(p,c,f[0]*17,f[1]*17,f[2]*17,f[3]*17)
        end
      end

changed to:

Code: Select all

      local ptr=ffi.cast('unsigned char*',data:getPointer())
      for c=0,3 do 
        for p=0,31 do
          local f=pal[p][c]
          for x=0,3 do
            ptr[0]=f[x]*17
            ptr=ptr+1
          end
        end
      end