Recommended Posts

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

0

Share this post

Link to post

Share on other sites

Using your own cursor class may be tricky. And please anyone correct me if I'm wrong. I have followed windows evolution from the beginning and from what I beleive, the cursor is hardware implemented now. Meaning that the card handles it and it's movement, which is why it's so speedy and precise and independant of the operation of windows itself. It's called hardware cursor. Look it up on google. I'm not sure, but you could probably change your class to use hardware cursor. But if your just putting the cursor quad in with the rest of Direct3D vertex data then you are stuck with the speed of the rest of the data.

Hope this can give you a lead in the right direction.

-Devin

0

Share this post

Link to post

Share on other sites

Hardware Cursor It is impossible to build a high-performance graphics subsystem if the cursor needs to be drawn using software. This is not much of an issue, since many DAC's today support hardware cursors, and many/most graphics cards provide this function.

Share this post

Link to post

Share on other sites

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.

Share this post

Link to post

Share on other sites

Original post by RyannI'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

0

Share this post

Link to post

Share on other sites

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.