26

Fakt, UI jest do bani. Dodatkowo denerwujace jest skalowanie obrazu oraz brak scanlines.
Tym bardziej ciesze sie, ze wraca support dla a800win.

27 Ostatnio edytowany przez Dracon (2011-12-27 23:16:36)

Mnie tez troche dobija interfejs Altirry, a poza tym ponawiam pytanie:
ktory emulec jest lepszy (na dzis - koniec roku 2011) odnosnie emulacji dzwieku - Altirra czy A800Win? Chodzi o wrazenia ogolne, wiernosc odgrywania digitek, itp.

28 Ostatnio edytowany przez AXE/SSG (2011-12-27 23:31:31)

sprawdzilem nemezis emulatorow malego atari - raving vieprz.
w 4.1 juz sie nie wiesza jak wczesniej, choc dalej nie widac glownych efektow.
pod tym wzgledem jednak atari++ pozostaje najlepsze, ale tu interfejs jeszcze mniej do mnie przemawia...

@Dracon
nie sprawdzalem sampli, ale moim subiektywnym uchem syntetyki na 800winplus po ustawieniu sound quality na 3 graja prawdziwiej niz na altirze.

don't come after... please don't follow me along. when you read this, i'll be gone...

29 Ostatnio edytowany przez Dracon (2011-12-27 23:43:40)

No to chociaz w dwoch rzeczach A800Win jest lepszy od Altirry - interfejsie i dzwieku. :)
Zatem Phaeron ma co robic, nawet jak doda juz wszystkie mozliwe rozszerzenia sprzetowe i dodatki (o Slight Sid juz pamietal). ;)

30

poprawka. cos musialem nakombinowac w ustawieniach, bo po wylaczeniu non-linear mixing w altirze bylo zdecydowanie lepiej!

moja platforma testowa to: numen, realtek hd audio z w miare aktualnym sterownikiem, creative itrigue 3330
- na poczatku (logo TQA, chodzenie po otwartym swiecie) basy sa tak czyste jak w a800winplus
- dalej, po wyjsciu z korytarzy do rotatora podloga-sufit i torusa, "metaliczne" dzwieki brzmia rownie dobrze.

poki co, remis.

don't come after... please don't follow me along. when you read this, i'll be gone...

31

Fox napisał/a:

"Usiąść i porozwijać sobie Altirrę" w praktyce oznacza:

Ale fork Altirry ma nadal więcej wspólnego z rozwojem Altirry niż programowanie WinPLusa.

Fox napisał/a:

Mógłbyś wyjaśnić, dlaczego akurat przy małych projektach należy współpracować, a przy dużych konkurować?

Gdybym gdziekolwiek wypowiadał się o dużych projektach, to pewnie bym spróbował. Małe projekty natomiast są zazwyczaj utrzymywane przez niewielkie grupki ludzi mających domdzieckopracęobowiązki, toteż współpraca między projektami (nawet ograniczająca się do wzajemnego podkradania kodu) pozwoliłaby tym ludziom osiągnąć więcej niż gdyby mieli sobie osobno programować te same funkcje na różne sposoby.

Fox napisał/a:

Każdy może ściągnąć źródła i je skompilować, a sugerujesz, jakoby kod PLusa był nieosiągalny dla programistów projektu Atari800.

Miałem raczej na myśli, że możliwość zbudowania WinPLusa jest poza zasięgiem programistów, którzy np. mogą nie mieć dostępu do Windows i VisualStudio.

Fox napisał/a:

To nic nie zmieni.

Nie wiem czy się dobrze rozumiemy, ja nie proponuję tutaj wrzucania WinPLusa do repozytorium Atari800.

Fox napisał/a:

Co do "na pewno autorowi PLusa byłoby tak wygodniej", to niech się wypowie Jaskier.

Miałem na myśli że na pewno było by mu wygodniej gdyby wtręty WinPLusowe były w repozytorium.

Fox napisał/a:

Między innymi chodziło właśnie o kod, który (...) i okazało się, że równie dobrze przydawała się w portach Atari800 Win32 oraz WinCE (...)

No ale Twój przykład nie pasuje do kwantyfikatora, czyli ma się nijak do mojej początkowej uwagi.

mazi napisał/a:

Dodatkowo denerwujace jest skalowanie obrazu

A co z nim jest nie tak? Działa poprawnie, Atari800 też już to ma.

A8CAS - narzędzie do 100% archiwizacji kaset Atari

32

Nie jestem teraz w domu i nie mam dostepu do mojego sprzetu ale, jak sie okazuje, na komputerze moich rodzicow moge odtworzyc ten sam efekt:

http://i41.tinypic.com/rup3ir.jpg

Chodzi o to, ze wolalbym rozwiazanie takie jakie jest w a800win+, iz wybieram tryb a emu sam mi przeskaluje wyswietlany obraz atari do podanej rozdzielczosci.

33 Ostatnio edytowany przez Jaskier (2011-12-28 21:25:27)

Witam,

Ale się miło kłócicie, aż fajnie popatrzeć :)

No to teraz kilka słów wyjaśnień ode mnie:

Atari800 jest emulatorem tworzonym od wielu lat przez wielu ludzi. Może wygląda on na zaśmiecony, ale z całą pewnością jest mniej zaśmiecony niż jakieś 6 lat temu. Obecnie ma on czystą strukturę: główny emulator + funkcje specyficzne dla platformy. Problem w tym, że struktura Atari800Win to: funkcje specyficzne dla platformy (interfejs Atari800Win) + główny emulator. Ta zamiana ról powoduje, że nie da się od tak po prostu użyć funkcji z atari800, potrzebne są zmiany, ale do tego wątku jeszcze wrócę.

Mam ogromny podziw do Phaerona, który startując od zera uzyskał w kilka lat porównywalny poziom emulacji atari jak wielu twórców atari800 przez znacznie większy okres czasu. Tyle, że nie widzę związku dlaczego rozwój Altirry miał mieć jakiś wpływ na Atari800Win. Sugestia, że jeśli przestałbym pracować nad Atari800Win to pracowałbym nad Altirrą jest śmieszna. Przede wszystkim nie sądzę aby Phaeron potrzebował mojego wtrącania się do jego kodu. Co ciekawe (jak ktoś czytał wątek na atariage ten wie), to właśnie Phaeron zdebugował i znalazł błąd w jednej z beta wersji Atari800Win. Czyli również on nie uważa, że powinien być tylko jeden jedyny zatwierdzony emulator Atari pod Windows.

Ustalmy sobie jedno. Emulatorami atari są takie emulatory jak: Altirra, atari800, Atari++ i inne. Atari800Win jest czymś w rodzaju spin-offa atari800. Realizacją pomysłu stworzenia emulatora atari800 z interfejsem znanym z Windows. Specyficznego projektu, ponieważ prawie zawsze rozwijanego przez 1-2 osoby (pomimo bycia GPL). Obecnie również ma on 2 developerów. (I pomimo iż drugi jest prawie niewidoczny, to bez jego rad nie dałbym rady zbudować wersji 4.1.)

Atari800Win polega mocno na kodzie atari800. Swego czasu mocno pracowałem z Foxem aby to połączenie uczynić silniejszym. Dzięki jego staraniom udało się doprowadzić do tego, że Atari800Win kompilował się bez przeszkód z dowolną wersją atari800. Skutki jego działań są widoczne obecnie. Po 6 latach jedyne zmiany jakie musiałem dokonać w Atari800Win aby się kompilowało z atari800 to:
-zmiana nazw zmiennych
-zmiana kilku #ifdefów
-zmiana obsługi generowania palety kolorów
niewielkie zmiany jak na 6 lat pracy trzeba przyznać.

Obecne widoki na przyszłość można opisać tak:
-Altirra, Atari++ i inne będą wydawane jak ich autorom się zechce pracować,
-atari800 wciąż będzie rozwijane przez grupę jego twórców.

A co zrobić z Atari800Win? Nie mam ochoty wtrącać się w pracę innych developerów. Phaeron pewnie niechętnie widziałby wtrącanie się do jego kodu. Nie mam również ochoty tworzyć atari800 bo nie znam się na emulacji Atari.

Mogę więc robić 3 rzeczy:
-Stworzyć międzyplatformowy interfejs dla arari800 oparty o wxWidgets. Oznacza to jednak pisanie właściwie wszystkiego od nowa.
-Zintegrować Atari800Win z atari800 na takiej samej zasadzie jak inne porty (jak np. SDL). To też jednak oznacza przepisanie większości Atari800Win od nowa.
-W dalszym ciągu rozwijać Atari800Win w jego obecnej postaci.

Ta ostatnia opcja oznacza, że przy każdej nowej wersji atari800 trzeba będzie dopasowywać Atari800Win do atari800. Jak jednak pokazałem wcześniej nie jest to aż takie straszne. Byłoby oczywiście miło, gdyby autorzy atari800 zaakceptowali moje patche do atari800. Nie psują one nic w ich kodzie a mi ułatwiają pracę na przyszłość. Ale jak nie, to nie. Nie ma problemu. Czas potrzebny na utrzymywanie nowych wersji Atari800Win jest i tak wciąż mniejszy niż tworzenie nowych wersji emulatora (WX czy innego). A ponieważ czasu mam mało, to nie mam wyjścia. Albo będę raz na jakiś czas wypuszczał nową wersję Atari800Win opartą nowy kernel atari800 (mam nadzieję tylko, że częściej niż do tej pory), albo nie będę robił nic. (No w sumie to mi jeszcze pozostaje zrobienie ostatniego dema.)

Nie oczekuję, że twórcy atari800 będą utrzymywali kod Atari800Win. Chociażby z powodu nieposiadania kompilatora VC. Sam jednak fakt, że części Atari800Win znajdują się w atari800 wielce pomaga w pracy. Z reguły bowiem programiści nie usuwają bez potrzeby #ifdefów nawet jak ich istoty nie rozumieją. Mogę co każdą wersję podsyłać zmiany jakie musiałem dokonać w atari800 aby Atari800Win się budowało (tak wyglądała moja współpraca z Foxem). Przynajmniej nie będę musiał drugi raz nakładać tych samych zmian. (A patch nie zawsze działa, zależy ile w oryginalnym kodzie jest zmian.)

Nie wiem jakie super funkcje ma Atari800Win, które powinny niby się znaleźć w atari800. Co do odtwarzania dźwięku to zaprzeczam, nie ma w nim nic, co by zmieniało emulację dźwięku. Zresztą przecież wszystko jest opensource. Można kopiować co się chce. Swoją drogą dziwię się, że nikt przez 6 lat nie zrobił własnego buildu. Widać nie było to aż takie niezbędne do życia. Przeceniacie rolę Atari800Win.

I na razie tyle. Idę spać.

P.S. Coś się chrzani w emulacji w NTSC przy DirectSound (i chyba nie przy WaveOut, ale nie mam jak sprawdzić bo mój domowy komputer nie odtwarza WaveOut, tylko DirectSound, dziwne nie?), ale już mi się nie chce tej nocy debugować.

P.S.2 Pierwsze przykazanie: piłeś, nie pisz.

P.S.3 Umieściłem już beta 5 na githubie.
Tym razem dodałem też pełny instalator. Można sprawdzić czy działa.
Zmiany w tej wersji:
-Przypomniałem sobie, że trzeba dokompilować patch dla drukarki.
-Drobne poprawki w monitorze.
-Zwiększony bufor DirectSound, dzięki czemu w trybie NTSC działa płynnie nawet przy latency 2.

Aby odpackować teksty trzeba najpierw odpackować  program do ich odpackowywania - Energy #1

34 Ostatnio edytowany przez Krótki (2011-12-29 00:45:21)

Dracon napisał/a:

ktory emulec jest lepszy (na dzis - koniec roku 2011) odnosnie emulacji dzwieku - Altirra czy A800Win?

Altirra jest lepsza, bo np. ma 100% emulację przerwań POKEY-a, więc jeśli lubisz Emkaya i użyjesz ich do generowania dźwięku, Atari800 (w tym Win) leży i kwiczy.

mazi napisał/a:

Chodzi o to, ze wolalbym rozwiazanie takie jakie jest w a800win+, iz wybieram tryb a emu sam mi przeskaluje wyswietlany obraz atari do podanej rozdzielczosci.

Możesz wybrac zarówno rozdzielczość ekranu w trybie fullscreen (Tools->Options), jak i ustawić sposób skalowania taki sam jak w WinPLusie (View->Filter mode na Point i View->Stretch mode na Integral Square Pixels). Niestety połączenie obu funkcji póki co jest kulawe - skalowanie jest niedokładne i wygląda koślawo.

Zwróć tylko uwagę, że piksele prawdziwego Atari nie są kwadratowe (szczególnie w NTSC), więc nie da się wiernie odtworzyć obrazu posługując się skalowaniem "integral".

Jaskier napisał/a:

Atari800 (...) Obecnie ma on czystą strukturę: główny emulator + funkcje specyficzne dla platformy.

Moim zdaniem nie jest tak różowo, w "jądrze" emulatora wciąż niemało jest skrawków specyficznych dla platform. Jest na tym polu co nieco do poprawienia.

Jaskier napisał/a:

Sugestia, że jeśli przestałbym pracować nad Atari800Win to pracowałbym nad Altirrą jest śmieszna.

Nie sądzę żeby któś to tutaj sugerował.

Jaskier napisał/a:

Po 6 latach jedyne zmiany jakie musiałem dokonać w Atari800Win aby się kompilowało z atari800 to:
-zmiana nazw zmiennych
-zmiana kilku #ifdefów
-zmiana obsługi generowania palety kolorów

Nie działa zmiana palety przy przełączaniu PAL<->NTSC.


Jaskier napisał/a:

Byłoby oczywiście miło, gdyby autorzy atari800 zaakceptowali moje patche do atari800. Nie psują one nic w ich kodzie a mi ułatwiają pracę na przyszłość. Ale jak nie, to nie.

Podeślij na atari800-users, to że ja jestem niechętny takim łatom w szczególnych przypadkach, nie znaczy że to akurat ma być taki przypadek ani że jestem jakąś wyrocznią w tym projekcie.

Jaskier napisał/a:

(A patch nie zawsze działa, zależy ile w oryginalnym kodzie jest zmian.)

Ale to moim zdaniem zaleta takiego rozwiązania. Skoro patch przestaje dawać się aplikować, to znaczy, że w kodzie zaszły na tyle duże zmiany, że potencjalnie mogły zepsuć działanie patcha i należy się temu przyjrzeć.

Jaskier napisał/a:

Nie wiem jakie super funkcje ma Atari800Win, które powinny niby się znaleźć w atari800.

Pomyślmy. Mapowanie klawiszy, opcje w Advanced Atari Settings, skanlinie (w Atari800 póki co tylko w trybie OpenGL), szybkie software'owe skalowanie obrazu, Sound latency. Wszystko to przydatne funkcje, które da się z pewnym wysiłkiem zrobić tak, żeby było wieloplatformowo.

Ale w sumie jest remis, Atari800 tez ma kilka fajnych bajerów, których WinPLus póki co nie wspiera ;-)

Jaskier napisał/a:

Co do odtwarzania dźwięku to zaprzeczam, nie ma w nim nic, co by zmieniało emulację dźwięku.

... wyłączając całą zawartość pliku Sources/Core/sound_win.c. Nb. OIDP SYNCHRONIZED_SOUND chyba trochę duplikuje WinPLusową funkcjonalność w rodzaju Update divisor i Sound quality, ale musiałbym się temu przyjrzeć.

Jaskier napisał/a:

Swoją drogą dziwię się, że nikt przez 6 lat nie zrobił własnego buildu.

Próba była.

A8CAS - narzędzie do 100% archiwizacji kaset Atari

35

Krótki napisał/a:
Jaskier napisał/a:

Po 6 latach jedyne zmiany jakie musiałem dokonać w Atari800Win aby się kompilowało z atari800 to:
-zmiana nazw zmiennych
-zmiana kilku #ifdefów
-zmiana obsługi generowania palety kolorów

Nie działa zmiana palety przy przełączaniu PAL<->NTSC.

Kurde, gdzie? Przecież przy zmianie trybu jest uruchamiane Colours_Update()

Krótki napisał/a:
Jaskier napisał/a:

Byłoby oczywiście miło, gdyby autorzy atari800 zaakceptowali moje patche do atari800. Nie psują one nic w ich kodzie a mi ułatwiają pracę na przyszłość. Ale jak nie, to nie.

Podeślij na atari800-users, to że ja jestem niechętny takim łatom w szczególnych przypadkach, nie znaczy że to akurat ma być taki przypadek ani że jestem jakąś wyrocznią w tym projekcie.

Jak tylko wydam 4.1

Krótki napisał/a:
Jaskier napisał/a:

Nie wiem jakie super funkcje ma Atari800Win, które powinny niby się znaleźć w atari800.

Pomyślmy. Mapowanie klawiszy, opcje w Advanced Atari Settings, skanlinie (w Atari800 póki co tylko w trybie OpenGL), szybkie software'owe skalowanie obrazu, Sound latency. Wszystko to przydatne funkcje, które da się z pewnym wysiłkiem zrobić tak, żeby było wieloplatformowo.

Ale w sumie jest remis, Atari800 tez ma kilka fajnych bajerów, których WinPLus póki co nie wspiera ;-)

Proszę o listę. Zaraz się nimi zajmę :)


Krótki napisał/a:
Jaskier napisał/a:

Co do odtwarzania dźwięku to zaprzeczam, nie ma w nim nic, co by zmieniało emulację dźwięku.

... wyłączając całą zawartość pliku Sources/Core/sound_win.c. Nb. OIDP SYNCHRONIZED_SOUND chyba trochę duplikuje WinPLusową funkcjonalność w rodzaju Update divisor i Sound quality, ale musiałbym się temu przyjrzeć.

Wydaje mie się, że nie. Sound quality to po prostu parametr do MZPOKEYSND_Init. Update divisor, to parametr określający co ile skan linii ma być aktualizowana zawartość bufora dźwięku (procedura pokey_update). Jestem w 99% przekonany, że nie było tam nigdy funkcjonalności duplikującej SYNCHRONIZED_SOUND.

Krótki napisał/a:
Jaskier napisał/a:

Swoją drogą dziwię się, że nikt przez 6 lat nie zrobił własnego buildu.

Próba była.

Aaaa... coś kojarzę, w końcu podesłałem mu swoje źródła. Ale gościu chyba zrezygnował.

W moim przypadku sprawa jest inna. Ja NIGDY nie zrezygnowałem ani z tworzenia rzeczy na Atari ani z supportu do Atari800Win. Po prostu miałem bardzo dużo zajęć w pracy. I dlatego odłożyłem inne sprawy. Ale jak mi się zdarzy trochę wolnego to albo zrobię jakieś demo (B2L2) albo co innego.

Dlatego możecie być w 100% pewni, że ja będę jeszcze na Atari tworzyć. A czy będzie to za rok czy za 20 lat? Dla mnie bez znaczenia. Po prostu musicie się przyzwyczaić do mojego sposobu postrzegania czasu :)

Aby odpackować teksty trzeba najpierw odpackować  program do ich odpackowywania - Energy #1

36

Jaskier napisał/a:

Kurde, gdzie? Przecież przy zmianie trybu jest uruchamiane Colours_Update()

Trzeba jeszcze oprogramować PLATFORM_PaletteUpdate po stronie platformy.

Jaskier napisał/a:

Proszę o listę. Zaraz się nimi zajmę :)

Emulacja XEP80, emulacja Austin Franklin 80, emulacja IDE, emulacja przelotowości w kartridżu SDX, sprzętowe skalowanie obrazu OpenGL (wraz z całą logiką odpowiedzialną za wyliczanie właściwych proporcji w NTSC i PAL w videomode.c), oraz, jak się okazuje, także SYNCHRONIZED_SOUND. Jest jeszcze podobno działająca emulacja rozszerzeń z 1090/1400XL/1450XL (votrax, tryb 80 kolumn), ale nie testowałem tego. Więcej grzechów nie pamiętam.


Krótki napisał/a:

Update divisor, to parametr określający co ile skan linii ma być aktualizowana zawartość bufora dźwięku (procedura pokey_update). Jestem w 99% przekonany, że nie było tam nigdy funkcjonalności duplikującej SYNCHRONIZED_SOUND.

pokey_update to funkcja niekompatybilna z SYNCHRONIZED_SOUND, który wymaga odpowiedniego oprogramowania po stronie platformy, zob. src/sdl/sound.c. To że masz zdefiniowane SYNCHRONIZED_SOUND=1, nie wystarcza. Porównaj jakość odgrywanych sampli w Beep'em All! na Altirrze, na Atari800 z --enable-synchronized-sound, i na WinPLusie, a usłyszysz co ta funkcjonalność daje.

Nie chodzi Ci czasem po głowie po prostu wykorzystać w WinPLusie libSDL do odtwarzania dźwięku? Byłoby prościej.

A8CAS - narzędzie do 100% archiwizacji kaset Atari

37

Krótki napisał/a:

Trzeba jeszcze oprogramować PLATFORM_PaletteUpdate po stronie platformy.

A no w sumie tak, przecież trzeba przepisać kolory z powrotem. Dzięki.

Krótki napisał/a:

Emulacja XEP80, emulacja Austin Franklin 80, emulacja IDE, emulacja przelotowości w kartridżu SDX, sprzętowe skalowanie obrazu OpenGL (wraz z całą logiką odpowiedzialną za wyliczanie właściwych proporcji w NTSC i PAL w videomode.c), oraz, jak się okazuje, także SYNCHRONIZED_SOUND. Jest jeszcze podobno działająca emulacja rozszerzeń z 1090/1400XL/1450XL (votrax, tryb 80 kolumn), ale nie testowałem tego. Więcej grzechów nie pamiętam.

Z tego wszystkiego posiadam w domu tylko XEP80. Więc pewnie za to się zabiorę najpierw. W ogóle to idiotyczne urządzenie i chyba nigdy go nie użyłem.
A co do SYNCHRONIZED_SOUND to obecnie badam problem. Chyba tylko port SDL tego używa, ciekawe czemu?
W ogóle zamieszane to wszystko. Zamiast korzystać z dotychczasowych funkcji trzeba ręcznie przepisać dane z bufora. Dziwne to wszystko.

Krótki napisał/a:

Nie chodzi Ci czasem po głowie po prostu wykorzystać w WinPLusie libSDL do odtwarzania dźwięku? Byłoby prościej.

Pewnie na tym się skończy :) Ale na razie w 4.1 nie planuję przełomowych zmian.

Aby odpackować teksty trzeba najpierw odpackować  program do ich odpackowywania - Energy #1

38 Ostatnio edytowany przez Krótki (2011-12-30 01:57:52)

Jaskier napisał/a:

A co do SYNCHRONIZED_SOUND to obecnie badam problem. Chyba tylko port SDL tego używa, ciekawe czemu?

No mówiłem, bo rozdział między "głównym emulatorem" a "funkcjami specyficznymi dla platformy" nie jest tak wyrazisty jakby mógł być.

EDIT:

Jaskier napisał/a:

Z tego wszystkiego posiadam w domu tylko XEP80.

A wiesz że to się świetnie składa :-) Mam do Ciebie prośbę, żebyś sprawdził jaką ilość skanlinii zajmuje jeden znak wyświetlany przez XEP80. Bowiem są sprzeczne źródła, twierdzące raz że ta ilość to 10 linii, innym razem że 11. Stephen w podlinkowanym wątku sprawdził że w trybach NTSC i PAL ta ilość to 10 skanlinii, ale chciałbym żeby zweryfikował to również choć jeden Europejczyk z PAL-owskim komputerem i PAL-owskim telewizorem. Jeślibyś to sprawdził, będę mógł poprawić błąd w Atari800, które wyświetla teraz 11 linii.

A8CAS - narzędzie do 100% archiwizacji kaset Atari

39 Ostatnio edytowany przez Jaskier (2011-12-30 20:16:34)

Krótki napisał/a:
Jaskier napisał/a:

Z tego wszystkiego posiadam w domu tylko XEP80.

A wiesz że to się świetnie składa :-) Mam do Ciebie prośbę, żebyś sprawdził jaką ilość skanlinii zajmuje jeden znak wyświetlany przez XEP80. Bowiem są sprzeczne źródła, twierdzące raz że ta ilość to 10 linii, innym razem że 11. Stephen w podlinkowanym wątku sprawdził że w trybach NTSC i PAL ta ilość to 10 skanlinii, ale chciałbym żeby zweryfikował to również choć jeden Europejczyk z PAL-owskim komputerem i PAL-owskim telewizorem. Jeślibyś to sprawdził, będę mógł poprawić błąd w Atari800, które wyświetla teraz 11 linii.

Kurde, godzinę walczyłem aby to ustrojstwo uruchomić.
Monitor mam nędzny (Neptun) a aparat fotograficzny jeszcze gorszy.
Tak na moje oko to jest to 12 linii. 7 na literę i 5 na odstęp.

Zresztą sam zobacz. Podsyłam zdjęcie.

Upichciłem już kolejną betę. Tym razem udało się doprowadzić do tego, że te demko z dźwiękiem na GTIA zaczęło robić coś więcej niż pierdzieć.

Niestety z rozwiązania zadowolony nie jestem. System dźwięku w Atari800Win ściśle polega na tym, że co ramkę jest taka sama ilość sampli a w SYNCHRONIZED_SOUND nie musi być. Poza tym coś dziwnego się robiło przy zmianie parametrów dźwięku (no bo nikt chyba nie przyzna, że wykrzaczanie się programu przy free() z błędem, że próbowano pisać do niezaalokowanej pamięci jest normalne). Podejrzewam jakieś race condition pomiędzy wątkami.

Niestety muszę stwierdzić, że możliwości rozwoju 4.1 się kończą. Bez znaczących modyfikacji nic nie dam rady zrobić. Do przemielenia jest obsługa dźwięku, ekranu, inicjowania emulatora oraz restartu emulacji. Zostać mogą chyba tylko okna dialogowe.

Post's attachments

XEP80.gif 181.75 kb, nikt jeszcze nie pobierał tego pliku. 

Tylko zalogowani mogą pobierać załączniki.
Aby odpackować teksty trzeba najpierw odpackować  program do ich odpackowywania - Energy #1

40

Ale numer. Rzeczywiście, 12 linii bez wątpnienia, dziękuję za zdjęcie.

To ja dyskusję na temat XEP80 przenoszę do osobnego wątku.

A8CAS - narzędzie do 100% archiwizacji kaset Atari

41

Cześć,

Wrzuciłem finalną wersję 4.1 na github. Nie jest może najdoskonalsza, ale jako tako udało się połączyć rdzeń atari800 2.2.1 z resztą kodu a to było priorytetem. W najbliższym czasie zacznę robić 4.2

Aby odpackować teksty trzeba najpierw odpackować  program do ich odpackowywania - Energy #1

42 Ostatnio edytowany przez Dracon (2012-01-07 00:57:54)

Jaskier napisał/a:

Ale jak mi się zdarzy trochę wolnego to albo zrobię jakieś demo (B2L2) albo co innego.
Dlatego możecie być w 100% pewni, że ja będę jeszcze na Atari tworzyć.

"Co innego" czyli to, na co sie szykowales, tj. "MISJA 2" ??? ;)

Mozna tez pomyslec o zrobieniu pecetowego odpowiednika AFM-u /ATARI FONT MAKERA/, z podobnymi rozwiazaniami i ciut wygodniejszym interfejsem. Kolejne pokolenie beda za to zapewne wdzieczne, no i zdrowa alternatywa dla istniejacego softu na PC nie zaszkodzi (wrecz przeciwnie...). :)

43

Stworzenie tej gry jest w dalszym ciągu w planie. Tak jak stworzenie dema. I ewentualnie jednego dema w Turbo Basicu.
A na PC tylko emulator. Innych rzeczy nie planuję i nie mam nawet pomysłu.

Aby odpackować teksty trzeba najpierw odpackować  program do ich odpackowywania - Energy #1

44

Hej!

Dzięki za port z nową wersją jądra Atari800. Bardzo mi się podoba skalowanie Hi-END :) nie wiem jak to jest realizowane ale wygląda wyśmienicie :D Jednak działa u mnie jakoś kosmicznie wolno, przy turbo F7 i włączonym skalowaniu typu Hi-End emulator wyciąga jedynie 237% prędkości oryginału, ze skalowaniem typu "normal" prędkość Turbo osiąga prędkość ponad 2000%.

Nie wiem jeszcze czego to wina, ale dziwnie się zachowuje emulator przy efektach które mają jedną ramkę (50Hz refresh). Monitor mam ustawiony na 50Hz odświeżania. Wszystkie efekty mieszczące się w ramce wyglądają tak jakby miały dwie ramki. A zatem wszystkie np. scrolle poziomie i pionowe strasznie są poszarpane (wyglądają tak jakby miały dwie ramki). Co gorsza efekt czasami ustępuję i wszystko wygląda OK. Nie ważne czy włączę czy wyłączę GDI i jaki rodzaj skalowania wybiorę. Ale często ten efekt ustępuje jak zmieniam tryby skalowania obrazu.

Mam kartę ATI Radeon HD4600, wybrana rozdzielczość to 1920x1080 @50Hz. Emulator pisze cały czas iż prędkość to 100%. Jakieś pomysły? Czy tylko mnie ten problem się pojawia?

Sprawdzę jeszcze zaraz jakąś nowszą wersję Atari800.

45

seban napisał/a:

Bardzo mi się podoba skalowanie Hi-END :) nie wiem jak to jest realizowane ale wygląda wyśmienicie :D

Zajrzyj na:
http://en.wikipedia.org/wiki/Hqx

Mam w planach wprowadzenie też wersji 3x i 4x.

seban napisał/a:

Jednak działa u mnie jakoś kosmicznie wolno, przy turbo F7 i włączonym skalowaniu typu Hi-End emulator wyciąga jedynie 237% prędkości oryginału, ze skalowaniem typu "normal" prędkość Turbo osiąga prędkość ponad 2000%.

Biorąc pod uwagę jak skomplikowany to algorytm...
Ciekaw jestem jak wydajnościowo wyjdzie wersja 4x :) Może trzeba będzie zaangażować kilka rdzeni?

W opcjach Performance możesz zmniejszyć częstotliwość odświeżania dla trybu fullspeed.

seban napisał/a:

Nie wiem jeszcze czego to wina, ale dziwnie się zachowuje emulator przy efektach które mają jedną ramkę (50Hz refresh). Monitor mam ustawiony na 50Hz odświeżania. Wszystkie efekty mieszczące się w ramce wyglądają tak jakby miały dwie ramki. A zatem wszystkie np. scrolle poziomie i pionowe strasznie są poszarpane (wyglądają tak jakby miały dwie ramki). Co gorsza efekt czasami ustępuję i wszystko wygląda OK. Nie ważne czy włączę czy wyłączę GDI i jaki rodzaj skalowania wybiorę. Ale często ten efekt ustępuje jak zmieniam tryby skalowania obrazu.

Mam kartę ATI Radeon HD4600, wybrana rozdzielczość to 1920x1080 @50Hz. Emulator pisze cały czas iż prędkość to 100%. Jakieś pomysły? Czy tylko mnie ten problem się pojawia?

W trybie DirectX czy GDI?
Ale w sumie to się nie dziwię. Drobna odchyłka od 50Hz i cała synchronizacja leży.

Aby odpackować teksty trzeba najpierw odpackować  program do ich odpackowywania - Energy #1

46 Ostatnio edytowany przez seban (2012-01-08 21:47:15)

Hej!

HQX po prostu rewelacja! :D Siedziałem i oglądałem sporo dem/gier od nowa :) Przyglądając się jak to działa. Muszę przyznać że bardzo mi ten algorytm skalowania przypadł do gustu :) (a raczej do oczu :P)

W przypadku Atari800Win nie ma znaczenia czy wybiorę GDI czy też nie dzieje się dokładnie to samo.

Co do emulatora, masz rację 50Hz wcale nie musi być to to 50Hz z którym działa Atari 8-bit. Sprawdziłem również Atari800 2.2.1 (zarówno SDL jak i DX). Dzieją się bardziej lub mniej wnerwiające efekty ale podobne do tego co dzieje się w Atari800Win, tam nawet gorzej jest bo dźwięk zaczyna rwać i przeskakiwać koszmarnie. Tak więc zakładam iż taka uroda render/display engine w przypadku mojej karty/monitora. Zwróciłem na to uwagę ponieważ np. w Altirra ten efekt nie występuje a scrolle i jedno-ramkowe efekty wyglądaj tak płynnie jak na oryginalnym sprzęcie.

Btw. jeszcze jedna może mało istotna uwaga jak mam włączone skalowanie Hi-End to przy odpalaniu emulatora nie pojawia się ten durny komunikat (Win7) "schemat kolorów został zmieniony na podstawowy windows7"

http://dl.dropbox.com/u/44199/a800win_col.jpg

Nie znam się zupełnie na display sub-system dla Windows jednak przełączenie opcji "Display Memory Type", z typu "System" na "Video" pozwoliło ten problem wyeliminować, a co za tym idzie nerwowe miganie ekranem przez Windows7 przy uruchomieniu emulatora i wymuszonej przez system zmianie schematu koloru... bezpowrotnie ustąpiło ;-), również nie pojawiają się te durne komunikaty :)

http://dl.dropbox.com/u/44199/a800_vid.jpg

A i prędkość w "turbo mode" [F7] wzrosła do 2700% :) Co mi wcale nie przeszkadza a ułatwia czasami debug jak muszę czekać na konkretny moment :)

47

u mnie nie ma różnicy pomiędzy stretching: Normal i HiEnd
Smooth wygląda za to cacy

Lynx I / Mega ST 1 / 7800 / Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
DDD HDD / AT Speed C16 / TF536 / SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
http://260ste.atari.org

48 Ostatnio edytowany przez seban (2012-01-09 01:13:02)

Hej!

Jak nie ma? U mnie Smooth to porażka bo rozmywa ostrość krawędzi. Nie cierpię tego trybu skalowania jest okropny. Nadaje się do zdjęć i tekstur w grach ale nie do emulatorów. Zresztą sam zobacz:

tryb normal (skalowanie przez normalne powtórzenie pixeli) - da się znieść - tak miałby wyglądać obraz z Atari na wysokiej klasy monitorze ;)

http://dl.dropbox.com/u/44199/atari800win_normal.png

tryb smooth (skalowanie z interpolacją pixeli) - rozmazane krawędzie zarówno w pionie jak i poziomie, okropieństwo w/g mnie:

http://dl.dropbox.com/u/44199/atari800win_smooth.png

i na koniec tryb Hi-END (skalowanie algorytmem o którym wspomniał Jaskier, rewelacja w/g mnie!), jakość obrazu której do tej pory nie widziałem przy skalowaniu żadnym znanym mi algorytmem, jeżeli nie widzisz różnicy popatrz dokładnie na czcionki:

http://dl.dropbox.com/u/44199/atari800win_HiEND.png

i dla porównania bezpośredniego:

http://dl.dropbox.com/u/44199/a800win_scaling_compare.png

49

Jaskier napisał/a:

Biorąc pod uwagę jak skomplikowany to algorytm...
Ciekaw jestem jak wydajnościowo wyjdzie wersja 4x :) Może trzeba będzie zaangażować kilka rdzeni?

Jeżeli rdzenie, to tylko vs10 i Parallel Patterns Library i np parallel_for_each.
Nie czytałem algorytmu, ale z opisu wynika, że to proste lookup, to na pewno nie da się go zaimplementować na GPU?

50

ok, po resecie emulatora HiEnd u mnie widać tylko jak są literki:
a Smooth wygląda tak, co mi się w sumie bardzo podoba:
http://img805.imageshack.us/img805/8459/capture1cd.png
http://img31.imageshack.us/img31/2033/capture2ks.png
http://img163.imageshack.us/img163/2280/capture3iq.png
http://img545.imageshack.us/img545/5441/capture4fi.png

Lynx I / Mega ST 1 / 7800 / Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
DDD HDD / AT Speed C16 / TF536 / SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
http://260ste.atari.org