Log In  

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
P#125144 2023-02-01 23:43

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
P#125146 2023-02-02 02:57

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

P#125169 2023-02-02 13:50 ( Edited 2023-03-28 06:02)
1

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.

P#125171 2023-02-02 13:56 ( Edited 2023-02-02 15:36)

Are you using .edu or paid version?

P#125174 2023-02-02 14:25

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!

P#125178 2023-02-02 14:59
2

@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.

P#125181 2023-02-02 15:38

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

P#125187 2023-02-02 16:47 ( Edited 2023-02-02 16:54)

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.

P#125206 2023-02-02 23:24
1

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.

P#127236 2023-03-16 18:23

[Please log in to post a comment]

Follow Lexaloffle:          
Generated 2024-03-29 04:44:27 | 0.043s | Q:28