The front layers move at 1 pixel per frame and those in the background are slower.
Those that go to 1 are smooth, those that go to 0.5 are smooth, but if I lower the speed at which the objects move more, you can see that they stumble from pixel to pixel.
I know the “round” option and I have it disabled.
Is there any way for the background layers to move slowly but smoothly (I don’t care about pixel perfect)? I’ve already tried scaling the sprites to a higher resolution, zooming the camera and all that, but I think they are patches to the problem. The question is, am I doing something wrong or with this resolution is normal behavior and there is no way to solve it if it is not by increasing resolution?
This is normal how pixels behave at lower resolutions. You can set your project’s resolution to something like 1920x1080 which is 3x scaled 640x360. And you can use camera zoom set to 3 on your layers.
This should give you more pixels and makes the pixels move smoother.
First of all it would be much better to change the position of the cameras, rather than each object individually. Then you only need to calculate one position per layer.
To avoid warping you could Round() the resulting positions. Or to do it in a simple arithmetic way, use tickers and only update the position of a layer when needed.
This will update layer 1 every frame, layer 2 every other frame, and layer 3 every 4 frames. There’s no need to calculate anything else as you will just be moving the layers by 1 pixel each time.
I take note of using tickers to check only when necessary, that would make it more efficient, but I don’t know if I haven’t understood something, would this solve the problem that slow sprites look at blows? My problem is not for processor load, it’s for using a low resolution.
Yes, doing it this way will prevent any warping or tearing because it is always changing the position by 1 whole pixel at a time.
Your previous method was introducing tearing because the real positions are floating-point accuracy, which the renderer has to then “fit” into the available grid of pixels.
So to avoid that we need to either store a separate value for the real position versus the rounded position (i.e. 12.00357 is the real position, 12 is the pixel position), OR just make sure you only add whole pixels to positions.
Sorry to insist, but in the tests I have done, if I code to advance 0.5px for each frame, it looks slower but smoother. The problem Is with 0.2px or 0.25px for example. In the case of 0.5px it shouldn’t it look bad because I’m using decimals?
(In any case I’m restructuring the project to move the layers instead of the sprites separately)
I think what’s happening is that the renderer is hitting rounding error differently based on the offset. Or in other words, when it processes 0.5 the resulting pixels all end up rounded in the same direction. But on 0.2 some of the pixels are pushed one way while the others are pushed the other way? I’m slightly guessing here…
But to clarify, in my case the problem is not sprites that seem to dance and do not finish choosing position looking like rubber, what I try to avoid (if possible) is that they do not move from pixel to pixel, but using intermediate pixels or subpixels to make it smoother.
I can solve it by raising the resolution to 1080 and zooming in, but I wanted to see if it could be done without using that trick.
base_resolution is the actual resolution of the game. base_render_scale is the scale at which I would like my resolution to increase. This also allows me to have like, basically, different resolution for different layers. So, if the game is 640x480, I can have UI that’s double the resolution, and I just zoom out.
You do need to change the camera’s position to (height or width)/(2 * base_render_scale) to get the camera’s position to what you see in editor.
I think the reason why it works in godot is because you can have multiple viewports (different layers rendered at different resolutions)
The current versions of pixijs (the GD5 renderer) don’t seem to support this as far as I can find, although I’d love to be incorrect if anyone more versed in it than me can chime in.
Those are both results of the same root problem. If you keep the camera position as well as the object positions all on whole-number coordinates, then both of those effects should be nullified.
On the other hand if there are any coordinates with a decimal, then the renderer will have to start making decisions about where to draw. By avoiding any sub-pixel coordinates you prevent the renderer from making those decisions.
The zoom method should be used when you want your assets to be at a lower resolution than the actual rendering of the game. But, it is not always desirable if you want a true low-res style, because while the sprites will be chunky, their positioning will be more accurate. Also any effects will be processed at the higher resolution as well.
Exactly, many tell me to use the method of increasing the resolution, but you have to keep in mind that it also involves greater processing with the effects, for example.
Yeah, it does increase the CPU load, although I was more referring to the visual aspect. For example an outline effect will create the outline at the higher resolution, not matching with your assets. In some cases you can mitigate this using the “pixelate” effect at the end of an effect chain, but not always.
