Moving sprite is jitter.

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
pgimeno
Party member
Posts: 3544
Joined: Sun Oct 18, 2015 2:58 pm

Re: Moving sprite is jitter.

Post by pgimeno »

ddabrahim wrote: Sun Sep 18, 2022 9:07 am It is printed steady 0.16-0.17 ms occasionally drop as low as 0.001 the moment the jitter happens.
According to the video, rather that a lag spike, which would cause two identical frames, what is seen is a skipped frame. This matches the 0.001 ms of frame time that you're getting. It's like one of the frames is being processed much faster than the actual monitor frame, and rather than waiting for the monitor frame to finish, it is processed right after the previous one finishes.

This could still be a software driver bug, but I think that it's more likely that it is a hardware problem. The vertical sync interrupt signal may be glitching, or taking too long. It could be due to bad contact of the connector, a loose solder, noise, a faulty component, a design flaw, or even a malfunction in your motherboard's clock, who knows.

See if it helps to place this line at the top of love.update:

Code: Select all

love.timer.sleep(0.005)

ddabrahim wrote: Sun Sep 18, 2022 9:07 am Wondering if my Antivirus could interfere or something else.
Maybe, but I'd say it's not likely. It would produce lag spikes instead of skipped frames. It's the first thing I thought before watching the video. Anyway, you can try to disable it and see if that changes anything.

ddabrahim wrote: Sun Sep 18, 2022 9:07 am
pgimeno wrote:better placed out of the function, so that you only have one metatable for all objects instead of a distinct metatable for each. And similarly, you don't need to have a distinct draw function for every object; it can be placed out of the constructor and assigned inside, so that all objects share the same function.
Thank you for the suggestion. I am actually trying to avoid inheritance and DRY practice intentionally this time because this is where usually spaghetti code begins which always doing me headache to debug after. I have started my project from scratch because of this. I know it is not practical but my brain is simply not capable to see through inherited code implemented at multiple levels across multiple files. But once I get more comfortable with OOP in Lua I'll consider it.
I'm not suggesting to split it into different files or anything. What I'm suggesting is this:

Code: Select all

local candy = {}
local candy_mt = {__index = candy}

local function candy_draw(self)
    love.graphics.draw(self.image,self.x,self.y,0,self.scale,self.scale)
end

candy.new = function(_image, _x, _y)
    local t = {}
    setmetatable(t, candy_mt)

    t.image = _image
    t.x = _x or 0
    t.y = _y or 0
    t.scale = 0.5

    t.draw = candy_draw

    return t
end

return candy
I don't think that complicates the code that much.

ddabrahim wrote: Sun Sep 18, 2022 9:07 am So in case it is remain a mystery why is it happening to me, does anyone know about "Sub pixel rendering"? Someone on the forum has mentioned it is solved jitter but I have no idea how to even begin. I mean love.draw render everything, how can I even manipulate that?
Sub-pixel rendering means to use the floating-point coordinates for drawing instead of flooring them. This can look smoother but it can also look blurrier. Anyway it seems to me that your code is already doing this, and that's clearly not helping.
User avatar
ddabrahim
Party member
Posts: 182
Joined: Mon May 17, 2021 8:05 pm
Contact:

Re: Moving sprite is jitter.

Post by ddabrahim »

pgimeno wrote:See if it helps to place this line at the top of love.update:
Unfortunately it didn't help :(
pgimeno wrote:I think that it's more likely that it is a hardware problem. The vertical sync interrupt signal may be glitching, or taking too long. It could be due to bad contact of the connector, a loose solder, noise, a faulty component, a design flaw, or even a malfunction in your motherboard's clock, who knows.
Well, Mac computers are famous for being horrible gaming machines and I can confirm that OpenGL powered games runs horrible on this thing. Design flaw sounds about right combined with poor drivers maybe. I can only hope it is not a faulty component :P
pgimeno wrote:I'm not suggesting to split it into different files or anything. What I'm suggesting is this:
I don't think that complicates the code that much.
No it is not but in my actual project I have many more object types not just candies with lots of properties and methods. So if I were doing this, guess it would be more organised to split in to files so other objects can also inherit the same common properties and methods. But if I was going down on this road, I would begin to split everything in to files then my brain going to melt when something doesn't work.
I can never get it right and always end up with spaghetti.

There are certain aspects I like about OOP like the constructors, properties, methods but I think functional programming fit my brain much better so I am trying a mix of the two now and I am just glad Lua allow me to do that.

Anyway thanks a lot for all the suggestions and help. Guess for now I write it down as hardware/software problem with my computer and continue as is. Maybe the new Vulkan renderer going to improve it. Vulkan and Metal powered games usually runs fine on this thing. Hope it going to help.
Post Reply

Who is online

Users browsing this forum: No registered users and 42 guests