Quote:
Originariamente inviato da TheDarkAngel
come fa ad avere un lag di 1ms?
l'usb è stata fatta per fare 125herz...
mah... non capisco...
|
Trovi tutto qua se ti va di leggere:
http://razer.tigga.org/phpBB2/viewtopic.php?t=3129
E qua:
http://razer.tigga.org/phpBB2/viewto...asc&highlight=
Questo è quello che spiega uno dei realizzatori:
"First, a couple of facts to clear up the confusion on the driver end ...
Windows XP and the USB low speed HID protocol supports an 8 BYTE data packet = 64 bits maximum size.
Windows XP restricts the USB low speed HID protocol to an 8ms polling rate contrary to USB spec. Windows 2000 and ME comply with the USB spec. This is why we had to find another way around instead of increasing polling rate, it won’t work in WinXP (but it will work, in OSX and Linux, for instance).
The “8 bit” data packet is just a convention that most mice use to report X/Y information. There is in fact no such restriction in Windows, as long as the total information sent, including things like button presses etc, do not exceed 64 bits. How much data is apportioned to X/Y is determined by the FIRMWARE of the mouse, the default drivers on the OS will take their cue from the firmware and receive data accordingly (the beauty of USB plug and play).
The problem with 8 bits for X/Y info is well known. -127/+127 (left/right) is the maximum info that can be sent, resulting in a very low maximum top speed of around 11” per second at 800dpi and 6400 frames per second.
On top of this problem, the old MX500 did not have buffer overflow protection, so if it exceeded +127 instead of staying at +127, it would either error and reset to zero, or worse, reset to -127, resulting in the mouse going in the OPPOSITE direction as fast as possible!
With 12 bits, the maximum is -2048/+2048, with 16bits the maximum is -32k/+32k.
Here's what we discovered about a competitor's "gamer mouse".
The "gamer mouse" defaults to 800dpi with 400dpi available via Mouseware install.
However, the "gamer mouse" continuously sends a normal legacy 8 bit data packet (for compatibility), and a 12 bit data packet which WinXP can recognize and use if this mouse is set to 800dpi mode.
Whether or not the “zeroing”/”negative acceleration” error has been fixed is hard to confirm, but it appears so.
Razer Diamondback implementation is like this:
1ms is implemented, BUT, it only works in Win2k and other OSs that properly support the USB protocol. It does NOT WORK in WinXP which forces low speed HID devices to 8ms (you can’t set it lower, and you can’t set it higher).
An 8 bit/16bit solution has been implemented, much like Logitech’s 8/12bit solution. This was not present in the 1ms units that we sent Blueprints for testing, hence they may have experienced negative acceleration in WinXP in these test units. WinME and Win2K users would not have noticed this since the 1ms poll rate setting would have been accepted in the firmware by the OS. The 8bit part of the data packet should never be seen by the OS, which should just throw this info away. However, it’s there JUST IN CASE someone decides to plug the mouse into a USB equipped machine running Win95 or has a USB port that is nonstandard, which is highly unlikely since this mouse is meant for gamers.
The 1ms lag feature won’t work in WinXP, and the majority of western gamers do run WinXP. The 16bit data packet completely resolves this issue. The best performance ironically will be achieved by those running Win2k."
Comunque la situazione attuale XP/2000 la sapevo, quello che mi interessava era la proiezione futura, non vorrei che per qualche motivo il 2000 possa non essere adatto ai nuovi titoli, se lo escludete ben venga, vorrà dire che appena posso faccio il passo
