Is this “allowed” ?
g.drawImage(player, (int)playerX, (int)playerY, this);
My thought was that in my class, the playerX and playerY would keep it’s “true” float value. And then chop off the deciamls when rendering.
This will, I think, result in a more accuarate speed because it doesnt lose the decimals every cycle.
But it looks wrong for some reason.
There are no other (efficient) alternatives, so that’s fine.
There’s nothig wrong with casting floats to ints (except that it rounds towards 0)
One thing to watch out for while typecasting - always do it at the last step when possible. Since rendering is usually the last step in your game cycle, it’s fine.
Keep in mind though that java2D can only render ints which means that a slow movement stutters due to the loss of precision. You can easily get away with a game update rate of 30 and render rate capped at 30 and keep things smooth with only integer movement rates. Another reason why java2D sucks for rendering.
Are you claiming that other things can render coordinates as floats? E.g. render at (10.5, 10.5)? So rendering only half of the eleventh pixel on both axises?
No you cannot render sub pixels as there are none.
Thing is, java2D looks like pooder at low movement speeds where opengl does not. I think this as to do with the way in which opengl renders.
That was kind of my point. 
However, I haven’t really looked closely at the difference of how slow move speed looks with OpenGL vs Java2D, so I wouldn’t know of the difference. 
There is no higher accuracy than a pixel accuracy, this is a hardware limitation. The way you do it is pretty much optimal: using floats and only casting them to ints when rendering.
Only if you are working with tile maps you may need to pay close attention to the way things are rounded: if one row of tiles gets its position rounded up, and the next round rounded down the result may be a tiny but very noticeable gap. So perhaps in that case you could try rounding up or down to avoid this. But that doesn’t seem necessary in you case.
Yes and no. Both Java2D and OpenGL can use interpolation to give the appearance of sub-pixel accuracy through interpolation. As the Java2D drawImage calls only take ints, you have to use the form that takes an AffineTransform, and also make sure that interpolation is set to bilinear or bicubic. Of course, you didn’t want this to work quickly, right? ;D
Depending on your algorithm, using icode(playerX + 0.5f)[/icode] might be better - will have the effect of rounding.
You can use translate(double tx, double ty) together with bilinear interpolation to preserve subpixel movement inside an image but the edges won’t be affected. This’ll be really slow unless it’s hardware accelerated though. Plus it’s the best you can do without any hardware antialiasing like multisampling or supersampling.
This was what I was thinking about when deciding whether to round the playerX itself or to typecast it.
If you hold down “left” for lets say 1minute. You are gona lose a small amount(0.1-0.9) every time you updade. And in the long run it will be a pretty big difference. Wouldn’t it?
I am using interpolation. But I think im using it wrong because I didnt understand anything of that 
I use it when updating, for example, movement.
playerX += 3.0f*interpolation;
I missed out that you’ll probably need the antialiasing hint too. That still might not work with drawImage() though. See this blog post from 2007 - http://weblogs.java.net/blog/campbell/archive/2007/03/java_2d_tricker.html. Not sure if that’s still accurate. I’ve seen code in the Java2D implementation that seems to treat blitting sub-pixel positioned images differently. As you said, unless this is on an accelerated pipeline, it’s going to be slow.
Different meaning (well usage) of interpolation.
g.setRenderingHint(RenderingHints.KEY_INTERPOLATION, RenderingHints.VALUE_INTERPOLATION_BILINEAR);
Sigh, and now I got even more reading to do…
EDIT:
WOW, It looks so much better now 
I can’t stop looking at it -.-