I would like to draw an oriented line toward a target depending on a specific angle calculated via tangent which will give a radian result.
As far as i know, to get a precise rotation, i have to use a double
value in order to express a correct radian.
However, Spritebatch.Draw
requires a float
value as rotation:
public void Draw (
Texture2D texture,
Vector2 position,
Nullable<Rectangle> sourceRectangle,
Color color,
**float rotation,**
Vector2 origin,
float scale,
SpriteEffects effects,
float layerDepth
)
If i convert the double
value to float
, the angle is incorrect and it will miss the target i am expecting to intersect.
How can i draw the correct oriented line based on my double
instead of float
?
The best case could be to trace the line inside the Update()
instead of the Draw()
but i think i'm not enough experienced to achieve that with a thing like Vector2.Transform()
because i can't visualize what it will do and i can't find a proper noob-oriented explanation.
I don't think you're going to be able to get any more precise than that. You're using XNA, which means you're stuck using XNA's API. There is no overload for Draw
that takes a double
there. Just float
.
Graphics cards don't have great support for doubles anyway. Consider this link: https://msdn.microsoft.com/en-us/library/windows/desktop/bb509646%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396
That talks about the different scalar types that HLSL can support. It does list double
as an option, but it states that
You cannot use double precision values as inputs and outputs for a stream.
XNA is actually a rather thin wrapper over DirectX, so I wouldn't expect it to support much in the way of doubles. In fact, I'm having a hard time thinking of any game framework that uses double
. WPF is the closest I can think of, and that's a UI framework, not a game dev framework.
For the purpose of a video game, it's rather rare that float
isn't precise enough for what you're doing. I suspect that there's either a separate, genuine bug that's preventing you from getting things accurate enough (which even double
wouldn't save you with), or an entirely different approach that you could take that would get you around it.
I know you already thought of this, but if precision is really the only problem here, you could do the math separately, ahead of time, and then just convert it to a float when you pass it in to the Draw
call.