For plain 2D there are some problems with both methods. you will get smooth movement of sprites only when you are using integer steps (eg. x=x +2). If you use the described correction codes, x would maybe incremented like this: x=x + 1.32. so the sprite would move only every so and so-th time, resulting in jerky motion. You may decide to staticly sync your game to 60 Hz and please the user in the readme to set the monitor to 60 Hz for ultimate fun. If he plays at 85 HZ, it will only run to fast. There has been some code to force a new frequency, but I think that's really unfriendly to the user, and even dangerous for the hardware.
a solution for this dilemma is to use virtual 2D using 3D Sprites. They can be moved by steps smaller than 1.0. This system also allows a lot of powerfull things like fast rotation and scaling, as well as semitransparent things and additive blend modes for pyro fx etc.
There are several libraries for virtual 2D, some of them offer a list of commands that are replacing their 2D counterparts.
a solution for this dilemma is to use virtual 2D using 3D Sprites. They can be moved by steps smaller than 1.0. This system also allows a lot of powerfull things like fast rotation and scaling, as well as semitransparent things and additive blend modes for pyro fx etc.
There are several libraries for virtual 2D, some of them offer a list of commands that are replacing their 2D counterparts.