Pamiętam. Jednak podtrzymuję, że zachodzi tu wyjątek, mianowicie w postaci programu, który jest silnikiem emulacji innego CPU. Tutaj C niestety polegnie, bo jest JEDNAK językiem stosunkowo wysokiego (za wysokiego) poziomu.

gcc dla m68k to było kolejno 2.7.2, 2.8.1, 2.95.2. Wszystkie wersje generują dość przyzwoity kod wynikowy, zresztą chyba nie może być inaczej, skoro gcc przeprowadza optymalizację jeszcze na etapie niezależnym od maszyny, a dopiero to co mu wychodzi przekłada na mnemoniki. Podejrzewam, że na innych platformach z jakością kodu jest dokładnie tak samo.

Pytanie jest idiotyczne z dwóch względów:

a) masz wyżej napisane, że silnik asemblerowy jest szybszy od ANALOGICZNEGO kodu w C (czyli: algorytm ten sam)

b) asembler to jednak nie jest C, więc wymyślenie programu w C, a potem przełozenie go ręczne na asembler nie może dawać wyników znacząco lepszych niz w przypadku produktu kompilatora; implementacja algorytmu musi być nie tylko w asemblerze napisana, ale tez w asemblerze wymyślona.

Dla ułatwienia dodam, że ten program chodzi na procesorach od 68020 do 68060 i nie zawiera nieczystych sztuczek w rodzaju samomodyfikującego się kodu (bo to na Motorolach powoduje problemy z cache'em).

Cały program z gcc nie ma nic wspólnego, poza tym, że gcc występuje tu jako wartość porównawcza. Ale twierdzę, że to jest właśnie taki przypadek, gdzie nie tylo gcc, ale dokładnie każdy kompilator zawiedzie. A to z tego powodu, że kompilator jest bezmyślnym automatem. Może optymalizowac znane sobie (czyli swoim twórcom) konstrukcje pod względem formalnym, oraz dokonywac analizy programu na np. częstotliwośc użycia pewnych zmiennych, żeby zdecydować, które zmienne umieścić w rejestrach, które na stosie a które gdzie tam. Oraz dysponuje repertuarem tym podobnych chwytów.

To wszystko jednak nie zmienia faktu, że kompilator nie ma bladego pojęcia, co kompilowany program robi, oraz jak można wykorzystać architekturę danej maszyny do zrobienia tego lepiej. To wie tylko człowiek, bo tylko człowiek jest w stanie zrozumieć algorytm.

Fox: zagadnienie nie ma nic wspólnego z opcjami optymalizacji kompilatora C, a raczej z tym, jak kompilator w ogóle działa, no i jak jest zdefiniowany język C jako taki.

Myślimy, że nie ma przeszkód, żebyś to zrobił.

Jellonek, ty teoretyzujesz, a ja napisałem w asemblerze silnik 6502 sześć razy szybszy od analogicznego kodu generowanego przez gcc. Taka jest różnica między zdaniem moim a twoim.

No to podziel się tym sposobem, bo mi na razie synchronizacja internetu z fi2 wydaje się koncepcją dość egzotyczną.

Moim zdaniem nie ma siły - pudełko może wysłać pakiet z informacją o zdarzeniu do komputera remotnego, poczekać na potwierdzenie przyjęcia i dopiero wtedy przesłać tę samą informację do kompa lokalnego ALE to też niewiele da, bo pakiet z informacją zwrotną nie nadejdzie natychmiast, lecz droga też zabierze mu nieco czasu.

Jeśli więc pomiędzy wysłaniem pakietu z informacją o zdarzeniu a potwierdzeniem przyjęcia upłyną np. 2 sekundy, to nie znaczy, że komputer zdalny dostał informację po dwóch sekundach, tylko że dostał ją gdzieś w czasie od t+0 do t+2, że tak powiem. Kiedy konkretnie - to jest kompletnie nie do ustalenia.

(EDIT: a może i jest - w pakiecie zdarzenia trzeba byłoby zaznaczyć czas nadania, a w zwrotnym czas przyjęcia; a dalej jak poniżej).

Rozwiązaniem jedynym realnym moim zdaniem jest transmisja synchroniczna, to znaczy pudełka generują określoną liczbę pakietów na sekundę niezależnie od tego co robią gracze. Streaming pakietów, innymi słowy, wtedy opóźnienia transmisji dałoby się łatwo przeliczyć w oparciu o podstawę czasu nazwijmy to, co pomogłoby wyeliminować desynch.

Ale obawiam się, że z tym będzie problem, o którym pisano już powyżej, to znaczy gra typu Spy vs. Spy przestanie być grywalna jeśli na na reakcję na ruch joystickiem trzeba będzie poczekać do paru sekund.

Alex, nosty ma rację, przemyśl to jeszcze. Tu nie chodzi o rozjechanie się zegarów, tylko właśnie sytuacji w grze, co będzie spowodowane tym, że "ewenty" joysticka będą docierały do obydwu komputerów nierównomiernie: do jednego - lokalnego - natychmiast, do remotnego natomiast - z opóźnieniem powodowanym przesłaniem pakietu przez internet. I odwrotnie, remotny komp będzie dostawał lokalne wydarzenia natychmiast, ale do twojego będą one docierały z opóźnieniem np. pół sekundy.

Efekt będzie taki, że ty go w ryj, i on na twoim ekranie w ryj dostaje, ale na drugim komputerze on jest już w drugim pokoju a ty nie wiadomo gdzie.

PS. demko to była Pierestroyka.

Ale w Hammurabiego można byłoby pograć.

A ile ten "długi zasilacz" ma amperów? Muszę coś wpisać do manuala w kwestii recommended power supply.

Czyli, jaka w końcu jest wymagana moc zasilacza? Bo rozumiem, że u delego był za słaby?

U mnie się nie chce odtwarzać :( Ani mplayer ani XMMS tego nie bierze.

Zamek? A było coś, faktycznie. Widoczne podczas drogi do knajpy ;)

(Hint: ja osobiście rzygam zamkami czesko-słowackimi, oni to w kółko pokazują, nawet wmuszają; w środku są posadzki, sufity i lanszafty na ścianach, przedstawiające czeskich wielmożów w chwili mówienia po niemiecku - ja mimo wszystko preferuję spotkania z naturą, czyli zdrowa czesko-słowacka knajpa z knedlikami w sosie padlinowym zwanym gulaszem oraz piwo w ilościach).

ACSI = Atari Computer System Interface o ile pamiętam (przydałby się artykuł o tym w Atariki, tak w ogóle).