a working setColor compatibilty multiplier

Showcase your libraries, tools and other projects that help your fellow love users.
User avatar
Tricky
Citizen
Posts: 75
Joined: Thu Dec 18, 2014 4:07 pm
Location: Breda, the Netherlands
Contact:

Re: a working setColor compatibilty multiplier

Post by Tricky »

For me the change from 255 to 1 didn't make sense anyway.
Yeah 255 is indeed the max color value due to 255 being the decimal equivalent to binary 1111111
For me it works very very confusing since all graphic manipulation programs I have (as well as other programming tools I use) use a 0-255 scale, so you can imagine I was NOT amused about this change, and if it really needed to be done a DIFFERENT FUNCTION handling the 0-1 scale could be desirable (WITHOUT deprecating the original function!!!!)

Now I was "blessed" by laziness. I fell asleep every time I had to type love.graphics.setColor so I had a "color=love.graphics.setColor" present. All I needed to do was adding a version checker that would divide all values by 255 if version 11 or higher was detected. Saved me a lot of "code rot". The speed in which drastic changes take place on LÖVE, makes me wanna avoid all original direct love calls but use my own in stead, so I only need to add a version checker and the different code that I would need and voilà everything works.... again... :-/

Oh well... ;)
User avatar
Nixola
Inner party member
Posts: 1949
Joined: Tue Dec 06, 2011 7:11 pm
Location: Italy

Re: a working setColor compatibilty multiplier

Post by Nixola »

There are more ways to represent colours, some of which exceed 255.
lf = love.filesystem
ls = love.sound
la = love.audio
lp = love.physics
lt = love.thread
li = love.image
lg = love.graphics
User avatar
s-ol
Party member
Posts: 1077
Joined: Mon Sep 15, 2014 7:41 pm
Location: Cologne, Germany
Contact:

Re: a working setColor compatibilty multiplier

Post by s-ol »

Tricky wrote: Sat May 26, 2018 2:53 pm For me the change from 255 to 1 didn't make sense anyway.
Yeah 255 is indeed the max color value due to 255 being the decimal equivalent to binary 1111111
For me it works very very confusing since all graphic manipulation programs I have (as well as other programming tools I use) use a 0-255 scale, so you can imagine I was NOT amused about this change, and if it really needed to be done a DIFFERENT FUNCTION handling the 0-1 scale could be desirable (WITHOUT deprecating the original function!!!!)

Now I was "blessed" by laziness. I fell asleep every time I had to type love.graphics.setColor so I had a "color=love.graphics.setColor" present. All I needed to do was adding a version checker that would divide all values by 255 if version 11 or higher was detected. Saved me a lot of "code rot". The speed in which drastic changes take place on LÖVE, makes me wanna avoid all original direct love calls but use my own in stead, so I only need to add a version checker and the different code that I would need and voilà everything works.... again... :-/

Oh well... ;)
how about:

Code: Select all

-- compat.lua
local _setColor = love.graphics.setColor
function love.graphics.setColor(r, g, b, a)
  return _setColor(r/255, g/255, b/255, a and a/255)
end
this is Lua after all.

0-1 is semantically more correct, and as Nixola points out, more general than 0-255. Some colorspaces have 0-360 for example.
Having the values normalized is also mathematically ideal, it means that you can multiply components properly.
If you are working with 0-255 values internally then you have to take care to divide by 255 when you do thinks like multiplying colors or exponentials etc.

s-ol.nu /blog  -  p.s-ol.be /st8.lua  -  g.s-ol.be /gtglg /curcur

Code: Select all

print( type(love) )
if false then
  baby:hurt(me)
end
User avatar
Tricky
Citizen
Posts: 75
Joined: Thu Dec 18, 2014 4:07 pm
Location: Breda, the Netherlands
Contact:

Re: a working setColor compatibilty multiplier

Post by Tricky »

s-ol wrote: Mon May 28, 2018 9:05 am
Tricky wrote: Sat May 26, 2018 2:53 pm For me the change from 255 to 1 didn't make sense anyway.
Yeah 255 is indeed the max color value due to 255 being the decimal equivalent to binary 1111111
For me it works very very confusing since all graphic manipulation programs I have (as well as other programming tools I use) use a 0-255 scale, so you can imagine I was NOT amused about this change, and if it really needed to be done a DIFFERENT FUNCTION handling the 0-1 scale could be desirable (WITHOUT deprecating the original function!!!!)

Now I was "blessed" by laziness. I fell asleep every time I had to type love.graphics.setColor so I had a "color=love.graphics.setColor" present. All I needed to do was adding a version checker that would divide all values by 255 if version 11 or higher was detected. Saved me a lot of "code rot". The speed in which drastic changes take place on LÖVE, makes me wanna avoid all original direct love calls but use my own in stead, so I only need to add a version checker and the different code that I would need and voilà everything works.... again... :-/

Oh well... ;)
how about:

Code: Select all

-- compat.lua
local _setColor = love.graphics.setColor
function love.graphics.setColor(r, g, b, a)
  return _setColor(r/255, g/255, b/255, a and a/255)
end
this is Lua after all.

0-1 is semantically more correct, and as Nixola points out, more general than 0-255. Some colorspaces have 0-360 for example.
Having the values normalized is also mathematically ideal, it means that you can multiply components properly.
If you are working with 0-255 values internally then you have to take care to divide by 255 when you do thinks like multiplying colors or exponentials etc.
I basically went a bit like this

Code: Select all

 
 --[[ This is fake code, so it won't work, it was just to get the picture]]
 if version<11 then
    color=love.graphics.setcolor
  else 
    color=function(r,g,b,a)
       love.graphics.setcolor(r/255,g/255,b/255,a/255)
    end
 end    
 
 
That is fake code, it was just to get the picture, and this way it works on both 0.10 as on 11.x
Now I wonder what good a 0-360 scale would do since 0-255 already creates more colors a human eye can distinguish (not to mention the only color value I've ever seen in a 0-360 scale is the hue value in hsv coloring, due to 360 degrees making the full color circle, but if it did make sense the change the way it was done, was just way ugly, making all LÖVE programs suffer from code-rot in the process.
I also wonder if having to divide all colors by 255 all the time doesn't lead to performance issues in more complex programs...

Well, I already coded when colors where still in a 256-color-palette with each palette slot only having a 0-63 scale for colors, and I do remember that it was rather a big switch to go to a 0-255 scale, not to mention, getting rid of palettes altogether, but I could see the sense back then. Now it just seems like, well, we can do it, so why don't we.... Figures ....
User avatar
holywyvern
Prole
Posts: 8
Joined: Wed Apr 05, 2017 7:06 pm
Contact:

Re: a working setColor compatibilty multiplier

Post by holywyvern »

You can do it simpler:

Code: Select all

local lib = {}

if love._version_major < 11 then 
  lib.setColor = love.graphics.setColor
  lib.getColor = love.graphics.getColor
else
  lib.setColor = function (r, g, b, a)
     love.graphics.setColor(r / 255, g / 255, b / 255, (a or 255) / 255)
  end
  lib.getColor = function ()
    local r, g, b, a = love.graphics.getColor()
    return r * 255, g * 255, b * 255, a * 255
  end
end

return lib

You could override love.graphics.getColor and love.graphics.setColor directly, but that's your choice to make.
grump
Party member
Posts: 947
Joined: Sat Jul 22, 2017 7:43 pm

Re: a working setColor compatibilty multiplier

Post by grump »

holywyvern wrote: Mon Jun 04, 2018 12:42 pm

Code: Select all

  lib.getColor = function ()
    local r, g, b, a = love.graphics.getColor()
    return r * 255, g * 255, b * 255, a * 255
  end
That doesn't work as expected, because getColor returns truncated values.

love.graphics.setColor is also not the only function that takes colors - there's plenty more in several interfaces that can't be all replaced so easily. For a complete solution that takes care of everything for you, use this:

Code: Select all

if love._version_major >= 11 then
    require('cindy').applyPatch() -- https://github.com/megagrump/cindy
end
This makes love.graphics, Shader, ImageData, SpriteBatch and all other relevant things work with the [0-255] range again. Or you can omit applyPatch() and use the provided alternative functions (e. g. setColorBytes) instead that work with the old range.
User avatar
D0NM
Party member
Posts: 250
Joined: Mon Feb 08, 2016 10:35 am
Location: Zabuyaki
Contact:

Re: a working setColor compatibilty multiplier

Post by D0NM »

2grump: You r such a party saVer!
At least migrated our Zabuyaki beat 'em up to Love 11.3
the final thing was cindy.
And usually I use polyamory (for video lessons about old/new love2d, etc).
Last edited by D0NM on Wed May 20, 2020 9:45 pm, edited 1 time in total.
Our LÖVE Gamedev blog Zabuyaki (an open source retro beat 'em up game). Twitter: @Zabuyaki.
:joker: LÖVE & Lua Video Lessons in Russian / Видео уроки по LÖVE и Lua :joker:
grump
Party member
Posts: 947
Joined: Sat Jul 22, 2017 7:43 pm

Re: a working setColor compatibilty multiplier

Post by grump »

D0NM wrote: Wed May 20, 2020 7:56 pm 2grump: You r such a party safer!
At least migrated our Zabuyaki beat 'em up to Love 11.3
the final thing was cindy.
Thank you very much for the feedback!

The change to the "new" color range makes a lot of sense for newer projects, but I'm happy that this little hack helped you port your game to LÖVE 11 with less effort. That's why I made it in the first place.
Post Reply

Who is online

Users browsing this forum: No registered users and 44 guests