Jerky Camera + Lerp + Low Resolution

How do I...?
1

Hi,

I’ve just implemented a follow camera in a low resolution retro platformer. The resolution of the game is 320 x 180. But there is an issue with the smoothness of the camera with lerp.

Lerp

When the Camera catches up with the Player at the last few movements until it’s zeroed in, it’s noticibly jerky.

I’ve tested tuning off Rounding Pixels to see if that makes any difference, it doesn’t.

I’ve not had the same issue in Construct or Unity with the same low resolution - I’m wondering if it’s as good as I can get in GDevelop?

All the info online seems to be for higher resolution games and they all use the same lerp method.

Using a standard camera without lerp is too fixed and looks too basic, but with lerp added, it isn’t much better. I think it’s how Gdevelop is interpolating the pixels on a fixed pixel grid, where as other engines don’t do this by default.

I also did notice that if you rotate and object in the editor manually (Angle), then the sprite object is smooth, similar to how other game engines render pixel art:
rotation

But if you rotate the sprite in the Events/Actions, you get a very pixelated output:
rotation2

Perhaps moving and rotating in the Events/Actions it works differently to the Scene view under the hood.

Is there anything else that can be done to make the camera smoother in GDevelop?

2

For the latter question, yes, the scene editor is basically not rendering at native resolution of your game, so it has substantially more pixels to work with. Low resolution assets have always had this issue unless an engine is “cheating” (not actually rendering at low resolution, or not using true nearest-neighbor scaling). You can read more about this here:

For the former, lerp can get weird at explicitly low numbers, but I’d have to do testing. What framerate do you have your game set to?

Edit: For the first question about rotation, if your camera is being focused on your player character, you may be able to do the type of cheating I mentioned above by setting your game resolution much higher via events, then zooming all layer cameras in by that same factor. (E.g, your game is 320x180, you use the event action to set the game to 1280x720 (4x), then set up events to zoom each layer by 4x). I haven’t tested this so it may still have the same issue.

3

I prefer the ‘modern’ way to handle low resolution pixel art - I think players expect a smooth motion with the camera these days - this is not to suggest GDevelop is at fault, it just appears to do things in a different way.

I tested the same scene with Unity and construct, they are both buttery smooth with the camera.

I’m using the default, 20 to 60 frames per second.

I think your solution is a possible idea, however I think there may be quite an overhead - keeping the low resolution I was hoping to make this game test or future projects at a low resolution to make them keep the frame rate up.

I did do the ‘trick’ regarding upscaling the resolution for the Preview window, however one caveat was that the Preview window isn’t centered each time, it shunts off to the bottom right of my monitor and requires dragging into place each time.

I did notice after my previous questions regarding the camera that other users had similar questions with layers and there was a couple of mentions of jerky behaviour too - often users are confused how the camera works, it wasn’t just me :wink:

Most low res side scrolling games I’ve seen created with GDevelop appear to only use the standard camera without lerp - there’s no pro examples that I’ve seen that show good results with this.

I’m not currently sure whether I’ll get what I need from GDevelop currently, it has potential I’m sure for the future.

4

Note for this one: There is a “Center the window” action you can use too, and will help you avoid this.

For the option I mentioned above, your assets would still be the same resolution they are today. Just the game canvas would technically be larger (even though it’s rendering at the lower resolution). There should be almost no overhead to performance.

That said, I’m still not 100% sure it would solve the issue, as I’m unclear whether it’s going to interpolate the zoomed positions (and allow for more room to move) or if it’s going to just treat it the same as if it was just running at the lower resolutions. I’ve thrown this up on the discord to see if anyone knows more or knows the technical aspects.

As mentioned, this has to do with low resolutions and slow movement (with Lerp movement getting slower the closer it is to the destination, due to how its interpolation works). This does happen in Unity as well, depending on the settings, as you can see here:
https://forum.unity.com/threads/scrolling-jitters-when-using-pixel-perfect-camera.965279/

GDevelop’s renderer is PixiJS, and it seems like in most cases the fixes I’m seeing on the net from pure PixiJS users are similar to what I mentioned (have a larger canvas/resolution in general, zoom your layers to match that size), although some of them are the opposite extreme (actually scale up your assets to 2x/3x their native size and have the game be at 640x360 or higher, etc).

5

On a separate note: I want to ensure you don’t feel bad or are worried about asking these questions. You’re definitely not putting down the engine in any post I’m seeing, so I appreicate you having this dialogue.

While I’m just a mod and not one of the engine devs, all I’m seeing in this thread is you raising concerns with being unable to replicate what you’re seeing in other engines/reproduce it exactly the same way.

I totally get that, and am just here to try and provide context on how you might be able to accomplish it, or why things are behaving as you’re seeing.

1 Like
6

People often get offended in technical forums when you compare engines or similar - I don’t wish to tread on anyone’s toes!

I’ve just been testing out GDevelop to see if it is comparable to Construct for creating low reolution pixel art platformer style games - having behaviours for the hard grunt of the coding is very handy and speeds things up a great deal in making a game - Construct and GDevelop are quite similar.

I have a good number of years experience with Construct 2 and more recently Unity - Construct 2 is now a bit limited due to being depreciated, and also the lack of Android export is a pain, plus I don’t like subscriptions that are now part of the business model for Construct 3 - although I totally see why they have done it. Unity is great, but coding takes a long time to get right and just getting a good base for a platformer controller (that I like) can take a long time.

GDevelop has a good ethos, I like the positive vibe from the the creator too.

Currently for me GDevelop isn’t totally there yet (for me), however I understand that there is a new team working on improving things.

I’d be keen to know what they say on Discord regarding the low resolutions + camera + lerp, this topic again might be useful to others trying out GDevelop for the first time. Maybe from the discusion something positive may come of it in the future, if not now :wink:

For me I see having to do work-arounds for things just slows down development. I just want to import my assets without having to re-size them, or mess with resolutions to fix the rendering. But I totally understand no engine is perfect!

If there are any updates regarding this topic, I’d love to know.

Additonally, thanks for the helpful replies and time you’ve spent answering my questions.

Jay.

7

As a quick test, I did try this using the Tilemap platformer example:

Resolution set to 160x90 in the game properties.
Game resolution set to 1280x720 via events (window not resized)
Zoom set to 8x (8x90=720)
Framerate minimum set to 60 fps, max 120fps
Camera lerped to player location

Overall it seems pretty smooth to me, and these are the only events needed to accomplish it:

image
image1321×280 18.4 KB

To try it out yourself you can check the preview here: https://game-previews.gdevelop-app.com/1644180077522-554647/index.html

You’ll want to hit F11 after launching the preview to full-screen it.

Here’s the same example without doing the resolution change:
https://game-previews.gdevelop-app.com/1644180494084-788199/index.html

1 Like
8

Thanks for putting in the effort to test :slight_smile:

Even though it is smoother, there is flickering/wiggling as the sprites are re-drawn in the update while the camera centres to the Player - surprising at this frame rate.

It’s a partial fix, but it still doesn’t look that good to me.

Just for refernece with Construct 2 from over 6 years ago, “Super Platform Engine”, which is just a simple game template for Construct 2. It is bundled with the game assets and basic events, behaviours etc - not an engine itself as the name might suggest. It shows how smooth at low resolutions Construct 2 is.

SPE The Asset
https://www.construct.net/en/game-assets/game-templates/super-platformer-engine-12

Try out the demo online
https://www.construct.net/en/free-online-games/super-platformer-engine-3243/play

This is more akin to how I would expect GDevelop to look with camera movement.

9

So now I’m slightly confused at what you’re asking for, because I’m very familiar with SPE (C2 was my primary tinkering tool for many years, C3 is what made me look elsewhere :smiley: ). The SPE demo runs at at a much higher resolution than native (used to be 800x600, looks like it’s now ~1280x720) with 16x16 assets scaled up/zoomed in unless something has changed.

You can even see this easily due to the swaying grass in the demo as you go through the level, as it’s rendered at a much higher resolution than what would be possible with 16x16 sprites when it sways, meaning it is using more pixels than what would be available at native 320x180 resolutions.

You’ll have the same type of camera if your native camera/game resolution is 800x600 or higher, and you’ll get close with smaller resolutions using the events I mentioned above.

Now, that said, I totally forgot to turn on position rounding on my example above, which is likely why you were seeing some sub-pixel rendering (wiggling).

Here’s another example with that enabled for you to test with: https://game-previews.gdevelop-app.com/1644242706976-99137/index.html

Here’s the same project with the native resolution being 320x180 and zoom at 4x, a bit closer to SPE’s sizes to see how that’d behave: https://game-previews.gdevelop-app.com/1644242764467-960788/index.html

Obviously, keep in mind this tileset and sprite dimensions are only 8x8 pixels, so a higher resolution asset (like 12x18/16x16 from SPE) will have even smoother movement as your native resolution will be larger (320x180 or higher) than the original example I gave.

10

I don’t like to correct people when they’re wrong, but as you are telling me what you think are facts, I have to speak up - the SPE demo is 320, 200. The assets are 16x16.

SPE
SPE730×608 13.7 KB

I’ve used SPE myself for many years for refernce as it’s such a good asset for pixel art style platformers. I’ve used it in Unity also, and in case you didn’t see from my previous screenshots, I tested the assets with GDevelop.

I’m not sure what you are seeing in your demo example that you’ve provided, but there is a lot of tearing, the update is very poor, and yes, it’s very clear that it isn’t smooth. You can’t push the cube into a triangle hole :wink:

I create all my retro style platformers with 320 x 180 with 16x16 sprites and tiles.

As I’ve said already, I’m not hear to criticise, and again I’m greatful for your replies, but GDevelop obviously can’t produce smooth scrolling with low resolutions - I’m not the first to mention it after searching, it seems pretty obviously the way it’s coded under the hood. Of course I’m happy for someone to prove me wrong, but I haven’t seen one demo so far where there is a smooth camera, especially not with using Lerp.

11

Just to add context: The window size isn’t the native resolution in C2 and C3 due to how it deals with scaling. Native resolution is decided under the hood in (at least C2, I don’t think it would change in C3, but I haven’t messed with it a ton) via the scaling methods used. High quality scaling in C2 and C3 scales up assets and then uses downscaling and sampling (and in some cases mipmaping) to make it fit whatever resolution the window is currently at.

I was guestimating what resolution the scaling was using at the time of playing the demo today, but you can see what I’m talking about here:

The player character is 12x18 pixels, but placed next to the grass you can see that parts of the grass are substantially smaller than what would be 1 pixel on the sprite (look at the small tips of the grass off by themselves):

image
image879×600 3.46 KB

This is only possible if the actual rendering resolution is higher than the 320x180

Looking at the actual rendered size, the smallest pixel on the grass is roughly about 1/8th the size of the single pixel size on the character (looking at the hand pixels):

image
image1318×666 7.79 KB

So the actual resolution being rendered by the engine is probably 1280x720.

Edit: All of that out of the way, are you still seeing distortion on the last two examples I posted? I’m not seeing it when playing them fullscreen.

12

Apologies, I may know why we are seeing different things in the newest examples.

What refresh rate is your display? I’m running a 240hz display and since chromium/browsers are refresh rate locked, I may be getting more rendered fps than you are in the examples.

(I’m also trying to help narrow down some of this incase there is an enhancement that can be made for the engine that can be made by the devs)

13

I’m not sure why your examples look different to the original SPE assets (the grass for example), but all the pixels are the same size in the original asset, inside the editor and in preview. All pixels are the same on all the assets when they are displayed on screen in Constrcut - perhaps under the hood so to speak there may be something going on, but not visible like in your screenshots - see my screenshots:

Inside Construct 2 Editor

SPE2
SPE21014×642 6.17 KB

In the browser, game running (Firefox)

SPE3
SPE31105×217 20.6 KB

I don’t see how you can guess that the resolution isn’t as is. Yes it’s upscaled, but that is necessary to make the game look bigger in the browser (or whatever is outputted to), otherwise it’s be rather small obvously.

Yes as I said, the GDevelop game examples you provided have tearing and don’t look great, plus you can see the update as the camera moves into place - better than standard GDevelop settings, but still not up to par - you can see the sprites update as they are drawn, which isn’t great.

If you’ve a 240hz monitor, it’s unlikely that many others will see any improvement as it’s not very common for other’s to have that spec. You really should test on a lesser display so you can see for yourself.

My machine is no slouch by any means, and heck this is a simple, really simple scene to render for even an old raspberry pi.

GDevelop and Construct may be sinilar in intention and looks, but they are too totally different beasts under the hood - the rendering engines just don’t compare sadly.

Anyway, I realise there’s nothing to do now for me unless the engine changes the way it renders - I’m sure for many beginners it might be good enough, but it’s just not for me thank you :slight_smile:

All the best.

14

No worries. Thanks for testing! I normally reduce my refresh to 60 hz when testing in the full IDE and didn’t even think of it when testing with the web IDE.

I’m sorry that this isn’t working for you. If you do want to continue with the engine until when/if a change is made, keep in mind that you could also always just resize your assets by a multiplication factor (scale all assets up by 2x or 6x, render natively at 640x360 or 1920x1080.) This will get a similar effect to what is happening on the Construct side.

This is very likely something similar being done for camera movement in that engine, so this has been helpful as something I can show the devs.

To add detail on the resolution comparisons: The way you can tell the assets on SPE are rendered at a different resolution is how they move. If Construct were natively rendering them at 320x180 when it is being played, assets could only move to where there is 1 pixel. Yet you can see that when grass is moving when running the demo, they’re moving to positions (and have portions of their assets) less than 1 pixel (if it was actually running at 320x180). This isn’t possible graphically, so the engine is rendering the game itself at a higher resolution to do the movement (swaying) rendering.

If you ever want to check this yourself, you can do something similar by playing a demo, fullscreening it, then taking a screenshot and opening it up in something like GIMP or another image editor where you can edit the grid size. If it was rendering at 320x180, on a 1920x1080 display that would mean 1x1 pixel grid would become 6x6 pixel grid. If you set your grid to 6x6 pixels and align the image so one “pixel” with a grid square, you can then see if any of the image is rendered “off pixel”. Again, you can’t graphically have smaller than 1 pixel, so any situation where a color exists mixed with other colors within a grid square is an indication that the engine’s rendered resolution isn’t actually 320x180, like this:
image

This type of comparison is similar to something called pixel counting, which is a pretty common method of guestimating native resolution, and is how places like Digital Foundary were able to tell what the “real” resolution of games were even if their assets (and displayed resolution) were much higher (or lower) resolutions.

15

The discussion you had is really interesting, indeed many game engines work … differently than
GDevelop.
I can’t say how the engines work, and how they should work.
However there is definitely something strange in the rendering of GDevelop during camera movement.

One thing I know is that PixiJS (the graphics engine behind GDevelop) does not support mipmaping. I’m not saying that mipmaping is the solution, I just want to bring a piece of the puzzle to this reflexion you have here.

In my opinion we need someone who knows more about rendering (with PixiJS) to enlighten us.

And maybe the rendering loop isn’t in the right order, I don’t know, just thinking loudly.

1 Like
16

Thanks for your input Bouh.

I’m not sure if it’s a bug, or just by design.

For those reading this post, those that are new to game dev, I just wanted to explain in simple terms what we are all discussing - it’s not just about the camera, it’s the way GDevelop is rendering sprites compared to other game engines.

GDevelop displays sprites in a siilar way how it was done in the old 8 bit days - such as with the Commoder 64 - yes I’m old, I know :wink:

Modern game engines such as Unity, render sprites in what some purist would say is cheating, the sprites aren’t on a pixel grid, their movement doesn’t move pixel by pixel, they are (if the term is correct) ‘interpolated’.

This means as a sprite moves (or a camera) in GDevelop, sprites can’t be drawn between pixels, but in Unity and Construct sprites can. This allows really smooth movement, including the camera etc.

But for those in Unity who prefer the more authentic pixel grid style, you can import a package to do this - although for me, I like being able to more sprites more smoothly, especialy when it comes to rotating sprites - otherwise I would have to make sprites for each angle of rotation and animate them.

Below is a sprite square with a low resolution (320x180 cropped), it is how Construct 2 and Unity displays sprites by default:
Capture

But in GDevelop, this is the how they are displayed, ‘authenticly’:
Capture2

This means the discussion we have had with the camera movement issue, this is all part of the same thing. The camera is essentially just moving the sprites, and they can only occupy space on the pixel grid, there is no inbetween pixels, this gives us a quite choppy result.

The reason why most people don’t notice it is because they often go for much higher resolutions. But with retro style games that are 8x8, 16x16 or possibly even 32x32 sprites, it looks obvious that things aren’t moving smoothly.

It’s odd though that the editor of GDevelop displays sprites like Unity or Construct without the pixel grid (although you can snap to it), but when the game is playing, it switches over to fixed pixels - no inbetween.

For me, and I’m sure many others, having the rendering of sprites the same as the editor is what you would expect in the preview.

17

Hey all, thanks for digging on that subject :slight_smile:

I think we see different notions that are mixed in this thread and I think the best way to clear any doubt would be to re-create the exact same game in two engines and send here the link to the resulting game + the GDevelop project so we can check directly what was done.
(this is the usual motto from game engine developers: provide a minimal reproduction case ;)).

By exact same game, I mean: same resolution, same assets, same events/code, same object positions, same framerate, same linear/nearest neighbour settings (see below), same texture settings (see below).

In particular, a few things:

  1. The camera and all objects in GDevelop are using floating point numbers, so they are living in a world not tied to the game resolution (as in any other game engine, apart maybe from those for very old games). It means an object can be “between” two pixels of the screen.
  2. Rendering in the game is done by default in a “linear” way, but there are settings to use “nearest neighbour”:
  • The scaling of the game canvas is linear, meaning that pixels are interpolated. You can switch to “nearest” in the game properties. If you do, the rendering uses “fixed pixels”.
  • The display of textures is also by default smoothed (linear). If you do a pixel art game, you probably want to disable this.
  1. The rendering in the scene editor is always smoothed, no matter your settings.

The point 3 is maybe a problem in itself that we could fix (to avoid confusion).
But I’d like to be sure what the settings are you are using for the rest (and if there is something there no clear we can also make it clearer - I have no doubt the interface is far from being perfect :)).

I’m asking because I read:

but when the game is playing, it switches over to fixed pixels - no inbetween.

and

But in GDevelop, this is the how they are displayed, ‘authenticly’:

And this seems to indicate a nearest neighbour scaling setting in the game?

I also see that @JayH you mentioned “This means as a sprite moves (or a camera) in GDevelop, sprites can’t be drawn between pixels, but in Unity and Construct sprites can. This allows really smooth movement, including the camera etc.”

This sounds strange because this is exactly what should happen: all objects (i.e: sprites) and cameras can be between pixels, and are interpolated when rendered while the camera and/or the sprites have a position that is not exactly on a pixel.

Anyway, appreciate the time and effort of everyone here to understand what’s going on. :blush:
If we can continue with a game made in two engines to compare, that would be very useful, as a game project allow to discuss on specific things and reproduce the issue at home rather than making hypothesis :slight_smile:

1 Like
18

Hi,

Thanks for your reply :wink: I’ve put together two Platformer demos, one with Construct 2 and the other Gdevelop 5.

They are pretty much identical (Tileing in the levels is slightly different on both as I didn’t have time to make them exactly identical - won’t effect performance. They both use the same assets that are 16x16 sprites/tiles. The game resolution is 320 x 180. They are Windows executables contained in zips. Both use default cursor/arrow controls.

The Constrcut 2 files are larger due to not being able to reduce the files on export, normally they would be smaller.

After unzipping

https://drive.google.com/file/d/1BgoHWmPHIiVlSTRG8eSARJ-EYLmcunJr/view?usp=sharing
To run the Construct 2 version, go to:
win64/nw.exe

https://drive.google.com/file/d/1BZiOm4Ut8wqz0CzZQR0stGuPZaUqnwgc/view?usp=sharing
To run the Gdevelop 5 version, go to:
dist/Tester Setup 1.0.0.exe

Then scale the window as required.:slight_smile:

Hop that helps!

2 Likes
19

Thanks! Any chance you can share the GDevelop project folder for this? :slight_smile:

20

Hi,

Here’s the project files for the GDevelop platformer demo, let me know how you get on :wink:

https://drive.google.com/file/d/1BmDfZ6NopHc0SlljfYmC_pAPmlO10pw4/view?usp=sharing

If you’ve any questions, please let me know.

1 Like