Default values for love.graphics.setColor

[T-Bone]

Something that's bothered me for a while is that whenever I'm drawing something with colors, I type

Code: Select all

love.graphics.setColor(255, 255, 255)

afterwards to reset the color to white. It's a lot to type when you do it over and over. Wouldn't it be nice if love.graphics.setColor could be called without arguments to reset the color to white?

It's easy to implement yourself with something like this

Code: Select all

oldColor = love.graphics.setColor
function love.graphics.setColor(r,g,b,a)
    oldColor(r or 255, g or 255, b or 255, a)
end

but wouldn't it be a reasonable default behaviour? Or perhaps it's preferable to use love.graphics.push/pop (but that's even longer to type)?

Have any of you also thought this would be useful?

[Jasoco]

I'd be for this actually. Just love.graphics.setColor() could just set to white instead of throwing up an error.

[slime]

Hmm, but Canvas:clear() sets the canvas' background color to full transparency (0,0,0,0) and clears it.

This should probably be on the issue tracker.

[Jasoco]

But we're not talking about canvases. We're talking about love.graphics.setColor().

[slime]

If one color function behaves a certain way, people should expect the rest to behave the same instead of doing the opposite, right?

[T-Bone]

If one color function behaves a certain way, people should expect the rest to behave the same instead of doing the opposite, right?

Well, by default, the background color is black and the foreground color is white. So if you look at it like both functions set the colors to their defaults, there's no inconcistency.

[Plu]

clear() and setColor() are two completely different things. I would expect love.graphics.clear() to reset the entire screen to black as well. (In fact, I'm pretty sure it does just that)

But setting the default drawing color to white makes sense to me.

[Robin]

There's a difference, though:

Code: Select all

love.graphics.setColor() -- set the color to WHAT? It doesn't really make sense
canvas:clear() -- OK, this clears the canvas
canvas:clear(244, 32, 100) -- This clears the canvas and oh look you can pass a specific color too

The difference is that for Canvas:clear() the color is secondary information, while for love.graphics.setColor() it is primary information (and you shouldn't leave that out).

[Santos]

"Setter" functions which can be called without arguments typically "release" the currently active state, for example love.graphics.setCanvas, love.graphics.setStencil and love.graphics.setScissor. I'm not sure if this quite the same thing as setting the color back to its original state. If "calling a setter function without arguments sets the state back to the original state" was a convention, one might expect, say, ParticleSystem:setPosition to set the coordinates of the ParticleSystem to 0, 0 when it's called without arguments. I don't think this would be so good because you would have to be aware of the convention, otherwise it could be hard to tell what calling a setter without arguments means, and you'd have to be know what the original state is, and also the original state might be kinda arbitrary.

SpriteBatch:setColor when called without arguments does something special (*hoping I'm recalling this correctly*), in that is "releases" the set colors of the SpriteBatch, which means the SpriteBatch is then affected by the global color instead of individually set colors.

Just to note, I think the love.graphics.push/pop stack only deals with coordinate system state, and not other graphics state such as color.

[Plu]

How about adding love.graphics.clearColor()?

Of course, you could simply add it yourself if you felt like it.