I'm new to PICO-8, and my first experiment was to create a simple program that moves a rectangle back and forth. When I run it, the movement will be fairly smooth at first, but then I start to notice a sort of hitching every couple of seconds. I tried this both on my desktop and laptop, and see the same behavior on both computers.

Is this something with my code, my eyes, or PICO-8 itself?

I'm running this on Windows by the way.

Here is the code I'm trying:

x = 109
xs = -1

function _update()
  x = x + xs
  if x < 0 or x > 110 then
     xs = xs * -1
    end
end

function _draw()
  cls()
  rectfill(x,0,x+15,30,12)
end

First off, @kaneda23, _update() and _draw() are 2-different functions and it's difficult for beginning coders, including myself, to get them to run in perfect synchronization.

Your best bet is to put all the drawing in _update() and not even mess with _draw(). Try out this code to see if it is any smoother:

x = 109
xs = -1

function _update()
  cls()
  rectfill(x,0,x+15,30,12)
  x = x + xs
  if x < 0 or x > 110 then
     xs = xs * -1
  end
end

ooh, that's bizarre. I'm seeing it too -- nice find!

misc notes:

• the builtin fps monitor (ctrl-p) doesn't show any problems. it seems to get choppy for 1 second every 8 seconds, or possibly a little longer than that (on my machine). even weirder -- this 8-second timer doesn't reset when I reset the cart
• If I change _update to _update60, it seems to go away? hard to tell
• the issue is still present (maybe a bit worse) when I launch pico8 with pico8 -software_blit 1
• I have a backup of pico8 v0.2.1b saved; this behavior exists there too
• I can't get a recording of it -- the issue goes away if I use my screen recording software to capture the pico8 window
• what are these dots on the ctrl-p monitor? they disappear while my screen recorder is active, strange:

here's the modified cart I'm using:

x = 100
w = 16
dx = -1

function _update()
 x += dx
 if x<0 or x+w-1>127 then
  x -= dx
  dx *= -1
 end
end

function _draw()
 -- cls()
 for i=0,15 do
  local s=128\4
  local x,y=i%4,i\4
  rectfillwh(x*s,y*s,s,s,(x+y)%2+1)
 end

 -- player
 rectfillwh(x,30,w,60,12)

 -- 8 second color cycle:
 rectfillwh(0,120,128,8,8+time()%8)
end

function rectfillwh(x,y,w,h,...) rectfill(x,y,x+w-1,y+h-1,...) end

tested on 64-bit windows 7 and 64-bit manjaro linux

On Linux I don't perceive the issue. My monitor is at 60Hzs as I believe are most people.

@pancelor I always get the dots but they are in a different place in my window.

@dw817 I'm not sure the advise to skip _draw is something we should be telling people. It seems to me more important to understand the underlying "proper" way to do things first.

Are you using .edu or paid version?

To add another random bit of anecdata, I see this behavior whether or not I use your code with _update or _update60, and also whether or not I use _draw or put everything into _update using @dw817's code. I'm also on a Linux laptop with a 60Hz display. Pretty wild!

@dw817: Isn't lack of synchronization the entire point of having separate _draw and _update functions? If both can't be done in a single cycle, _draw is skipped so that _update still happens and logic processing isn't interrupted. I suppose if you're absolutely sure your draw operations won't slow down logic, then it might be okay. But since this is dependent on the user's system, it seems like a risk with no particular benefit.

Also, FWIW, I'm away from my main computer right now so tried this out on Education Edition. OP's original code works without stuttering, using both _update and _update60. With the draw code in _update there is major stuttering for a couple seconds, which then seems to disappear.

I only asked because a school provided/handmedown laptop, using chrome browser to run .edu ver sounds like a recipe for jank, figures it would be good to rule that out since op didn't give much info

I'm using the paid version. My desktop is a Ryzen 5 3600, and my laptop is a Core i5-1135G7, so I don't think there should be any issue with system power.

@dw817: I tested with moving the draw code to the update() function as you suggested, and it doesn't seem to change the behavior as far as I can tell.

@pancelor: I tried update60() instead of update(), and with the speed variable changed from 1 to 0.5 to adjust, it seems smoother. Or at least if there is judder, it's not as noticeable.

I've seen this too. Tested it:

• on a Linux laptop (Acer, older)
• on a Windows 11 laptop (Lenovo, new)
• in the -edu web version (Firefox, Linux and Windows)
• the original code and dw817's version
• with _update and _update_60
• fullscreen and windowed
• using software blitting

In every case there is some stuttering. It seems to me the sync with the screen refresh is just slightly off.