Why does this grid stutter

I'm making an agar.io clone and I want to render a grid in the background, here's the code:

X = -(CAMERAX MOD 50)
DIST = 50*(400/CAMERAW)
WHILE X <= CAMERAW
    GLINE X, 0, X, 240, RGB(200,200,200)
    X = X+DIST
WEND

Y = -(CAMERAY MOD 50)
DIST = 50*(240/CAMERAH)
WHILE Y <= CAMERAH
    GLINE 0, Y, 400, Y, RGB(200,200,200)
    Y = Y+DIST
WEND

The grid stutters when the camera moves, why?

First of all, I see you are using MOD. IMHO, the only sensible output for MOD where the second operand is a positive value N is a value between 0 (inclusive) and N (exclusive). Many programming language designers, including SmileBasic, are not sensible in this way, when the first operand is negative. So, test your code under the circumstance that the first operand is negative, or write your code so that it never is. Second, you seem to be confusing in-game coordinates with on-screen coordinates... or something. Your vertical lines go from Y value 0 to Y value 240, but for your horizontal lines the value of the variable Y only goes as high as CAMERAH. If that's not an outright bug, it's a clear indicator that you've got two concepts mixed up and crossing each other in ways they shouldn't. So, I'd recommend you take a step back. Be sure you know the semantics of each value - whether in-game coordinates of the game world, coordinates of the camera, coordinates on the screen, any other types of value you use... and make sure the relationships between the values are all clear, the calculations to go from one set of coordinates to another are all correct, and you're not using a number with one type of semantics in a context that requires a different type of number.

The issue is not your code. Your code is perfect, and using MOD was a very impressive choice. The "stutter" must be because you aren't giving your program any pause each frame (VSYNC). But I pushed your idea further and made a more elegant approach using a FOR loop instead of WHILE, and combining them together (but it does the same thing as your code). Here it is: And a screenshot of what it looks like: You were going to have to calculate I and J eventually, so I added that in as well. There doesn't seem to be any flickering, from my observation, everything goes smoothly.

The issue is not your code.

Yeah, actually there is an issue with the code, as I pointed out. Try using 200 for CAMERAW, and there aren't enough lines drawn on the screen... and the scrolling is jerky, not because of a lack of VSYNC, but because the MOD isn't operating on the right numbers. Try using, say, 600, and many calls to GLINE are totally off the screen... and the scrolling is jerky.

Ohhh, got it, I didnt try changing the width and height Changing the width and height to something less than the screen dimensions will appear "glitchy" but thats just because its only drawing what it needs to, since you're telling it that the screen is smaller than it really is. But for bigger screens, I didnt consider non-square cells Okay well, that issue is easy to fix Change the 50 (CMX MOD 50) TO (CMX MOD DX) Then it will support rectangles as well as squares Does that help?

(CMX MOD 50) to (CMX MOD DX)

and the corresponding change for Y does help, yes. But, since MOD converts its operands to integers, there are still some artefacts visible when scrolling slowly for some 'zoom' levels. And it still does not address the issue of too few lines being drawn if CMW or CMH is smaller than the relevant number of pixels, or needless offscreen lines being drawn if they are greater. Rather than patching together shortcuts to piecemeal address some issues, and partially, the last paragraph of my first post on this page "take a step back" is really the best advice I can give for resolving this issue properly and fully.