[Solved - Graphics Driver Bug] Weird Canvas Issue

[BOT-Brad]

So I am porting my football project over to 0.10.0, and I have come across a bizare issue.

I have a gamestate system which draws to a canvas. This drawing works fine and everything appears correctly, however when I attempt to clear the canvas (no longer using canvas:clear(), but love.graphics.clear(...)), it will not actually clear the currently active canvas, and you get that weird sort of constant draw effect when Windows used to freeze a bit with a modal dialog box when you dragged it around.

Now initially I thought this was some weird bug with my code, but I have found that adding the following line of code before actually drawing the canvas to the screen fixes the issue;

Code: Select all

love.graphics.print("HELLO!",0,0)

And the issue no longer happens. What on earth is going on? Here is my love.draw code. Note that g.gfx is simply an alias for love.graphics

Code: Select all

function love.draw()
	-- Draw to game canvas
	g.gfx.setCanvas(g.game_canvas)
	g.gfx.clear(50, 150, 100, 255)
	-- BEGIN DRAWING HERE
	g.gfx.setColor(255, 255, 255, 255)
	g.state.draw()
	-- END DRAWING HERE
	-- Set canvas
	g.gfx.setCanvas()
	-- Draw game canvas
	g.gfx.setColor(255, 255, 255, 255)
	g.gfx.print("HI",0,0) -- Add this to stop the canvas from never clearing?!?!?1?!?
	g.gfx.draw(g.game_canvas)
end

Not even sure where to begin with this bug.

EDIT: OK, I am really confused. If I switch my state.draw code to drawing directly without using any canvases, everything works fine. As soon as I start using canvases like before everything goes weird. Has the way canvases work and are used changed a lot in 0.10.0 or something?

[BOT-Brad]

OK, pretty sure something with love.graphics.clear(...) is dodgy.

replacing this;

Code: Select all

love.graphics.setCanvas(g.game_canvas)
love.graphics.clear(0, 0, 0, 255)

with this;

Code: Select all

love.graphics.setCanvas(g.game_canvas)
love.graphics.setColor(0, 0, 0, 255); love.graphics.rectangle("fill", 0, 0, width, height)

Fixes the issue and everything works as it should.

[s-ol]

OK, pretty sure something with love.graphics.clear(...) is dodgy.

replacing this;

Code: Select all

love.graphics.setCanvas(g.game_canvas)
love.graphics.clear(0, 0, 0, 255)

with this;

Code: Select all

love.graphics.setCanvas(g.game_canvas)
love.graphics.setColor(0, 0, 0, 255); love.graphics.rectangle("fill", 0, 0, width, height)

Fixes the issue and everything works as it should.

Hm, I think I experienced something similar in a tiny demo I was working on but I just blamed it on being too tired. The project was basically just two Canvas getting cleared and some primitives being drawn and I was really confused over the things that happened when I changed the order of independent things around. I'll investigate again when I get home, could very well be that lg.clear() is dodgy. If you have the time you could try finding the commit that caused this on bitbucket or by bisecting even.

[slime]

love.graphics.clear is essentially a direct call into OpenGL. It calls glClear, which clears the active render target(s) to the specified color. Also keep in mind that [wiki]love.graphics.setScissor[/wiki] affects the area in the active Canvas that is cleared.

If it's not working properly it may be a driver bug. What graphics card, operating system, and driver version do you have?

This 0.10.0 code:

Code: Select all

canvas = love.graphics.newCanvas()

function love.draw()
    love.graphics.setCanvas(canvas)
    love.graphics.clear(0, 255, 0)
    love.graphics.setCanvas()
    love.graphics.draw(canvas, 0, 0)
end

Should be roughly equivalent to this 0.9.2 code (calling canvas:clear in 0.9.2 while the canvas is already active just calls glClear – or a newer function if OpenGL 3 is supported):

Code: Select all

canvas = love.graphics.newCanvas()

function love.draw()
    love.graphics.setCanvas(canvas)
    canvas:clear(0, 255, 0)
    love.graphics.setCanvas()
    love.graphics.draw(canvas, 0, 0)
end

Do they both behave the same for you?

[BOT-Brad]

They do indeed both behave the same, however maybe I am misunderstanding how canvas:clear (or graphics.clear in 0.10.0) works.

In love 0.10.0, I would expect the following code to randomly show a new colour every frame.

Code: Select all

canvas = love.graphics.newCanvas()

function love.draw()
	love.graphics.setCanvas(canvas)
	love.graphics.clear(love.math.random(255), love.math.random(255), love.math.random(255))
	love.graphics.setCanvas()
	love.graphics.draw(canvas, 0, 0)
end

Yet it only ever sets the colour once (randomly), then never seems to actually clear the canvas ever again unless I add pretty much any graphics.* command to the canvas (such as graphics.print, graphics.circle, graphics.polygon, etc.) and then it will randomly cycle through the colours as expected.

Also, if I draw to the canvas in a one-time function after the first time the canvas is cleared (on the first time love.draw is called), then the graphics I drew to the canvas remain there and despite love.draw running 60 times a second (with vsync on), the graphics remain there and love.graphics.clear has no effect on the active canvas (again, unless I draw something else to it).

EDIT: As for specs of my PC (I haven't tested this on my laptop or another PC yet, will do that shortly).

GPU: Radeon 6850 HD (Link -> http://www.amd.com/en-us/products/graph ... /6000/6850)
OS: Windows 7 Ultimate 64-bit
Driver Version: Sorry, the driver version of what exactly?

[s-ol]

They do indeed both behave the same, however maybe I am misunderstanding how canvas:clear (or graphics.clear in 0.10.0) works.

In love 0.10.0, I would expect the following code to randomly show a new colour every frame.

Code: Select all

canvas = love.graphics.newCanvas()

function love.draw()
	love.graphics.setCanvas(canvas)
	love.graphics.clear(love.math.random(255), love.math.random(255), love.math.random(255))
	love.graphics.setCanvas()
	love.graphics.draw(canvas, 0, 0)
end

this produces a different color every frame on my Intel integrated GPU. Just tried to reproduce my problems with a simple script but I couldn't, so it probably is my fault there - looks like this is your driver I suppose?

[slime]

In love 0.10.0, I would expect the following code to randomly show a new colour every frame.

Yeah, it should (and it does for me on my system).

Can you also test it in 0.9.2? Like:

Code: Select all

canvas = love.graphics.newCanvas()

function love.draw()
	love.graphics.setCanvas(canvas)
	canvas:clear(love.math.random(255), love.math.random(255), love.math.random(255))
	love.graphics.setCanvas()
	love.graphics.draw(canvas, 0, 0)
end

GPU: Radeon 6850 HD (Link -> http://www.amd.com/en-us/products/graph ... /6000/6850)
OS: Windows 7 Ultimate 64-bit
Driver Version: Sorry, the driver version of what exactly?

Video driver version. I forget where exactly you can find it – it's probably in Catalyst Control Center.

[BOT-Brad]

Yes, in 0.9.2 the same thing happens, just a single colour and then nothing. I am glad it seems to be an issue on my machine then. Here are all the version mumbo-jumbo from CCC.

Packaging Version: 12.104-130328a-157485C-ATI
2D Version: 8.01.01.1295
D3D Version: 9.14.10.0969
OpenGL Version: 6.14.10.12217

I will try and update my graphics drivers now, as it seems they were last updated in 2013, whoops.

EDIT:

Updated my drivers, they are all now apparently the latest versions.

Packaging Version: 15.20.1062.1004-150803a1-187669C
2D Version: 8.01.01.1500
D3D Version: 9.14.10.01128
OpenGL Version: 6.14.10.13399
Mantle Version: 9.1.10.0077

CCC Version: 2015.0804.21.41908

Will restart my PC and let you know how I get on.

[BOT-Brad]

Hmm, nope, still just pauses on the single first randomly generated colour.

EDIT: I am stumped, I actually just got the 0.9.2 version of the code to work by running it in the 64-bit version of LOVE and everything changes colour every frame, however the 0.10.0 version still does not work either in the 32-bit of 64-bit versions.

[slime]

I was testing in Mac OS X before - after booting into Windows it seems my AMD Radeon 6750m has the same graphics driver bug.

It happens for me regardless of whether I use 64 bit or 32 bit versions of 0.9.2 or 0.10.0 though.