quad fills: bug? hardware issue?

Questions about the LÖVE API, installing LÖVE and other support related questions go here.
Forum rules
Before you make a thread asking for help, read this.
User avatar
cag
Citizen
Posts: 65
Joined: Sun Jun 29, 2008 5:09 am

quad fills: bug? hardware issue?

Post by cag »

They say a picture is worth a thousand words:
sadness.
sadness.
bugsy_scrn.png (27.18 KiB) Viewed 12209 times
But this image will probably just confuse you. Anyways, this is the situation: I've got a few lines of code that tells the graphics engine to draw a filled quad at a place. For some reason, it works sometimes and fails miserably at other times. I should know, since I've changed those lines to draw outlined quads instead.
I've a wild guess/hunch that after some amount of color changes or something after the graphics are reset, the filled quads stop working for some mysterious reason, maybe due to some internal hardware or what-have-you limitation opengl has or something (crystal clear, I know).

Anyways, that's the situation on my setup. Maybe it doesn't screw up in other OS's or hardware setups or whatever. I've up'd a copy of the original love file before I changed it to outlines, which I would love to have checked. This is quite strange. I will perhaps later isolate the test case to find out for sure...

If you'd be interested in checking this out and comparing screens:
lovetris.love
original
(40 KiB) Downloaded 467 times
User avatar
qubodup
Inner party member
Posts: 775
Joined: Sat Jun 21, 2008 9:21 pm
Location: Berlin, Germany
Contact:

Re: quad fills: bug? hardware issue?

Post by qubodup »

the falling ones are always empty, the fallen down ones are always full.

for me at least.
lg.newImage("cat.png") -- made possible by lg = love.graphics
-- Don't force fullscreen (it frustrates those who want to try your game real quick) -- Develop for 1280x720 (so people can make HD videos)
User avatar
cag
Citizen
Posts: 65
Joined: Sun Jun 29, 2008 5:09 am

Re: quad fills: bug? hardware issue?

Post by cag »

That seems to point in the direction of a bug, since I've got the same results. Will look into it...
Thanks.
User avatar
cag
Citizen
Posts: 65
Joined: Sun Jun 29, 2008 5:09 am

Re: quad fills: bug? hardware issue?

Post by cag »

OK, so I figured this one out.

Apparently, polygons have to be described in a CCW fashion or things like filled polys will break. Horribly. I remember this has something to do with CCW oriented hit testing to be more efficient in rendering systems, but the point is that either Love needs to change (which would probably be a hackey and unpleasant change as it involves digging into OpenGL's guts), or the preferred note in the documentation to put things in counterclockwiseness.
User avatar
mike
Administrator
Posts: 364
Joined: Mon Feb 04, 2008 5:24 pm

Re: quad fills: bug? hardware issue?

Post by mike »

I do recall having mentioned the counter-clockwise issue at least 3 times in the documentation and once in a tutorial, if I recall correctly. The problem is that I usually don't recall correctly so I could be horribly wrong. I'll look into it.
Now posting IN STEREO (where available)
User avatar
rude
Administrator
Posts: 1052
Joined: Mon Feb 04, 2008 3:58 pm
Location: Oslo, Norway

Re: quad fills: bug? hardware issue?

Post by rude »

cag wrote:Apparently, polygons have to be described in a CCW fashion or things like filled polys will break.
This is because you have to draw them in counter-clockwise order to get the front face facing you. Otherwise you'll be looking at the back face.
cag wrote:which would probably be a hackey and unpleasant change as it involves digging into OpenGL's guts
It's possible to enable drawing of back faces (easily), but not without a significant performance penalty, so it's not worth it.

So that's not going to happen, but we could provide a function which removes the problem in the rectangle-case:

Code: Select all

love.graphics.rectangle( mode, x, y, width, height )
Users of love.graphics.quad will still have to RTFM or suffer. Hmm ... you gave me an idea for an improvement in the manual. :3

Edit: mike posted while I wrote this post ... I thought phpBB3 had protection for this kind of thing.
User avatar
cag
Citizen
Posts: 65
Joined: Sun Jun 29, 2008 5:09 am

Re: quad fills: bug? hardware issue?

Post by cag »

...I... honestly don't know how I missed that, having looked at the page at least 3 times. x_x
User avatar
mike
Administrator
Posts: 364
Joined: Mon Feb 04, 2008 5:24 pm

Re: quad fills: bug? hardware issue?

Post by mike »

Worry not, cag.. if it's there it's obviously not obvious enough.
Now posting IN STEREO (where available)
User avatar
qubodup
Inner party member
Posts: 775
Joined: Sat Jun 21, 2008 9:21 pm
Location: Berlin, Germany
Contact:

Re: quad fills: bug? hardware issue?

Post by qubodup »

LÖVE was created to be a user-friendly engine in which simple (or complicated) games could be made without having extensive knowledge of system or graphics functions and without having to dedicate time towards developing the same engine features time and time again.
I'm sorry if this comes like a "love you!" or a loving finger. And actually: Not being experienced makes me stand in a bad position to claim that there is a problem with how quads are drawn.

So please you, who have experience: review whether "you have to draw it ccw" conflicts with the engine's philosophy.

I can imagine two cases: the player draws shapes or shapes in the game are evolving in unpredictably (regarding this ccw-thing) manner.

These are probably exceptions.
lg.newImage("cat.png") -- made possible by lg = love.graphics
-- Don't force fullscreen (it frustrates those who want to try your game real quick) -- Develop for 1280x720 (so people can make HD videos)
User avatar
cag
Citizen
Posts: 65
Joined: Sun Jun 29, 2008 5:09 am

Re: quad fills: bug? hardware issue?

Post by cag »

I suppose that sort of thing is inevitable... I mean, love does use hardware stuff for graphics rendering. However, it's marked "extensive," and having to order points counterclockwise shouldn't be considered part of extensive graphics knowledge, but moreso a rule one just has to trust. Maybe.

As for shapes evolving ingame, I highly doubt morphing shapes would/should change the direction the points describing the shape is ordered in. Rotation wouldn't, and most basic shape drawing shouldn't... and if one is coding a game that dynamically changes the shapes of things in the game, then chances are that the project is ambitious enough to the point the programmer should have a bit more knowledge.
Post Reply

Who is online

Users browsing this forum: Bing [Bot] and 5 guests