getColor/setColor subtracting 1

[William Willing]

love.graphics.getColor (or love.graphics.setColor, I'm not sure) is giving me some unexpected behaviour. I have the following code.

Code: Select all

function love.draw()
	local r, g, b, a = love.graphics.getColor()
	love.graphics.print(r .. ', ' .. g .. ', ' .. b .. ', ' .. a, 0, 0)
	love.graphics.setColor(r, g, b, a)
end

When I run it, I expect to see 255, 255, 255, 255 all the time (or whatever the colour is currently set to, but the numbers should remain the same). Instead, every frame getColor or setColor seems to subtract 1 from r, g, b and a, until they all reach 0.

Does everyone get this same behaviour or is it computer dependent? Am I overlooking something?

I looked at the source code and all I can find is this.

Code: Select all

Color Graphics::getColor()
{
	float c[4];
	glGetFloatv(GL_CURRENT_COLOR, c);

	Color t;
	t.r = (unsigned char)(255.0f*c[0]);
	t.g = (unsigned char)(255.0f*c[1]);
	t.b = (unsigned char)(255.0f*c[2]);
	t.a = (unsigned char)(255.0f*c[3]);

	return t;
}

If glGetFloatv doesn't return 1.0f but something like 0.9999f instead, it would explain the behaviour I see, but it seems unlikely to me that this is the case.

[Saegor]

not this kind of problem for me

i tried on linux mint, it stay at 255, 255, 255, 255

[William Willing]

That would mean that it works differently on different computers. That's unfortunate, but thanks for testing.

I was a bit surprised, actually, that no-one else had reported the same problem (not that I could find, anyway). I'd expect using getColor and setColor to be a common way to save and restore the color state of love.graphics. Is it really something specific to my machine (Windows 7, GeForce GTX 550 Ti)? Or could something else be causing this?

[Jasoco]

No problem here on OS X. Let's relaunch Windows 7 again...

Nope. No problem over here. (Running Windows 7 in Parallels on my MacBook Air)

My graphics card is an integrated Intel HD 4000.

[William Willing]

Okay, so I just dug up my old laptop and tested it there: no problems. It seems to be something specific to my current machine. Strange. Anyway, thanks Jasoco and Saegor for testing.

If anyone of you ever gets a bug report from one of your players that stuff seems to fade out for no reason, they may have the same problem I have. :-)

[Nixola]

I've got a similar problem here, it subtracts 2 each time, Windows 7 x64, Nvidia Geforce GTX 560 Ti

[Uhfgood]

While I've never actually experienced this problem itself, you might want to check between 64bit and 32bit versions of love. Some were complaining it faded to gray on the 64bit version, but worked fine on the 32 bit version.

[William Willing]

it subtracts 2 each time

That rules out rounding errors, then.

Also, calling getColor and setColor multiple times per frame doesn't make the rgba-values decrease any faster, which seems to suggest that the problem isn't in those functions themselves.

Although I haven't found the cause of the problem yet, I wrote a little workaround. Just run this script before anything else and I believe it should fix the problem.

Code: Select all

love.graphics.setColor(255, 255, 255, 255)
local test = love.graphics.getColor()

if test < 255 then
	local f = love.graphics.getColor

	love.graphics.getColor = function()
		local difference = 255 - test
		local r, g, b, a = f()
		return r + difference, g + difference, b + difference, a + difference
	end
end

[Uhfgood]

does this little workaround work for any color you get and set, or is it limited to 255, 255, 255, 255 ?

And if I put it in my source (where get color acts as it should) is it going to screw anything up for me (that does not have the problem) because If I can use it for any color, then I might put it in my source so that people that play my love file don't get that fading gray screen or whatever

[Nixola]

It works because it gets the error, if it's 0 it applies no corrections