4) The method Xaer0 suggested may move the bullet several pixels at each time the formula is executed, which may lead the bullet to bypass something it shouldn't (such as a wall). The method that I suggested will give the bullet trajectory, pixel by pixel.
This might be a good place to point out that if you do collision detection in "pixel space", you are doing it wrong and should have a close look at why proper collision detection is very different from "checking for intersections every frame". After that you will realize why brute forcing collision detection by moving stuff in a painful pixel by pixel fashion to check every single one along the way is getting you down voted.
Sorry, but every time someone is throwing trigonometry at trivial problems it's making me cry.
Sorry I wasn't clear, but I never said he should use pixel by pixel approach on colision, just that this will give him the trajectory that he could use to calculate the collision in a simple way (not using vectors, which is way more complex).
1) It doesn't do the same thing, it calculates a starting point and a predicted end point. His method calculates a direction and will interpolate it.
There's no interpolation of any kind in Xaer0's code. The only thing it does is directly calculate the end point. The same end point whose components are curiously named "finalX" and "nextY" in your code.
Every dt it will move the bullet, this will interpolate its trajectory.
I took it from a code I use on a game where nextX and nextY was used, it was just adapted to fill the post.
PS: Love how people negativate others without posting a reason around here.