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.
@@wuffier1 I thought that at first, but I'm not sure if it's true. The "pixels" are bigger after being upscaled, and any differences in camera placement between low res and high res are less than one upscaled "pixel", otherwise it would have already shifted the low res camera over to the next integer. Does that make sense?
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.
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.
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
i've run into the jittery sprites in unity as well. the issue is likely that the sprites aren't alligned with the pixel grid of the background, and so due to rounding, can seem to shift positions as the camera moves. I've fixed this in my pixel art games by ensuring the positions of all the sprites is locked to the pixel grid.
The viewport solution makes sense. To fix the jittery issue, you want to use rounded integer coordinates for your entities’ visual components (sprites) while maintaining the floating point coordinate of the actual logical coordinate of the entity.
When it comes to fonts, what I generally do is using/making a... bitmap pixel art font, since the game is also pixel art styled anyways. GameMaker usually lets me fix the jitter by letting me floor() the values of the camera position and object drawing positions. Not sure if it can be applied to other game engines but I think it should, or at least a similar approach.
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
what i did was render the game in hd and just zoom in the camera. Not everything is pixel perfect, but whenever something is stationary i snap it to the pixel grid so it's not noticable that sprites can move into subpixels
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
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 created a gamemaker extention for this problem called stanncam (like me lol) the solution is a bit of a mix, draw your game at low res, scale it up, but then also offset its position by a fraction when its at high scale, to fix the stuttery camera. this wont fix everything, somtimes pixel perfect just looks better, thats a choice you have to make
you could make the pixel art part a shader so that you get pixelation only on the specific part you want but for the exemple you showed it's easier to just have a solution that get no pixelation on the part you want instead you can do this with viewport but i don't remember how though also the shader solution works better with low detail 3d models or svg rather then pixel sprite but i am sure there's a way to sinc the shader with the pixel sprite
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).
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 (.
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.
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?
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
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?
In my opinion low-resolution rendering is doomed to fail. I would rather have the whole game logic running on floats, then on the renderer snap each entity to be rendered to a grid of the desired resolution. The camera has its own grid too . I would make it so that the grid has the same number of visible tiles regardless of the renderer resolution. Then by continuously varying the resolution of each grid for each entity, the desired effect can be achieved. Camera and world grids probably need to be aligned to avoid jitter, but they can still have different resolutions. I also wonder why using an engine for this. If you are looking for that specific look, probably better have your own. We are talking about 2D games, it doesn't need to be complicated. Can use SDL2 or better OpenGL or even better Vulkan depending on your needs and current skillset.
Just... don't make it smooth? that's how it was back then, isn't the point of it to feel retro? Nobody complains that NES games scrolls at pixel increments.
there isn't a clean solution, because there simply isn't a solution. it's not possible to have a game that runs at a lower resolution upscaled, also have a smooth camera. the jittering of the crosshair is easily fixable, though. that has nothing to do with the engine, but how the sprite is interpolated.
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
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".
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.
then the giant "pixel" blocks you drew can overlap the background "pixels" halfway, something that is impossible in actual pixel games imagine taking two square sheets of paper and partially covering one with the other, that is possible with your approach but not on real hardware, so it will look inauthentic and amateurish
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
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.
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.
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.
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?
Can someone explain what's the issue of the second approach? It doesn't feel retro because the motion is too smooth, have you tried limit the refresh rate? Why is that an issue if the original asset is made in low-res? (Sorry not playing pixel-art game very much)
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.
@@gdhasmile here's the problem: - in godot you can make an audio stream loop by ticking a checkbox - but in most cases this is not enough to make seamlessly looping background music: if the track has some sounds that have a release tail at the end, they should overlap the beginning. but you can't just include them at the beginning of the track or you would get weird releases that come from nowhere on the first loop. plus, what if your track has an intro? - the most common solution to this problem is to separate the track into two parts: head and loop - the head plays when the music starts - when the head ends, immediately play the loop and well, loop it - unfortunately in godot you can't queue audio like this: you _can_ try to do it manually but since your code is limited to frame time and does not live in audio sample time, it won't really be possible to start it at the right audio sample. and an offset of a very small amount of audio sample can be noticed by a human ear - if godot gave us audio queuing or a way to access the underlying audio engine, or DSP time, this would be fixed
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.
3 місяці тому
ahh floating point issues, when rendering float values in higher dimensions but capped by a round
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.
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.
@@wuffier1 I thought that at first, but I'm not sure if it's true. The "pixels" are bigger after being upscaled, and any differences in camera placement between low res and high res are less than one upscaled "pixel", otherwise it would have already shifted the low res camera over to the next integer. Does that make sense?
I though the answer was to make the hud in pixel art at the same resolution of the game 🤷♂️
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
was about to say that
It jitters because you've got a mix of floats and integers in the code.
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.
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.
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
i've run into the jittery sprites in unity as well. the issue is likely that the sprites aren't alligned with the pixel grid of the background, and so due to rounding, can seem to shift positions as the camera moves. I've fixed this in my pixel art games by ensuring the positions of all the sprites is locked to the pixel grid.
The viewport solution makes sense. To fix the jittery issue, you want to use rounded integer coordinates for your entities’ visual components (sprites) while maintaining the floating point coordinate of the actual logical coordinate of the entity.
I think it pretty simply needs a pixel shader at native resolution
When it comes to fonts, what I generally do is using/making a... bitmap pixel art font, since the game is also pixel art styled anyways.
GameMaker usually lets me fix the jitter by letting me floor() the values of the camera position and object drawing positions.
Not sure if it can be applied to other game engines but I think it should, or at least a similar approach.
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
what i did was render the game in hd and just zoom in the camera. Not everything is pixel perfect, but whenever something is stationary i snap it to the pixel grid so it's not noticable that sprites can move into subpixels
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
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
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 created a gamemaker extention for this problem called stanncam (like me lol) the solution is a bit of a mix, draw your game at low res, scale it up, but then also offset its position by a fraction when its at high scale, to fix the stuttery camera.
this wont fix everything, somtimes pixel perfect just looks better, thats a choice you have to make
you could make the pixel art part a shader so that you get pixelation only on the specific part you want but for the exemple you showed it's easier to just have a solution that get no pixelation on the part you want instead you can do this with viewport but i don't remember how though also the shader solution works better with low detail 3d models or svg rather then pixel sprite but i am sure there's a way to sinc the shader with the pixel sprite
for the camera, using the 2 viewport solution, just make the pixel viewport a bit larger and smoothly hover the camera over
but, the jitter in câmera panning were present in pixel art games in the past, not all of them but a lot of them
Can't you just do option 2 and then manually recreate the pixel artifacts through post processing or similar approaches?
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).
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 (.
This is all easy to manage wtf lol. You can render the game and ui on separate layers in most game engines.
Also, snap your stuff to the pixel grid
can you just use a shader to pixelate everything? or will that give the game herpes?
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.
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?
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
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?
yup, had this problem too even in Godot 4
In my opinion low-resolution rendering is doomed to fail. I would rather have the whole game logic running on floats, then on the renderer snap each entity to be rendered to a grid of the desired resolution. The camera has its own grid too . I would make it so that the grid has the same number of visible tiles regardless of the renderer resolution. Then by continuously varying the resolution of each grid for each entity, the desired effect can be achieved. Camera and world grids probably need to be aligned to avoid jitter, but they can still have different resolutions. I also wonder why using an engine for this. If you are looking for that specific look, probably better have your own. We are talking about 2D games, it doesn't need to be complicated. Can use SDL2 or better OpenGL or even better Vulkan depending on your needs and current skillset.
It’s pixel art. It’s not supposed to have smooth scrolling or mixels.
Have you tried anti aliasing?
I'd suggest checking out aartificial and his astortion devlog. He discusses exactly this problem in one of the videos
Um, shader? Just use a pixel shader, that way only the graphics get low resolution instead of the camera with it.
Just... don't make it smooth? that's how it was back then, isn't the point of it to feel retro? Nobody complains that NES games scrolls at pixel increments.
there isn't a clean solution, because there simply isn't a solution. it's not possible to have a game that runs at a lower resolution upscaled, also have a smooth camera.
the jittering of the crosshair is easily fixable, though. that has nothing to do with the engine, but how the sprite is interpolated.
Hmm…
RPGMaker2003 !
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
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".
uh don't use a game engine
your upscaling there is doo doo
learning how to do things yourself is power, not using a game engine. screw those guys.
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.
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.
then the giant "pixel" blocks you drew can overlap the background "pixels" halfway, something that is impossible in actual pixel games
imagine taking two square sheets of paper and partially covering one with the other, that is possible with your approach but not on real hardware, so it will look inauthentic and amateurish
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
Doesn't godot literally have pixel snapping?
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.
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.
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.
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?
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
you could "scale" up the pixels... instead of a purely 1 pixel squares, each "pixel" could be a 9 pixel square for example.
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.
Can someone explain what's the issue of the second approach? It doesn't feel retro because the motion is too smooth, have you tried limit the refresh rate?
Why is that an issue if the original asset is made in low-res?
(Sorry not playing pixel-art game very much)
you can't just offset the upscaled smaller image?
Very interesting discussion, thank you for sharing
Unreal engine doesn't care about 2D
Anti aliasing literally solves your non-issue
I think pixel art is as stupid as it sounds. Why that waste?
U just need to use a camera 2d
Great vid!
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.
Wdym it's not supported?
@@gdhasmile here's the problem:
- in godot you can make an audio stream loop by ticking a checkbox
- but in most cases this is not enough to make seamlessly looping background music: if the track has some sounds that have a release tail at the end, they should overlap the beginning. but you can't just include them at the beginning of the track or you would get weird releases that come from nowhere on the first loop. plus, what if your track has an intro?
- the most common solution to this problem is to separate the track into two parts: head and loop
- the head plays when the music starts
- when the head ends, immediately play the loop and well, loop it
- unfortunately in godot you can't queue audio like this: you _can_ try to do it manually but since your code is limited to frame time and does not live in audio sample time, it won't really be possible to start it at the right audio sample. and an offset of a very small amount of audio sample can be noticed by a human ear
- if godot gave us audio queuing or a way to access the underlying audio engine, or DSP time, this would be fixed
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.
ahh floating point issues, when rendering float values in higher dimensions but capped by a round
good video :)
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
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