Textured Polygons for All!

[Ref]

I'm running the Love 0.9.0 build:
Boolsheet-love_winbin-3a210b37dc82

[Jasoco]

Here is an OS X build from today: https://dl.dropboxusercontent.com/u/421 ... sx-pre.zip
Nearly every existing love game won't work with 0.9.0 without some function call name changes, partly because the window functions in love.graphics got moved to love.window yesterday.

There are still some issues with Geometries that may or may not be solved by the time 0.9.0 is released: in order to support concave polygons, it performs polygon triangulation internally to convert the polygon into individual triangles, but as a result the color and texture coordinate interpolation might not always behave as expected.

I had to comment some lines in order to get the example from before working. So how do I apply an image to this? Can I apply an image to it? All I see so far is gradients. Warping images to odd shapes is what I'm really interested in. Especially if it's slightly faster than this library which is sadly a bit of a speed bottleneck. But it works great for now.

[slime]

So how do I apply an image to this? Can I apply an image to it? All I see so far is gradients.

The tables in the table given as an argument to love.graphics.newGeometry require at least x,y position coordinates and u,v texture coordinates. The position coordinates are where the corners (vertices) are drawn, and the uv texture coordinates are what part of the drawn image is at that corner. Position coordinates are in pixels, and uv coordinates are a number in the range of [0..1] (or more, if you want wrapping).

For example, a standard boring 100x100 quad can be created like this (although love.graphics.newQuad still exists, to make this particular case simpler):

Code: Select all

function love.load()
    image = love.graphics.newImage("foo.png")

    local geominfo = {
        {0, 0, 0, 0}, -- x, y, u, v
        {100, 0, 1, 0},
        {100, 100, 1, 1},
        {0, 100, 0, 1},
    }

    geom = love.graphics.newGeometry(geominfo)
end

function love.draw()
    love.graphics.drawg(image, geom, 0, 0)
end

In that example the u,v texture coordinates in each vertex match what you'd expect from a normal quad, but they don't have to - and the position coordinates don't have to either. Or you could add more vertices, or remove one to make it a triangle.

Currently Geometries can be concave, but as I mentioned earlier that's causing some problems, so it might be limited to convex polygons by the time 0.9.0 is released (although you can draw multiple convex Geometries to create what looks like a concave textured shape.)

EDIT: Convex-only as of today.

[Jasoco]

Does the current version of 0.9.0 use LuaJIT or just regular Lua?

[Ref]

Does the current version of 0.9.0 use LuaJIT or just regular Lua?

Good question.
Was under the impression that it would use LuaJIT.
Anyone know?
Jasoco, have you had any luck with Geometry & images.
Seems to be working for me.
Be interested to see what you have so far.

[slime]

Right now it uses standard Lua 5.1, but I believe the plan is to switch to LuaJIT by default before release.

[Jasoco]

Ref, your example also still love.graphics.setMode incorrectly. And it uses setCaption which also doesn't work the way it used to. I don't know how they work for you, but over here it just errors.

I'm still not sure how to use this. Like at all.

If I have a set of coordinates, say the following:

Code: Select all

100, 100,
250, 130,
325, 320,
80, 290

And this image:

Framed2.png (3.19 KiB) Viewed 5388 times

How would I make it look exactly like this: (The image on the right, with the point coordinates represented by the polygon on the left.)

Screen Shot 2013-05-13 at 3.47.19 AM.png (49.3 KiB) Viewed 5388 times

[bartbes]

Code: Select all

100, 100,
250, 130,
325, 320,
80, 290

If we want to drawn it from the top-left corner, the geometry will be made from something like..

Code: Select all

{
    {0, 0, 0, 0},
    {150, 30, 1, 0},
    {225, 220, 1, 1},
    {-20, 190, 0, 1},
}

Ref, your example also still love.graphics.setMode incorrectly. And it uses setCaption which also doesn't work the way it used to. I don't know how they work for you, but over here it just errors.

Those changes were made just yesterday, or the day before, I believe, so he probably has an older version.

[Jasoco]

Code: Select all

100, 100,
250, 130,
325, 320,
80, 290

If we want to drawn it from the top-left corner, the geometry will be made from something like..

Code: Select all

{
    {0, 0, 0, 0},
    {150, 30, 1, 0},
    {225, 220, 1, 1},
    {-20, 190, 0, 1},
}

It works! Awesome. Can't wait for it to be integrated with LuaJIT so I can do some real tests. I'm hoping this is faster than the PixelEffect version. I'll do some benchmarking later comparing the speed of this library with the official Geometry in the current 0.9.0. Really wish 0.9.0 was done. If it had LuaJIT right now I'd start porting my project and use it for prototyping right now.

Ref, your example also still love.graphics.setMode incorrectly. And it uses setCaption which also doesn't work the way it used to. I don't know how they work for you, but over here it just errors.

Those changes were made just yesterday, or the day before, I believe, so he probably has an older version.

Makes sense.

[slime]

Code: Select all

100, 100,
250, 130,
325, 320,
80, 290

If we want to drawn it from the top-left corner, the geometry will be made from something like..

Code: Select all

{
    {0, 0, 0, 0},
    {150, 30, 1, 0},
    {225, 220, 1, 1},
    {-20, 190, 0, 1},
}

That example will have visual problems due to the lack of perspective-correct interpolation (because there is no real z-coordinate or 'perspective'.)

9c5kqdm.png (14.38 KiB) Viewed 709 times

I somewhat corrected for it manually (in that particular image's case with those particular coordinates, at least):

Code: Select all

{95, 95, 0.5, 0.5},
{0, 0, 0, 0},
{150, 30, 1, 0},
{225, 220, 1, 1},
{-20, 190, 0, 1},
{0, 0, 0, 0}

DbFPccN.png (12.58 KiB) Viewed 709 times

You could probably do some trickery with hijacking the per-vertex color values to be a pseudo-z coordinate when used with a custom vertex shader that also has a custom perspective projection matrix, in order to get around the interpolation issues (it would probably be a less hack-ish way of doing 3D compared to straight Geometries, once you set it all up.) I am not sure whether you'd need a real depth buffer or not to do that, however.