VOGONS


First post, by silikone

User metadata
Rank Member
Rank
Member

Any good documentation on how mice evolved into having wheels, optical sensors, extra buttons, and enhanced DPI? As far as I know, the wheel was widely introduced with the Microsoft Intellimouse released somewhere from 96 to 98. It was apparently succeeded by the Intellimouse Explorer in 99 that pioneered optical mice and two extra buttons. I don't know where it went from here, but I assume Logitech cloned and improved the cutting-edge mice of the time. I'm wondering which mouse was the first to feature high DPI modes that have proven essential for most gamers. Also, what kind of software supported the wheel and extra buttons during their introduction?

Do not refrain from refusing to stop hindering yourself from the opposite of watching nothing other than that which is by no means porn.

Reply 2 of 12, by j^aws

User metadata
Rank Oldbie
Rank
Oldbie

I came across this site a while ago regarding evolution:

http://renoir.en.kku.ac.th/courses/188473/mouse/mouse.html

BTW, optical mice have been around for decades - I was using one on a Sun workstation back in the early 90s, and they had high DPI when using a special mouse pad...

Reply 4 of 12, by d1stortion

User metadata
Rank Oldbie
Rank
Oldbie

Interesting topic. Likely, the switch from PS/2 to USB brought higher polling rates by default for way more precision; that could only be acheived with manual tweaking on PS/2 mouses and perhaps not every one of those supported that.

Also, I think the software part evolved even more than the hardware. I can't remember exactly how it was back in the day with PS/2 mice and I don't have one here, but at least the emulated USB mouse in Win98 DOS window feels weird compared to regular desktop operation. It's like if the vertical and horizontal axes had different sensivity.

Even with Windows games, especially pre-2000, I find that the mouse feeling strongly depends on the individual game. Quake 2 has a slightly jittery feel to it, similar to PS/2 mice, while Unreal has that mouse lag issue I posted about here once and still couldn't figure out the cause for it. So in that respect the situation has definitely improved for gaming. Funnily enough though, I find that modern gaming mouses complicate the situation again with their adjustable DPI settings and what not and especially the need for stupid drivers. I use a Logitech G400 on my main computer and the fact that it needs to be recognized by the driver on each bootup to load the correct settings is very annoying.

Reply 5 of 12, by VileR

User metadata
Rank Oldbie
Rank
Oldbie
d1stortion wrote:

the emulated USB mouse in Win98 DOS window feels weird compared to regular desktop operation. It's like if the vertical and horizontal axes had different sensivity.

I guess it depends on what you're running there... could it be text-mode constraints?

[ WEB ] - [ BLOG ] - [ TUBE ] - [ CODE ]

Reply 6 of 12, by silikone

User metadata
Rank Member
Rank
Member
d1stortion wrote:

use a Logitech G400 on my main computer and the fact that it needs to be recognized by the driver on each bootup to load the correct settings is very annoying.

I use a G400 myself without any drivers installed. DPI can be changed with the buttons on the fly.

Do not refrain from refusing to stop hindering yourself from the opposite of watching nothing other than that which is by no means porn.

Reply 7 of 12, by d1stortion

User metadata
Rank Oldbie
Rank
Oldbie

And that's exactly what I don't want. I don't have a need for DPI change on the fly, so I set it to a fixed value in order to prohibit accidental changes. The only way to do this is of course with their driver.

Reply 8 of 12, by d1stortion

User metadata
Rank Oldbie
Rank
Oldbie
VileRancour wrote:
d1stortion wrote:

the emulated USB mouse in Win98 DOS window feels weird compared to regular desktop operation. It's like if the vertical and horizontal axes had different sensivity.

I guess it depends on what you're running there... could it be text-mode constraints?

RTS games.

Reply 9 of 12, by leileilol

User metadata
Rank l33t++
Rank
l33t++

It wasn't until Windows Me (one thing Me is good for) and 2000 when smoother mouse rates were more common. Yes there's ways to hack that in 98 and earlier with different drivers and tweaks, but sometimes it can lead to compromises (i've seen oen 'smooth mouse for win98' that rendered my wheel useless)

I never had a high DPI USB mouse working smoothly in Win98 properly.

apsosig.png

Reply 11 of 12, by silikone

User metadata
Rank Member
Rank
Member
Hatta wrote:

You didn't need high mouse DPI back in the day, because your screen resolution was a lot smaller.

For the desktop, sure, but I wouldn't want to go back to 400 DPI for games, especially at their default mouse sensitivity.

Do not refrain from refusing to stop hindering yourself from the opposite of watching nothing other than that which is by no means porn.

Reply 12 of 12, by d1stortion

User metadata
Rank Oldbie
Rank
Oldbie

Interesting post from Carmack on the topic:

I spent quite a while investigating the limits of input under windows recently. I foudn out a few interesting things: […]
Show full quote

I spent quite a while investigating the limits of input under windows recently. I foudn out a few interesting things:

Mouse sampling on win95 only happens every 25ms. It doesn't matter if you check the cursor or use DirectInput, the values will only change 40 times a second.

This means that with normal checking, the mouse control will feel slightly stuttery whenever the framerate is over 20 fps, because on some frames you will be getting one input sample, and on other frames you will be getting two. The difference between two samples and three isn't very noticable, so it isn't much of an issue below 20 fps. Above 40 fps it is a HUGE issue, because the frames will be bobbing between one sample and zero samples.

I knew there were some sampling quantization issues early on, so I added the "m_filter 1" variable, but it really wasn't an optimal solution. It averaged together the samples collected at the last two frames, which worked out ok if the framerate stayed consistantly high and you were only averaging together one to three samples, but when the framerate dropped to 10 fps or so, you wound up averaging together a dozen more samples than were really needed, giving the "rubber stick" feel to the mouse control.

I now have three modes of mouse control:

in_mouse 1: Mouse control with standard win-32 cursor calls, just like Quake 2.

in_mouse 2: Mouse control using DirectInput to sample the mouse relative counters each frame. This behaves like winquake with -dinput. There isn't a lot of difference between this and 1, but you get a little more precision, and you never run into window clamping issues. If at some point in the future microsoft changes the implementation of DirectInput so that it processes all pending mouse events exactly when the getState call happens, this will be the ideal input mode.

in_mouse 3: Processes DirectInput mouse movement events, and filters the amount of movement over the next 25 milliseconds. This effectively adds about 12 ms of latency to the mouse control, but the movement is smooth and consistant at any variable frame rate. This will be the default for Quake 3, but some people may want the 12ms faster (but rougher) response time of mode 2.

It takes a pretty intense player to even notice the difference in most cases, but if you have a setup that can run a very consistant 30 fps you will probably apreciate the smoothness. At 60 fps, anyone can tell the difference, but rendering speeds will tend to cause a fair amount of jitter at those rates no matter what the mouse is doing.

DirectInput on WindowsNT does not log mouse events as they happen, but seems to just do a poll when called, so they can't be filtered properly.

Keyboard sampling appears to be millisecond precise on both OS, though.

In doing this testing, it has become a little bit more tempting to try to put in more leveling optimizations to allow 60 hz framerates on the highest end hardware, but I have always shied away from targeting very high framerates as a goal, because when you miss by a tiny little bit, the drop from 60 to 30 ( 1 to 2 vertical retraces ) fps is extremely noticable.

http://floodyberry.com/carmack/johnc_plan_199 … .html#d19980608