You can draw your pixel art game to the low resolution viewport, scale it up to your full resolution viewport, and then take the camera position after the decimal point and offset the low resolution viewport by that amount. For the jittery targets and cursor, you could try drawing at integer positions.
Also, render the cursor on the HUD viewport. There's probably no one-size-fits-all to this. Different designers will want to draw the line at different places for where some things will be drawn at game res and where some things will be drawn at window res. Multiple viewports probably is the most robust way. Maybe some installable library could make this a bit easier to work with, I dunno. While the purity of everything being 1:1 and pixel aligned is great, I have to say i prefer native res viewport and just assuring everything is scaled the same so stuff still looks correct in context, but everything can still move smoothly in a way that feels good.
Note that you would have to add one extra pixel to the width and height of the low-res viewport, or else the viewport would not fill the screen at non-integer offsets.
I've seen @aarthificial use a technique he calls "smooth parallax"-to render the game with the camera's position snapped to the pixel grid, then offset the image after upscaling (you may need to render one or two pixels more in each dimension so that the image border is out of view). This allows for smooth scrolling and pixel-perfect graphics simultaneously. You can even render multiple layers and have them scroll independently of each other (hence the "smooth parallax" name), or have some layers not be pixelated to, for example, render the UI in full resolution.
A lot of the solution for text would be picking a more appropriate font if they didn't want to disrupt the game's style too much with modern vector scalable fonts with antialiasing, or find vector fonts that take to not being antialiased well.
1:40 What exactly do you mean when you say you "lose that retro look and feel"? The only things I see different between the two methods are camera roation being jittery or smooth, dummies being jittery or smooth, the pixelated motion of the gun, and of course the UI being lower or higher quality. The UI can be disregarded as the difference you're pointing out here because the GOAL of upscaling was for better UI, but which parts of all those other things are what make it look and feel "retro" to you? Because if the camera and dummy jittering is what sells that effect for you, then there isn't a solution that can solve your problem WHILE removing those. If your only issue is the smooth pixelation of the gun being lost, then can't you just apply something like a pixelation shader over the whole screen (pre-UI layer) to reimplement that effect with a higher resolution? It's kind of hard to know what can be done about the problem when the problem seems to be an inherent issue of the kind of game you want to create. You can't live in a big neighborhood if you don't want neighbors, it contradicts the purpose of living in a big neighborhood.
@@chickensio4755 Okay, I see what you mean there, but I'm not even sure how you'd go about fixing that. It's a fundamental issue of the size of the pixels relative to the size of motions he wants to perform. The fact is, the camera and dummy jitteriness are CAUSED by it being snapped to the grid with a low pixel density, and the smoothness of the checkerboard when the camera rotates is a feature of only HIGH pixel density. You can't use low pixel density if you want to avoid the jittering, and you can't use high density if you want to avoid smooth looking edges, as that's simply what happens when you rotate grids of squares but re-render the transformed image to a plane of the same size. The only real solution would be rewriting a never-before-seen graphics engine from the ground up that is capable of drawing all the pixels at their normal scale, but allowing fractional-pixel camera and entity position adjustments, since the only way to stop the jittering from occurring on the dummies and camera would be to adjust them by the fractions of pixels in precision that you LOSE by having a small resolution, but this ALSO means that the dummies wouldn't be centered on the pixel grid of the viewport when the camera is at awkward angles, which would ALSO look very weird. Point is, there is literally no solution to have high resolution text, non-jittering dummies and camera motion on a low resolution game world, without allowing certain things to desync from the pixel grid. It is literally a graphical oxymoron.
@@chickensio4755 I genuinely don't see the difference. (I'm comparing 1:02 and 1:41). The tiles have the same amount of pixelation (15 pixels per side) and appear to be the same size relative to the other sprites. I think the retro feel may just be down to how rotations are visualized? But I'm not sure
@@cynthiaclementine4757 I don't think it's about the resolution, but about the movement. In the second version pixels don't snap to the grid, it's as if the low resolution was using subpixel-rendering before being scaled. I hope that makes sense. If you look at Celeste, pixels of different sprites are always aligned on a grid. You can't move Madeline by an amount smaller than a pixel.
I struggled with this (not even with pixel art) but I believe this is what I did to solve this in Godot: 1. go to project->settings->rendering-2D->Snap. Check snap 2d transforms and snap 2d vertices. This is typically what “pixel perfect” when games have this option. HEADS UP, this only appears when searching “pixel” or when showing advanced settings. So just look up pixel in settings. This should be the fix. 2. Still in settings, textures->default_filters. Mess around with this. I believe it depends on your sprites. Finally make sure the nodes texture is something besides inherited. Not that this can’t work but it’ll typically make textures/sprites look blurry. EDIT: IF USING PIXEL ART, make sure to go into project settings, ->display->window->stretch->scale mode and switch that bad boy to integer. Should make stuff look smoother and not smeared. I found all this from a random Godot form before it got taken down. Hope this helps!
i feel like for the cursor issue, you could just snap the cursor to the pixels. for the text, the simplest solution i can think of is to make a custom, pixel art font.
A pixelating post effect could do the trick, pixelating the content, at full resolution, the best of both worlds, though at the cost of performance of course.
The solution you just proposed works fine. You can even snap your camera to the pixel grid while keeping track of subpixels (like they did all the way back to the NES days), then put your high resolution at the same camera position. Snapping to grid will fix the pixelation errors in your game screen and tracking subpixels will fix framerate dependent rounding error. Then your high res camera, which is supposed to be for UI only, will be synced with the game camera for whatever systems need that, and will render at a high resolution if you want it to.
Can't you just disable antialiasing on the text and/or use a pixelated font??? Also, just make the positions of objects on the map round relative to the map, rather than the screen, so it stays cohesive. My only problem at the moment (from two years ago when I updated AEWVS ABC) has been implementing a pixelated font into the project using a sprite-sheet, because for some reason I can't stop a native font from being antialiased on an HTML canvas for some reason
what you can do is just apply a shader that renders only specific objects into that retro res, while having it also not snap to the 640 x 360 grid. For example, have the rotation pixelated, but have the x and y movement smooth. Im sure there is some way to do this
You can just render the game layer en HD and just quantize the pixel position in the shader to be absolute increments in world space (instead of screen space).
To solve the camera problem just use a viewport in native resolution but with one pixel extruded in each direction. Then use another viewport on the upscaled image and position it acording to the decimal value of the camera position. The UI problem you already talles about it and is the standard way yo do it. However I really discourague using different resolutions between UI and game in pixelart. HD text/elements in pixelart looks really out of place and ugly.
In Game Maker, there's a GUI render that's separate from the game render. Looks like the workarounds suggested here for Godot are to create that same idea.
Před dnem
ahh floating point issues, when rendering float values in higher dimensions but capped by a round
If you want to make a high res game with pixel art sprites why don't you just scale the sprites? I've seen games or assets doing that. Like having an imaginary rule when creating assets that one pixel equals 10x10 pixel (or larger). Or scaling the entities in engine to a more appropriate scale to the game resolution. I don't see a reason as to why one should avoid that when you want to make a game that has ""just"" a retro look.
to make a smooth camera in a pixel art game simply move the viewport at -(cam_pixel_pos%1) and don't use anti-aliased text in pixel art games use actual sprite fonts instead
Not sure why you couldn't make every sprite scale up based on the render resolution. Certain resolutions could give the effect of the camera being closer or further to match at a clean scale, but it'd look perfectly pixelated without scaling artifacts at any resolution. You'd probably want to have collisions and such be based on an underlying grid though so the scale doesn't effect it though
Honestly not quite sure how to approach this, I guess you could have a slightly larger viewport for the game, only moving the game camera in discrete steps and "interpolating" the position of the viewport as rendered in the main window. I might try implementing that in OpenGL
I guess that's the price of using modern video cards optimized for 3d rendering, for a 2d game, or trying to match a retro style. Back in my day we had to code our scrolling routines, and everything is snapped to pixel/integer boundaries. (Yes we did have floating point errors, but usually you could mitigate this by floor()ing your positions.
But do old games have smooth cameras? If I play SNES games on an emulator, does something like Super Mario Bros. 3 have a smooth camera? I'd expect it to be jittery as well, no? Didn't old games bounce 1 pixel to the side at a time as well?
this is fine because it's not that bad to come up with a gdscript solution. however it makes me sad that properly looping a music track that has an intro is.. still not supported in godot.
I personally solve a lot of these problems by rendering at native resolution and then using shaders to pixelize the elements that I want to match the pixel style
Rendering at native resolution has the downside of performing much worse though, 2560x1440 is 16x more pixels than 640x360. It's not a big deal for 2D games because they typically don't have insane graphical requirements, but it makes performance more of a consideration. I will say that the shader approach does have a higher limit for freedom and creativity in my opinion, lots of cool 2.5 and 2d games out there that use 3d assets.
@@research417 applying shaders to 2D elements is fine! If you’re telling me to manually compute all kinds of advanced 2d graphical effects on the CPU, you’re simply wrong
You can have a smooth camera with a pixel perfect game. There is a gamemaker tutorial that does that. Also, not normalizing the move direction vector of the camera might help.
In godot there is a way of displaying the "canvas" window, as far as I remember, it expands the image and it still remains smooth, But for pixel text, you need to create your own font (.
Plenty of pixel art games have smooth cameras, I'm not sure what you're on about. If you're talking about how so many games are jittery you can about antialiased point sampling. Either way, you've not made clear what problem you're actually talking about and the problems you maybe are referring to are solved problems?
Isnt the jitteriness because things arent snapping to the pixel grid and they are technically doing some kind of half scaling thing. Like you know you cant have half a pixel, its a subpixel thing? Didnt Gamemaker Studio solve this issue?
Probably, but then you'd need to manually apply the shader to each sprite. This is probably way less performant than rendering at a high resolution while sampling the low res sprites. Also, I'm not sure how that would fix the jittering issues, which seem to be based on positions jittering.
The problem isn't "we haven't figured it out". The problem is "most modern game developers would rather struggle with the limited feature set of the modern game engines than abandon the beaten path to go and code the solution themselves".
I actually saw a devlog recently where someone made a game in 720p which the dev had some issues with because downscaling didn't work. The dev ended up remaking every graphic in the game in a non-pixel artstyle
You can draw your pixel art game to the low resolution viewport, scale it up to your full resolution viewport, and then take the camera position after the decimal point and offset the low resolution viewport by that amount.
For the jittery targets and cursor, you could try drawing at integer positions.
Also, render the cursor on the HUD viewport.
There's probably no one-size-fits-all to this. Different designers will want to draw the line at different places for where some things will be drawn at game res and where some things will be drawn at window res. Multiple viewports probably is the most robust way. Maybe some installable library could make this a bit easier to work with, I dunno. While the purity of everything being 1:1 and pixel aligned is great, I have to say i prefer native res viewport and just assuring everything is scaled the same so stuff still looks correct in context, but everything can still move smoothly in a way that feels good.
Note that you would have to add one extra pixel to the width and height of the low-res viewport, or else the viewport would not fill the screen at non-integer offsets.
I saw the thumbnail and I immediately knew what this was about. I feel you so much, no joke this keeps me up at night sometimes.
There is Astortion, the guy who made that figured out a really cool way to get smooth cameras with upscaling. Super cool
I've seen @aarthificial use a technique he calls "smooth parallax"-to render the game with the camera's position snapped to the pixel grid, then offset the image after upscaling (you may need to render one or two pixels more in each dimension so that the image border is out of view). This allows for smooth scrolling and pixel-perfect graphics simultaneously. You can even render multiple layers and have them scroll independently of each other (hence the "smooth parallax" name), or have some layers not be pixelated to, for example, render the UI in full resolution.
This is why so many of my games have no text 😭
no localisation needed then, I see.
A lot of the solution for text would be picking a more appropriate font if they didn't want to disrupt the game's style too much with modern vector scalable fonts with antialiasing, or find vector fonts that take to not being antialiased well.
I appreciate when a game communicates things without explicitly instructing me.
It doesn't break the flow.
1:40 What exactly do you mean when you say you "lose that retro look and feel"? The only things I see different between the two methods are camera roation being jittery or smooth, dummies being jittery or smooth, the pixelated motion of the gun, and of course the UI being lower or higher quality.
The UI can be disregarded as the difference you're pointing out here because the GOAL of upscaling was for better UI, but which parts of all those other things are what make it look and feel "retro" to you?
Because if the camera and dummy jittering is what sells that effect for you, then there isn't a solution that can solve your problem WHILE removing those.
If your only issue is the smooth pixelation of the gun being lost, then can't you just apply something like a pixelation shader over the whole screen (pre-UI layer) to reimplement that effect with a higher resolution?
It's kind of hard to know what can be done about the problem when the problem seems to be an inherent issue of the kind of game you want to create. You can't live in a big neighborhood if you don't want neighbors, it contradicts the purpose of living in a big neighborhood.
look at the tiles, they look smooth in this one where as in the old one the tiles were pixelated and small thngs like that
@@chickensio4755 Okay, I see what you mean there, but I'm not even sure how you'd go about fixing that. It's a fundamental issue of the size of the pixels relative to the size of motions he wants to perform. The fact is, the camera and dummy jitteriness are CAUSED by it being snapped to the grid with a low pixel density, and the smoothness of the checkerboard when the camera rotates is a feature of only HIGH pixel density. You can't use low pixel density if you want to avoid the jittering, and you can't use high density if you want to avoid smooth looking edges, as that's simply what happens when you rotate grids of squares but re-render the transformed image to a plane of the same size.
The only real solution would be rewriting a never-before-seen graphics engine from the ground up that is capable of drawing all the pixels at their normal scale, but allowing fractional-pixel camera and entity position adjustments, since the only way to stop the jittering from occurring on the dummies and camera would be to adjust them by the fractions of pixels in precision that you LOSE by having a small resolution, but this ALSO means that the dummies wouldn't be centered on the pixel grid of the viewport when the camera is at awkward angles, which would ALSO look very weird.
Point is, there is literally no solution to have high resolution text, non-jittering dummies and camera motion on a low resolution game world, without allowing certain things to desync from the pixel grid. It is literally a graphical oxymoron.
@@chickensio4755 ? How is the pixel shader not solving these?
@@chickensio4755 I genuinely don't see the difference. (I'm comparing 1:02 and 1:41). The tiles have the same amount of pixelation (15 pixels per side) and appear to be the same size relative to the other sprites. I think the retro feel may just be down to how rotations are visualized? But I'm not sure
@@cynthiaclementine4757 I don't think it's about the resolution, but about the movement. In the second version pixels don't snap to the grid, it's as if the low resolution was using subpixel-rendering before being scaled. I hope that makes sense. If you look at Celeste, pixels of different sprites are always aligned on a grid. You can't move Madeline by an amount smaller than a pixel.
I struggled with this (not even with pixel art) but I believe this is what I did to solve this in Godot:
1. go to project->settings->rendering-2D->Snap. Check snap 2d transforms and snap 2d vertices. This is typically what “pixel perfect” when games have this option. HEADS UP, this only appears when searching “pixel” or when showing advanced settings. So just look up pixel in settings. This should be the fix.
2. Still in settings, textures->default_filters. Mess around with this. I believe it depends on your sprites.
Finally make sure the nodes texture is something besides inherited. Not that this can’t work but it’ll typically make textures/sprites look blurry.
EDIT: IF USING PIXEL ART, make sure to go into project settings, ->display->window->stretch->scale mode and switch that bad boy to integer. Should make stuff look smoother and not smeared.
I found all this from a random Godot form before it got taken down. Hope this helps!
i feel like for the cursor issue, you could just snap the cursor to the pixels. for the text, the simplest solution i can think of is to make a custom, pixel art font.
A pixelating post effect could do the trick, pixelating the content, at full resolution, the best of both worlds, though at the cost of performance of course.
The solution you just proposed works fine. You can even snap your camera to the pixel grid while keeping track of subpixels (like they did all the way back to the NES days), then put your high resolution at the same camera position. Snapping to grid will fix the pixelation errors in your game screen and tracking subpixels will fix framerate dependent rounding error. Then your high res camera, which is supposed to be for UI only, will be synced with the game camera for whatever systems need that, and will render at a high resolution if you want it to.
Can't you just disable antialiasing on the text and/or use a pixelated font??? Also, just make the positions of objects on the map round relative to the map, rather than the screen, so it stays cohesive.
My only problem at the moment (from two years ago when I updated AEWVS ABC) has been implementing a pixelated font into the project using a sprite-sheet, because for some reason I can't stop a native font from being antialiased on an HTML canvas for some reason
what you can do is just apply a shader that renders only specific objects into that retro res, while having it also not snap to the 640 x 360 grid. For example, have the rotation pixelated, but have the x and y movement smooth. Im sure there is some way to do this
It jitters because you've got a mix of floats and integers in the code.
You can just render the game layer en HD and just quantize the pixel position in the shader to be absolute increments in world space (instead of screen space).
To solve the camera problem just use a viewport in native resolution but with one pixel extruded in each direction. Then use another viewport on the upscaled image and position it acording to the decimal value of the camera position.
The UI problem you already talles about it and is the standard way yo do it. However I really discourague using different resolutions between UI and game in pixelart. HD text/elements in pixelart looks really out of place and ugly.
I think it pretty simply needs a pixel shader at native resolution
yup, had this problem too even in Godot 4
The camera solution I use is you render outside the cameras viewport a bit and then you smoothly interpolate camera movement across the rendered image
It is posible to interpolate the camera viewport to make it smooth. There are a couple tutorials that explain it, I recomend the one by Picster
In Game Maker, there's a GUI render that's separate from the game render.
Looks like the workarounds suggested here for Godot are to create that same idea.
ahh floating point issues, when rendering float values in higher dimensions but capped by a round
If you want to make a high res game with pixel art sprites why don't you just scale the sprites?
I've seen games or assets doing that. Like having an imaginary rule when creating assets that one pixel equals 10x10 pixel (or larger).
Or scaling the entities in engine to a more appropriate scale to the game resolution.
I don't see a reason as to why one should avoid that when you want to make a game that has ""just"" a retro look.
can you just use a shader to pixelate everything? or will that give the game herpes?
to make a smooth camera in a pixel art game simply move the viewport at -(cam_pixel_pos%1)
and don't use anti-aliased text in pixel art games
use actual sprite fonts instead
Not sure why you couldn't make every sprite scale up based on the render resolution. Certain resolutions could give the effect of the camera being closer or further to match at a clean scale, but it'd look perfectly pixelated without scaling artifacts at any resolution. You'd probably want to have collisions and such be based on an underlying grid though so the scale doesn't effect it though
Honestly not quite sure how to approach this, I guess you could have a slightly larger viewport for the game, only moving the game camera in discrete steps and "interpolating" the position of the viewport as rendered in the main window. I might try implementing that in OpenGL
Godot's 2D camera jitter is insufferable! I can't believe that one or the best engines for pixel art games has such a glaring, nonsensical flaw.
you can't just offset the upscaled smaller image?
Great vid!
I guess that's the price of using modern video cards optimized for 3d rendering, for a 2d game, or trying to match a retro style. Back in my day we had to code our scrolling routines, and everything is snapped to pixel/integer boundaries. (Yes we did have floating point errors, but usually you could mitigate this by floor()ing your positions.
But do old games have smooth cameras? If I play SNES games on an emulator, does something like Super Mario Bros. 3 have a smooth camera? I'd expect it to be jittery as well, no? Didn't old games bounce 1 pixel to the side at a time as well?
this is fine because it's not that bad to come up with a gdscript solution. however it makes me sad that properly looping a music track that has an intro is.. still not supported in godot.
you could "scale" up the pixels... instead of a purely 1 pixel squares, each "pixel" could be a 9 pixel square for example.
I personally solve a lot of these problems by rendering at native resolution and then using shaders to pixelize the elements that I want to match the pixel style
Rendering at native resolution has the downside of performing much worse though, 2560x1440 is 16x more pixels than 640x360. It's not a big deal for 2D games because they typically don't have insane graphical requirements, but it makes performance more of a consideration.
I will say that the shader approach does have a higher limit for freedom and creativity in my opinion, lots of cool 2.5 and 2d games out there that use 3d assets.
Applying shaders to individual 2d sprites is also... not ideal.
@@research417 if you have a 1440p screen you definitely have the computer to drive it
@@research417 applying shaders to 2D elements is fine! If you’re telling me to manually compute all kinds of advanced 2d graphical effects on the CPU, you’re simply wrong
You can have a smooth camera with a pixel perfect game. There is a gamemaker tutorial that does that. Also, not normalizing the move direction vector of the camera might help.
In godot there is a way of displaying the "canvas" window, as far as I remember, it expands the image and it still remains smooth, But for pixel text, you need to create your own font (.
Plenty of pixel art games have smooth cameras, I'm not sure what you're on about. If you're talking about how so many games are jittery you can about antialiased point sampling. Either way, you've not made clear what problem you're actually talking about and the problems you maybe are referring to are solved problems?
Isnt the jitteriness because things arent snapping to the pixel grid and they are technically doing some kind of half scaling thing.
Like you know you cant have half a pixel, its a subpixel thing?
Didnt Gamemaker Studio solve this issue?
Have you tried anti aliasing?
Can't you just... Make sprites bigger? Pixelose today is design choice rather than limitation. The game is in HD but sprites are made to look 16-bit.
Um, shader? Just use a pixel shader, that way only the graphics get low resolution instead of the camera with it.
Ultimate solution: Don’t move the camera.
This is a joke, don’t take it seriously!
Isn't it possible to just use shaders to pixelat each object individually?
Probably, but then you'd need to manually apply the shader to each sprite. This is probably way less performant than rendering at a high resolution while sampling the low res sprites. Also, I'm not sure how that would fix the jittering issues, which seem to be based on positions jittering.
@@Shack263 could you not apply the shader to a separate viewport that has all the objects you want shaded?
@@ryanwillingham yes you can. I forgot about that lol.
@@Shack263 lol
good video :)
Lock the camera and build a game where there are only levels small enough for the camera, problem fixed.
skill issue
The problem isn't "we haven't figured it out".
The problem is "most modern game developers would rather struggle with the limited feature set of the modern game engines than abandon the beaten path to go and code the solution themselves".
I actually saw a devlog recently where someone made a game in 720p which the dev had some issues with because downscaling didn't work. The dev ended up remaking every graphic in the game in a non-pixel artstyle
You talking about Mark Brown of GMTK, and his game Mind Over Magnet? He's a pretty major game dev channel, so that's what came right to mind.
@@Semudara yeah that's who I meant