Niezalogowany (Zaloguj się)

Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

Vanilla 1.1.4 jest produktem Lussumo. Więcej informacji: Dokumentacja, Forum.

Spy Hunter-modyfikacja dla joya 2-przyciskowego?

Od 1 do 23 z 23

- 1:
  
  CommentAuthorJacques
- CommentTime6 May 2023
Jak wiadomo, są joye 2 (A i B) i więcej przyciskowe, sporo gier na Amigę korzysta z przycisku B.
Zastanawiam się czy istnieje lub może dałoby się zrobić modyfikację Soy Huntera, żeby puszczanie oleju było na przycisku B takiego joysticka? ;-)
- 2:
  
  CommentAuthorMq
- CommentTime6 May 2023
A ten tutaj co robi na drugim przycisku?
->link<-
- 3:
  
  CommentAuthorJacques
- CommentTime6 May 2023
Dzięki, sprawdzę!
- 4:
  
  CommentAuthorJacques
- CommentTime6 May 2023
O to chodziło, dzięki!
Drop Zone też sprawdziłem :-)
- 5:
  
  CommentAuthorMq
- CommentTime7 May 2023
Spoko, tak mi się przypomniało, że to było zebrane w jednym miejscu. A tu jeszcze jest spis tych gier przerobionych z informacją w tabelce ile przycisków obsługują i jakie funkcje zostały dodane na tych przyciskach: ->link<-
- 6:
  
  CommentAuthorJacques
- CommentTime7 May 2023
Świetna inicjatywa :-)
- 7:
  
  CommentAuthorPecus
- CommentTime30 May 2023
O fcuk!
Co z bezsensowny pomysł z tym Joy 2B+ !!!

Chciałem do Scorcha dodać obsługę, no i dopiero wtedy zauważyłem, że ktoś sobie wymyślił, że przyciski 2 i 3 niewciśnięte "generują" zmianę wartości POT0 i POT1, a wciśnięte dają taki sygnał jakby nic nie było podłączone.
Czyli jeśli obsługuję te przyciski i podepnę zwykły joy, to są one widziane jako cały czas wciśnięte!

W teorii miało to chyba umożliwić rozpoznanie czy taki joy jest podłączony, a w praktyce nie da się zrobić prostego (zwięzłego) kawałka kodu, który będzie obsługiwał tak standardowy joy (traktując przyciski 2 i 3 jako nieistniejące) jak i Joy 2B+ (wtedy zaczną działać funkcje dostępne pod 2 i 3).

Przy takiej konstrukcji trzeba sprawdzić na początku jaki joy jest podłączony i wybrać odpowiedni sposób obsługi całości sterowania.

A po ch... komu ta możliwość detekcji?? Nie mam pojęcia.

I dlatego też te wszystkie gry, do ściągnięcia z podanych linków nie działają ze zwykłym joyem (zagrajcie sobie w BoulderDash - życzę powodzenia).

A najgorsze, że ludzie powielają ten idiotyczny projekt i tworzą projekty kompatydebilne. No sorry.
Wkurzyłem się - choć w sumie - nie będę używał i nie oprogramuję i tyle.

W developie jest już Scorch z obsługą 2giego przycisku, ale obsługuje go ODWROTNIE niż w Joy 2B+ , czyli w sposób normalny nie przeszkadzający w używaniu standardowego kontrolera bez dodatkowych przycisków.

Dziękuję za uwagę :)
- 8:
  
  CommentAuthorMq
- CommentTime30 May 2023
Pecuś, to nie do końca tak jak piszesz. Chodzi o zaszłość historyczną. Otóż jeszcze "w epoce" były w sprzedaży (choć mało popularne) joysticki z dwoma fire. Były to nieraz te same joysticki które znamy (znanych producentów), tylko miały drugi fire, nieraz po prostu rozdzielone dwa fire, bo fizycznie występowały zwykle dwa, tylko działały jako jeden.

Te joysticki z dwoma fire działały w standardzie takim właśnie jak w tym joy2b. Standard ten był wykorzystywany na Amidze i jest trochę gier, które to wykorzystują. Każdorazowo jednak na Amidze jest tak, że dla joysticka dwuprzyciskowego trzeba wybrać go w opcjach gry. Każda taka gra działa tez na normalnym joysticku.
Jeżeli na Atari te przerobione gry nie działają poprawnie, to nie jest wina sprzętu, tylko niewłaściwego przerobienia gry.

Dlaczego było w tą a nie w inną stronę? Ano dlatego, że wszystkie styki w normalnym joysticku działają tak, że zwierają odpowiedni pin do masy. Żeby uzyskać odwrotne działanie przycisku, to trzeba go zwierać do plusa zasilania, a to jest o tyle niewskazane, że niesie ryzyko zwarć różnorakich w rozsypujących się konstrukcjach styków. Tak myślę, ale nie jest to ważne co myślę, ważne że jest pewien standard, który był używany jeszcze "w epoce" - co prawda
nie na Atari, ale jednak był.

Odwrotne działanie przycisku było wykorzystywane przez komodorowców. Oni wprowadzili sobie taki odwrotny standard, ale to się wiąże z problememi w drugą stronę: nie ma takich joysticków, więc trzeba sobie samemu takie robić/przerabiać, a po drugie w Amidze jest odwrotnie, więc nie da się tego samego joysticka używać z Amigą i C64. Standard "Amigowy" został szerzej zaakceptowany i jest używany obecnie też na Atari.

A wiem to wszystko dlatego, że kilka lat temu opracowałem interfejs (S)NESctrl do padów NES/SNES podłaczanych do Atari i wtedy Amigowcy poprosili mnie o dodatkowy drugi fire, więc go zrobiłem w tym ich standardzie. Gdy opracowywałem mój interfejs, nie było jeszcze joy2b+, więc ucieszyłem się że po latrach powstał w standardzie takim, że również mój interfejs działa z tym poprawnie.

Drugi przycisk w joyu nie jest mi szczególnie potrzebny, korzystam z tego rzadko, więc nie ma to dla mnie wielkiego znaczenia czy gra go obsługuje, ale jeśli dokładać obsługę drugiego przycisku do gry na Atari, to nie ma sensu robić tego w odwrotną stronę. Po pierwsze nikt nie ma joysticka, który to obsługuje, a po drugie istniejące już rozwiązania mają tą linię sprzętowo podciągniętą do plusa, więc jak ktoś korzysta np. z (S)NESctrl, albo z joy2b+, to jak zrobisz obsługę fire odwrotnie w Scorchu, to takie joye będą miały przycisk drugi fire cały czas wciśnięty i gra nie będzie działać poprawnie. Dla poprawnego działania uważam, że w grze powinny być opcje do przestawiania tak jak było to w grach na Amidze, a nie robienie tego "na pałę".
- 9:
  
  CommentAuthorPecus
- CommentTime30 May 2023 zmieniony
Ale na Atari nie było nigdy takich gier i takiego standardu.

Po co więc dopasowywać się do (moim zdaniem) złego standardu zamiast zrobić to dobrze.
Wystarczy przełącznik odwracający działanie przycisków 2 i 3 w takim joyu.

Myszka do Amigi też działa odwrotnie niż do Atari i nikt nie przerabia programów z tego powodu.
Ludzie przerabiają myszki (albo kupują takie z przełącznikiem).

No i ja wiem jak to działa na poziomie elektrycznym. I nie nazwałbym tego zwieraniem do plusa, bo masz rezystancję. Rozwiązanie o którym myślę (odwrotne do Joy 2B+) to raczej działanie symulujące podłączanie paddli (wciśnięty przycisk) i ich odłączanie (przycisk puszczony. Nie widzę tu specjalnych zagrożeń.

Widziałeś ile dobrych gier popsuli przerabiając je pod ten wynalazek (jeszcze raz polecam BoulderDash :) )?

Poważnie zastanawiam się czy nie pójść drogą XXXLa :) i nie zostawić w Scorchu obsługi odwrotnej. Czyli jak podepniesz Joy 2B+ to nie ma opcji - trzymaj drugi przycisk przez całą grę ewentualnie puszczając go na chwilę :)

Gdyby było to odwrotnie można by pisać kod prosty, uniwersalny (nie ma przycisków, nie działa ich obsługa), a tak.... Mamy w Scorchu obsługę do 4 joysticków. Trzeba by dopisać detekcję każdego (albo w menu dodać opcję wyboru), a potem w trakcie rozgrywki zmieniać działanie procedur wejścia w zależności od tego jaki joy jest w danym porcie (co oznacza spore wydłużenie tych procedur).
Odpada zamienianie się joystickami w czasie gry (jeśli jeden to Joy 2B+ a drugi normalny) itp.

Przy odwrotnym (dla mnie naturalnym) nie ma wszystkich tych problemów, wszystko obsługuje się wspólną procką, nie potrzeba detekcji/wyboru , nic się nie kszani przy zamianie joysticków.

Poza tym ledwie upchnąłem tę obsługę 2giego przycisku i nie będę kopał się z koniem dalej i psuł gry (bo żadna sztuka zrobić dwie wersje).
- 10:
  
  CommentAuthorMq
- CommentTime30 May 2023
No tak, źle przerobili, więc popsuli te gry:-) Zgadzam się z tym w 100%. Z tym że standard (nazwijmy w skrócie Amigowy) o którym mowa zaczął być stosowany (w Atari) i używany już kilka lat temu, ludzie mają już masę takich joysticków, a interfejsy, które są z tym standardem zgodne nie dają się od tak przerobić i nagle działać w obie strony.

Mysz Atari i Amigi działa odwrotnie w sensie takim, że ma kierunki odwrotnie lewo-prawo, ale akurat podałeś bardzo dobry przykład przypadkowo, bo zapomniałem o tym, a przycisk fire pod względem schematu jest tożsamy z lewym przyciskiem myszy, natomiast przycisk prawy myszy odpowiada drugiemu fire. Oba te przyciski (w myszach) są zwierane do masy przy wciśnięciu i oba działają identycznie w myszy Amigowej i Atarowej. A więc przycisk fire drugi jest zgodny z prawym przyciskiem myszy właśnie w tą stroną w którą mamy go obecnie - czyli zwierany do masy. Co więcej, np. w Atari ST w tym miejscu w ogóle nie ma wejścia potencjometrycznego, tylko drugi przycisk myszy to jest tak na prawdę zwykły przycisk fire, połączony do drugiego portu joya. Tak właśnie jest: w Atari ST tylko w jednym porcie joya jest obsługiwany pin z drugim przyciskiem myszy, który fizycznie jest podłączony do pierwszego portu pod pierwszy fire. Oba przyciski są skonstruowane jako zwierane do masy.

Generalnie zasada jest taka zwykle, że różne przyciski i przełączniki konstruuje się jako zwierane do masy i jest to zgodne ze sztuką w elektronice, a co najmniej jest dobrą praktyką.

Pytasz jeszcze po co dopasowywać się do "złego standardu" zamiast zrobić to "dobrze". Załóżmy, że nawet myślisz słusznie, tak na prawdę nie chodzi o to czy słusznie czy nie, ale o to co warto robić, a czego nie. Odpowiadam więc na to pytanie: po to, że jest już cała masa gier, które działają wg tego standardu, a wg przeciwnego nie ma ani jednej takiej gry. Po to, że jest już cała masa interfejsów do padów, które posiadają ludzie obsługujących ten standard, a przeciwnego nie obsłużą. Po to, że jest cała masa joysticków joy2b+ które posiadają ludzie. Dodanie do nowej gry obsługi drugiego przycisku w "odwrotnym standardzie" nie tylko nie jest potrzebne nikomu, bo nikt nie ma takiego joysticka, ale jeszcze dodatkowo spowoduje że wszystkie joysticki i interfejsy z obsługa drugiego fire (w standardzie "Amigowym"), które ludzie posiadają, nie będą nagle działały z tą jedną tylko grą i będą powodowały efekt podobny do tego, o którym piszesz w grze Boulder Dash. Te przerobione gry mają swoje wersje osobne pod joya z normalnym fire i pod dwa-trzy przyciski. Osobne wersje. W nowych grach moim zdaniem powinno być to rozwiązywane przełącznikiem w menu, wtedy można wprowadzać jeden lub drugi czy trzeci standard, można też wprowadzić wszystkie na raz. Przełączanie w menu np. zastosowano w grze Moonpatrol Redux i jest to bardzo fajne i przyjazne wszystkim użytkownikom.
- 11:
  
  CommentAuthorJacques
- CommentTime30 May 2023
@Mq
Amen :-)
- 12: CommentAuthormono
- CommentTime30 May 2023 zmieniony
Trzymam stronę Pecusia. Też lekko pobladłem jak zobaczyłem, jak to jest wymyślone.

Dla porównania - oto, jak zaprojektowano dwuprzyciskowy joystick dla 7800 ->link<- lub ->link<-
Działa to tak, że stan dowolnego joya czyta się ze zwykłego buttona (TRIG/STRIG), a to który konkretnie i czy obydwa z paddla (POT/PADDLE). Da się? Da się! Oczywiście zamiast tracić jeden przycisk można było mieć 3, ale ciągle okazuje się że nawet te 40 lat temu można było coś zaprojektować z głową.
- 13:
  
  CommentAuthorMq
- CommentTime30 May 2023
@mono, ale ja nie twierdzę czy to jest dobrze zaprojektowane czy źle, ani nie chodzi tu o to, żeby trzymać czyjąś stronę. To nie jest głosowanie za tym jak będzie lepiej zaprojektować coś, bo tutaj nikt niczego nie projektuje. Mówimy o rozwiązaniu, które zostało przepchnięte kilka lat temu. Od strony komputera i od strony programowej jest to oczywiście do dupy i ja też trzymam "stronę Pecusia" - tutaj pełna zgoda. Natomiast sprzęt jest inny, jest tego masa wśród ludzi i jak ktoś chce obsłużyć drugi przycisk w swojej grze, to on działa tak że jest zwierany do masy. Zrobienie tego odwrotnie jest napisaniem softu pod nieistniejący sprzęt po prostu, a dodatkowo powoduje, że ten istniejący zrobi kłopoty w samej grze. Jeszcze raz: nie ma ani jednej takiej gry, która robi coś takiego, ani nie ma ani jednego takiego joysticka wśród ludzi podłączających go do Atari. Skąd w ogóle pomysł, żeby zrobić w grze obsługę czegoś co nie istnieje? W wątku o Scorchu ludzie pytali o obsługę drugiego przycisku ale jak rozumiem w domyśle chodziło im o ich drugi przycisk istniejący już w sprzęcie, a nie o wymyślenie nowego drugiego przycisku. Myślę, że to jest nieporozumienie.
- 14: CommentAuthormono
- CommentTime30 May 2023
No to się rozumie samo przez się. Za późno na wprowadzanie standardu, więc musimy się męczyć z koszmarem.
Sam byłem wielkim zwolennikiem tego projektu. Nadal jestem zdania że warto w nowych produkcjach obsługiwać nowe rozszerzenia (w tym dodatkowe przyciski na które się bardzo cieszyłem), tyle że włosy mi za każdym razem wypadają jak widzę jak to zostało zrobione.
- 15:
  
  CommentAuthorPecus
- CommentTime30 May 2023 zmieniony
Ja też nie zamierzam zmieniać "standardu", po prostu nie będzie w Scorchu jego obsługi i już.
Za dużo by zajęła.

W wątku na AAGE padł przykład uniwersalnego (powiedzmy) kawałka kodu, który (nie sprawdzałem jeszcze) wygląda że miałby szanse zadziałać.

Tyle, że, Scorch na początku nie przewidywał użycia joysticka (w ogóle :) ), potem został wzbogacony o nią, a na końcu dodałem obsługę wielu joysticków w dość pokręcony sposób (oczędzając pamięć i swoją pracę :) ).
Otóż jest globalna zmienna trzymająca numer aktywnego joya, a na VBI chodzi maleńka procka:
```
; support for joysticks :)
        ldx JoystickNumber
        lda STICK0,x
        sta STICK0
        lda STRIG0,x
        sta STRIG0
        ; and PADDLES (2 and 3 joystick button)
        txa
        asl
        tax
        lda PADDL0,x
        sta PADDL0
        lda PADDL1,x
        sta PADDL1
```
tu już z obsługą przycisków 2 i 3 :)

A potem w kodzie gry zawsze czytany jest stan pierwszego joysticka.
No i tu ten proponowany kod nie zadziała i będzie wymagał sporo roboty i pamięci, a ta znowu się skończyła :)
- 16: CommentAuthormono
- CommentTime30 May 2023 zmieniony
Kod dla przycisku joysticka jest prosty:
```
lda TRIG0S   ;$284
cmp state.?t0
sta state.?t0
scs
jsr fire
```
fire odpala kiedy przycisk jest naciskany (zmiana z 1 na 0).
Odpowiedni kod mógłby być dla paddla:
```
lda PADDL0   ;$270
and #$C0
cmp state.?p0
sta state.?p0
scs
jsr fire
```
Zakładając że niepodłączony paddle daje wartość $E4 (wolne skanowanie) lub $E5 (szybkie skanowanie), to przy jedno-przyciskowym joysticku, wszystko gra - fire nigdy nie odpali.

Ale przy podłączonym Joy2B+ paddle zwraca mniej niż $Ex a przy wciśniętym zwraca $Ex (!). No to jak zrobić kod, który odpali fire po wciśnięciu?
```
lda PADDL0   ;$270
and #$C0
eor #$C0
cmp state.?p0
sta state.?p0
scs
jsr fire
```
Warianty są takie:
- kiedy mamy 1-przyciskowego joya fire nie odpali nigdy bo wartość paddla będzie zawsze $Ex (nie ma zmiany, C jest zawsze ustawiony).
Jak mamy Joy2B+ podłączony wtedy:
- przy podłączeniu joya fire nie odpali (stan zmieni się z $Ex na mniej),
- ale przy odłączaniu odpali (zmieni się z mniej na $Ex),
- wciśnięcie przycisku (zmiana z mniej na $Ex) odpali fire,
- zwolnienie przycisku (zmiana z $Ex na mniej) nie odpali.

Teoretycznie powinno działać, trzeba sprawdzić.

Edit: Oczywiście stany stabilne: przycisk wciśnięty i przycisk zwolniony mają odzwierciedlenie w state, ale nie odpalają fire. Tylko moment wciśnięcia przycisku odpala.

Edit 2: A może nawet $C0 zamiast $E0 byłoby sensowniejsze.

Kłopot z tym, że jak się podłączy wtedy dwuprzyciskowy joystick od Atari 7800 to te przyciski będą się zachowywać odwrotnie i trzeba by nie robić EOR-a.

Jest jeszcze jeden standard (5+) ->link<- dla dwóch dodatkowych przycisków START oraz SELECT polegający na równoczesnym zwarciu przeciwstawnych kierunków joysticka:
```
lda JSTICK0   ;$278
and #%1100
seq
lda #%0001
cmp state.?start
sta state.?start
scs
jsr fire

lda JSTICK0   ;$278
and #%0011
seq
lda #%0001
cmp state.?select
sta state.?select
scs
jsr fire
```
- 17:
  
  CommentAuthorMq
- CommentTime30 May 2023 zmieniony
@mono to rozwiązanie ze sprawdzeniem zmiany stanu przycisku zamiast sprawdzania czy jest wciśnięty wydaje mi się bardzo eleganckie. To na prawdę pomysł na poziomie - nie chcę za mocno przysładzać, ale dodał bym, że jak wszystkie Twoje pomysły:-) Powinieneś być dyżurnym konsultantem wszystkich programistów na Atari:-) Taki zawód nowy:-)

Ale myślę jeszcze jak by trzeba wtedy rozwiązać np. trzymanie fire dłużej...
Edit: aha, skoro odczytaliśmy że został wciśnięty, to trzeba by to zapamiętać i wtedy jeśli jest taka sytuacja to dalej sprawdzać już samo wciśnięcie a nie moment wciśnięcia.
No ale fakt faktem, że komplikuje to wszystko program. Niemniej jednak da się:-)
- 18:
  
  CommentAuthorPecus
- CommentTime30 May 2023 zmieniony
Nie umniejszając nic @mono to jest to rozwiązanie z AAGE o którym wspominałem - kto to wymyślił?? :)

Dla mnie problemem jest obsługa wielu portów, bo trzeba trzymać oddzielnie stan każdego, a przy takim sposobie jak zastosowany w Scorchu, to już w ogóle zaczyna być problematyczne.

A o dłuższym przytrzymaniu nie wspomnę :)

Chyba zrobię obsługę joya od Atari 7800 (skąd mi się 7200 wzięło?? :) )i tyle, to dobry standard i do tego nasz :) No i powinienem się zmieścić.
- 19:
  
  CommentAuthormiker
- CommentTime30 May 2023
7800 proponuję jednak. :)
- 20: CommentAuthormono
- CommentTime30 May 2023 zmieniony
@Mq: Tak :)
Trzeba zrobić zwykłe liczniki takie, jak robi OS na VBLK:
```
vblk:
  ...
  lda state.?t0
  bne ?skip
  lda cntr.?t0
  beq ?skip
  dec cntr.?t0
  bne ?skip
  jsr fire
?skip
  ...
```
a przy detekcji wciśnięcia przycisku zresetować licznik ilością ramek przez które trzeba trzymać przycisk
```
lda TRIG0S   ;$284
  cmp state.?t0
  sta state.?t0
  bcs ?skip
  lda #10
  sta cntr.?t0
?skip
```
@Pecus: to pomyśl sobie o obsłudze tzw przycisków "turbo" w NES-ie :) tam idzie fala prostokątna o szerokości poziomu 16ms :)

Edit: Podłączyłem tego szarego pada od 7800 do XE i paddle się jednak nie chcą zmieniać :( Słabiutko. TRIG się zmienia.
- 21:
  
  CommentAuthorPecus
- CommentTime31 May 2023 zmieniony
Ale zgodnie ze schematem powinny się zmieniać paddle w 7800... ciekawe.
Z resztą jak wtedy rozpoznać który przycisk wciskamy?

Cuś masz popsute :P

Dobrze, kurde!
Zrobiłem w Scorchu obsługę Joy 2B+ (tylko 2gi guzik) sprawdzając zmianę stanu. Nie wiem jak to zadziała przy kilku joystickach (na emulatorze wygląda że działa - przechowuję tylko jeden stan dla wszystkich 4rech portów.... ciekawe jak to się zachowa przy kilku Joy 2B+).

Wada.... nie działa repetycja tego przycisku, co wynika ze sposobu sprawdzania i właściwie działania w momencie puszczenia.

Proszę bardzo! Jest w gałęzi develop.
- 22: CommentAuthormono
- CommentTime31 May 2023
Działa w momencie puszczenia bo nie zanegowałeś.
- 23:
  
  CommentAuthorPecus
- CommentTime31 May 2023
Wiem :)
Nie zanegowałem bo mi 1 (słownie JEDNEGO) bajtu na tę negację zabrakło :)

Ale spoko. Właśnie, dzięki optymalizacjom, udało się odzyskać 17b. będzie negacja.

Od 1 do 23 z 23