quad fills: bug? hardware issue?

[cag]

They say a picture is worth a thousand words:

sadness.

bugsy_scrn.png (27.18 KiB) Viewed 11641 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 408 times

[qubodup]

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

for me at least.

[cag]

That seems to point in the direction of a bug, since I've got the same results. Will look into it...
Thanks.

[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.

[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.

[rude]

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.

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.

Edit: mike posted while I wrote this post ... I thought phpBB3 had protection for this kind of thing.

[cag]

...I... honestly don't know how I missed that, having looked at the page at least 3 times. x_x

[mike]

Worry not, cag.. if it's there it's obviously not obvious enough.

[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.

[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.