GML Visual movement is smooth windowed but jittery in fullscreen unless I tab out/in?

[hdarren]

Does anybody know why that would be? In windowed mode the game camera movements are super smooth but in fullscreen mode the screen when moving looks jittery.

I'm drawing the application_surface myself as I use some screen shader effects. In fullscreen mode I've tried resizing the surface to an exact multiple of the game so the surface scaling should be pixel perfect just like in windowed mode. But I did check and in both windowed and fullscreen it is capable of showing sub-pixels so the movements should feel the same. I don't think I'm doing anything special with the camera, it just follows the player around using the camera_set_view_pos() function. I've tried playing around with the resolution and vsync but I just can't figure out the problem here.

//edit: Through testing I have discovered that whilst fullscreen if you tab out then tab back into the game then the movement becomes super smooth just like when it's windowed. Does anybody know why or how to automatically replicate it so the player doesn't have to tab?

 

[NightFrost]

Are you saying your camera/view setup is capable of moving between "pixels" on the upscaled surface? Because what normally happens on simple upscaled application surface is the view aligning to pixels. Say your base width is 480 pixels, and the camera x-position is 100. So the view fetches room content starting at position 100 and picks up 480 pixels. If your display is 1920, it means you then scale it up by a ratio of 4.0 and display it. If your view moves to right by one pixel, to x-position 101, the movement scales up to four pixels on the scaled up final result. Because fractional pixels do not exists, the view always reads from rounded integer position when creating the app surface content. The content getting scaled afterwards bears no relevance to this operation.

My solution to getting smooth movement when small pixel art game needs scaling up is to draw scaled up in the first place. I create app surface and camera that are of largest integer multiplier that fits the screen. For example a game with base width of 480px gets a multiplier of four on a 1920px wide screen. I save this value to a variable I call global.Scaling. Then everything gets scaled by this value. Instances set their xscale and yscale to this, movement speeds are multiplied by this, UI elements scale their base position by this, and so on. (I hypothesize that other pixelart games done with GMS that have smooth scrolling on all resolutions do something very similar.)

EDIT - tilemaps are an additonal headache because their draw cannot be scaled. I route their draw through a surface to be able to freely scale them up.

 

[TheouAegis]

Following up, when you say jittery, do you mean it's drastically jumping from left to right? Or do you mean it's going rapidly left right left right left right left right? I've heard people refer to both as jittery (even though for me jittery means the second one). If you are referring to the first one, then what nightfrost said should be enough. However, if it's the second one, then my question is are you sure you are actually getting proper sub-pixel rendering in windowed mode? Are you sure the sprites and everything else aren't getting a slight blur? For the same reasons that the first one would happen, I would expect the second one to show the same thing, where instead of moving, say, 2 pixels left and right over and over, what will be happening in windowed mode would be moving half pixels over and over, which is going to cause blurring. The line between motion blurring and monitor ghosting is narrow, and by the sounds of it what you should be experiencing in window mode is motion blur instead of monitor ghosting. Motion blur is not a good thing, as it can cause headaches and eye strain.

 

[NightFrost]

Good call, I assumed jitter referred to the phenomenon that emerges from directly scaling up pixel art by large factor, but it can mean other things too...

 

[hdarren]

By jittery I'm talking more that movement looks almost juddery. It's as if one step the camera moves 0.1, but then the next step 0.5. I've checked the code to see what the exact precise position of the camera is and it outputs exactly the same whether fullscreen or windowed.

I was taking screenshots to see if anything was wrong there but no the pixels are all full squares and no blurring.

I did notice however that tabbing out whilst fullscreen then tabbing back in solved the jittery problem and makes the movement as smooth as it is whilst windowed. I can't expect people to tab out/in though so I would like to figure out why tabbing out/in makes it look smooth and try and replicate that.

@NightFrost I recommend you look into cameras as it does all this for you when you use the surface_resize(application_surface) function if you are drawing it yourself. You don't need to be resetting every object's scaling and speeds. The camera system is capable of sub-pixel movements.

 

[robproctor83]

Try enabling vsync if its not already. Also, try disabling the borderless fullscreen option and see if that makes a difference. It might be something like when you first start it's in normal fullscreen but when you alt/tab it goes into borderless fullscreen or something like that. You should also open up the debug_overlay and the profiler and see if anything is out of place.

 

[hdarren]

Tried vysnc and the various display options, nothing seems to change things. Everything looks the same in the profiler when windowed, fullscreened, and then tabbing out/in to make fullscreen smooth. FPS on Steam says it's consistently at 60fps comparing the three modes.

 

[NightFrost]

The camera system is capable of sub-pixel movements.

It is? Because back in the day when I was checking out and testing view stuff, and I could only get pixel-aligned stuff out. That admittedly was what must be around three years ago by now, on 1.4, so I may esily have done some newbie mistake there. I'll have to check the project and see if something was wrong, I should still have my old 1.4 projects around.

 

[hdarren]

It is? Because back in the day when I was checking out and testing view stuff, and I could only get pixel-aligned stuff out. That admittedly was what must be around three years ago by now, on 1.4, so I may esily have done some newbie mistake there. I'll have to check the project and see if something was wrong, I should still have my old 1.4 projects around.

You're correct 1.4 cannot do it but GM2 has changed the view system to a camera system which has very smooth sub-pixel camera movements. It is a bit harder to set cameras up now but worth it.

 

[TheouAegis]

You're correct 1.4 cannot do it but GM2 has changed the view system to a camera system which has very smooth sub-pixel camera movements. It is a bit harder to set cameras up now but worth it.

Well, that opens up a whole other can of worms, but they still useful. So now everything is rendered at subpixels instead of just the instances. lol

 

[NightFrost]

You're correct 1.4 cannot do it but GM2 has changed the view system to a camera system which has very smooth sub-pixel camera movements. It is a bit harder to set cameras up now but worth it.

Aha, interesting. I had looked at various YYG posts regarding new GMS2 features but obviously not thoroughly enough as I had completely missed this. I did check my old 1.4 view tests project, and while it was spaghetti of code fragments and commented out pieces as I had looked at various features, amusingly enough it would have had the same pixel-aligning "problem" if brought to GMS2, as I was for whatever reason rounding the coordinates. (I created a simple camera test and verified this.) Well, at least I can get rid of several scaling scipts that most ingame visible instances are calling at create time to scale-ify themselves to display. Well not in existing projects, I won't fix what ain't broke, but in future ones.

 

[robproctor83]

Not trying to derail the thread but are you certain it has sub pixel movement? I'm using cameras with gms2 but it only moves in full pixels and I can't seem to find anything in Google about it. Maybe it's a setting or something?

Regarding the issue you are having, here are a few other thoughts. Try running the clean command in the IDE, I doubt it will fix anything but it's worth a shot. Also, maybe try making another base game with just the resolution aspect and see if it has the same problem. Another idea would be to remove a large chunk of your game and see if it fixes it, keep removing stuff until you find the culprit. If it's happening in a new game or you removed everything from your current game and it's still happening it could be computer related. Maybe try posting a video of the problem or an exe for us to test. Speaking of, try testing an exe and see if it makes a difference.

 

[Japster]

This is probably a daft one, but when developing TetraLogical, it would run *silky* smooth in a window, and jittery/chuggy in fullscreen. I tried LOADS of stuff, checked room_speed etc, nothing worked...

...then I realised I was connecting my monitor via 'DVI', and it's a 2K monitor. Turned out the game switching into full screen native resolution was dropping the signal down to 30hz refresh - nothing at all to do with my game!

I switched to HDMI with a decent cable, and BOOM! - problem solved... I'd never really noticed it was in 30Hz on the desktop, as I'd mainly only ran Windows in 2560x1440, and GMS2 etc, and my games in 1920x1080....

It did explain why Just Cause 3 seemed to also only be running at 30FPS max at full 2K res, and why turning V-Sync off didn't make it any smoother....