Pixel perfect games in Godot

[fractalcounty]

Describe the project you are working on

A low-res 2D platformer with a high-res UI, smooth camera movement, and zoom.

Describe the problem or limitation you are having in your project

In 3.0x+, the common method for making pixel perfect games with a high resolution UI was fairly straightforward. You would toggle the 2D stretch mode, set your project resolution to something like 1920 x 1080, and throw your game inside a viewport node at a desired base resolution (such as 640 x 360). If you wanted take it a step further and implement a smooth camera, a common solution was to use a framebuffer shader with custom camera logic. Although a bit cumbersome, it did the trick well enough.

In 4.0, it's no longer this simple. Implementing a high-res UI with a low-res game is doable, but every known method for smooth camera movement I could find no longer works as effectively in 4.0. Additionally, 4.0 introduces even more factors that impact how pixels are displayed in 4.0, each creating dozens of different combinations that produce vastly different, loosely documented, and often undesirable effects. While not all specific to 4.0, here are some factors I can think of:

• Viewport stretch settings in project settings, also may cause sprites to render incorrectly when combined with subviewports as seen with #61301
• Viewport and window override resolution in project settings
• "Resize" toggle in project settings (may contribute to pixel distortion as per #62869)
• Size and Size 2D override in SubViewport inspector
• "Snap 2D Transforms to Pixel" and "Snap 2D Vertices to Pixel" in project settings, which introduces jitter as per #71074 as well as #63185, blur as shown in #66527, as well as undesirable scaling and rotation behavior as seen with #60443
• "Snap 2D Transforms to Pixel" and "Snap 2D Vertices to Pixel" in the SubViewport node inspector, which may induce blurring with movement #66527 and rotation #57221
• Texture filtering options for sprites as well as subviewports
• The “centered” toggle for objects, especially sprites with odd dimensions
• Editor grid pixel snap (which still occasionally places objects at non-integer positions)
• Camera node smoothing options (seems to always introduce jitter to some degree)
• Camera and player movement (ensuring that position is rounded to an integer, or vice versa)
• Calculating camera or player movement in _physics_process vs _process, see #71226
• Collision shapes being offset at subpixel values at runtime
• Physics interpolation (not implemented in 4.0)
• The position of the game window (causes unpredictable sprite bleed as shown in #67164?)
• Usage of integer scaling (not a feature in the engine, here's a community made option.)
  • Production edit: Integer scaling is available since Godot 4.2

To me, this is a painful amount of variables to deal with for such a common use case. I have tried every combination of these options alongside upscaling shaders, pixel buffers, custom camera smoothing, viewport textures, and more. The resulting process is a maddening game of cat-and-mouse in which you're constantly balancing jitter, blur, and sprite distortion while never quite eliminating one or the other.

This is the closest I was able to get before throwing in the towel. I achieved smooth camera movement on the sides of the screen, but it introduces pixel distortion. Enabling pixel/vertices snap gets rid of the pixel distortion, but introduces blur on everything. I'm not sure which is worse, so I just avoided using it.

2023-03-01.20-40-03.mp4

Describe the feature / enhancement and how it helps to overcome the problem or limitation

The exact solution to this problem is complicated, as it is most likely a complex combination of intentional engine design, user error, and lack of documentation. However, I think a few things would help in this regard.

Before mentioning any in-engine solutions, it's worth mentioning that a detailed and precise collection in the docs outlining the best practices for pixel perfect games, especially in regards to smooth camera movement or zoom, would help a great deal without needing to touch the engine itself. It wouldn't fix the inherent issue of complexity here, but combined with some sort of "hybrid pixel perfect" starting template, it would be a decent remedy.

In terms of in-engine solutions, a few preexisting proposals such as integrated integer scaling would help alleviate this problem to some degree. However, I think a "PixelCamera2D" node or something similar designed specifically for this common use case would be wildly beneficial.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

An example would be a camera node called "PixelCamera2D" that would allow functionality for sub-pixel perfect smooth scrolling in 2D games. This concept isn't new or particularly complicated, and this write up by Daniel Ludwig is a perfect starting point for how it could be implemented. In essence, it would just be a standard camera with extended framebuffer capabilities that would be used for low-res subviewports. The issue with this approach is that it isn't perfect (especially with parallax) and doesn't sufficiently mitigate jitter or distortion in 4.0+ for some reason.

An alternate approach may be necessary that avoids using a pixel buffer entirely that utilizes the core engine to achieve smooth camera movement in some other way. This goes well beyond my scope, but definitely worth looking into.

If this enhancement will not be used often, can it be worked around with a few lines of script?

I imagine it would be used very frequently, at least by indie developers who work with pixel art a lot. It could very easily optionally just not be used.

Is there a reason why this should be core and not an add-on in the asset library?

Normally just implementing that method on a per-project basis or as an addon would be more than sufficient, but as previously mentioned, things have changed quite a bit. Here's a few reasons why I believe this should be a core feature:

• Pixel perfect games (and ones with smooth camera movement by extension) are an absurdly common use case and having that functionality available out of the box would be a game changer for quality of life
• Godot 4.0 introduces a plethora of new changes and modifications to the render server that makes dealing with this issue unreasonably cumbersome as a user, let alone anybody working with the core engine.
• This is a frustrating issue that I imagine many users will have to deal with, and I'm not sure it will ever be completely addressed through an addon any time soon (especially if it needs to be addressed through additions to the core engine)

[fractalcounty]

Little update for anyone stumbling upon this via search engines: Reddit user /u/golddotasksquestions provided an excellent step by step write-up on how to combine low res UI with low-res games using viewports in 4.0.

As you can see, the process is pretty janky and unintuitive by Godot standards- especially for such a common practice in indie games. It's also worth mentioning that this probably won't help with smooth camera movement or alleviating jitter unless you're willing to implement a cocktail of features on top of it such as physics interpolation, custom camera logic, as well as a pixel buffer. I've tried everything I could find so far and haven't had much luck, but your mileage may vary.

My biggest concern about this whole process is the amount of new users that are going to inevitably google something as basic as "how to set up pixel perfect smooth camera in godot 4" and be faced with 3 or 4 results consisting of wildly different workarounds that don't even work anymore. For that, I think this is a pretty crucial usability issue that needs to be addressed in some shape or form.

[Calinou]

Can you upload the project that was used to create the video somewhere? This could be useful to try to make it work correctly.

Also, was the video recorded with integer window scaling (or a sharp bilinear shader applied on a SubViewport)?

[fractalcounty]

Also, was the video recorded with integer window scaling (or a sharp bilinear shader applied on a SubViewport)?

Working on cleaning up the project now. The video was recorded with manual integer window scaling; aka setting the project resolution to 1920x1080, setting the subviewport size to 640x360, and setting the subviewport scale to 3x. Bypassing the subviewport scale entirely and using the built in editor scaling in the settings achieves the same effect.

[bitbrain]

The current workaround with sub viewport is not optimal, as the editor only displays content in the bounding box of the sub viewport and it is not possible to drag & drop nodes into the scene. Having a large scene (e.g. TileMap) is very difficult to edit/deal with on a pixel perfect setup. The workaround is to navigate to the scene inside the SubViewport directly and edit the level from there (needs to be its own scene file). Especially for larger games this process is painful.

PixelPerfectCamera2D hopefully addresses that issue, just like Camera2D from an editor perspective, so the scene itself is still editable/fully viewable.

[HybridEidolon]

This issue encompasses far more individual issues than what the title suggests.

The viewport-upscaled-to-screen technique still works just fine in Godot 4.0, for both 3D and 2D, so this convention is untouched.

For @bitbrain's problem, this is easily solved by a runtime Autoload script which arranges the SceneTree to handle your viewport setup, so that it's not part of your scenes at all. You'd want autoloads in a larger project that needs to manage game state in a consistent way anyway (think scene transitions, persistent state across scenes, networking, etc). I usually set up a global autoloaded state machine that bootstraps the selected play-in-editor scene into itself to manage the game while still being able to start from a specific scene, 2D or otherwise.

The "smooth 2D camera" technique is actually fairly specific to very small viewport resolutions and the specifics of how it's implemented could practically vary between games (custom camera solutions?). I'm not sure if I would want such an effect for something that is mimicking a real retro console. This specific method only applies to a particular subcategory of a category of 2D games and thus I don't think it makes sense to have it as a core feature.

For coordinate snapping, I use this script in addition to the vertex snapping option, and it mostly works fine. In combination with Nearest filtering, you will get about 90% of the way there. Counterintuitively, you do not want to snap the Camera2D's coordinates when using this approach, otherwise you will get the jittering seen in those issues because the rounding directions across different items will not always match.

extends Node2D

class_name PixelSnapped

# usage: make this node the parent of a CanvasItem you want snapped to worldspace integer boundaries
# only apply this to purely visual node hierarchies

func _process(delta: float) -> void:
    var parent = get_parent()
    if parent == null:
        return
    position.x = round(parent.global_position.x) - parent.global_position.x
    position.y = round(parent.global_position.y) - parent.global_position.y

The editor failing to snap to integer coordinates in some scenarios is definitely a bug. If you need to, you can write tests in your game's test framework to verify that scenes have no nodes on subpixel coordinates, which will catch any project member's mistakes too.

I can't imagine how having collision shapes snap to pixels would work. Not even retro console games did this; they often used fixed point arithmetic ("subpixels") when integrating physics, but didn't allow static objects to exist at subpixel coordinates. Changing this would require a completely different physics model. A given project might want that, but I don't think this makes sense as a core feature.

The problem with sprite texture filtering exists regardless of engine. In Godot 4 you can set the default filtering to Nearest No-Repeat to alleviate this, but you're still ultimately on the hook to ensure your materials have the proper filtering settings. Once again, since Godot is general purpose, there are things you are ultimately responsible for deciding how to accomplish.

Overall I feel the story here is that Godot is a flexible engine serving a lot of interests and there is no one-size-fits-all option when it comes to rendering in 2D (IMO there never has been, but Godot comes closer than any other option I've seen). This is a problem that existed before 4 and will continue to exist forever. Asking it to serve a specific niche like this introduces a lot of unnecessary complexity to the core.

[bitbrain]

@HybridEidolon a GDExtension providing a PixelPerfectCamera2D node can always be an alternative, in case it is a too specific use case for Godot itself. However, I am not sure if the Godot C++ API allows for that (yet).

Asking it to serve a specific niche like this

I would not call this problem niche, considering how many pixel perfect games are out there. I have no quantifiable data to back this up, though.

EDIT @HybridEidolon a bit offtopic but could you share an example of how you implemented this?

I usually set up a global autoloaded state machine that bootstraps the selected play-in-editor scene into itself to manage the game while still being able to start from a specific scene, 2D or otherwise.

[fractalcounty]

@HybridEidolon I would like to clarify that the list I included in the post isn't a collection "changes the core engine needs" or "things that need to be fixed", it was just a list of factors that the end user has to battle with when approaching a common use case like this. Some of them may or may not be impacted by open issues, which is why I linked them as they only add to the complexity. This list has only grown since 3.x, which complicates things considerably.

The "smooth 2D camera" technique is actually fairly specific to very small viewport resolutions and the specifics of how it's implemented could practically vary between games

I mentioned this specific implementation because it covered a wide variety of use cases in 3.x, but is no longer as effective under identical conditions in 4.0. Like I said, it isn't perfect and is in no way a comprehensive solution. However, I did find success in tweaking it for a wide variety of different resolutions for what it's worth.

This specific method only applies to a particular subcategory of a category of 2D games and thus I don't think it makes sense to have it as a core feature.

I'm not suggesting that it specifically should be implemented into the engine as a core feature, it's just an example of one of many common techniques that previously worked. Whether or not it's a common use case ultimately comes down to opinion, but that still doesn't impact the issue of complexity that many will have to deal with.

In terms of the other suggestions you made such as using an autoloaded state machine to dynamically arrange and handle viewports or using a script to handle vertex snapping- I would personally argue that these are cumbersome workarounds that shouldn't be required in the first place. These aren't just practices for very specific and niche scenarios, these are practices that apply to pixel perfect games as a whole- which highlights the whole usability problem even more.

This is a problem that existed before 4 and will continue to exist forever. Asking it to serve a specific niche like this introduces a lot of unnecessary complexity to the core.

This isn't a matter of asking "I want Godot to implement a core engine feature that that fits the exact needs of my game". It's a specific example of usability that wasn't great to begin with that was worsened in 4.0. Adding complexity to the core is the opposite of what I'm suggesting- this is more about improving usability in general.

Additionally, it's not just the camera smoothing, it's that the Camera2D and viewport nodes are just flat out frustrating to work with in pixel perfect games. There's too many points of failures and long-standing "unsolvable" issues that have only worsened in 4.0. If these usability issues are inherent to the engine and will continue to exist forever, then a dedicated solution makes sense in my opinion. That goes beyond just having a smooth camera.

At the end of the day, the workflow for working with pixel perfect games is significantly more complicated in 4.0, and borderline unfeasible for more specific use cases like the one I initially described. The line between user error and unintended behavior is far too blurry at the moment, as issues with jitter seem to affect low-res games across the board to some degree.

I now realize that this problem likely goes beyond what I initially created this issue for. If I could guess, it's probably a cacophony of bugs, user error, and lack of documentation that all contribute to the same exceedingly complicated problem. However, I still think it's a crucial issue that needs to be addressed in some way.

[HybridEidolon]

I would not call this problem niche, considering how many pixel perfect games are out there.

Niche in the sense that it has very specific rendering requirements that don't gel well with any other "style", not necessarily in popularity. This has always been a difficult problem with modern rendering and will continue to be. Even moreso for super low-res art.

a bit offtopic but could you share an example of how you implemented this?

I don't have an example on hand, but the pieces you need are described in the documentation. The SceneTree's root node has 1 child node which is the "current scene" and then all of your configured Autoload child nodes when the game starts. You can then move the nodes around however you need them arranged at runtime and implement your own "change scene" functions to accommodate. In Godot 4, the SceneTree root node is a Window. It may help to open the remote scene tree debugger while the game is running to visualize how the root hierarchy is arranged.

In terms of the other suggestions you made such as using an autoloaded state machine to dynamically arrange and handle viewports or using a script to handle vertex snapping- I would personally argue that these are cumbersome workarounds that shouldn't be required in the first place.

The former is what makes Godot uniquely powerful compared to contemporaries and I disagree that it is a "workaround". No other engine I've seen gives you as much control over the runtime scene tree as Godot. Learning how these tools work makes Godot significantly more powerful than it initially appears. The current documentation is a little sparse, but it does point out this flexibility.

The latter is just one method of implementing what you need; you could perform the same logic by putting all your snapped visual nodes into a SceneTree group and iterating over them in an Autoload so you don't have to litter your scene configurations with these nodes. I would favor solutions that don't require specialized node setups if I was starting a project today, and Godot absolutely grants you the power to do that.

Additionally, it's not just the camera smoothing, it's that the Camera2D and viewport nodes are just flat out frustrating to work with in pixel perfect games.

While these tools require a deep understanding of Godot's scene model to work well for 2D pixel art, it is also a massive boon to the engine that they are individually simple and flexible and have relatively unsurprising behavior.

If these usability issues are inherent to the engine and will continue to exist forever, then a dedicated solution makes sense in my opinion.

They're inherent to any engine that uses real numbers, triangle rasterization and a scene graph to represent the rendered world. The linear algebra becomes less intuitive when you start needing to round numbers at specific points. There is inherent complexity introduced by being able to "attach" sprites to other sprites and apply linear transformations to compose the scene. You would experience these same sorts of issues in a hand-rolled engine if you were using hardware rendering too. In some ways 2D pixel art games are easier done with simple masked blitting against a framebuffer and a flat array of "objects" with update and draw callbacks (which I'll add, you absolutely can do in GDScript if you really wanted to).

I think the problems outlined here are ultimately solved by better learning material and a template to demonstrate how to do it correctly. It is absolutely possible to get Godot 4 to do 2D pixel art well without significant hurdles; I have not really experienced regressions relative to Godot 3 in this respect, even porting Godot 3 projects into 4. Maybe I could do a write-up on what is specifically needed and why certain issues occur when implementing it.

[fractalcounty]

I think the problems outlined here are ultimately solved by better learning material and a template to demonstrate how to do it correctly.

While I do completely agree with this, I still think the elephant in the room is the lost functionality from 4.0. It's not that making pixel perfect games are too hard, it's downright infeasible after a certain point as far as I can tell. There's just too many new issues that go far beyond this feature suggestion unfortunately.

[HybridEidolon]

Here is a project to serve as a test case: PixelPerfect.zip

1. A SubViewport is created at runtime and arranged inside a SubViewportContainer and AspectContainer. The current scene is added to the SubViewport. The pixel-perfect configuration is set up on the SubViewport instead of the project, which consists of a forced resolution and both snapping settings enabled. This subviewport is at 320x180 (matching 16:9 320-width). This is all handled by an Autoload.
2. None of the snapping settings are changed on the project itself.
3. level.tscn contains a simple 2d platformer with a parallax background. No special snapping scripts are attached.
4. A Label is added next to the AspectContainer to demonstrate full-viewport resolution rendering alongside the low-res sub viewport.
5. This project is running in GL Compatibility renderer but is identical between all 3 renderers.

Notably, no scripts are needed to snap transforms on pixel alignment. This is a departure from approaches I've used for Godot 3. Everything became a lot simpler when I stopped trying to hack in my own solution!

For the most part, the behavior of the snapping is exactly as desired. The only thing that isn't correct is when the player begins moving for the first time, there are noticeable rounding issues between the camera and the player sprite, but as soon as the player's Y changes, this disappears entirely. I think that is probably a rounding issue in the canvas renderer. As far as I'm aware, this is basically identical to Godot 3.5, except that Godot 4 also grants us the ability to control the snapping settings on the SubViewport node rather than the entire project, which is a pretty significant improvement.

Hopefully this can serve as a useful basis to implement the smooth scrolling behavior described above; the actual Camera transforms aren't affected by scripts, so their global positions can be used in a shader on top of the viewport texture.

[bitbrain]

@HybridEidolon great solution right there! However, I was wondering how we could achieve "smooth" camera movement with this (e.g. camera following the player smoothly, with everything still pixel-perfect but the camera itself is not stuttering). A great example is Celeste: https://youtu.be/qyOapJgLcEI?t=997 they have pixel-perfect viewport (all the pixels always align on the screen) but the camera is smooth.

I tried to do it with the example you attached but the camera stutters once I enable position smoothing.

[HybridEidolon]

You need to make sure your camera is updating at the same frequency as the physics (i.e. switch the camera process callback to Physics)

[malaVydra]

Thank you for the suggestion. However, this doesn't really achieve the desired result.
The camera still doesn't move smoothly like it does in the Celeste video shown above.
In order for camera to be smooth it would need to move by sub-pixel amount units.
This was easier to bypass by creating a Viewport with a shader that moves it on sub-pixel level while the camera loads normally.

However, although not the perfect solution, this was a lot easier to achieve in the earlier version, and I agree with everyone else here that this is something that would be really useful if made easier and more straight forward, as most of 2D indie games are pixel-art games.

[HybridEidolon]

The camera still doesn't move smoothly like it does in the Celeste video shown above.
In order for camera to be smooth it would need to move by sub-pixel amount units.

The camera is not on subpixel alignment in Celeste. The camera appears smooth because the resolution is relatively high and the camera is much more complex than the built-in smoothing option and doesn't directly lag behind the player in most situations.

This was easier to bypass by creating a Viewport with a shader that moves it on sub-pixel level while the camera loads normally. ... this was a lot easier to achieve in the earlier version

This is still possible and there are no regressions preventing this. All you need to do is apply a shader to a quad using the SubViewportTexture and displace it by its UVs, with the SubViewport being a few pixels larger than the target resolution. Same as Godot 3.

[lorenzo-arena]

All you need to do is apply a shader to a quad using the SubViewportTexture and displace it by its UVs, with the SubViewport being a few pixels larger than the target resolution. Same as Godot 3.

Did anyone manage to get this working?

[jordanlis]

Wow, I never thought that one of the most requested feature could be closed as "not planned" by the team...

Many people came up with very different needs, but at one point, the request remained simple to me : allowing the camera to be smooth like in the video and being able to move the camera at the level of "real pixels of the screen" like it was possible to do it with a complex mix of codes and nodes, but still not stable through the different realeases of godot.

I find very harsh to close it. Even if I understand the decision because of the conversation that was going nowere, I find it very controversial to close something so requested by the community, and to gather votes and then say to those many that have voted that they won't be heard.

I respect the choice, but this is hard to admit that maybe it will never be possible to have a really smooth camera in pixel perfect games due to this decision, although many people wants to make pixel art games with godot.

[h0lley]

If smooth jitter-free scrolling for pixel art games is indeed solvable with an extension of the Camera2D node or a script that does some magic with Viewport.canvas_transform, then ideally along with closing the related issues/proposals, we would be able to point people to such a script or entry in the AssetLib.

My understanding is that this proposal existed exactly because a GDScript solution was not possible, so I am quite curious of how it would look like. People just want their stuff to work - it doesn't have to be built-in, so if someone can show such a script I am sure all complaints would be quenched. :)

[markdibarry]

@jordanlis The proposal wasn't closed because it wasn't popular enough or the feature wasn't desired. It was because the proposal didn't propose a viable way to achieve the request, and most of the conversation was off-topic and not leading us any closer to it being solved. The suggestion was to create an all-in-one node, but the consensus was that it isn't currently feasible. The effect they're creating is very complex and the only example provided requires:

• Camera2D node with a custom script
• SubViewport with a custom script
• SubViewportContainer with a custom script
• custom shader
• a custom singleton script

I'm not sure how all of that would be possible in one node. Personally, I actually would love to see this as a possible feature or plugin, but no one has provided one or proposed a way to make one yet. If there is a viable proposal, I'd be happy to help work on it.

In the meantime, until a solution is devised, we've been talking about including documentation and examples for different pixel art setups, since this is widely misunderstood subject. I'd love to champion anyone who'd like to step up and make a tutorial or template for making this effect in 4.x.

[KeyboardDanni]

@jordanlis I feel that pixel perfect graphics in Godot is a solvable problem and I'd like to personally see it through, as this impacts me as well. At the same time, we need actionable items in order to make progress. If you can think of any specific issues, please feel free to mention them here so that we can track these efforts.

[JaythFactor]

When I first started following this topic, I was mostly interested in two improvements:

1. Sub-pixel jittering to be resolved.
2. Camera movement to move along the actual screen's pixel grid, as opposed to the game's pixel grid, allowing much smoother camera movement. Essentially detaching only the camera from the pixel-perfect concept.

As far as I can tell, with minimal work this can now be achieved in 4.3dev4 with results like so:

2024-03-07.16-16-49.mp4

Project from #84380

Note: The camera sprite looks like it jitters around only because the actual camera is following the sub-pixel position of the sprite and the sprite is snapping to the closest pixel for the render. Good camera smoothing example in the next video.

2024-03-07.16-21-39.mp4

Game project here.

Note: The box movement while it's being pushed here looks a little jittery because it moves on different frames than the player does, which can be resolved with proper pixel-perfect physics coding(I think).

The steps I took to make these changes in 4.3dev4:

1. Go into Project Settings->Rendering->2D and set Snap 2D Transforms to Pixel to true.
2. Now go to Project Settings->Display->Window.
3. Ensure that Window Width Override and Window Height Override are both set to 0, setting Viewport Width and Viewport Height to what the override values were if present. Also take note of the scaling factor that was being used. ex: if the override width and height were 1920x1080 and the viewport width and height were 640x360, then the scaling factor was 3. (1920/640 = 3)
4. Now, go to your Camera2D node and set it's zoom to the scaling factor you found. For my example, that would be the 3.
5. Also make sure you scale any CanvasLayers by the scaling factor as well, since they will now be drawn with the screen pixel grid, not game pixel grid.

And that's it. There are some caveats, like how lines and other primitive draw shapes will not be pixelated anymore, but I wasn't using those anyway, and you could probably give them a pixelated effect using shaders too.

I'm not sure if this will help anyone else or if it's what people want from the engine for their pixel-perfect games, but it works for what I want to do, so I thought I'd share.

[h0lley]

nice, thanks for sharing.
although for projects like mine where CanvasItem scaling is already used extensively throughout a large codebase with the assumption that the base scale is 1.0 it's... unfortunate to say the least.

[markdibarry]

For the most part a lot of the sub-pixel jittering problems are solved with the recent change from flooring to rounding. The only remaining issues are things like platforms and pushing boxes which is a different problem and not solvable without a custom script. This will be an issue with any two or more CanvasItems that you're trying to make appear to move as one in float space. The bright side is that it's pretty easy to make scripts for these scenarios. At least for moving platforms, CharacterBody2D does a lot of the heavy lifting for you with it's Moving Platform inspector section.

Another thing that only becomes more apparent when you get to much smaller screen size games, is the appearance of camera jitter from things moving on screen, but that's just a drawback of things being pixel perfect on a small screen. This is a lot more apparent when you try to use camera smoothing since it makes the space between pixels more obvious as it slows down. The other way to solve these scenarios is to, well, not have things pixel perfect like the Camera2D/SubViewport/Shader scrolling trick that started this discussion.

Documentation and examples would be great to have to explain all these different gotchas, since there's so many different ways to implement pixel games and what may be a desirable effect to some may be unacceptable to others.

[JaythFactor]

After tinkering a bit, I realized I made a mistake. I had originally said you need to scale all CanvasItems by the scaling factor, but I mistyped. I meant all CanvasLayers. If the CanvasItems are in the game space, then they don't need to be scaled using this setup.

Sorry for the mix up.

[oncoremarco]

I was able to use this to get things moving smoothly, but I've noticed that there doesn't seem to be any way to get smooth pixel movement working when using subviewports. With a scene set up like below:

You can set your real output screen size on the Control and SubViewportContainer, then on subviewport container set "Stretch" and "Stretch Shrink" to your scale factor (eg, a 1280 x 720 window is a 320 x 180 pixel viewport scaled up by 4 times.) Even with "Snap 2D Transforms" set on the SubViewport, you'll always get choppy motion when doing so.

It's important to be able to utilize subviewports because some games may require screen effects (like shaders) that can be applied through these viewports, or compositing UI to the screen with separate resolutions from the background. From everything I've tried though 4.3 doesn't seem to be able to support both crisp pixel perfect movement and the usage of subviewports.

[fractalcounty]

It was because the proposal didn't propose a viable way to achieve the request and most of the conversation was off-topic and not leading us any closer to it being solved.

I'm perfectly fine with this, as the point of the proposal was to spark a discussion about what could be done and to get more attention on an issue that was, admittedly, very difficult to effectively communicate or replicate.

The only thing I (now) disagree with is the idea that we're not any closer to it being solved. If #86837 is any indication to go by, there has been a great deal of progress on tackling this problem and pixel perfect workflows are as viable as they've ever been in 4.x. Awesome!

Despite all the bellyaching I've done in this thread, I can't say thank you enough to the core engine developers and contributors working on tackling this.

For anyone with specific & ongoing issues that are finding themselves here via Google, take a look at #86837 (not a place for discussion though)

[verbal-torment]

Been following this thread for a while. Really appreciate the work that you've all done. Unfortunately I'm still coming up short when trying to get pixel perfect movement. As far as I can tell, I have it down to 2 configurations which each produce the opposite problem:

Both Scenarios:

• Using 4.3dev6
• Pixel snapping is on
• Camera is attached to the player and has no smoothing
• Moving the player through the basic movement template

Config 1: Low Res + Stretch

• Resolution: low (320 x 180), scaled up
• Stretch: viewport, stretch, keep, integer

When moving, this produces a smooth character, but a jittery background:

low_res.mp4

Config 2: High Res + Zoom

• Resolution: high (1920 x 1080)
• Stretch: stretching disabled entirely
• Camera zooms in appropriately to scale

When moving, this produces a jittery character, but a smooth background:

high_res.mp4

I see some people seem to have gotten it working with, I think, either one of these 2 configurations. So I'm wondering what I could be missing. Hope this contribution is helpful.

[JaythFactor]

Either that or it's the snapping. Smooth camera movement doesn't mix with pixel snapping very well(the lower the resolution, the more noticeable it is). You'd have to find some way to snap the camera too and get a similar result to the first config, or you can make peace with not pixel snapping for the player specifically during movement, but then snapping their position to a pixel when they stop. That wouldn't be "pure" pixel-perfect, but you'll always get a little jerky movement in a "pure" pixel-perfect environment.

[JaythFactor]

I see good results for "pure" pixel-perfect projects when the player moves quickly and is very animated. Otherwise, the chunky by-pixel movement becomes very noticeable. For the "non-pure" approach you can also ditch the pixel snapping project option as I stated above, and make sure that all nodes stop at pixel-perfect positions, but allow sub-pixel movement when not at rest. Essentially a pixel-perfect environment not enforced by the engine or the renderer, but by you and how you setup the movement logic.

[JaythFactor]

You can also try not sticking the camera movement directly to player movement, but instead have it smoothly follow the player, like in the second video in my post above. That might make config 2 work.

[verbal-torment]

Appreciate the replies. I actually came to a similar conclusion, re: high res + manually snap when not moving. For now I'll try that. My goal is a pixel-snapped character, and a camera that moves freely but always ends its movement on a pixel. So no matter what, I think I have to do some manual snapping. I'll try some of this tomorrow and post the results

EDIT: Looking more through the tracker, I found this project: https://github.com/godotengine/godot/files/13244300/PixelPerfectTest.zip

This looks pixel-perfect to me, and its using low res configuration. Seems like the only difference is that they do all camera & players updates in _physics_process. I'll keep investigating

[KeyboardDanni]

Yep! I deliberately went with physics process for everything where possible so that all updates happen in lockstep. Otherwise if you have an object moving on physics step and camera moving smoothly on idle step (or vice versa) you'll get jitter from the updates not lining up.

But that's just one piece of the puzzle. The first video you posted is basically the same as the PixelPerfectTest. But I'm assuming you want a camera that can move across subpixels. Your second video appears to be snapping the graphics but since the camera isn't snapped, the character appears to wobble. Unless you smooth out the camera movement between positions, I don't think there's a good way to get the second method to look good. Edit: I'd also have it so the camera targets only whole pixels, so that when the character moves less than a pixel it won't also move the camera. But do have the camera tween between those whole pixels.

[jeffbdavenport]

There a two major issues in Godot that causes these issues. First one has been mentioned, which is the Position smoothing of Camera2D. This is because by default the smoothing happens outside of the Physics loop. You can resolve this issue by changing the Process Callback to "Physics" instead of "Idle" on the Camera2D node Inspector settings.

The second and biggest issue is pixel skewing that is caused by Transforms not being perfectly pixel snapped. So neither the Camera2D zoom, nor the Project Settings Dispaly>Window>Stretch features should be used at all or pixels will still skew. Then General>Rendering>Snap 2D Transforms to Pixel must be enabled. Then adjust the scale of the level's root node to the desired scale. You can set this scale dynamically based on the current window size if needed:

var saved_size := Vector2(0, 0)
var desired_height :=1440.0
@onready var root_node := get_parent()

func _process(_delta: float) -> void:
  var size = DisplayServer.window_get_size()
  if saved_size != size:
    saved_size = size
    root_node.scale = Vector2(size.y / desired_height, size.y / desired_height)

• Note, you will need to adjust other game values to be multiplied by this scale value as well (Such as speeds, gravity, velocities)

[KeyboardDanni]

I would avoid doing anything that would modify the physics simulation in any way. Having to change velocity scaling based on zoom level would mean that players would get different results based on the camera zoom (or even the size of the window), meaning that some players' machines might run into hard-to-find bugs (not to mention players could intentionally change the scale value in order to cheese sections of the game). It also means having to decorate too much of the code with scaling values which violates DRY (same problem with doing physics code in variable step and putting delta everywhere).

I think the best solution here would be to render the low-resolution "view" of the game world via custom viewport, scale this viewport to zoom the scene, and combine this with either viewport or canvas_items stretch mode on the root viewport depending on whether you want a more classic retro feel (game res is root viewport res) or something with HD graphics in the HUD like Celeste. I'll go ahead and make this my next area of focus and see if I can produce a good working demo.

[amorykiet]

Here is a project that i made a celeste-like minigame with godot 4.x. Hope this is good example for a low-res 2D platformer with a high-res UI, smooth camera movement.
https://amorykiet.itch.io/fansipan

[dude17943]

One issue that I've found is that even with "Snap 2D Transforms to Pixel," the character begins to jitter in an unacceptable way. I've seen it suggested here:
https://www.youtube.com/watch?v=ijGoJbz2zME
That rounding the object's position solves the issue - which is true to a point - but also removes all floating point calculations, meaning that objects below a certain speed threshold will never move at all due to having their speed rounded down.

[dude17943]

Does it work if you use SnapToPixel for setting the GlobalPosition? It seems like some speeds work better for floor while others need rounding.

I suspect a large part of this issue is the distance from the camera to the target whenever the two reach equilibrium in speed. For different target speeds, the camera will end up being different distances away from the target. Sometimes these distances cross over the half pixel threshold that results in jittering.

One idea is to try and snap the camera offset from the target to whole pixels once the target starts moving fast enough. For example, if the target is at (30.3, 50.3) and the camera is following behind it at (40.6, 50.7), we could try snapping it to (40.3, 50.3).

I'm not exactly sure how to handle the offset this way but I tried implementing the camera from #9256 (comment) using the following code:

		if (IsInstanceValid(Player))
		{
			AquireTarget();

			var offsetTarget = targetPosition + targetOffset;

			Vector2 newPos = Vector2.Zero;

			newPos.X = offsetTarget.X;
			newPos.Y = offsetTarget.Y;

			newPos = newPos + Vector2.One;

			var tempPosition = GlobalPosition;

			if (tempPosition.DistanceTo(newPos) > 0.5f)
			{
				tempPosition = tempPosition.Lerp(newPos, lerpWeight * (float)delta);
			}
			else
			{
				tempPosition = newPos;
			}

			GlobalPosition = tempPosition;

			var subPixel = new Vector2(GlobalPosition.Round().X - GlobalPosition.X, GlobalPosition.Round().Y - GlobalPosition.Y);
			
			if (subPixel.Length() < 0.1)
			{
				subPixel = Vector2.Zero;
			}
		}

But unfortunately that also gave me jitter. I'm trying to document all my steps in hopes that someone else doesn't waste their time going down the same rabbit holes I do.

[Renari]

Does anyone try PhantomCamera in this case?

I tried using phantom camera and had massive stuttering so swapped by to my custom solution which is moving the camera in the physics update.

[dude17943]

I -THINK- I may have come to a satisfactory conclusion by

• Changing the Camera's "Priority" and "Physics Priority" to default
• Physics Interpolation is OFF, Physics Jitter Fix is at default setting of 0.5
• Snap 2D Transforms to Pixel is ON

Then move the camera in both the _Process AND _PhysicsProcess methods.

EDIT:
Nevermind, introducing any kind of camera smoothing breaks this method as well.

Below is every camera I've tried commented out. You should be able to swap between them to test them out, but none of them work. I do feel like the fact that nobody's been able to come up with a satisfactory solution to this issue in over a year should indicate to the dev team that there's an issue to be addressed here.

using Godot;
using System;
using System.Threading;

public partial class GameCamera : Camera2D
{

	[Export]
	public float lerpWeight = 0.1f;
	public Node2D Player;
	public Vector2 targetPosition;

	//subpixel position
	public Vector2 RealGlobalPosition;

    public Vector2 LastGlobalPosition { get; private set; }

    // Called when the node enters the scene tree for the first time.
    public override void _Ready()
	{
		RealGlobalPosition = GlobalPosition;
		MakeCurrent();
		Player = GetTree().GetFirstNodeInGroup("Player") as Node2D;
	}

	public override void _Process(double delta)
	{
		UpdateCamera((float)delta);
	}

	// Called every frame. 'delta' is the elapsed time since the previous frame.
	public override void _PhysicsProcess(double delta)
	{
		UpdateCamera((float)delta);
	}

	public void AquireTarget()
	{
		targetPosition = Player.GlobalPosition;
	}

	public Vector2 SnapToPixel(Vector2 point)
	{
		return (point + new Vector2(0.5f, 0.5f)).Floor();
	}

	public void UpdateCamera(float deltaPass)
	{
		//basic "Snap" - works and looks smooth
		/*
		if (IsInstanceValid(Player))
		{
			AquireTarget();
			GlobalPosition = targetPosition;
		}
		*/

		/*
		if(IsInstanceValid(Player))
		{
			AquireTarget();
			GlobalPosition = GlobalPosition.Lerp(targetPosition, 1.0f - Mathf.Exp(-deltaPass * lerpWeight));
		}
		*/

		/*
		if(IsInstanceValid(Player))
		{
			AquireTarget();
			GlobalPosition = GlobalPosition.Lerp(targetPosition, 1.0f - Mathf.Exp(-deltaPass * lerpWeight));
		}
		*/

		/*
		//lerpweight needs to be around 0.01 to work!
		if(IsInstanceValid(Player))
		{
			AquireTarget();
			RealGlobalPosition = RealGlobalPosition.Lerp(SnapToPixel(targetPosition), lerpWeight);	
			GlobalPosition = RealGlobalPosition.Floor();	
		}

		*/

		/*
		if(IsInstanceValid(Player))
		{
			AquireTarget();
			RealGlobalPosition = RealGlobalPosition.Lerp(SnapToPixel(targetPosition), lerpWeight);		
			GlobalPosition = SnapToPixel(RealGlobalPosition);
		}
		
		*/

		/*
		if(IsInstanceValid(Player))
		{
			AquireTarget();
			RealGlobalPosition = RealGlobalPosition.Lerp(targetPosition, 1.0f - Mathf.Exp(-deltaPass * lerpWeight));
			var Overflow = new Vector2(RealGlobalPosition.X % 1, RealGlobalPosition.Y % 1);
			GlobalPosition = RealGlobalPosition - Overflow;

			var newDistance = GlobalPosition.DistanceSquaredTo(targetPosition);
			var lastDistance = GlobalPosition.DistanceSquaredTo(targetPosition);
			
			if (newDistance > lastDistance)
			{
				GlobalPosition = LastGlobalPosition;
			}
			LastGlobalPosition = GlobalPosition;
		}
		*/

		/*
		if (IsInstanceValid(Player))
		{
			AquireTarget();

			var offsetTarget = targetPosition + targetOffset;

			Vector2 newPos = Vector2.Zero;

			newPos.X = offsetTarget.X;
			newPos.Y = offsetTarget.Y;

			newPos = newPos + Vector2.One;

			var tempPosition = GlobalPosition;

			if (tempPosition.DistanceTo(newPos) > 0.5f)
			{
				tempPosition = tempPosition.Lerp(newPos, lerpWeight * deltaPass);
			}
			else
			{
				tempPosition = newPos;
			}

			GlobalPosition = tempPosition;

			var subPixel = new Vector2(GlobalPosition.Round().X - GlobalPosition.X, GlobalPosition.Round().Y - GlobalPosition.Y);

			if (subPixel.Length() < 0.1)
			{
				subPixel = Vector2.Zero;
			}
		}
		*/



	}

}

EDIT2:

I'm increasingly beginning to believe this is just a limitation of the engine I'll have to live with. The least worst results I have gotten have been:

On the character's movement code, in _PhysicsProcess:

		var velocity = (Direction.Normalized() * MoveSpeed) + OverflowVelocity;
		OverflowVelocity = new Vector2(velocity.X % 1, velocity.Y % 1);
		Velocity = (velocity - OverflowVelocity);

		MoveAndSlide();

On the camera, in BOTH _PhysicsProcess and _Process:

		if(IsInstanceValid(Player))
		{
			AquireTarget();
			RealGlobalPosition = RealGlobalPosition.Lerp(targetPosition, 1.0f - Mathf.Exp(-deltaPass * lerpWeight));
			GlobalPosition = RealGlobalPosition.Floor();
		}

• Physics Interpolation is ON, Jitter Fix at 0
• Snap Transforms to Pixel is ON

The result looks like this:
https://github.com/user-attachments/assets/550f6e5e-1539-4b62-bad2-1cc82de9e639

Which still has jitter, especially diagonally, but unless there are some changes to the engine I just don't think it's possible to not get jitter and still have camera smoothing.

[h0lley]

I do feel like the fact that nobody's been able to come up with a satisfactory solution to this issue in over a year should indicate to the dev team that there's an issue to be addressed here.

I've been trying to find a satisfactory solution for this since probably around 2018 when I started my topdown project in Godot 3.

[c0d3r9]

Try it...good luck. ;)

[weirdbeardgame]

Just contributing to this discussion by saying, I ended up ultimately throwing away the Camera2D as is suggested in the Documentation and writing my own Pixel Perfect camera which albeit is still heavily WIP.

` public void Scroll(double delta)
{
//ToDo: Detect if isScrolling Based on set static area or drag bounds!!
var newOrigin = _cameraView.CanvasTransform;

    // Note that focusArea in this case is an Area2D, could make it a Node2D as well
    Vector2I targetPosition = (Vector2I)_focusArea.GlobalPosition.Round();

    newOrigin.Origin = -targetPosition + _halfHeight;

    // Limits are tile map limits to keep the camera in bounds
    // Currently having a small issue where the camera can't reach end of level.
    int minX = Limits[(int)LimitDir.LEFT] + _halfHeight.X;
    int maxX = Limits[(int)LimitDir.RIGHT] - _halfHeight.X;
    int minY = Limits[(int)LimitDir.UP] + _halfHeight.Y;
    int maxY = Limits[(int)LimitDir.DOWN] - _halfHeight.Y;

    // Clamp Camera to Map Limits / boundaries
    newOrigin.Origin = new Vector2(Math.Clamp((int)newOrigin.Origin.X, minX, maxX), Math.Clamp((int)newOrigin.Origin.Y, minY, maxY));

    _cameraView.CanvasTransform = newOrigin;
}`

In this particular instance, I wanted pure Pixel Perfect physics, not SubPixel but renders at a Pixel Perfect resolution.
The key factor being, Player Position even though I'm not pasting that code in this comment, is output as Rounded return _inputVelocity.Round(); Then, I clamp the Viewport's Transform 2D to a rounded off Vector2I and do the actual transform including clamping to TileMap size to keep the camera in the map itself. So far so good on my end. I will eventually be adding a SubViewport into my scene with a TextureRect attached to the camera that renders at 480p wide while the final output resolution will be 1080p

The resulting Scroll:
https://github.com/user-attachments/assets/df56a5d7-dad0-4db0-a69b-6754b8aac9e0

That being said, if anyone has any comments on my solution, feel free!

[weirdbeardgame]

Fair enough, my artist had suggested it (Think it's at an odd resolution). But regardless, I hope my code's useful :)

[KeyboardDanni]

Personally, I use Camera2D, but not its automatic scrolling features. I don't parent it to anything, and I handle positioning and smoothing operations myself. It's important that you set the camera's process_priority and process_physics_priority to a high value so it always updates last in the frame, after everything else has moved. Also make sure the camera moves during physics_process along with the object you're tracking.

For widescreen pixel games, 640x360 is an excellent resolution as this will scale evenly to 720p, 1080p, 1440p, and 4K. When adjusting the resolution down though, take care not to have your objects move so fast that you can't see anything coming at you from offscreen. May also want to adjust your level by collapsing some of the empty space, so that it remains fun at a reduced speed.

[Ziboo]

Personally, I use Camera2D, but not its automatic scrolling features. I don't parent it to anything, and I handle positioning and smoothing operations myself. It's important that you set the camera's process_priority and process_physics_priority to a high value so it always updates last in the frame, after everything else has moved. Also make sure the camera moves during physics_process along with the object you're tracking.

For widescreen pixel games, 640x360 is an excellent resolution as this will scale evenly to 720p, 1080p, 1440p, and 4K. When adjusting the resolution down though, take care not to have your objects move so fast that you can't see anything coming at you from offscreen. May also want to adjust your level by collapsing some of the empty space, so that it remains fun at a reduced speed.

Hello @KeyboardDanni .
Any chance you could share the code or a small package ? That would be awesome :)

[KeyboardDanni]

@Ziboo I'd been meaning to make an example for this but I got wrapped up in a few other projects. I'll try to make this my priority now.

[Ziboo]

@Ziboo I'd been meaning to make an example for this but I got wrapped up in a few other projects. I'll try to make this my priority now.

Thank you for taking the time ! Really appreciate it !

[adamscott]

Hey everyone!

I do feel like the fact that nobody's been able to come up with a satisfactory solution to this issue in over a year should indicate to the dev team that there's an issue to be addressed here.
— A comment in this discussion

I understand the frustration of everyone here. Pixel perfect games are notoriously hard to do.

I personally think that there's a ceiling of what can be done. And I'm saying that because I am a dev that worked really hard to fix those issues in 4.3.

Did you know that sprites jitter in Pokémon Red on the GameBoy? Here's a capture I made of Pokémon Red on BGB, a super accurate Game Boy emulator (slowed down at 25%). Notice how we shouldn't see some parts of the chair behind RED's mom when RED is moving.

pokemonred.mp4

If it cannot be done properly on a game such as this one on a native and revered pixel-based platform, well, maybe it's something that cannot be "fixed". Pokémon Red taught me that.

So I'm not saying that nothing can be done from now on. If you find new techniques, we'll be the first to integrate them in the engine if it fits. I'm just saying that you shouldn't be so hard on yourself if you do find that your game is not pixel perfect enough.

[weirdbeardgame]

I don't think it should be a separate type of camera necessarily, but we should have some sort of pixel rounding mode in Camera2D or at the very least fix the existing bugs. If the bug is in the core code, the fix should go there too.

Yeah, I was thinking in similar terms to Unity's pixel perfect Camera. But a button or a setting for the Viewport in the engine settings would be a fine solution as well.

[lawnjelly]

Would you accept a PR, adding a camera type like what I'm working on? Aside from my resolution, it's returning clean round integers and seems functional enough.

Just to point out this is probably an ideal use-case for an addon to start with (a lot of camera stuff is possible and efficient to do even in gdscript in my experience). This is also a great opportunity to work out any kinks before going further (i.e. proposal etc).

Bear in mind also if there are recommended addons they can be linked from the docs.

[dsnopek]

Just to point out this is probably an ideal use-case for an addon to start with (a lot of camera stuff is possible and efficient to do even in gdscript in my experience). This is also a great opportunity to work out any kinks before going further (i.e. proposal etc).

I agree.

There is some artistic license in exactly what it means to be pixel perfect, and starting in an addon makes it easier to iterate, and hash out ways to accommodate all the use cases.

[weirdbeardgame]

Would you accept a PR, adding a camera type like what I'm working on? Aside from my resolution, it's returning clean round integers and seems functional enough.

Just to point out this is probably an ideal use-case for an addon to start with (a lot of camera stuff is possible and efficient to do even in gdscript in my experience). This is also a great opportunity to work out any kinks before going further (i.e. proposal etc).

Bear in mind also if there are recommended addons they can be linked from the docs.

I can release my efforts as an addon in the near future. I'm doing this with the Viewport directly because of some extra issues I was having when attempting to clamp the Camera2D, I've got a good node tracking scroll, now I plan on adding Zoom, panning effects, and maybe some basic scripting for old style JRPG cutscenes with Camera effects

[JoannaFalkowska]

If it cannot be done properly on a game such as this one on a native and revered pixel-based platform, well, maybe it's something that cannot be "fixed". Pokémon Red taught me that.

I... uh. Kind sir, I don't want to be rude, but this revered game and platform were engineered 30 years ago.

You seem to be under the same impression as @HybridEidolon earlier in this thread:

The "smooth 2D camera" technique is actually fairly specific to very small viewport resolutions and the specifics of how it's implemented could practically vary between games (custom camera solutions?). I'm not sure if I would want such an effect for something that is mimicking a real retro console.

But it's 2025. With pixel art, we are not mimicking "real retro consoles". We are mimicking Stardew Valley, Celeste and Undertale.

[h0lley]

I am dropping this video here, as it is recent and I find it describes the issue at hand perfectly. It also showcases nicely how this is an issue present across all sorts of game engines, and that even accomplished games suffer from it.

a solution based on Picster's tutorial for Godot 3.x (that I am sure has been posted in here probably several times already) is being hinted at, but not explained in detail.

if we can create a proof of concept project from this working in Godot 4, then a new proposal for a built-in implementation could become worthwhile.

[c0d3r9]

I think the most of us would: https://www.youtube.com/watch?v=zxVQsi9wnw8
in Godot 4.x

[KeyboardDanni]

@c0d3r9 The part at 1:20 in this video illustrates why you probably don't want to have camera smoothing in a more retro-style pixel perfect game. Most console games made in the 8-bit and 16-bit era don't go for this sort of camera movement. I think Donkey Kong Country mostly gets away with it because of the limited vertical camera movement, and the larger, more-detailed sprites with lots of animation frames so your eyes don't really cling to individual pixels for long anyway.

That aside, I think we could use this for ideas on how to improve the experience for those who want the more modern hi-res approach. Just note that Godot's current built-in pixel snap uses floor(x + 0.5) instead of round() as it gives consistent behavior for negative coordinates.

[c0d3r9]

Its just an info because as that issue beginning here, that video was the way that most people would have.
For me is start in the next days an own pixelart project with pixelart style for the gfx and smooth(subpixel) movement and scrolling.
Fingers crossed ;)
I think a solution maybe never found.
But if it works on Godot 3.x why not 4.x. (i think its the new render system optimised for vulkan)

[KeyboardDanni]

I don't see any reason why this technique wouldn't work in 4.x. I'll see if I can make an example and report back on my findings.

[c0d3r9]

Haven´t try this tutorial with 4.x but some people try that in past without success.

[weirdbeardgame]

So, while this is still a Heavy work in progress. I at least wanted to share what I've gotten so far
It's best used with a SubViewPort Renderer

Right now, it has a functional pixel-perfect scroll and AutoScrolling. My eventual goal is to fix up the equation a bit to handle Zoom which won't make it Pixel Perfect I'm aware but, I want the scroll code to account for screen size and Zoom as well. I'm also planning to implement other camera movements and effects like Pan, up, down, left, and right or maybe a rotation effect. The end goal being a scriptable cutscene camera as well as a camera that can be used for normal ingame stuff.