Integer scaling and sharp bilinear scale options

[jayare5]

There are many pixel art games made with GDevelop that sadly suffer from a problem I can best refer to as "uneven pixels". It's what happens when you resize the window of a low resolution game, but the pixels become messy and ugly because they are no longer displayed at an exact scale of the game's resolution. A fix is very simple in theory, we need 2 new options:

1 - Integer scaling 2 - Sharp bilinear

I'll describe and provide an image just to be sure:

1 - Integer scaling: This would force the game to scale only to a multiple of 100% of its base resolution as the window size grows. (200%, 300%, 400%, etc. but nothing in between). The user should still be able to resize the window, but the game would have black borders and stay fixed at its base resolution instead of growing in size, until the window is the size of the next multiple of 100% of the game's base resolution.

2 - Sharp bilinear: Same as what GDevelop currently does, except "very slightly blurry". It's like a blur option, except that the size of the "blur" is always 1 pixel no matter what size the game window has been resized to. This means that if you played a low resolution game, and upscaled it to the full size of a typical monitor, the game's pixels would be big, but in between them would be a tiny blend of 1 pixel in size, which would give the illusion that all pixels are even.

I wouldn't use sharp bilinear with the game enlarged to anything below 200%, as can be seen in the image below, it will be kind of blurry, but not having it is worse anyway. Where it really shines is past 200%, it will always look good no matter what the window is resized to after that. It should kinda be the default for everything. Nintendo themselves use this technique with their retro games on Switch! And it is what most people had been using with emulators for many years before Nintendo did this anyway.

Reference image (maybe open this in a new tab or an image editor to analyze what is happening):

In the 247% example (or really any size other than multiples of 100%) the GDevelop behavior makes the pixels look messy compared to the other 2 suggested options.

These 2 features would fix an issue I found already posted: https://github.com/4ian/GDevelop/issues/5071

[D8H]

This is already partially possible :

• camera zoom + resolution change actions can achieve an integer nearest neighbors scaling
  • the screen dimension expressions can be use to choose the integer ratio if needed
• the game setting can be set to bilinear to scale the decimal part

This example is doing this:

• https://gdevelop.io/game-example/free/platformer-with-tilemap

It would be better if it was just a setting to use.

[jayare5]

Thank you for your reply!! Unfortunately, the camera zoom will ruin the pixel grid. I want to be able to make pixel art games render at low resolutions like a retro game would, but if we use the zoom feature, an object's pixels can render in the middle of the pixels for another object or tile:

It's supposed to be like this this:

[D8H]

Thank you for your reply!! Unfortunately, the camera zoom will ruin the pixel grid. I want to be able to make pixel art games render at low resolutions like a retro game would, but if we use the zoom feature, an object's pixels can render in the middle of the pixels for another object or tile

Did you take the screenshot with the example? It has a pixel perfect behavior, it's not supposed to stop on an half pixel.

[jayare5]

Heh, good question, I slowed the character down to be able to get a good look at the problem. However it can still happen without any modifications. If you just tap forward slightly, you can get it to look like this:

But regardless. The game is still rendering all the pixels in the middle of others while in motion, and it makes it look very obvious that it's not a low resolution game because the movement is too smooth. If you tried to make a Super Mario Bros clone with NES graphics, or really a clone of any game from old consoles, but a smooth motion like this, it would just not feel like the real thing. I prefer to just leave the camera as it normally is, which works great of course, but we lose the slight anti aliasing effect that you demonstrate with this project.

If nothing else, that's the anti aliasing I would have liked! But with normal camera :D

Edit: Seems like the PixelPerfectMovement extension is glitchy too, because the character gets stuck upon touching walls! If I remove the extension, it doesn't happen anymore.