Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
FujiNET firmware v1.3.0 Nowa wersja oprogramowania do interfejsu sieciowego FujiNET. Tym razem z obsługą TCP!
hatari 2.5.0 Od dwóch dni dostępna jest najnowsza (2.5.0) wersja Hatari.
Grawitacja 2024 Czas na kolejną edycję 8 bitowego GameJamu.
Tenebra na Atari ST/STE Wersja gry na duże atari.
Wyniki FujiCup 2023 Wyniki konkursu FujiCup na najlepszą grę dla 8-bit Atari w 2023 roku zostały ogłoszone!
Strony 1
Zaloguj się lub zarejestruj by napisać odpowiedź
Ponieważ znowu wywołałem zamęt, tym razem poza forum. Testowałem sobie dwa joye (tu brak lokowania produktów), i na jednym mam wrażenie wyraźnego opóźnienia reakcji na ruchy (fire OK). Jest jakaś metoda aby zmierzyć takie opóźnienie? Najlepiej bezpośrednio przez Atari, ale może być też za pomocą Arduino. Teraz jestem na urlopie, ale po powrocie chciałbym to sprawdzić. Tak dla siebie. Ktoś coś albo pomysły jak w miarę prosto to sprawdzić?
Przecież mój tester świetnie się do tego nadaje :) Podejrzewam, że masz zaśniedziałe styki, wtedy reaguje z opóźnieniem czasami.
https://atarionline.pl/utils/F.%20Diagn … 16k%29.atr Nwet na końcu jest mini gierka polegająca na szybkości reakcji; fire co prawda, ale mogę zrobić wersję, że będzie działało na kierunki.
Ostatnio edytowany przez qbahusak (2023-08-01 14:40:30)
Podziękował, jak wrócę z urlopu potestuję. Zaśniedziałe styki nie powinny być, sprzęt zupełnie nowy. Ale obstawiam albo chińskie switche, albo ich smarowanie lub niewłaściwą dla Atari oporność.
Looknąłem pod emu (edytka mode), niestety, testuje tylko prędkość działania przycisku lub czegoś nie wiem. Fire działa ok, natomiast jest opóźnienie (według mojej subiektywnej oceny) w działaniu kierunków... Więc poproszę o wersję z kierunkami.
Ostatnio edytowany przez Sikor (2023-08-01 14:45:59)
Napisz se w bejziku, przecież to szybciej niż napisanie tych kilku linijek tekstu na forum:-) Zrób se program, który np. zmienia kolor tła na odpowiedni ruch i sprawdź po kolei wszystkie kierunki.
a=peek(joystik), if a=sprawdzany kierunek then poke kolor tła czerwony, if a=15 then poke kolor tła niebieski; goto z powrotem na początek:-)
Jeżeli joystick jest mechaniczny, w sensie, że to są po prostu mechaniczne styki, to nie ma mowy o żadnym opóźnieniu. Chyba, że jakaś elektronika coś po drodze przetwarza i wystawia "sygnały" dla wejścia joysticka. Styk, to styk, działa natychmiastowo. To co Kuba pisze o zaśniedziałych stykach, to może się ewentualnie dziać, bo przy ruchu joya coś tam nie kontaktuje i tylko czasem jak ruszysz tym stykiem to zakontaktuje lepiej, stąd może być opóźnienie, ale nie w sensie, że prąd wolniej płynie, tylko w sensie, że pierwszy styk nie daje styku i dopiero mocniejsze lub równiejsze dociśnięcie w którymś tam momencie zadziała.
Załączam wersję 1.02 z testerem reakcji na kierunki również. A co się namęczyłem z nową wersją cc65, z godzinę z hakiem, zanim się skompilowało.
Ostatnio edytowany przez qbahusak (2023-08-01 18:22:26)
@Mq, to mi nie załatwia sprawy
@qbahusak: dzięki, pod emu działa. Będą testy w domu.
Jeżeli joystick jest mechaniczny, w sensie, że to są po prostu mechaniczne styki, to nie ma mowy o żadnym opóźnieniu. Chyba, że jakaś elektronika coś po drodze przetwarza i wystawia "sygnały" dla wejścia joysticka. Styk, to styk, działa natychmiastowo.
Tak powinno, o ile nie jest opór zrobiony dla innego urządzenia (większy, na inne napięcie) lub nie jest zaśniedziały (to już napisane) lub zabrudzony (na przykład nieodpowiednim smarem, takie gałki sie też trafiają u chińczyków). Wyjdzie w praniu w dalszych testach, bo właśnie mocno się zdziwiłem przy graniu. Pierwszy raz w życiu zauważyłem taki efekt na mechanicznym joyu...
Patrzę sobie na schemat Atari i faktycznie na wejściach kierunków z portu joya do portA w Pokeyu są podpięte kondensatory 1nF do masy. Czyli jak łączymy styk kierunku do masy w joysticku, to przez ten nasz styk natychmiast się rozładowuje ten kondensatorek i wtedy mamy stan niski na wejściu portA dający sygnał, że wychylono kierunek. I teraz jeżeli zewrzemy ten nasz styk odpowiednio dużą rezystancją, to ów kondensatorek będzie się rozładowywał powoli przez rezystancję naszego styku, co da opóźnienie zadziałania. Może tak być. Jeśli tak, to moim zdaniem trzeba te styki obejrzeć, może gołym okiem widać, że zaśniedziało. I zmierzyć normalnie miernikiem rezystancję jak styk jest zwarty, jak jest tam jakaś rezystancja, to przeczyścić kontaktem do styków (nie radzę mechanicznych metod, bo są skuteczne, ale problem po jakimś dość krótkim czasie będzie powracał). Po przeczyszczeniu zmierzyć znowu rezystancję i jak jest poprawione skutecznie, to dopiero sprawdzać na komputerze - to da pewność naprawy, ja bym tak to zrobił.
Jak masz omomierz taki z epoki (analogowy) do dwie szpile i do kabelka joya. Zobaczysz po wskazówce czy zanim nie złapie to nie lata w te i nazad. Bo jeszcze może być tak, że "gra" sprawdza joya w jakiś tam czasach a u Ciebie zanim zaskoczy styk to "podzwoni" przez chwilę. Wtedy powstaje randomowy delay. U mnie takie kwiatki się robiły i ostatecznie rozebrałem i joya i mikrostyk (na te sprężynki) i czyściłem. Bo mój joy ma tylko jeden przycisk bo to epokowe polskie dzieło :)
EDIT:
A jak często odświeża ATARI port? Tam da radę szybciej niż 50Hz? Bo przyszedł mi taki pomysł, żeby zrobić tester na zasadzie "waterfall". Raczej by pokazało czy styki utraciły na kontakcie.
Ostatnio edytowany przez Gienek (2023-08-05 09:12:12)
Trzeba czytać port bezpośrednio z portu, wtedy można jak się często chce, chyba by się dało w przerwaniach DLI co linię obrazu nawet. Natomiast jeśli czytamy z rejestrów cieni z użyciem OS-a, no to OS chyba odświeża rejestry w VBL, czyli co ramkę.
Nie wiem tego w sumie co tu napisałem, tylko tak na szybko z głowy wymyśliłem, więc jeśli piszę bzdurę jakąś, to niech mnie ktoś poprawi:-)
@Mq
Dobrze piszesz. Takie coś da niezłą regularność detekcji. Bo raczej szybciej niż linia to programy nie wykrywają zmian.
Taki coś mi przyszło do głowy, że jak jest program ANTICa i np. co linie ma LMS z przerwaniem DLI to w zasadzie można mieć przygotowane wcześniej te kombinacje naciśnięcia przycisków i kierunków w postaci grafik. I teraz co linię sprawdzam port i ustawiam adres następnej linii na tą odpowiednią grafikę.
Powstanie taki obraz działania styków. W zasadzie można się trigować jak oscyloskop, czyli od pierwszego skoku do 239 linii i stop. Powiedzmy, ileś do tyłu i będzie wykres jakości działania przycisku.
Aż to sprawdzę, czy taki numer przejdzie :)
Hehe:-) No ciekawe. Faktycznie prawie oscyloskop:-)
Natomiast jeśli chodzi o praktyczność tego wszystkiego co tu piszemy w kontekście użycia joysticka do gier, to po prostu im lepszy i pewniejszy styk w joyu, tym lepszy joystick, bo pewniejszy. Dlatego jedne joye były lepsze, a inne gorsze (również pod tym względem). Moim zdaniem w każdym joyu chodzi o to samo: trzeba zadbać o jakość styków, wyczyścić je, kontaktem potraktować, słowem sprawić, żeby styk działał najlepiej jak to możliwe.
Nie da się fizycznie gałą joya, czy tam przyciskami pada naparzać tak szybko, żeby miało znaczenie odczytywanie joya częściej niż raz na ramkę. Myślę, że żadna gra nie robi tego częściej, a wręcz z doświadczenia w pisaniu gier wiem już, że sprawdzanie joya co trzy ramki daje efekt wystarczający, żeby nie było czuć żadnych opóźnień, a ruch gracza co trzy ramki jest w miarę szybki i płynny. Poruszanie co ramkę jest za szybkie po prostu. Atari ma spory zapas do pisania szybkich gier:-)
Edit: co do powyższego, to 50Hz to jest 20ms. Sprawdzanie joya co trzy ramki to jest co 60ms. Współczesne pady bezprzewodowe bluetooth dobre firmowe dają opóźnienia rzędu 80ms i wtedy czołowi producenci takich urządzeń bardzo się tym chwalą, że mają bardzo niskie opóźnienia. Przy graniu takimi padami (testowałem kilka różnych pod tym kątem) nie zauważam subiektywnie żadnego, nawet minimalnego opóźnienia w grach. To tak żeby uzmysłowić o jakich rzędach wielkości czasów tutaj rozmawiamy.
Ostatnio edytowany przez Mq (2023-08-05 20:52:02)
To jest ciekawe, że kiedyś graliśmy i na 20ms a teraz jest super jak jest 80ms a jeszcze jak dojdą jakieś chmury to czasem po 200ms jest delay. Ale też zaobserwowałem, że odpalenie ATARI młodemu pokoleniu daje jakąś dodatkową frajdę właśnie z tego pixelperfect i tych 20ms. Po prostu błysk, dym i "zabity". Bezwzględnie, bezlitości, bez dyskusji.
No ja czyściłem tego na zdjęciu joya. Tak mu się robi co jakieś kilka lat (bo ma już 35). Mikrostyk (ta blaszka w środku) pokrywa się jakimś nalotem no i robią się takie dziwne opóźnienia. Może to jest to?
W sumie mógłbym wymienić na nowy styk, no ale skoro da się naprawić. Joy ma jeden tylko przycisk, toporny że aż ręka boli. Swoją drogą kolega w owym czasie miał lutownicę kupioną w sklepie identyczną jak rączka tego joya :) Dlatego obstawiam, że mikrostyk też jest bez jakiejś filozofii i pasuje od "Żuka".
Natomiast w mechanizmie mikrostyku to ten ruch nie jest taki idealnie prostopadło-równoległy. Więc przy nalocie pierwsze dotknięcie może mieć faktycznie jeszcze dużą rezystancję. Dopiero jak się "wwierci" to łapie.
... robię ten "oscyloskop" :)
EDIT
Decathlon sprawdza co 20ms. Założyłem breakpoint na odczycie PORTA i co odczyt przyrasta na tablicy czasu o 0,02s. Czyli maksa można nabić machając 25Hz. No to dzisiejsze pady wymiękają :)
EDIT2
Nie mogłem się powstrzymać i zrobiłem turbohacka dla Decathlona. Nawet z tym 110 przez płotki nie jest łatwe :)
Ostatnio edytowany przez Gienek (2023-08-06 11:38:42)
Do decathlonu, to ja zrobiłem specjalny tryb pracy w moim interfejsie (S)NESctrl kiedyś. Wciskasz przycisk w padzie, a interfejs sam macha lewo-prawo. Tylko fire trzeba potem wcisnąć w odpowiednim momencie. Niektórzy mówią, że gra robi się bez sensu, ale nie do końca bo właśnie liczą się momenty wciśnięcia fire, odpowiednie kąty rzutów, skoków itd. Nie pamiętam czy w Decathlon, ale są też inne gry na machanie lewo-prawo i tam oprócz tego machania właśnie często są jeszcze inne parametry istotne.
W Decathlonie nie trzeba machać aż 25Hz. Wydaje mi się, że tam jest jakaś histereza jeszcze opadania tej siły, bo wystarczy rytmicznie machać i można znacznie wolniej, a max się utrzymuje.
Tak w Decathlonie jest jakiś algorytm całkujący... Zmiana stanu joya podbija, a brak powoduje opadanie siły, więc pewnie da się pobudzać go trochę wolniej. W każdym razie co ramkę sprawdza stan joya. Żeby słupek siły był zablokowany na maks to musi być co ramkę zmiana (i to robi ten hack w przykładzie, zmienia BEQ na BNE sprawdzające czy w nowej ramce była zmiana). Bez tego słupek tylko pulsuje do maksa, co łatwo sprawdzić włączając emu na mniejszym speedzie.
Załączam wersję 1.02 z testerem reakcji na kierunki również. A co się namęczyłem z nową wersją cc65, z godzinę z hakiem, zanim się skompilowało.
Soft, że tak powiem, genialny w swojej prostocie.
Pomógł mi zweryfikować, że przyciski niby wydające się działać całkiem nieźle w praktyce (w joyu) okazały się kiepskie.
Gdyby tak jeszcze w gierce dało się dołożyć 2 i 3 fire to byłby dla mnie pełen ideał :)
Ostatnio edytowany przez Zgrd (2023-09-24 16:01:23)
Strony 1
Zaloguj się lub zarejestruj by napisać odpowiedź
[ Wygenerowano w 0.124 sekund, wykonano 15 zapytań ]