change love's color handling to use floats instead of integers

Issue #596 wontfix
created an issue

i know this is going to be an extremely popular proposal, so here it goes!

currently, love handles color channels using values in the range [0, 255]. this is somewhat unfortunate, as floats in [0.0, 1.0] are much more common nowadays. plus, they are generally just nicer to work with


  • math on color channels is nicer. instead of having to shrink the result of color operations back to [0, 255] from some wonky number, operations either remain in the [0.0, 1.0] range (multiplicative operations) or are much nicer to average (additive operations)
  • pixel effects/shaders already use floats
  • maps more nicely with 0.9.0's HDR canvases: [0.0, 1.0] is typical low-dynamic range, (1.0, +inf) is HDR land
  • floats offer a hell of a lot more than 255 values, at least as far as the math is concerned.
  • floats don't expose the underlying precision like integers do.
  • whether it's a .png or an .exr, (1.0, 1.0, 1.0) means white


  • compatibility break (but those happen often anyway considering the api isn't stable yet)
  • float-based image formats are less common, therefore people are used to bytes. this would be apparent when working with ImageData

Comments (7)

  1. Alex Szpakowski

    The second drawback is a very big one, I think. It's also much easier/more intuitive to write many values in integral bytes than in normalized floats, e.g. setColor(192, 160, 150) vs. setColor(0.75, 0.625, 0.58594).

    Math on color components is much less common than just setting or getting colors normally. Also, color channel value comparisons would become much less nice, in terms of using literal values in code.

  2. Alex Szpakowski

    Would similar matching functions be expected for every other color-setting function, then? i.e., canvas:clear, SpriteBatch:setColor, ParticleSystem:setColor, ImageData:setPixel, ImageData:mapPixel,, etc.

  3. Landon Manning

    Insteading of completely mucking up how people use colours, the following function (or some variation thereof) should probably work for you.

    -- Returns floats
    function (r, g, b, a)
        local i = 255
        return r/i, g/i, b/i, a/i
  4. Log in to comment