From my point of view everything that the code pre disposes works perfectly, I feel like a neanderthal for not understanding how each thing works and fits together, and for sure many questions, but if I could ask one, I would love you to make a complete video about all the possible types of problems with shaking in the movement of the sprite (in any direction), I see that there are several problems on this topic of gamemaker 2 and it really surprises me how much I need to research to go deep into it, so that’s it, note 10 for your code and thank you very much for offering it, and sorry for my horrible english.
First, people using the built in "object following" camera in the room. That camera is locked to whole numbers only. So if you have a higher resolution application surface and your character moves in non-whole numbers, then the character will move a fraction of the pixel, and then the camera will later jump when they reach a whole different pixel; creating jitter
But even with a custom camera it's possible for jitter to be introduced because of the nature of floating point math and rendering on the GPU. If the camera is in a specific place and the object is in a specific place, it's possible for it to render a sprite one pixel shifted just because of floating point math. And this can change rapidly with very small changes in the position of either object. To combat that, I use a script that makes sure that the position of the view is rounded to the nearest multiple of the application surface ratio. So if your view is 100x100 and your app surface is 400x400 I make sure the view position is always a multiple of .25; And you can use the same concept for drawing sprites (though I've never needed to do that. Typically it's enough just to fix the camera)
I’m a bit of a layman, but gee, it’s crazy to think that just the difference in resolution can affect the camera’s interaction with the object in question so much, just by reading your comment I’m already going to be careful when tinkering with the camera, both to add effects and to adjust it definitively, well, thanks for the reply and for posting such a lifesaver, a lot of people have trouble at first dealing with these mathematical formulas applied directly without knowing how it works in practice, I myself broke my head for days before discovering that point_direction and point_distance is related to Pythagoras, finally thank you very much for this, if you created a course entirely on gamemaker studio I would buy haha, I hope you succeed with your crazy plans.
← Return to script
Comments
Log in with itch.io to leave a comment.
From my point of view everything that the code pre disposes works perfectly, I feel like a neanderthal for not understanding how each thing works and fits together, and for sure many questions, but if I could ask one, I would love you to make a complete video about all the possible types of problems with shaking in the movement of the sprite (in any direction), I see that there are several problems on this topic of gamemaker 2 and it really surprises me how much I need to research to go deep into it, so that’s it, note 10 for your code and thank you very much for offering it, and sorry for my horrible english.
Most jittering comes from camera related issues.
First, people using the built in "object following" camera in the room. That camera is locked to whole numbers only. So if you have a higher resolution application surface and your character moves in non-whole numbers, then the character will move a fraction of the pixel, and then the camera will later jump when they reach a whole different pixel; creating jitter
But even with a custom camera it's possible for jitter to be introduced because of the nature of floating point math and rendering on the GPU. If the camera is in a specific place and the object is in a specific place, it's possible for it to render a sprite one pixel shifted just because of floating point math. And this can change rapidly with very small changes in the position of either object. To combat that, I use a script that makes sure that the position of the view is rounded to the nearest multiple of the application surface ratio. So if your view is 100x100 and your app surface is 400x400 I make sure the view position is always a multiple of .25; And you can use the same concept for drawing sprites (though I've never needed to do that. Typically it's enough just to fix the camera)
I’m a bit of a layman, but gee, it’s crazy to think that just the difference in resolution can affect the camera’s interaction with the object in question so much, just by reading your comment I’m already going to be careful when tinkering with the camera, both to add effects and to adjust it definitively, well, thanks for the reply and for posting such a lifesaver, a lot of people have trouble at first dealing with these mathematical formulas applied directly without knowing how it works in practice, I myself broke my head for days before discovering that point_direction and point_distance is related to Pythagoras, finally thank you very much for this, if you created a course entirely on gamemaker studio I would buy haha, I hope you succeed with your crazy plans.