Mouse Input Lag #3779
Replies: 7 comments 7 replies
-
|
What emulated CPU speed? From what I know, PCem does rather simplistic mouse emulation - update after every CPU frame and not emulating actual update rates. So the slower the emulated CPU, the smaller the CPU frame, the more frequent the mouse updates, the smoother the mouse. 86Box, on the other hand, actually emulates the mouse update rates so you need some tool (ps2rate or Microsoft IntelliPoint) to raise from the default (usually decided by the combination OS and BIOS) that tens to be quite low (my logging sessions have shown rates as low as 40-something Hz). |
Beta Was this translation helpful? Give feedback.
-
|
As for the serial mouse, nominally, we do the same thing as PCem - updating after every CPU frame. But there's a catch - PCem blasts the serial data bytes at the guest instantly while we emulate the actual serial transmission speed, and the Microsoft serial mouse uses a speed of 1200 bps. That's going to limit the amount of packets per second by a lot, the Logitech C7 serial mouse technical reference actually warns about that. So PCem achieves its universal smoothness (that also isn't really smooth on faster emulated CPU speeds, anyway) by cutting down on accuracy. 86Box emulates the mice more accurately but that's going to mean lower report rates in some case, much as would occur on real hardware. In some cases, eg. for PS/2 mice, there are remedies (as said above, ps2rate or Microsoft IntelliPoint) but in other cases (eg. serial mice), there is unfortunately none. But you can set the MS/Logitech bus mouse (not InPort) with the rate set to continuous to have something more like PCem. |
Beta Was this translation helpful? Give feedback.
-
|
I'm curious as to which guest operating systems you've tried? I have noticed windows 9x leaves the ps/2 rate at whatever is set by the bios (which can be quite slow). 86Box leaves this as-is for accuracy purposes. There's a program called Another observation: It seems that NT 4 and greater will in fact set the ps/2 rate up much higher by default, even when the bios sets it to a low initial value. In my testing NT4, 5, 5.1 all have extremely smooth mouse performance in 86Box. I have also observed the same effect in other linux distributions (excluding 90s distros) such as early versions of ubuntu. Although overall the system will run slow on a pentium II, the mouse is extremely smooth because the ps/2 rate gets set up to the maximum rate by the OS. Do you have a system that you could share for us to check? One where you're having sluggish mouse performance. I'd also recommend trying NT 4 with a ps/2 mouse and seeing if the results are better. |
Beta Was this translation helpful? Give feedback.
-
|
Agree. 86Box has a serious mouse lag. Compare Rise of the Triad on 86Box and DosBox. Difference is astonishing. |
Beta Was this translation helpful? Give feedback.
-
|
I reiterate coldbrewed's question above:
As for this:
I'd like to see a comparison with real period hardware, not with DOSBox. Given how much faster disk (including floppy and CD-ROM) access is on DOSBox compared to real old hardware and 86Box, I'm inclined to believe their mouse performance is also unrealistically fast. |
Beta Was this translation helpful? Give feedback.
-
|
I believe I have the same problem. I created a 1:1 replica of a real computer on the 86box, and the mouse has a delay, if I move quickly from side to side, and suddenly stop, I can see the cursor "finishing" the movement, a type of input lag of half a second. My machine is emulating at 100% all the time, even when opening Windows Explorer. PCEm also has a delay, but it is much smaller (and more tolerable) |
Beta Was this translation helpful? Give feedback.
-
|
Input lag of half a second? I've never experienced anything like that. What emulated graphics card are you using? Perhaps whichever you're using, has incorrect timings that make it laggier than real hardware. |
Beta Was this translation helpful? Give feedback.
-
|
Perhaps there are two problems meeting here. Mouse responsiveness and redraw speed. I've tried DosBox, PCem and 86Box and have real hardware in mind. I am comparing in pure DOS in text mode. FreeDos or Win98 Dos, Volkov Commander or mouse test utilities (gtest.exe, mousecc.exe), gmouse or ctmouse, logitech mouse driver. Different host PCs, different graphics cards, Windows 10. Guest was 486 with Intel chipset, Intel DX-25, 8 MB, T8900D. Changing the processor for a faster one, or changing cycles had no significant effect. The response and redraw speed on real hardware of this configuration in text mode was snappy. I estimate about 10 observable mouse cursor positions with very fast mouse circling. Similar to the 60 Hz LCD in Windows today. DosBox response and redraw are very snappy, response maybe a bit slower than real HW. (At about 4000-12000 cycles.) With fast horizntal mouse oscillation from one side of the screen to the other, certainly 8 cursor positions are displayed, including the extreme positions. (But you can see in the video that the cursor doesn't always reach the other side of the screen.) PCem is a bit slower both on response and on the speed of redrawing. With an emulated serial mouse, I observe 6 displayed cursor positions while oscillating. (ctmouse /R1 /M) 86Box 4.2 with serial mouse response and redraw is slower than PCem. Only 4 displayed cursor positions when mouse oscillates. When using the emulation recommended by Logitech/MS Bus Mouse the response really improves and is about comparable to PCem. Hurray. But the redraw speed is still probably only about 4 cursor positions. However, when switching Render from QT SW, to QT OpenGL or OpenGL 3.0 Core, the redraw is even slower and it is downright easy to see the cursor arriving on the other side of the screen with a delay. Still, the cursor position only flashes in about 4 places on the screen. With OpenGL 3.0 Core, I've noticed several times that the rectangular text mode cursor briefly turns into an arrow - the windows cursor. |
Beta Was this translation helpful? Give feedback.
-
|
Are you comparing this to host hardware from the same period or to modern host hardware? Comparing mouse on emulated ancient hardware to modern host hardware is pointless. Modern mice have a vastly higher report rate than older mice. Thu bus also plays a part - serial is slow and is going to limit how many reports can be sent per second. For PS/2 - the default rate set by most older BIOS'es is low, and you need something like ps2rate.exe or Microsoft IntellISense or what it's called to have a proper rate. |
Beta Was this translation helpful? Give feedback.
-
|
In a previous post, I compared the response of an emulated 486 with an emulated serial mouse.
On these host PCs I compared the response of the DosBox, PCem and 86Box against how I remember the response on the 486 from the 90s. I compared in emulated DOS text mode. I also tried various Renders on the host PCs. In 86Box the emulated serial mouse had poor response compared to how I remembered. The Logitech/MS Bus Mouse was a response close to memory. Over the weekend I installed the 86Box on Nobara Linux with a 3.6 GHz i7 and GTX1070. In the 86Box, the emulated serial mouse had poor response compared to how I remembered. The Logitech/MS Bus Mouse was a response close to memory. GL renders were usable, the Vulkan option was not available. I didn't investigate thoroughly. Today I fired up a real old Pentium 166MMX with DOS and tested the response of a real serial mouse. With ball. I'm attaching a video shot at 60 fps. The LCD is very old from 2007. But even so, you can see the cursor response on the LCD compared to the mouse movement only 3-4 frames behind the mouse movement. That's 0.06 seconds. And this lag is not getting any bigger. The cursor is a bit delayed, but perfectly synchronized with the mouse movement. The cursor doesn't end the movement with more lag.
I hope you will be able to do this. Thank you. Real_P166_SerialMouse1.zip |
Beta Was this translation helpful? Give feedback.
-
|
Currently playing with 86Box under Win11 and Fedora 40 KDE/Wayland. I use ps2rate for 9x OSes and my panel is 240Hz, these seem to make mouse issues very apparent. |
Beta Was this translation helpful? Give feedback.
-
|
The guest is not even close to 240 Hz. Also, we support Vulkan on Windows as well, have you tried that? I also have no way of knowing the difference, given that I'm on a 60 Hz monitor. I also, again, recommend observing real period hardware and seeing how mouse movement is there, as opposed to comparing it to a modern host machine. |
Beta Was this translation helpful? Give feedback.
-
Yes but setting ps2rate from 80Hz to 200Hz gets me surprisingly close to my host.
Yeah, Linux is just smoother for me. However I don't insist that it's universally the case hence asking people having similar issues to try and confirm it. At the end of the day it could be host mouse driver/setup issue.
Unfortunately I have no access to real hardware. P.S. Are you against having two modes for mouse emulation? So people interested in accuracy could use current implementation while others would prefer performance/latency. |
Beta Was this translation helpful? Give feedback.
-
I would have no problem with that, the problems are more on how to implement that - I'd basically have to directly send the host delta's to the guest, but that would entail either writing to the guest directly from the UI thread where input is grabbed, which would mean cross-thread accesses, which I actually tried during the rework in 4.0 and it resulted in the guest mouse actually being slower due to the PIC emulation (for the IRQ's) not being thread-safe, or queue the individual delta's, but then you'd have a delay, anyway. But I have been thinking of how to solve the problem, I just haven't found a solution yet. |
Beta Was this translation helpful? Give feedback.
-
What happened?
Hello,
I have used 86Box and PCem for quite some time now and there seems to be an issue with 86Box. Not many people seem to talk about it but it's something I really notice. The mouse input lag in 86Box seems to be much worse than it is in PCem.
I've tried pretty much anything you cold think of:
-all versions of 86Box, including the latest builds (both 32-Nit and 64-Bit
-different host pcs
-different host pc mice
-different emulated mice in 86Box (serial, PS/2)
-different operating systems in 86Box
-emulation speed is always at 100%
-and so on...
I always compare it directly to PCem and real hardware. For example I use the exact same configuration as PCem and the same harddrive wich I just copied (I also made new virtual machines from the ground up in 86Box).
To compare the mouse behavior a little better I used Microsoft Paint in Windows and draw cricles. In PCem (and real hardware ofcourse) the circles are perfectly smooth, just like you expect them to. In 86Box however, the circles are weird, they have straight lines in them when you move the mouse a little faster, almost like it always skips a few frames or refreshes.
Thing is, if it would just be in paint than I would really care about it. But you do feel it as well when using Windows in 86Box. The mouse is all laggy. To me this is so annoying that I still use PCem instead of 86Box, even though I otherwise prefer 86Box over PCem.
I can't be the only one who notices this?
If you don't believe me just try it out for yourself. Open 86Box and PCem at the same time and go back and forth. You will see how much smoother PCem is.
Configuration file
No response
Operating system
Windows 10 and 11
CPU
i9 10850K and others
86Box version
5083
Build architecture
Windows - x64 (64-bit)
Build type
Download source
Official website (Jenkins, GitHub)
Additional context
No response
Beta Was this translation helpful? Give feedback.
All reactions