Only drawing every nth draw cycles

[ianfitz]

Hi All,

I am finally getting my hands dirty with Löve so can I just like, pre-emptively apologize for all the posts I will be making asking for questions over weeks and months to come?

TLDR: How do you sidescroll at a fast rate without things getting all blurry/hard to see?

Okay, I am trying to scroll a background left/right, when I do so it tends to "blur" if I set it at a fast enough speed. With such a fast frame rate, that totally makes sense, but for reference see OurTeamSmoothScroll.love to see what I mean. Try hitting left/right arrows, and the spectators faces with quickly blur as you scroll.

OurTeamSmoothScroll.love

(103.08 KiB) Downloaded 134 times

For my approach to solving this, I add a counter and step to the scroll table. The counter is incremented every update loop iteration, and the step variable is the max ceiling this counter should reach.

Only when the counter equals the step variable is the x value of the background being scrolled change. So the effect is the background is sort of scrolled in "chunks" or "steps".

This looks way better visually, sort of a chunky old school aesthetic that I"m going for. Def. no blurring.

OurTeamStepScroll.love

(51.98 KiB) Downloaded 147 times

Is this a sane/standard way of doing things, or is there some way easier way to not draw every frame, that I am missing?

Also here are gists of the two love files for your convenience:

https://gist.github.com/ianfitzpatrick/ ... c4e1d5b0ac
https://gist.github.com/ianfitzpatrick/ ... 9a18e57290

Thanks!

Edit: Originally had the wrong inline link for smooth scroll. Clarified a few other things too.

[Positive07]

You are not using delta time at all which is the most practical way to get smooth movement out of this kind of things.

Something like stated on this thread

I could be mistaken though, I haven't tried your examples that much

[ianfitz]

You are not using delta time at all which is the most practical way to get smooth movement out of this kind of things.

Something like stated on this thread

Okay, just tried it out following the code I saw in that thread with the following changes:

https://gist.github.com/ianfitzpatrick/ ... 0cbd7552af

Diff:

https://gist.github.com/ianfitzpatrick/ ... 247f1c5f14

But it still exhibits the blurry scrolling behavior shown in OurTeamSmoothScroll.love.

Also one thing that might be confusing, I originally had the wrong inline link to the love file for the "smooth scrolling" example that exhibits this blurry problem. That's now fixed.

[Positive07]

Well I now see your issue! You did it really well on the step example, I was just recommending that you use dt so that it looks the same regardless of the FPS count.

I would do this by time:

Code: Select all

love.update = function (dt)
   if love.keyboard.isDown("right", "d") then
      t = (t or 0) + dt
   end

   while t > 0.5 do
      x = x + 32
      t = t - 0.5
   end
end

Or something like that, this would move two times in a second, with 32 pixels increment, regardless of the FPS.

I'm not sure if this is what you want or how you would like it, but it's what I could understand, also you should take the advice that "if it works then it's right" so if what you have works, leave it! Optimization is the root of all evil, and premature optimization is evilness itself, so don't try to optimize too much

[ianfitz]

Code: Select all

love.update = function (dt)
   if love.keyboard.isDown("right", "d") then
      t = (t or 0) + dt
   end

   while t > 0.5 do
      x = x + 32
      t = t - 0.5
   end
end

Making the method not seemed dependent on FPS seems smart to me. I'll try this out tomorrow and report back.

, also you should take the advice that "if it works then it's right" so if what you have works, leave it! Optimization is the root of all evil, and premature optimization is evilness itself, so don't try to optimize too much

Ha truth. I mostly just want to make sure I wasn't missing something super obvious or built into the library. Thanks for taking a look!

[Positive07]

Glad I could help! And don't doubt on asking anyway, people in these forums is SUPER LÖVELY!
Would like to hear back from you if this works

Cheers

[ianfitz]

Cool, I tested your approach and it works equally as well as my stepped approach visually, but the code is much cleaner the way you have done it, and easier to reason too.

Attaching a reduced case (you can only hit right arrow key and scroll right, no bounds checking) for posterity.

OurTeamSimpleSmoothScroll.love

(51.83 KiB) Downloaded 120 times

Also here is gist as well.

https://gist.github.com/ianfitzpatrick/ ... 8569d6ce9b

Thanks again!

[ianfitz]

Hmmm, actually even though I have the code working I do have a question about that while loop. Just for my own learning.

Code: Select all

function love.update(dt)
    if love.keyboard.isDown("right", "d") then
      t = (t or 0) + dt

	   while t > 0.1 do
	      bg.x = bg.x - 64
	      t = t - 0.1
	   end
    end
end

If the while loop here used in essentially the same way an if/then block would be?

Code: Select all

function love.update(dt)
    if love.keyboard.isDown("right", "d") then
      t = (t or 0) + dt

	   if t > 0.1 then
	      bg.x = bg.x - 64
	      t = t - 0.1
	   end
    end
end

That code seems to work the same from what I can tell. Is this just a convention/clarity thing, or is there any difference?

[Positive07]

Yes! Exactly the same, but what would happen if dt was 1 second for example (because computer is crappy or whatever)?

In the while loop the block would suddenly move what would have moved if FPS where lower. In the case of the if, after the second passes the block would have moved only 64 pixels, and t wouldn't have been reseted to 0 again

The while loop makes sure that you get the same behaviour regardless of FPS, so you can't cheat by somehow changing the FPS