love.graphics.draw are the x and y floats ? is floor needed ?

[gcmartijn]

H!

I first need to understand what all x and y positions need to be when drawing/translating/scaling, before I can debug a 'glitch' problem.
At the moment I have a two simple images (head and a body), that are moving using vector movement.
Sometimes I can see a 1px y offset during the walking movement.

But I was thinking, what do videocard/love2d/os want ?

I did read that some people do use a love.graphics.draw(img,quad,math.floor(x),math.floor(y)) and for the scaling operation.
But is this needed, and better (to support most devices, for example) ?

If I do use floor then I have many more glitches, but I can fix that if I know what to use.

So the main question is: to floor or not to floor (for draw/translate/scaling)?

And the bonus question is, what does a image drawing do with this:

Code: Select all

love.graphics.draw(
        self.image,
        self:getQuad(),
        1.2312321321323,
        4.3423432423432
    )

In photoshop for example a pixel is never a float/double.

Thanks!

[EmmaGees]

If you don't use math.ceil or math.floor on the stuff you draw then you will have weird jittering when moving the camera and sprites around. Displays can't actually draw anything at exactly something like "2.5, 2.7" so that's why you get weird results when not rounding it up or down

[gcmartijn]

Oke, so now I'm going to floor all draw functions.

But what about the translate and transform actions ?
Do I need to floor them ?

Are there other function that I need to know, where I need to use floor from now on ?

[zorg]

As far as i know, photoshop gives you a discrete 2D plane with the width and height in pixels you can edit neatly.
Löve uses OpenGL, which gives you a 3D space wherein you have a 2D window into it where you can draw stuff.

You don't necessarily need to floor/ceil/round/truncate your values since the video card can handle floating point coordinates, the worst thing that happens is that you'll have the color of your pixel be distributed to more adjacent pixels on screen.

If you don't want that, and want pixel-accurate drawing, then either just flooring, or doing math.floor(x+.5) could work (also for the y value) - the difference is whether one needs to compensate for drawing to "the top left" or "the center" of a pixel; one will look bad, the other won't (and i can't remember which is which)
Same applies to translating, although you can get rid of the +.5 mentioned above if you just translate globally by .5,.5
Also for scaling, since any non-whole number will introduce rounding issues as well, when drawing something.
Rotation would be limited to 0,90,180,270 degrees (the function itself needs radians instead of degrees, there are conversion functions lua gives you) due to the same reasons.
Skew, if you want pixel-accurate, you don't use skew.

[gcmartijn]

Thanks for the info.

I want pixel accurate because I'm going to bind multiple moving drawing images together, in combination with old school graphics.
So I'm already using.

Code: Select all

love.graphics.setDefaultFilter("nearest", "nearest")
love.graphics.setLineStyle("rough")

[EmmaGees]

Oke, so now I'm going to floor all draw functions.

But what about the translate and transform actions ?
Do I need to floor them ?

Are there other function that I need to know, where I need to use floor from now on ?

You should definitely floor translate functions (for the best result) or ceil if you are using that on your draw functions, but scaling depends on what you're going for, that's a whole different conversation in my opinion as that's got disadvantages with some types of scaling. I used math.ceil on my scaling function in my last game but it also cut off parts of the scene which isn't ideal, but it looked much nicer.

[pgimeno]

If the pixels of your image correspond to the pixels of the screen, using floor() will fix a glitch where, if a certain row of column of pixels has coordinates near 0.5, sometimes they are rounded down and sometimes up, causing inconsistent pixels to be shown.

If they don't, and your image's pixels are not an exact multiple of the screen's pixels, or otherwise sufficiently bigger, you may get aliasing, and float coordinates will cause rounding to be applied to the float positions, sometimes up, sometimes down, depending on the decimals of the float.

That's all assuming a filter of nearest, nearest (which is the one you've said you were using). With the other filter, the image pixels are interpolated and the float coordinates make even more sense.

[Karai17]

Anything involving pixel coordinates needs to be floored.