Ja raczej czasu nie znajdę - za dużo roboty.
A tak na marginesie Pub Książęcy już nie istnieje - jest jakas nowa głupia nazwa.

Hehe, fajne ;) Można będzie sobie poszpanować wśród zwykłych śmiertelników :D

Wydaję mi się, że temat dyskusji nieco się oddalił. Może wizualnie przypomnę o temacie :-)

Kościół Wyznawców Antica :))

A może założymy fundację? ;)
Fundacja pomocy biednym programistom, albo Fundacja na rzecz 8-bitowego oprogramowania :)))

Nosty: te 20% to tak na oko i o smartphonie mówiłem :) główy nie dam ile dokładnie było. Mój PPC czyli iPaq h4150 chodzi na bateriach prawie 10h. Zawsze można zwolnić zegar i przyciemnic obraz - to wydłuzy czas pracy. WiFi i BT niestety zżerają baterie :(
Atari800 na smartphone chodzi u mnie dziwnie - jedne demka chodzą szybko inne wolno. Jakkolwiek w Spy vs Spy gram ostatnio dość często i bez żadnego dyskomfortu związanego z opóźnieniami.
Nie wiem jak jest z Mitac Mio - jak dla mnie jest to dziwne, że tylko 35%... może źle podaje prędkość? ;) Jak miałem kiedyś iPaq h1940 gdzie był 200MHz Arm to Numen działał na 100% a miałem wrażenie niekiedy, że nawet szybciej ;) Niestety Pocket Pocketowi nie równy....

Jelloonek: oj, no zjadłem jeden "+" ;) Co do efektów to była tylko przenośnia. Chodziło mi o to, że jeśli stosuje się wyuzdane techniki programistyczne ;) typu self modyfing code, rozpisywanie pętli czy tablicowanie czego się da to są to rzeczy dla kompilatora raczej nie do przyjęcia. Kompilator zawsze będzie się starał wyprodukować szybki i poprawny kod zgodnie z zasadami, a żeby osiągnąć zysk trzeba czasami pokombinować i pewne zasady złamać (patrz: nielegalne rozkazy). Fakt, nie ma może zbyt wiele dobrych kompilatorów na 6502, ale nawet jakby były to nie uwierze (póki nie zobaczę), że taki kompilator mógłby bardziej przyśpieszyć efekty np. występujące w Numenie czy jakimkolwiek innym powalającym na kolana demku.

Co do większych procesorów zgadzam się - kompilator lepiej potrafi optymalizować, bo nowe procki mają zaszyte rozmaite cuda (jasnowidzenie, kolejkowanie, cacheowanie, potoki, strumyki i inne rzeczki ;) ) i żaden z programistów nie jest w stanie sprawdzić kodując real-time, że jeśli zamieni dwa rozkazy miejscami to akurat w piątym potoku zwolni się jakiś rejestr i wtedy wykonają się ona 3x szybciej, bo w drugim potoku będzie następny dostęp do rejestru wykorzytanego za pięć linii :)))
Jakkolwiek algorytm działania programu dobiera programista i w ten sposób jest w stanie optymalizować dane zagadnienie na dany procesor. Chodzi mi o to, że każdy procesor jest w czymś lepszy, jeden liczy szybciej, drugi przetwarza dane szybciej etc.

Fox: A kiedy przyśpieszysz to co się da? ;) Jeśli chodzi o Pockety to jak już gdzieś rozmawialiśmy sprawa się rozwiąże po zmienie obsługi pamięci dodatkowej.

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?

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...

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ń.

Fox: mi chodziło tylko o to, że jeśli kod Atari800 my sie zoptymalizowalo i zmodyfikowalo pod kątem ARM-a  (pozwalajac sobie nawet na wstawki w asemblerze) to emulator moglby dzialac szybciej. Nie wiem o ile bo nie jestem specjalista od ARM-ów, ale biorąc pod uwagę, że ARM został opracowany na podstawie 6502 (podobno) mysle, ze mozna by przynajmniej te kilkanascie procent uzyskać. Podkreślam jednak, że to tylko na razie teoria nie poparta żadnymi badaniami.

Trochę źle mnie zrozumieliście. Żadnych "skoków" nie będzie ;)
Ja wcale nie zamierzałem wysyłać 50 pakietów na sekundę ;) To byłby kompletny bezsens.
Jeśli już miałoby tak być to lepiej byłoby przesyłać dane w formie streamingu (tj. streaming audio lub wideo). Wtedy w ciągu jednej sekundy można przesłać znacznie więcej niż 50 bajtów :) A generalnie chodzi o to, żeby mozliwie najdokładniej odtworzyć stany remote joya.

Pierwotnie myślałem o komunikacji takiej, jak w klawiaturze od PC. Przy każdej zmianie jest generowana komenda czyli jeden gracz rusza joyem w prawo to idzie tylko jeden pakiet - gdy puszcza idzie drugi pakiet. Tym sposobem dokładność ruchów jest zachowana za wyjątkiem drobnego opóźnienia od kilkunastu do kilkuset ms.

Podsumowając mamy dwie metody:
- data streaming, w której przesyłany jest aktualny stan portu Joya,
- blitter style packet, w której przesyłane są tylko zmiany stanów.

Teoretycznie pierwsza metoda mimo, że jest bardziej pasmożerna powinna dać mniejsze opóźnienie, ale póki się tego nie sprawdzi to pewności mieć nie można.

Jeśli ktokolwiek oprócz mnie jest zainteresowany proponowanym przeze mnie rozwiązaniem myślę, że watoby znaleźć ochotnika, który podjąłby się wykonania dwóch propotypów. Przetestuje się wszystkie możliwości i zobaczymy. Na pewno w jakąś grę w ten sposób pograć się da :)