26

Odp: Emulator atari

Umieszczając na forum publicznym krytyczne uwagi nt. czyjejś pracy warto wpierw dokładnie zapoznać się z tematem. Inaczej dochodzi do niekończącej się sprzeczki i bezsensownego obrzucania się błotem. Jako osoba od 7 lat związana z projektem Atari800, która poświęciła mu setki jeśli nie tysiące godzin swojego czasu, będę go bronił.

laoo/ng napisał/a:

Jakie są dowody, że kod atari++ jest zżynany z atar800? Z tych fragmentów kodu które czytałem, to jest on zupełnie inny.

atari++ jest zaprojektowanym od nowa emulatorem, jednak autor czerpał wiedzę o działaniu układów ze starych wersji Atari800 (sam do tego się przyznaje np. w nagłówku antic.cpp) w związku z czym występują błędy emulacji takie jak w Atari800 0.9.x. Co do żywcem wziętych fragmentów kodu to faktycznie były one niewielkie (np. tablica etykiet systemowych z monitor.c z identycznymi literówkami w nazwach etykiet jak w starych Atari800), ale autor atari++ wypierał się początkowo, że były jakiekolwiek i upierał się przy zastosowaniu swojej, jak sam napisałeś, niezrozumiałej licencji, odrzucając GPL. Dzięki temu, że udało się wywalczyć GPL możesz spokojnie wypuszczać swoje modyfikacje na GPL.

laoo/ng napisał/a:

atari800 to czyste C napisany w sposób przypominający wynik działania obfuscatorów (IMHO ma szanse na wysokie miejsce w IOCCC ;) )

"Czyste C" uznaję za komplement, ale do IOCCC daleko. Chyba widziałeś mało skomplikowanych programów - są one skomplikowane, bo realizują skomplikowane funkcje. Tak jest w przypadku Atari800 - zapewnia on po prostu dokładniejszą emulację i większą wieloplatformowość, niż atari++ i dlatego kod jest bardziej skomplikowany.

laoo/ng napisał/a:

a atari++ napisany jest bardzo czysto obiektowo i widać, że na początku był projekt, a nie radosne programowanie, dzięki czemu rozszerzanie go o cokolwiek nie sprawia żadnych trudności.

Bardzo podobała mi się konstrukcja pierwszych wersji atari++, jednak z tym bardzo czysto obiektowo to przesada. Co do projektu to niestety ja zauważam "syndrom Javy", tj. nadmiernej rozwlekłości kodu w imię obiektowości. Brakuje natomiast ważniejszej rzeczy: chociażby struktury katalogów w źródłach. W atari++ jest ponad 300 plików źródłowych w jednym katalogu. W tym pliki cart16k.cpp, cart16k.hpp, cart32k.cpp, cart32k.hpp i jeszcze kilkadziesiąt następnych do innych wielkości cartridge-y - czy rozwiązanie z cartridge.c i cartridge.h nie jest rozsądniejsze?
Co do łatwości rozszerzania, to w przypadku atari++ wydaje się, że wszystko trzeba robić na siłę obiektowo - a co w przypadku gdy nowa funkcjonalność niezbyt wpasowuje nam się w istniejący model obiektowy?

laoo/ng napisał/a:

Najnowsze dema chodzą i jedyne co zauważyłem, to że dźwięk faktycznie trochę pierdzi (co dowodzi, że przynajmniej POKEY nie był wyrżnięty ;P). A jakie są inne ciężkie winy, że tak jest jechany i skazany na banicję?

Jeśli chodzi o mnie, to życzę projektowi atari++ jak najlepiej. Sam chciałem pomóc w jego rozwoju, jednak szybko zauważyłem, że musiałbym wykonać powtórnie pracę, którą przez lata włożyłem w Atari800, bowiem w atari++ są błędy, które kiedyś były w Atari800. Najnowsze dema nie są najlepszym miernikiem jakości emulacji, znacznie lepsze są stare gry. Ilość portów i ludzi pracujących nad rozwojem emulatora też zdecydowanie przemawia za Atari800. Chociaż obiektowość atari++ może zachwycać na pierwszy rzut oka, na dłuższą metę (np. przy wprowadzaniu istotnych poprawek w emulacji Antica) jest niepotrzebnym balastem.

jellonek napisał/a:

becny kod jest w/g mnie lepiej rozwijany/bardziej przejrzysty niz atari800. ten ostatni od dluzszego czasu wyglada na zaniedbany...
od prawie roku gotowa byla poprawka do "f7" znanego z atari800win+ i do tej pory nie przejszla...

Dla projektu trwającego ponad 10 lat kilka miesięcy ciszy nie jest problemem - może po prostu jest dobry a użytkownicy zadowoleni? Niedbała jest natomiast poprawka, która w emulatorze wieloplatformowym koncentruje się na jednej platformie (używanej przez autora platformy) i nie uaktualnia dokumentacji. Gdyby poprawka była bez zarzutu, to od razu by przeszła - przecież to żaden wysiłek ją zaaplikować. Zachęcam do poprawienia poprawki tak, aby nie wprowadzała ona większego bałaganu do Atari800, niż jest obecnie.

https://www.youtube.com/watch?v=jofNR_WkoCE

27

Odp: Emulator atari

Za bezpodstawne krytyczne uwagi biję się w pierś i przepraszam! Napisałem trochę emocjonalnie, bo wcześniejsze posty też takie były. W kwestię kradzieży źródeł nie będę wnikał, bo nie mam intencji bronić autora ani nie ma to znaczenia w wykorzystaniu samego emulatora.
Tak z pewnej perspektywy, to porównywanie obu emulatorów jest bardzo trudne, bo mają odmienne założenia. Atari800 powstawał w zamierzchłych czasach, gdy wydajność miała znaczenia i poświęcono dla niej czytelność, podczas gdy w atari++ wydajność została poświęcona dla czytelności. W rezultacie jak atari800Win zjada tak mało procesora, że taskinfo nawet nie chce pokazać ile, to atari++ potrafi zjeść nawet 7%, ale nie wydaje mi się, żeby dziś stanowiło to problem. Dla mnie atari800 przedstawia się jako bardzo stabilny i dojrzały projekt, w którym nie ma miejsca na eksperymenty i zwykły "szary człowiek z ulicy" nie ma nawet odwagi nic tam dopisać. Z drugiej strony atari++ po pobieżnym zapoznaniu się z architekturą jest bardzo czytelny i podatny na modyfikacje i eksperymentowanie w nim jest bardzo proste. Dodanie GTIA Upgrade wymagało kilku dni zapoznawania się z architekturą i dosłownie kilku godzin pisania. Przyznam się, że mam już w fazie testów emulację 65c816 + liniowy ram (pisałem parę tygodni wieczorkami, bo dużo rozkazów :P), a puszczenie high-ramu na wyższym zegarze ze zgodnością z WARPem wymaga kilku żmudnych (bo znowu dużo rozkazów) ale prostych modyfikacji.
W rezultacie przeznaczenie obu emulatorów może być także różne. Na atari800 można odpalać stare gierki, ale uważam, że współczesnym hardwarowym rozwiązaniom jakie mamy teraz na scenie przyda się support nawet kosztem tego, że jakiś pixel zasyfi, pokey zapierdzi albo nie odpali się stara gierka.

28

Odp: Emulator atari

z deka broniac sie (btw. milo ze w koncu jest odzew ;) ) poprawka byla rzeczywiscie jedynie propozycją "jak ugryzc temat" (przykladowym rozwiazaniem). proponowany sposob przelaczania nie byl zwiazany z konkretna platforma i dzialal(by, gdyby nie owczesny bug w ui) na kazdej platformie, a tylko dla SDL dodawal F12 jako switch (dalem to jako przyklad - nie bylo propozycji jaki skrot klawiszowy zastosowac w innych portach, a i do tej pory miedzy portami chyba nie ma jednolitego podejscia do tego tematu - a mialo sie to ztcp przed pazdziernikiem zmienic).

nie interesowalem sie "upiększaniem łatki" (dokumentacja, inne porty, speedmeter) bo przez 14 miesiecy nawet linijki odpowiedzi na posta nie dostalem...

ale skoro widze odzew - i tu i na grupie - pewnie niedlugo poprawie, tyle ze widze ze bede musial rozbic "pacza" na osobne czesci, tj. atari.[ch] (pomyslec nad speed toggle) + ui.c + kawalek dokumentacji, oraz poszczegolne platformy + pozostala czesc dokumentacji (pod jakie klawisze podpiecie)

przy okazji moze porusze temat ktory rowniez te nieszczesne 14 miesiecy temu zamarl - funkcje klawisza f7...

co do naciskow na autora atari++, to pamietam ze dlugo pozostawal oporny i nie chcial sie przyznac do tego ze zywcem kod ukradl, ale przynajmniej teraz kod jego jest na GPL. i tak atari800 ze wzgledu na wieksza zwiezlosc kodu bedzie dzialac lepiej np. na arm9, czy powerpc (pockety, czy telefony - nadal nie moge sie zmusic do sportowania na platforme nokii :/ ).

laoo: czytelnosc, a wydajnosc kodu nie ma nic wspolnego. mozna pisac kod cholernie czytleny i nadal wydajny, jak i rownie niewydajny co nieczytelny... kwestia lezy gdzie indziej - kiedy nastapi przelanie czary goryczy i miast ciagle poprawiac kod, łatając, łatając, łatając - wezmie sie ktos za napisanie go od nowa (ewolucja jest fporzo, ale czasem potrzebna jest rowniez rewolucja) i na podstawie doswiadczen zebranych przy poprawianiu - od nowa napisze wszystko "tak jak trzeba".

fox: cos czuje ze autor atari++ nie przenosil do podkatalogow tych plikow, bo pewnie rozwija kod w (tfu) Visual Studio (tfu), i przez to nie zwracal uwagi - ale moze da sie go przekonac do sensownego przearanżowania struktury projektu...

Ostatnio edytowany przez jellonek (2007-04-23 13:04:09)

The UNIX Guru`s view of Sex:
unzip; strip; touch; finger; mount; fsck; more; yes; umount; sleep

29

Odp: Emulator atari

Z tą czytelnością / wydajnością byłem nieprecyzyjny. W czasach powstawania atari800 nie można było sobie pozwolić na taką architekturę, jaka jest w atari++, bo nie było komputerów, na których by to poszło. Sytuacja się zmieniła. Emulator powstał. Nie taki wierny jaki atari800, ale to już jest kwestia osobomiesięcy spędzonych nad kodem. Jego plusem jest spójność i łatwość modyfikacji i nie uważam, że autor przesadził z obiektowością. Jest poprostu konsekwentny. To nie jest kod w C tylko C++ i to dobry C++.  A żeby projekt sie nie zawalił i nie trzeba było go łatać, nie można sobie pozwolić na haki oszczędzające trochę czasu procesora.
A poza tym kod nie jest rozwijany w Visual Studio. W porcie windowsowym pomagał ktoś inny.

30

Odp: Emulator atari

aha - czyli tylko poprostu odnioslem mylne wrazenie...

The UNIX Guru`s view of Sex:
unzip; strip; touch; finger; mount; fsck; more; yes; umount; sleep

31

Odp: Emulator atari

jellonek napisał/a:

poprawka byla rzeczywiscie jedynie propozycją "jak ugryzc temat"

Jak wiesz projekt Atari800 nie ma nadmiaru developerów, którzy tylko czekają na pomysł, żeby mieć co robić. Ja i Perry jako osoby najlepiej znające emulator od środka napisaliśmy kawał TODO, ale nie zawłaszczamy sobie prawa do zrealizowania wszystkiego własnymi siłami (jakby mało było tego, co dotychczas zrobiliśmy). Chętnie natomiast weźmiemy udział w dyskusji, poradzimy, podpowiemy, itp.

jellonek napisał/a:

kiedy nastapi przelanie czary goryczy i miast ciagle poprawiac kod, łatając, łatając, łatając - wezmie sie ktos za napisanie go od nowa (ewolucja jest fporzo, ale czasem potrzebna jest rowniez rewolucja) i na podstawie doswiadczen zebranych przy poprawianiu - od nowa napisze wszystko "tak jak trzeba".

Właśnie dotknąłeś istotnej kwestii - łatek vs starannego projektu i napisania od nowa. Przepisałem na nowo znaczną część Atari800 i dlatego jestem krytyczny w stosunku do łatek, które chociaż trochę burzą porządek, bo wiem, że jeśli niskim nakładem pracy wprowadzi się je dzisiaj, to kiedyś nadejdzie czas, żeby je posprzątać (a autor łatki prawdopodobnie będzie już nieosiągalny).

https://www.youtube.com/watch?v=jofNR_WkoCE

32

Odp: Emulator atari

bo wiem, że jeśli niskim nakładem pracy wprowadzi się je dzisiaj, to kiedyś nadejdzie czas, żeby je posprzątać (a autor łatki prawdopodobnie będzie już nieosiągalny)

bolesne jak i prawdziwe...

The UNIX Guru`s view of Sex:
unzip; strip; touch; finger; mount; fsck; more; yes; umount; sleep