pomysl moze i ciekawy, ale teoretycznie wiekszosc gier na atari dziala w tepie "1raz na ramke" co oznacza ,ze stan joysticka jest sprawdzany 50razy na sekunde, wiedz ,zeby nie bylo by zadnych opoznien ping pomiedzy dwoma kompami podpietymi do internetu powinien byc <20ms, a raczej malo osob moze sie pochwalic takim dobrym laczem...
synchronizacja polaczenia by w pewnym sensie zalatwila sprawe, ale sterowanie bylo by bardzo "skokowe", pomiejajac nieregularny "ping" i packet lost...
przez co wiekszosc gier stala by sie srednio grywalna wlasnie ze wzgledu na sterowanie...

Ostatnio edytowany przez pr0be (2006-01-03 21:01:58)

W Hammurabiego, w Spy vs Spy i wiele innych ;) Nie twierdzę, że we wszystkie. Poza tym możnaby stworzyć specjalne gry pod taki interface czy nawet zaimplementować coś podobnego w emulatorze Atari800, wowczas moznaby opóźnić obraz no i obyłoby się bez lutowania :))

Wiadomo, wszystko zależy od opóźnień, ale jeśli np. w grze trzeba szybko ruszać joystickiem, to ruchy będą tak samo szybkie jak normlnie ale odrobinke opóźnione. Zresztzą skoro w Doom'a i inne gry sieciowe grają ludzie z całego świata i jakoś to wszystko chodzi to czemu by to nie miało sie sprawdzić z atarowskimi hitami ;)

Jeśli obaj gracze korzystaliby z tego samego providera i mielinp. neostradę to opóźnienia mogłyby być poniżej 20 ms.

Zreszta, póki się nie spróbuje to sie nie dowiemy w się da grać a w co nie ;)
Pomyślcie tylko... a do tego dodatkowa komunikacja przez Skype :)

Co to znaczy "wiedz"? Tryb rozkazujący od "wiedzieć"? Nie bardzo mi pasuje do kontekstu.

Istnieje cos takiego jak Kailera (zaimplementowane w Atari800Win [Atari800?]). Jak to dziala tam?

druga metoda + komunikacja po udp - to moze nawet miec sens...

alex - pomysl kuszacy (bo nie trzeba by przerabiac gierek) ale niestety awykonalny. Ty nie chcesz zrobic podlaczenia Atarki do sieci (chcialo juz wielu) tylko przesylac ruchy joya kazdego gracza do dwoch komputerow na raz, przy czym do jednego przez internet np. w USA? I jesli bedziesz przesylal tylko ruchy joya to te komputery Ci sie ZAWSZE rozsynchronizuja (znaczy w sensie ruchow postaci, a wiec rowniez obrazu na ekranie). Czasami po paru sekundach, czasami po paru minutach ale zawsze. Czyli na moim ekranie moj bialy szpieg bedzie wchodzil w drzwi, a na Twoim ten sam bialy szpieg bedzie walil glowa w sciane, bo drzwi beda obok. I co najgorsze, ja nie bede mial zadnego sposobu, zeby sie o tym dowiedziec!
Jak juz chcesz robic cos takiego to zainteresuj sie czeskim wynalazkiem - polaczenie lokalne Atarek przez porty joyow. Taki rodzaj sieci. Kilka gier toto wykorzystuje. Wez noza, przetnij taki kabelek wstaw z kazdej strony "czarne pudelko" podpiete do internetu i bedziesz mial zdalne polaczenie atarek przez internet. I zadna ze stron nie zauwazy roznicy w grach (oczywiscie napisanych dla tego polaczenia only).
Tyle. Ale fajnie, ze ktos ma jakies nowe pomysly :)

Komunikacja po UDP jest tym, co powinno być zastosowane w opcji nr 2 IMHO ;)

Jeśli chodzi o problem rozsynchronizowania komputerów to wyjdzie w praniu. Kiedyś było takie demo WFMH gdzie trzeba było puścić muzyczkę z dwóch komputerów, żeby było stereo - o ile pamiętam słuchałem i nagrywałem przez dobre kilkanaście minut i nic się nie rozjechało, jakkolwiek szansa na rozsynchronizowanie komputerów jakaś tam jest. Aby temu zapobiedz możnaby zrobić dodatkowo kabelek do gniazdka cartridge i synchronizować komputery za pomocą Fi2 i HLT tak, żeby żaden z komputerów nie wyjechal z taktowaniem ani o jeden cykl zegara. jednak w niektórych grach (tych niezręcznościowych) rozsynchronizowanie zegarów miałoby wpływ jedynie na muzyczkę. Np. we wspomnianej rpzeze mnie grze Spy vs Spy wszelkie eventy w grze generowane sa przez grających więc rozsynchronizowanie komputerow o sekunde czy dwie nie będzie miało znaczenia.

Co do czeskiego wynalazku to nie słyszałem, nie sprawdzałem ale w wolnym czasie jak znajde to zobaczę.

Takiej sytuacji nie bedzie. Napisałem przecież, że do komputera podłączany jest interface a Joy do interfaceu i zadaniem czarnego pudełka jest opóźnić Joy'a loklanie tak, aby w obu komputerach event nastpąpił równocześnie. Nie jest to łatwe - wiem, ale mam pewien pomysł jak to rozwiązać :) Kluczem jest tutaj dokładna synchronizacja wszystkich urządzeń.

Ostatnio edytowany przez alex (2006-01-04 19:35:00)

jesli potrafisz nie tylko teoretycznie zaprojektowac, ale i praktycznie zaimplementowac protokol ktory by zapewnil w lokalnym kompie TAKIE SAMO opoznienie jak w zdalnym (nawet teoretycznie nie wiem jak to zrealizowac) - to ok.

mocno naciagany pomysl...

A ja Wam mówię, że jest na to sposób :) Jedyny mankament tego rozwiązania to to, że opóźnienie może się dodatkowo zwiększyć o kilka procent względem rzeczywistego no i trzeba się strasznie nakombinować, żeby to wszystko działało jak trzeba.

Draco: dobrze kombinujesz :) dodaj tylko do tego specjalne timery i synchronizację z fi2.

Pytanie tylko czy warto...

Generalnie chodzi o zliczanie cykli i nie musi to być koniecznie fi2, ale skoro jest to można wykorzystać - jest w końcu bardzo stabilne i nim oba komputer syę rozsynchronizują minie duuużo czasu ;)

Załóżmy, że są dwaj gracze A i B. Obaj mają odpowiedni zestaw (komputer, interface, joystick, etc.). Po podłączeniu i uruchomieniu wszystkiego oba zestawy obliczają średnie i najgorsze czasy opóźnień między sobą. Aby te dane były na tyle zadowalające, aby można było grać zakładam, że obliczanie trwa 40 minut. Oba zestawy synchronizują swoje liczniki (chodzi o liczniki w IMGL'ach) czyli ustawiają je na zero :)

- Gracz A wciska fire.
- A wysyła informację do B, jednak nie przekazuje tej informacji do komputera tylko czeka.
- B otrzymuje informację, bierze wartość najgorszego opóźnienia (z B do A), przelicza je na cykle, dodaje do aktualnego stanu licznika i wysyła do A potwierdzenie z wyliczoną wartością, po czym zaczyna liczyć.
- A otrzymuje potwierdzenie najprawdopodobniej szybciej niz wynosi najgorsze opóźnienie (albo równo z nim) i czeka, aż jego licznik będzie równy odebranej wartości, po czym zapodaje fire do komputera :)
- Dokładnie w tym samym czasie B również dolicza się tego samego stanu i również zapodaje fire do swojego komputera.

Tak po krótce wyglądałaby komunikacja. Oczywiście przelanie tego na software i hardware nie jest takie proste i wybmaga dużo żmudnej roboty i pomiarów, ale to co opisałem jest realne mimo, iz oparte na statystyce i prawdopodobieństwie, bo w końcu nastąpi ten moment, że opóźnienie maksymalne zostanie przekroczone i komenda przyjdzie po czasie :(

Największym problemem w tym całym zaganieniu jest porornie banalna rzecz, a mianowicie początkowe wyzerowanie liczników. Żeby to wszystko, co napisałem, działało oba liczniki muszą być w miarę dobrze zsynchronizowane, żeby ewentualny poślizg o kilka cykli nie był większy niż powiedzmy 1/10 ramki (gra przecież może sprawdzać joya nawet 3 razy na ramkę).

De facto mamy tutaj znany problem synchronizacji czasu w sieciach teletransmisyjnych i możnaby pokusić się o wykorzystanie znanych sposobów. Dość ciekawą opcją byłoby wykorzystanie sygnału GPS. Moznaby też pokusić się o skonstruowanie liczników w formie dołączanych modułów, zsynchronizować je przy produkcji i po prostu fizycznie wysłać pocztą. Wtedy (zakładając, że bateria pozwoli im działać przez kilka miesięcy) mamy dwa idealnie zsynchronizowane liczniki - przynajmniej na jakiś czas :) Podobny sposób wykorzystuje się bodajże w tokenach bankowych.

Także reasumując - zostawmy na razie problem realizacji IMGL'a i sprawdźmy czy możliwe jest posiadanie dwóch identycznych liczników, które będą ze sobą porządnie zsynchronizowane?

Ostatnio edytowany przez alex (2006-01-05 01:14:23)

W Hammurabim posługujemy się klawiaturą (to tekstówka jest), a co więcej, input uzytkownika - a nie np. VBL - stanowi podstawę czasu. Dlatego jest to gra, która najbardziej nadawałaby się do grania przez internet.

Nawet kiedyś chciałem zrobić serwer Hammurabiego, który pozwalałby pewnej ilości użytkowników grać jednocześnie - ale tu na chceniu się skończyło.

Ostatnio edytowany przez drac030 (2006-01-05 10:09:43)