>>56988501>wheresee
>>56983966>by definition of what sprites even are, this is falseSeems like you're not understanding the basic concepts that we're discussing. The file of the sprite is rendered onto the screen, but it's not like pasting a png onto the screen and choosing exactly what pixels it takes up. It's rendered in space and it, as well as the camera, moves around to the point where in many frames the sprite pixels don't line up with the screen pixels. It being a sprite doesn't change this
>>56988527>This is literally your entire modus operandiWell let's see, I, in great detail may I add, described and supported why it's aliasing every single time you asked it. You have made alternative claims about what's happening on screen, yet made exactly zero (0) posts supporting your hypothesis. Look's like I accurately described (You)
>That space being the pixels on the screen, since it’s pixel artAgain, fundamental misunderstanding. The file of the sprite is rendered onto the screen, but it's not like pasting a png onto the screen and choosing exactly what pixels it takes up. It's rendered in space and it, as well as the camera, moves around to the point where in many frames the sprite pixels don't line up with the screen pixels. It being a sprite doesn't change this
>pixel are misplaced to look badThat's what aliasing does when you have pixels that don't line up with the screen pixels
>misreading the imageAnon, the sprite is rotated 45 degrees. Left side is what the original sprite is, but at a 45 degree angle. But sprites are made up of pixels, which are squares/rectangles, so they can't just rotate and be displayed the same. So the right image shows how it looks if you render the sprite. It's the exact same concept as what we're discussing. Pokemon sprites are 2D and made of pixels, and when they move certain ways they don't line up
>there are examples of hand drawing every frameAgain, I concede this solves aliasing, but it mandates sprites over models
