mouse lag & how it can be fixed for good (not by the users though)

[Preacher0815 1]

Hello everybody,

just got the game today. There seem to be a lot of things wrong with it, but the straw that broke the camel's back was that there doesn't seem to be a hardware cursor implementation for the mouse pointer.

As you might or might not know, a hardware cursor is another buffer in your video card's memory specifically used for the mouse pointer. It is drawn as an overlay over the frame buffers that hold the game's graphics and works independently from these. This means that no matter how low your FPS in the game are, the mouse pointer is always fast and responsive, kind of like the mouse pointer in Windows itself. Not using hardware cursor, the mouse pointer is drawn directly into the frame buffers. This means that its position is updated only when a new frame is shown on the screen.

The delay between the movement of your mouse hand and the mouse pointer's response on the screen not just feels extremely strange, you also have to double check whether or not the mouse pointer is in the right place. Two factors you just can't have if you're trying to immerse yourself in a game.

This is a request for Bohemia Interactive to implement such a hardware cursor.

[harbinger 1]

With all due respect - that's not quite how it works.

The framebuffer passes everything to the display - cursor and all - which is then remapped to the display itself, which does it's own thing to render the final view depending on it's inherent capabilites.

The mouselag is not caused by any hardware, it's a rendering effect. It cannot be solved by any hardware, who is going to code that for multiple hardware platforms when there is a nice easy software API?

In the bad old days of IRQ's and serial / Microsoft / proprietary mice you might have a point - but it's simply not the case the days.

[Preacher0815 1]

Yeah you're right, it's got nothing to do with the actual silicon. But I didn't come up with the term "hardware cursor", that's just what it's called. The lag is indeed a rendering effect, caused by that missing third buffer (frame buffer 1, frame buffer 2, "hardware cursor" buffer). With a hardware cursor enable game, the frame buffers don't actually pass -everything- to the screen, only a part of it. You never wondered why the mouse pointers of some hardware cursor enabled games don't show up in some screenshots?

More explanations can be found

here

here

and here

[mondoshawan 1]

With all due respect - that's not quite how it works.

The framebuffer passes everything to the display - cursor and all - which is then remapped to the display itself, which does it's own thing to render the final view depending on it's inherent capabilites.

Erm, not quite. :j:

The OP actually had it more technically correct -- a hardware cursor is an image overlay added in the near last stage in the rendering pipeline on the card just before the blitting step. The displays connected to your video card do very little aside from use phase-lock-loops to sync to the output display data and turn on and off pixels on the display. True, they do some image modification, depending on the display, but they do flatly nothing with mouse cursors. All the display sees is a stream of bits representing each frame.

The mouselag is not caused by any hardware, it's a rendering effect. It cannot be solved by any hardware, who is going to code that for multiple hardware platforms when there is a nice easy software API?

I don't think the OP was talking about hardware creating this effect -- they know it's caused by rendering a mouse cursor in software routines instead of letting the video hardware take care of it. He's asking that BI implement the use of a hardware cursor instead to get rid of the lag caused by the extra compositing step in software.

The problem can, in fact, be alleviated by using a hardware cursor -- especially since the DirectX APIs actually call for it. See also this MSDN article about the mouse functionality in DX9 and the last line which states that DX9 will use hardware cursors when it can.

Also note the following changelog link which notes that standard Windows GDI calls are used in DX10 and up, which should directly manipulate hardware mouse cursors.

I should also note that the hardware cursor technically is being used insofar as they are disabling it and simply reading mouse events from the xinput event queue or polling for mouse coordinates. This is likely because hardware cursors are less colorful and are generally less attractive than a comparable software cursor.

It's still no excuse for usability. :(

Edited October 2, 2012 by mondoshawan
Misunderstood the previous poster's earliest point.