"sswift, if 2 pixels can represent 1 coordinate using this method, what's keeping it from adding jerkiness to the movement?"
Everything is drawn using floating point values. So let's say my game's virtual resolution is 800x500. If the screen's resolution is 1600x1000, then that means that 0..0.5 in virtual coordinates maps to 0..1 on the real screen, and 0.5..1 in virtual coordinates maps to 1..2 on the real screen. So in this setup, half a virtual pixel maps to one whole pixel on the real screen. And one whole virtual pixel is represented with two pixels on the real screen.
If you were to move an object horizontally in whole virtual pixel increments, then it would move two pixels on the real screen. However, that only applies to a resolution where the ratio is 2:1. That's not likely to be the case most of the time. In that case, if you move the object whole virtual pixels, then sometimes it will be drawn pixel aligned at the true resolution, and sometimes it will be drawn misaligned with each pixel of the texture halfway under one screen pixel, and halfway under another. The 3D card would use the mipmaps to filter the pixel in that case, and the object might appear blurrier depending on just how high res it was in the first place.
What I'm trying to say, in as simple terms as I can muster, is that the sprites are filtered when they're drawn, so when they're halfway under a pixel they're drawn as if they're halfway under a pixel, they're not shifted to a whole pixel boundary. Also BlitzMax supports floating point coordinates for drawing images, and I draw and move all my sprites using floating point coordinates, so even when I was making the game specifically for 800x600 res, the sprite would still be drawn halfway under a pixel much of the time. That's how 3D games work, and while it does make the graphics a little blurrier, the movement looks smoother.
In short, it's not an issue. And when you're trying to calculate the mouse coordinates, if you're scaling 1024x768 to 800x600, yes, if you round everything to integers some mouse coordinates will share the same virtual pixel coordinate, but if you don't use integers then every pixel will map to a unique virtual location, which won't neccessarily be pixel aligned. But if you draw your mouse cursor using floating point coordinates, it will draw right where it should draw, halfway over a pixel if need be, so you won't see any issues.
I hope that explains things. This sort of code isn't intended for applications like a paint program where pixel perfect accuracy for everything is desirable. :-)
Everything is drawn using floating point values. So let's say my game's virtual resolution is 800x500. If the screen's resolution is 1600x1000, then that means that 0..0.5 in virtual coordinates maps to 0..1 on the real screen, and 0.5..1 in virtual coordinates maps to 1..2 on the real screen. So in this setup, half a virtual pixel maps to one whole pixel on the real screen. And one whole virtual pixel is represented with two pixels on the real screen.
If you were to move an object horizontally in whole virtual pixel increments, then it would move two pixels on the real screen. However, that only applies to a resolution where the ratio is 2:1. That's not likely to be the case most of the time. In that case, if you move the object whole virtual pixels, then sometimes it will be drawn pixel aligned at the true resolution, and sometimes it will be drawn misaligned with each pixel of the texture halfway under one screen pixel, and halfway under another. The 3D card would use the mipmaps to filter the pixel in that case, and the object might appear blurrier depending on just how high res it was in the first place.
What I'm trying to say, in as simple terms as I can muster, is that the sprites are filtered when they're drawn, so when they're halfway under a pixel they're drawn as if they're halfway under a pixel, they're not shifted to a whole pixel boundary. Also BlitzMax supports floating point coordinates for drawing images, and I draw and move all my sprites using floating point coordinates, so even when I was making the game specifically for 800x600 res, the sprite would still be drawn halfway under a pixel much of the time. That's how 3D games work, and while it does make the graphics a little blurrier, the movement looks smoother.
In short, it's not an issue. And when you're trying to calculate the mouse coordinates, if you're scaling 1024x768 to 800x600, yes, if you round everything to integers some mouse coordinates will share the same virtual pixel coordinate, but if you don't use integers then every pixel will map to a unique virtual location, which won't neccessarily be pixel aligned. But if you draw your mouse cursor using floating point coordinates, it will draw right where it should draw, halfway over a pixel if need be, so you won't see any issues.
I hope that explains things. This sort of code isn't intended for applications like a paint program where pixel perfect accuracy for everything is desirable. :-)