Obsługiwanie różnych precyzji padów

@Spine: stwórz proste narzędzie do testowania kontrolerów, podrzuć na forum (niekoniecznie tutaj) i poproś użytkowników o przetestowanie. Masz już nagrane dwa filmiki, więc będzie wiadomo co sprawdzać. ;)

@furious programming: to można sprawdzać we właściwościach kontrolera pod Windowsem ;)

Jest nawet webowe narzędzie do tego: https://gamepad-tester.com/

Spine napisał(a):

@furious programming: to można sprawdzać we właściwościach kontrolera pod Windowsem ;)

Jest nawet webowe narzędzie do tego: https://gamepad-tester.com/

ale to ty dzwonisz

Spine napisał(a):

Zero aplikacji diagnostycznych/debugujących/kalibrujących.

@Spine: tak, tyle że pamiętaj, że narzędzie systemowe może używać innego API do obsługi kontrolerów, a Unity innego.

obscurity napisał(a):

Spine napisał(a):

@furious programming: to można sprawdzać we właściwościach kontrolera pod Windowsem ;)

Jest nawet webowe narzędzie do tego: https://gamepad-tester.com/

ale to ty dzwonisz

Spine napisał(a):

Zero aplikacji diagnostycznych/debugujących/kalibrujących.

No tak... liczy się tylko ostatnie zdanie...
Dwa zdania poprzedzające nie mają żadnego wpływu na całość wywodu...

Najczęściej pady są demonstrowane podczas grania. Albo YouTuberzy pokazują jak pady są zbudowane, jak wyglądają i czym się różni wygląd różnych padów...
Zero aplikacji diagnostycznych/debugujących/kalibrujących.

Miałem na myśli, że YouTuberzy nie pokazują w swoich filmikach o padach, tego co mnie interesuje - aplikacji diagnostycznych itd. z ruchem drążków pada po okręgu.

Są kontrolery bez drążków https://store.steampowered.com/app/353370/Steam_Controller/
Jak coś, to leży w szafie i mogę sprawdzić co chcesz.

piotrpo napisał(a):

Są kontrolery bez drążków https://store.steampowered.com/app/353370/Steam_Controller/

Jeden drążek jest ;) Ten okrągły touch pad po prawej stronie mógłbym wykorzystać tak samo jak myszkę i być może tak właśnie jest on domyślnie mapowany w grach, więc w moim projekcie nie musiałbym nic zmieniać - myszka przesuwa niewidzialny celownik względem środka gracza i na tej podstawie określam kąt celowania (Atan2).

Jak coś, to leży w szafie i mogę sprawdzić co chcesz.

Dzięki za ofertę. Jak Ci się chce, to mógłbyś przetestować ten jeden drążek kontrolera.

1. Wejdź na stronkę https://gamepad-tester.com/ i naciśnij dowolny przycisk na testowanym padzie.
2. Możesz opcjonalnie zaznaczyć pole Test Circularity.
3. Wykonuj analogiem ruch okrężny powoli i obserwuj jak zmieniają się wartości.

Jeśli odczuwasz, że ruch zatrzymuje się na chwilę blisko X = 0 lub Y = 0, to znaczy, że osiowy deadzone występuje.

Znajomy dla mnie sprawdził kontroler oryginalny kontroler do Xboxa 360 i tam osiowy deadzone nie występuje.
Czyli na razie najtańszy i najstarszy pad z dobrymi drążkami to będzie ten dla Xboxa 360.

Na podróbce za ~60zł jest osiowy deadzone. Niestety nie mam pod ręką oryginalnego pada do Xboxa 360, więc pokażę wyniki z https://gamepad-tester.com/ dla podróbki oraz dla porówniania wyniki z oryginalnego pada Xbox OneSeries.

Podróbka Xbox 360:

Xbox One (najnowsza wersja):

Znajomy dla mnie sprawdził kontroler oryginalny kontroler do Xboxa 360 i tam osiowy deadzone nie występuje.

Rozebrałem swój, też do Xboxa ale podróbka. Na samych potencjometrach nie było martwej strefy w pozycji zero.

@jurek1980: Nie wiem dokładnie jak działają pady, ale chyba te całe potencjometry są podłączone do jakiegoś układu, który może jeszcze przeprowadzać na odczytanych danych jakieś korekty, zanim pójdą one przez USB do kompa, prawda?

Prawda. Myślę tylko, że mogą być też różne potencjometry i takie które mogą mieć realnie w pozycji osi pusty kawałek ścieżki żeby odczyt tego punktu był nie zależny od np. zużycia.

Spine napisał(a):

@jurek1980: Nie wiem dokładnie jak działają pady, ale chyba te całe potencjometry są podłączone do jakiegoś układu, który może jeszcze przeprowadzać na odczytanych danych jakieś korekty, zanim pójdą one przez USB do kompa, prawda?

Nie bardzo - do komputera przekazywany jest (był?) czysty sygnał. W domyślnych sterownikach wciąż masz kalibrację, w tych od producenta na ogół automatyczną kalibrację (bierze ekstrema dla osi z jakiegoś okresu).

Zakładam, że do padów wstawiane są tanie części i później próbuje się je programowo poprawić, ale jak masz syf na wejściu, to masz syf na wyjściu (może delikatnie przefiltrowany)

piotrpo napisał(a)

Nie bardzo - do komputera przekazywany jest (był?) czysty sygnał. W domyślnych sterownikach wciąż masz kalibrację, w tych od producenta na ogół automatyczną kalibrację (bierze ekstrema dla osi z jakiegoś okresu).

No ale jak czysty? Przecież USB ma D+ i D-, dwie linie. Mamy mnóstwo klawiszy a każdy joystic ma co najmniej 2 syganly na oś. O komunikacji pada bezprzewodowo już nie wspomnę. Wiem, że w grach/sterownikach jest jeszcze dodatkowa kalibracja, ale podejrzewam że to zaszłość która gdzieś tam pozostaje, np. kiedyś przy każdym podłączeniu jednej kierownicy zawsze musiałem robić kalibrację softową bo inaczej auto jechało własnym życiem. Teraz nikt już przy każdej grze takiej kalibracji nie wykonuje.
No nic, jeśli kogoś wprowadziłem w błąd to przepraszam. Nie siedzę w GameDev i budowie padów.

jurek1980 napisał(a):

No ale jak czysty? Przecież USB ma D+ i D-, dwie linie. Mamy mnóstwo klawiszy a każdy joystic ma co najmniej 2 syganly na oś. O komunikacji pada bezprzewodowo już nie wspomnę.

Gdyby kontrolery obsługiwały sygnał analogowy, to byłoby inaczej, ale o tym nie ma mowy. Mikrokontroler odczytuje stany potencjometrów i przycisków, a potem przesyła je po USB, wszystko działa cyfrowo. Problem polega na tym, że ów mikrokontroler może jedynie odczytać stan i wartości przesłać, a może też je najpierw samemu obrobić, przed transmisją.

Wiem, że w grach/sterownikach jest jeszcze dodatkowa kalibracja, ale podejrzewam że to zaszłość która gdzieś tam pozostaje, np. kiedyś przy każdym podłączeniu jednej kierownicy zawsze musiałem robić kalibrację softową bo inaczej auto jechało własnym życiem. Teraz nikt już przy każdej grze takiej kalibracji nie wykonuje.

Kalibracja nadal istnieje i istnieć będzie zawsze, bo każdy kontroler jest inny, stopień zużycia jest różny, więc aby móc otrzymać taki sam zestaw wartości cyfrowych, należy określić jakie są dostępne zakresy dla osi. I to właśnie się kalibruje — kręci się gałami, aby poznać ekstrema osi, a także określa się przybliżoną wartość pozycji neutralnej. Skoro wiadomo już jakie są zakresy, można je software'owo zmapować do wymaganych zakresów obsługiwanych przez API.

Mapowaniem wartości zajmuje się albo sterownik, albo API systemowe. Proces kalibracji urządzenia powoduje zapisanie ”gdzieś” wartości dostępnych dla danego kontrolera, które później są przesyłane do aplikacji. Można też odczytać surowe dane, a kalibrację oraz późniejsze mapowanie wykonać samemu, w całości po stronie kodu gry.

Takim przykładem jest stary dobry joyGetPosEx — normalnie pobiera się dane skalibrowane, ale można pobrać dane surowe, podając przy wywołaniu flagę JOY_RETURNRAWDATA. Natomiast rozmiar martwej strefy można pobrać podając flagę JOY_USEDEADZONE i w wyniku otrzymuje się stałą wartość, którą podaje nam sterownik urządzenia. Na temat DirectInput się nie wypowiem, bo nie znam, ale tam powinno być podobnie.

Moim zdaniem gamepady należy raczej traktować jako zamienniki klawiatury niż myszy.

Manna5 napisał(a):

Moim zdaniem gamepady należy raczej traktować jako zamienniki klawiatury niż myszy.

@Manna5: Czyli co? Jedna ręka ma używać pada do samego wciskania guzików, a druga ręka ma używać myszy?
To niepraktyczne i niewygodne. Pady są skonstruowane tak, aby trzymać je oburącz.

Np. w grze inFAMOUS 2 można jednocześnie wykorzystywać bardzo dużo elementów kontrolera:

• R1 trzymamy aby szybować,
• lewym drążkiem w tym czasie kierujemy gdzie lecimy,
• L1 trzymamy aby celować,
• prawym drążkiem celujemy,
• jednym z przycisków (okrąg, trójkąt, kwadrat, krzyż) strzelamy odpowiednim typem ataku.

I to wszystko używamy podczas szybowania :]

Na PS3 ograłem GTA V bez problemu gamepadem.
Na PC ograłem GTA V myszą i klawiaturą i też było spoko.

Ale GTA V to jest ten mainstreamowy typ gier, w których pad się sprawdza :]
Tam drążkiem przesuwam celownik, a nie wyznaczam kierunku celowania.

Ja po prostu daję graczowi wybór, czy gra klawiaturą i myszą, czy gamepadem.
I wielu innych twórców też to robi ;)

UPDATE

Od autora filmiku How to Fix Controller Input Snapping in Unity dowiedziałem się jaki model kontrolera do PS4 on posiada.
Okazało się, że jest to CUH-ZCT1. Mój kontroler do PS4 to CUH-ZCT2, czyli nowszy i niby lepszy.
Napisał mi, że "hadware'owy" osiowy deadzone nie występuje na jego kontrolerze i zdziwiłem się, bo u mnie występuje.

Kupiłem używany kontroler PS4, CUH-ZCT1 o numerze 4-472-348-04 G.
Sprawdziłem i drążki mają pełną swobodę! Bez przyciągania do osi.

Przydałoby się jeszcze sprawdzić, czy inne gamepady CUH-ZCT2 o takim samym numerze jak mój (4-594-645-31 G) też mają osiowy deadzone.
A także sprawdzić gamepady o innych numerach. Wtedy można by wykluczyć wszystkie nowsze gamepady do PS4 i uznać tylko te starsze za "dorobione".

In early September 2016, Sony confirmed a second version of DualShock 4 controllers, known as the DualShock Version 2 (CUH-ZCT2), which hosts slight improvements over the original DualShock 4, including USB communication, improved triggers and joysticks

Być może te improved joysticks to właśnie dodanie tego hardware'owego osiowego deadzone?
Jakiś inżynier uznał, że to będzie lepiej działać w grach na PS4 i zdecydował się na taki zabieg?

Przyleciał mi kontroler 8BitDo SN30 Pro z gałami. Sprawdziłem — całe szczęście nie wspiera przyciągania do osi:

To samo dla drugiej gałki — jest cacy. Będę go mógł używać bez żadnych ograniczeń i innych przeszkód, a także samodzielnie zaimplementować martwe strefy na potrzeby własnej gry (w końcu to proste jak drut, i jeszcze sobie histerezy dodam, a co!). ;)

Jednak nadal pozostaje problem z kontrolerami, które te strefy mają wbudowane — trzeba się przed tym zabezpieczyć. I o ile z poziomu kodu nie da się ich wykluczyć (co najwyżej jakieś protezy), to zawsze można dodać opcję do menu ustawień kontrolera, tak aby gracz mógł wskazać, czy jego kontroler ma takie przyciąganie do osi. Na tej podstawie będzie można stworzyć dwa tryby obsługi gałek — z własnymi martwymi polami, jeśli kontroler ich nie wspiera oraz bez, w przypadku np. tych ”popsutych” kontrolerów do PS4.

furious programming napisał(a):

Będę go mógł używać bez żadnych ograniczeń i innych przeszkód, a także samodzielnie zaimplementować martwe strefy na potrzeby własnej gry […]

No i właśnie zaimplementowałem przyciąganie do osi w swoim silniku. Sprawdziłem i wychodzi na to, że w Unity jest identycznie. Teraz przynajmniej wiem co w Unity oznacza Dead o domyślnej wartości 0.19 — jest to rozmiar kątowy strefy przyciągania, wyrażony w radianach. ;)

U siebie przechowuję połowę szerokości strefy, bo łatwiej go użyć w obliczeniach (kupka ifów i testy zakresów), a samo przyciąganie dotyczy nie tylko osi X i Y, ale też skosów. Co ciekawe, ustawiając rozmiar na 0.0, gałka działa w pełni płynnie, natomiast ustawiając maksimum, czyli π/8, gałka działa tak jak D-Pad i dostępnych jest tylko osiem głównych kierunków (w Unity będzie to π/4). Domyślnie mam ustawione π/32, co daje ~11° jako rozmiar całej strefy, podobnie jak w Unity.

To może niektórych dziwić, no bo niby po co przerabiać w ten sposób gałkę analogową na D-Pad. Ale zastosowanie jest całkiem sensowne — można mieć dostępne tylko główne kierunki (wzdłuż głównych osi i skosów), ale nadal mieć możliwość płynnej regulacji magnitudy. Czyli kompromis pomiędzy D-Padem, a analogiem.

Mi to wygląda na celową cechę tych drążków, a nie przypadek/błędy.

@Riddle: Możliwe...
Ale ta celowa cecha ogranicza użyteczność urządzenia.
Gierka, która chciałaby wykorzystać drążek do natychmiastowego, precyzyjnego wyznaczania kierunku, może działać tylko z częścią gamepadów dostępnych na rynku - zazwyczaj droższych niż Vakoss.

Spine napisał(a):

@Riddle: Możliwe...
Ale ta celowa cecha ogranicza użyteczność urządzenia.
Gierka, która chciałaby wykorzystać drążek do natychmiastowego, precyzyjnego wyznaczania kierunku, może działać tylko z częścią gamepadów dostępnych na rynku - zazwyczaj droższych niż Vakoss.

Próbuję Ci powiedzieć że zamiast podejść do problemu od strony: "ale pady mają zwaloną precyzję, trzeba to jakoś naprawić", podejdź do tego od strony: "aha, czyli twórcy padów specjalnie ściągają ruchy gałek pod ten X oraz pod narożniki - jak możnaby to wyłączyć i zczytać gołą pozycję?".

Myślę że możesz wtedy osiągnąć lepsze rezultaty.

Riddle napisał(a):

podejdź do tego od strony: "aha, czyli twórcy padów specjalnie ściągają ruchy gałek pod ten X oraz pod narożniki - jak możnaby to wyłączyć i zczytać gołą pozycję?".

Ale ja naprawdę próbowałem podejść od tej strony.
Problem w tym, że goła (RAW) pozycja uwzględnia deadzone.

Zobacz sobie np. na tej stronie: https://www.warframe.com/pl/gamepad

Pad PS4 - krzyżyk schodzi z osi razem z kółkiem i kropką, dopiero kiedy oddalę drążek od osi o odczuwalną odległość.
Pas Xbox Series X - krzyżyk reaguje na ruchy drążka, kółeczka są przyciągane do osi.

Krzyżyk ma symbolizować RAW input.

Spine napisał(a):

Riddle napisał(a):

podejdź do tego od strony: "aha, czyli twórcy padów specjalnie ściągają ruchy gałek pod ten X oraz pod narożniki - jak możnaby to wyłączyć i zczytać gołą pozycję?".

Ale ja naprawdę próbowałem podejść od tej strony.
Problem w tym, że goła (RAW) pozycja uwzględnia deadzone.

No to odczytaj Raw, Raw pozycję. Widocznie ta która nazywa się "RAW" wcale nie jest "Raw" tylko już jest przetworzona.

Riddle napisał(a):

Widocznie ta która nazywa się "RAW" wcale nie jest "Raw" tylko już jest przetworzona.

Problem w tym, że pewnie jest przetworzona zanim trafi kablem USB do komputera...

Spine napisał(a):

Riddle napisał(a):

Widocznie ta która nazywa się "RAW" wcale nie jest "Raw" tylko już jest przetworzona.

Problem w tym, że pewnie jest przetworzona zanim trafi kablem USB do komputera...

Nie wiesz tego. Może nie.

@Riddle: Jeśli masz jakieś konkretne info na ten temat to pokaż. Bo na razie obydwaj gdybamy...

Riddle napisał(a):

Próbuję Ci powiedzieć że zamiast podejść do problemu od strony: "ale pady mają zwaloną precyzję, trzeba to jakoś naprawić", podejdź do tego od strony: "aha, czyli twórcy padów specjalnie ściągają ruchy gałek pod ten X oraz pod narożniki - jak możnaby to wyłączyć i zczytać gołą pozycję?".

Ale tu nie chodzi o to, że precyzja jest zepsuta, a że dane otrzymywane po stronie aplikacji (np. Unity) są już poddane przyciąganiu, więc nic z tym nie da się zrobić. Żeby ”naprawić” ten problem, trzeba by dostać surowe dane i na nich operować, a takich Unity najwyraźniej nie otrzymuje.

Przy czym jeśli mowa o surowych danych, to jedyną opcją jaką widzę jest skorzystanie z Raw Input, którego obsługa to jakiś koszmar. Ewentualnie z prymitywu takiego jak joyGetPosEx i podaniem flagi JOY_RETURNRAWDATA, o ile jego ograniczenia nie przeszkadzają. Można to sprawdzić, aby się dowiedzieć czy dane osi będą faktycznie surowe, czy jednak nadal z uwzględnieniem przyciągania.

Nadal nie wiadomo w którym momencie — w przypadku wymienionych gamepadów — dane osi są poddawane przyciąganiu. Przyciąganie drążka do osi może się dziać w firmware kontrolera, w sterowniku kontrolera, w API systemowym lub też wyżej, np. w bibliotece będącej wrapperem systemowego API. Tutaj dwa ostatnie przypadki odpadają, bo w Unity można wyłączyć przyciąganie, ale to nic nie zmienia. Tak więc funkcja przyciągania zaimplementowana jest głębiej — albo w sterowniku, albo w firmware gamepada.

I teraz bądź tu mądry i znajdź gdzie to się dzieje. :D

furious programming napisał(a):

Riddle napisał(a):

Próbuję Ci powiedzieć że zamiast podejść do problemu od strony: "ale pady mają zwaloną precyzję, trzeba to jakoś naprawić", podejdź do tego od strony: "aha, czyli twórcy padów specjalnie ściągają ruchy gałek pod ten X oraz pod narożniki - jak możnaby to wyłączyć i zczytać gołą pozycję?".

Ale tu nie chodzi o to, że precyzja jest zepsuta, a że dane otrzymywane po stronie aplikacji (np. Unity) są już poddane przyciąganiu, więc nic z tym nie da się zrobić. Żeby ”naprawić” ten problem, trzeba by dostać surowe dane i na nich operować, a takich Unity najwyraźniej nie otrzymuje. Przy czym jeśli mowa o surowych danych, to jedyną opcją jaką widzę jest skorzystanie z Raw Input, którego obsługa to jakiś koszmar.

Nadal nie wiadomo w którym momencie — w przypadku wymienionych gamepadów — dane osi są poddawane przyciąganiu. Przyciąganie drążka do osi może się dziać w firmware kontrolera, w sterowniku kontrolera, w API systemowym lub też wyżej, np. w bibliotece będącej wrapperem systemowego API. Tutaj dwa ostatnie przypadki odpadają, bo w Unity można wyłączyć przyciąganie, ale to nic nie zmienia. Tak więc funkcja przyciągania zaimplementowana jest głębiej — albo w sterowniku, albo w firmware gamepada.

I teraz bądź tu mądry i znajdź gdzie to się dzieje. :D

No tak :D

To właśnie ten argument chciałem wyciągnąć. Jeśli OP jest już tego świadom to spoko.

Ja bym jednak sprawdził te kontrolery przy użyciu joyGetPosEx i flagi JOY_RETURNRAWDATA , bo to tylko kilka linijek kodu.