¿Sabe qué, señor
@Falkiño ? ¡Pues que tiene usted toda la razón! Me puse a toquetear directamente sin pensar en eso. Y eso que antes de comprar ya había visto lo de la aplicación oficial. Mejor primero actualizar y luego a ver que pasa.
En todo caso, ando muy verde en mandos modernos y soporte en PC, y menos en Linux. Voy a tener que investigar esto a fondo.
No obstante, pude hacer una breve calibración del analógico con una aplicación que encontré, y los controles que al principio en GoldenEye eran miserables pasaron a ser mucho mas potables.
Pero si, a actualizar se ha dicho. En mi caso tendrá que ser mediante una máquina virtual, al no usar ya windows directamente
------------------------------------------------------------
EDITO: Pues nada, ya actualicé y también usé la función de calibrado del stick con la app oficial, y lo que he descubierto en el proceso es decepcionante:
Para explicarlo bien, primero explico un par de cosas sobre como funcionan los sticks y mandos modernos.
Primero los sensores del stick producen una señal analógica (resistencia-voltaje, capacitancia) y un ADC (Analog to Digital Converter) los convierte a una señal digital de alta resolución. Luego un otro proceso usa un rango mas limitado dentro de ese rango "crudo/raw" y genera el rango normalizado accesible para el host/anfitrión (tu PC, consola, movil...). Por encima de esto, además, el mando puede almacenar y enviar al host una "máscara" de calibrado, definiendo la zona muerta y los máximos de rango sobre el rango normalizado de antes.
Una vez entendido esto, explico lo que hace MAL el 8BitDo64:
Primeramente el "trozo" del rango RAW que convierte a normalizado (0-255 en este caso) queda DENTRO del limitador de movimiento y no alcanza a tocar. O sea: Tu mueves el stick, y alcanzas 0 o 255 estando aún lejos de tocar el limitador de movimiento (el octágono de plástico; en este caso), o sea, que puedes "saturrar" el movimiento y aún ir mas lejos hasta tocar, sin que todo ese movimiento cuente para nada. Alcanzas el máximo de movimiento lógico antes de alcanzar el físico. Esto debería ser al revés.
-En segundo lugar, están la aplicación oficial, que hace un proceso de calibrado, pero por lo que he podido ver, lo hace sobre el rango normalizado que no alcanza el lmite, y aún encima lo hace mal, porque sigue dando zona muerta y limita el movimiento aún mas adentro del rango normalizado que ya es corto.
Esto se ve claramente durante el proceso de calibrado si uno mueve el stick lentamente hacia una esquina y ve que alcanzas el límite en pantalla mucho antes de alcanzarlo en el stick real. Está calibrando sobre una base incorrecta que no corrige.
Un calibrado correcto trabajaría con los datos RAW del ADC para corregir el rango que se traduce a rango normalizado, pero esta aplicación no parece hacer eso. Solo calibra sobre los datos ya incorrectamente normalizados y aún aplica una máscara de calibrado sobre ellos aún mas limitante. De forma que cada vez que conecto el mando al PC, el mando reporta esa mascara de calibrado al PC.
Uso en Linux un paquete llamado jtest-gtk. Cuando conecto el mando en D-Input, y voy a la página de calibrado encuentro lo siguiente:
De un rango de 0 a 255 (donde 0 es izquierda y 255 es derecha), aún me aplica una "máscara" con un mínimo de 15 (osea 16 unidades perdidas a la izquierda, de 0 a 15) y un máximo de 239 (otras 16 perdidas a la derecha, 255 a 239). Además de eso, también define una zona muerta de 30 unidades entre 112 y 142.
Bien... tras un calibrado con esa aplicación, los nuevos rangos quedan an 0-255 y una zona muerta nula entre 127 y 127, justo en el medio.
Por un lado, tiene el aspecto positivo de que la zona muerta es "virtual" y se puede anular porque el mando no la impone por hardware. Los datos llegan al host, y la máscara que los tapa se puede anular dependiendo del software disponible. Por otro lado, la máscara innecesariamente impone zona muerta y limita aún mas el rango de movimiento normalizado que ya de por si es mas corto de lo que debería.
MENUDA CHAPUZA!
Esto no es una limitación técnica, si no un mal hacer.
LLevaba años escuchando historias de que los mandos modernos no replican bien el original de N64 y parecía que es que fuera algo místico, con mi mapa mental de lo que es un stick analógico, no alcanzaba a entender cómo podía algo tan simple no hacerse bien. Y ahora lo entiendo. Es por dejadez.
----------------
Ya en otros aspectos: el stick podría tener un poco mas de resistencia, resulta un poco flojo de mas, pero no sería tan malo si no fuera por el mango y la posición del gatillo y el stick. Recuerdo que con un mando original el agarre me permitía apuntar de forma estable y disparar sin que eso me moviese el punto de mira (o la posición de la cabeza de Bond/Joannna con control 1.2), pero aqui, entre el mal agarrey la poca resistencia del stick, al tratar de disparar, se mue mueve el apuntado.
Vi a un tipo en YouTube que parecía saber de qué hablaba, explicar que no estaba convencido del mando pero que lo compró y le parecía casi perfecto... Está claro que tenemos diferentes conceptos de "perfección".
Con controles 1.2 en GE y PD con mando original, yo llegué a alcanzar un control que me satisfizo mucho.
Todo el mundo en YouTube constantemente se para y apunta manualmente con R incluso para enemigos cercanos. Yo apenas lo usaba para muy lejanos, El resto, simplemente usando el stick sin R, Y SIN AUTOAPUNTADO. y de maravilla.
Con este mando... imposible. no se puede.el rango está mal aún despues de calibrar y cuando disparas se te mueve todo.
No se hasta donde me valdrá para otros juegos. Pero creo que trataré de devolver o vender el que aún no abrí y no se si acabaré vendiendo también el que si he probado.
![[+risas]](/images/smilies/nuevos/risa_ani3.gif "más risas")
.
