Hey, I'm developing GUI for XNA. I have created my own cursor class, which is rendered as a sprite (because of transparency, shadow etc.). Problem is, once the framerate drops below ~40 fps, cursor movement becomes dysfluent. I'm updating mouse position already in another thread, but drawing itself is still in the main thread after all other stuff is drawn. Is there any way how to reach smooth cursor movement even on low framerates? Thanks, Ryann

Thank you for an advice. I'm developing under XNA, there is encapsulation of DirectX device, but methods like SetCursor() ain't implemented (it seems). I couldn't find any other reference to hardware cursor under XNA.

Quote: Original post by Ryann
I'm developing GUI for XNA. I have created my own cursor class, which is rendered as a sprite (because of transparency, shadow etc.). Problem is, once the framerate drops below ~40 fps, cursor movement becomes dysfluent. I'm updating mouse position already in another thread, but drawing itself is still in the main thread after all other stuff is drawn.

The hardware cursor is often displayed as an overlay so updated independantly of the rendering loop, this is the preferred solution.
If you haven't got access to the hardware cursor, you can take measures to reduce the mouse lag issues (which is often the biggest part of the problem). First make sure, that the GPU doesn't get too far ahead of the CPU (event queries can do that). In worst case if you're GPU limited, the amount of commands in the pipeline amount for almost three frames (plus the time it takes for the monitor to actually show the new position of the cursor which can take one refresh cycle or more depending on your monitor.). At 40 fps, three frames is 75 milliseconds. If you limit yourself to one frame of batched commands (which is enough to allow parallelism.. unless your rendering load vary greatly per frame. Also it can defeat some optimizations in the drivers.), then your cursor will at most take 25 ms between the time you issue the draw command and the time it arrives on the screen.

You should also have a shortcut in your rendering processing for mouse position. For example if you have something like input -> game logic -> render whole world -> render cursor -> present, (in fact the order in which you render the cursor won't matter because you only track the inputs once) then you add potentially one whole frame of rendering time to the delay. If your whole cpu rendering time is also 40fps, that would make you display the cursor at 100 ms after the mouse input has been acknowledged by your program (or 50 ms after the change above). So you should have a way to feed the mouse position independantly of the game logic and rendering code (cutting the delay to 25ms again). You should also make sure that the thread that treats windows messages can treat messages in a timely manner (not once per frame but as soon as they arrive).

Mouse cursor will also appear jerky if your rendering time varies greatly from frame to frame.

If you drop way too much, and you cannot reduce the load, maybe you could cut your rendering frame into several parts (if the rendering is the culprit), or update your game logic at a lower rate than display (if the game logic is the culprit) so that elements that may play a "psychological" role into what the player think of responsiveness of your game are updated more frequently.

LeGreg

Well, I have thrown away my software cursor and I'm using just hardware one (Windows cursor). I have found out Windows cursor supports 32bit colors with alpha so my main problem is solved (shadow, transparency).

I just had to use imported native LoadImage() function to get the handle and then assign it to the application form cursor.

My function for loading cursor:

public void SetCursor(string filename){        form.Cursor = new System.Windows.Forms.Cursor(LoadImage(IntPtr.Zero, filename,  2, 0, 0, 0x0010));}