On 24/12/2015 at 20:29, xxxxxxxx wrote:
One way to minimize the effects of rotating the bitmap would be two fold:
1. Make the bitmap square and large enough so that the 'important part' never intersects an edge (easy enough). Also, if you can use transparency, you mitigate the issue of background altogether - though this might be more difficult in the rotation process (??).
2. If you know the circular region of interest (the 'important part'), then you can restrict the pixels being rotated to a specific 'circular' region. This should not only minimize 1. but also increase performance.
When I made a node-based system in a User Area (UA), each node instance maintained a location (UL) and size parameter relative to a virtual plane. The derived UA class maintained the offset and extents of this virtual plane with respect to the UL of the UA 'view'. This allowed 'scrolling' of the UA virtually as a window into the virtual space.
With that in mind, if you are handling mouse clicks over the dials, you can use InputEvent() and check the dial location/size against the cursor location. In my case, it was a simple bounding-box check. For something like a rotated dial, for precision, you may need to refine the bounding check, say, using the angle to determine the diagonal of the box (of the two possible) and see how many pixels away from the pixels intercepted by that diagonal the cursor is.
ETA: Note that you would have four special cases involving the dial at 0/90/180/270 since the bounding-box would be more of a bounding line.
ETAM: Scratch the bounding-box checks. If you know the center of the rotation and the radius of the dial, you can easily determine where the cursor is with respect to the dial by calculating the angle and radius of the cursor point relative to the rotation center. While this requires sin/cos, you could simply use a sin/cos table to avoid the function calculations.