Po dobrym scenowo roku 2015 i słabszym 2016, upływające 12 miesięcy znów można uznać za bardzo udane. W ubiegłym roku zorganizowano sporo (także i w Polsce) imprez, na których ukazało się wiele świetnych produkcji. Pojawiło się kilka nowych formacji i - co staje się już tradycją - zaktywizowało się parę zasłużonych grup z przeszłości. Poniżej prezentujemy listę 10 najlepszych amigowych dem 2017 wg serwisu pouet.net. Listę uzupełniamy o swoje typy, które do pierwszej dziesiątki nie weszły (a które naszym zdaniem warto zobaczyć) oraz o krótkie podsumowanie całego roku. Miejsce 10 Chapter7 - Skarla Kod: Jamie Grafika: Vinie Muzyka: Marvin Link: http://www.pouet.net/prod.php?which=69700 platforma: Amiga 060 AGA party: Revision 2017, trzecie miejsce w Amiga Demo Compo Naszą dziesiątkę zaczynamy od naprawdę mocnego uderzenia. Już sam ten fakt pokazuje, że rok 2017 był scenowo naprawdę niezły. Grupy Skarla nie trzeba specjalnie przedstawiać. Ta francuska formacja wydaje dema rzadko (ostatnie Massive ukazało się aż 6 lat temu), ale gdy już coś pokażą to zawsze jest na co popatrzeć. Chapter7 to produkcja na 060, gdzie tradycyjnie mamy pokaz jednego z najlepszych (a według co niektórych najlepszego) silnika 3d na Amidze, za którym stoi Jamie. Demo jest wysmakowane, utrzymane w monochromatycznej palecie i zawiera naprawdę mocne i zaawansowane, jak na procesor 060, efekty (fluidy / metaballsy / rozbijanie obiektów / tunele). Wrażenie robi płynność całej produkcji i wysoka jakość tekstur. Na uwagę zasługuje również bardzo dobra ścieżka dźwiękowa Marvina. (slay) Świetne demo, praktycznie bez słabych stron, jednak jakby trochę niedocenione (#3 na Revision, #10 w Top10). Klimatyczne i techniczne, najwyższy poziom wykonawczy, ale spodziewany po ekipie z takim doświadczeniem i smakiem. Laboratoryjna perfekcja w każdym calu - aż do bólu. I tu właśnie mała łyżeczka dziegciu w hektolitrach miodności - lekko i podskórnie odczuwalny niedosyt emocji… Może za dużo zimnej kalkulacji, a za mało “efektu łoł”? A może dokładnie o to chodzi? Nie wiem, na pewno obejrzę to demo wielokrotnie, by kolejny raz poszukać odpowiedzi…. (sachy) Ładne, wysmakowane demo w wolnym tempie. Uwielbiam otwierającą scenę ze skaczącymi piłkami, którym towarzyszą pięknie wtopione w muzykę odgłosy odbić. Moim ulubionym fragmentem jest tunel z “kisielu” - najpierw zostaje pokazany z zewnątrz, a później kamera wjeżdża do środka. Bardzo efektowne. Sam tunel wygląda tak realistycznie, że człowiek ma ochotę biec po łyżeczkę i sięgnąć do monitora! W demie jest więcej efektów niebywałej urody jak choćby majestatycznie sunący dym zbudowany z cząsteczek czy „Kierownikowe” bryły, skąpane w monochromatycznym świetle. Brakuje mi jednak spójności. Każdy efekt sam w sobie jest super, ale demo jako całość sprawia wrażenia zbudowanego z oderwanych od siebie fragmentów. To odczucie potęguje muzyka. Podoba mi się ten kawałek, brzmi też bardzo przyzwoicie, ale mam wrażenie, że zbyt dużo się dzieje jak na tak krótki czas trwania. Mamy tu ambient, dubstep, eteryczne wokalizy, a nawet elementy dubowe, jednak wszystkie te składniki nie chcą się kleić w całość. I ostatnia rzecz. Niektóre efekty są mocno (chyba zbyt mocno) zainspirowane kilkoma demami z ostatnich lat. (jazz) Miejsce 9 Dandelion - The Electronic Knights Kod: Bifat Grafika: Chris Korte Muzyka: Blue, Titus, Tobe Link: http://www.pouet.net/prod.php?which=68903 platforma: Amiga OCS party: Datastorm 2017, trzecie miejsce w Amiga OCS Demo Compo Moim zdaniem najlepsza produkcja Bifata od czasu jego powrotu na scenę w 2016 roku, choć bardzo cenię również jego exe-packer Cranker, który po 27 latach zastąpił w końcu legendarny Titanics Cruncher (z jego słynnym “TITANICS-Cruncher decrunches while loading ...”). Dandelion to dla mnie demo, które choć nadal trochę osadzone w stylistyce oldskoolu, udanie próbuje wyjść poza bezpieczne standardy i zaproponować “coś nowego” na A500. Blob/Vector/Shade-ballsy to nie odświeżona idea z Red Sector Inc. MegaDemo, ale zupełnie nowa propozycja (polecam Blob/Shade’owy torus) i niezła blitterowa rzeźnia. Mamy też dopracowany Copper chunky (w tym wart zobaczenia tunel) oraz namiastkę “wektorowego świata”. Być może demko trochę kuleje pod względem spójności designu, ale podoba mi się próba zrobienia “szerszych” scenek (wnętrze torusa z wektorową wstęgą czy wektorowa sieć energetyczna na tle gwiazd) zamiast sekwencji pojedynczych efektów. Z niecierpliwością będę wyczekiwał kolejnych produkcji Elektronicznych Rycerzy pod komendą Bifata, bo techniczne niespodzianki są niemal wpisane w ich kodeks honorowy. (sachy) Zdecydowanie moje ulubione demo 2017! Oglądając Dandeliona na streamie nie mogłem się powstrzymać i raz po raz wykrzykiwałem: „Amigaaa!”. Mocno, głośno, z samych jajec. Sachy twierdzi, że demo jest oldskulowe, a dla mnie wręcz przeciwnie. Co my tu mamy? Transparentne metaballsy, tunel w Copper chunky, blurrowany twister z linii, majestatyczne słupy energetyczne i piękne, rozmyte wektory w części z creditsami, które przypominają nieśmiertelny Darkroom - Stellar… Dużo dobrego kodu. Może tylko tego mrugania mogłoby być mniej… Demo na pewno sporo by zyskało dzięki lepszej muzyce i designowi, ale mimo tych braków ogląda się bardzo dobrze i chce się do niego wracać. (jazz) Dandelion to - jak dla mnie - najważniejszy amiscenowy powrót roku 2017. Nawet jeśli uznamy, że Bifat już w 2016 zapowiadał swój comeback niewielkimi scenowymi kapiszonami, to jednak dopiero na Datastorm wystrzelił ze swojej koderskiej armaty. The Electronic Knights - formacja stojąca za kultowym demem Rampage z CeBIT 1994 - zaskoczyła po latach bardzo zacną produkcją. Pod względem koderskim jest to z pewnością amigowa waga ciężka. Co ważne, mimo oczywistych retrospekcji mamy tu powiew świeżości, a efekty podane są w ciekawy sposób (przeźroczystości, rozmycia itd.). Najbardziej podoba mi się tunel z animowaną teksturą, metaballsy i scenka ze słupami wysokiego napięcia na tle nocnego nieba. W Dandelion brakuje mi jedynie jakiegoś wspólnego mianownika i spoiwa dla poszczególnych części. Tak czy inaczej, świetne, bardzo solidne demo. (slay) Miejsce 8 Monomateria - Pacif!c Kod: Deadguy Grafika: Malmix Muzyka: Wasp Link: http://www.pouet.net/prod.php?which=68891 platforma: Amiga OCS party: Datastorm 2017, drugie miejsce w Amiga OCS Demo Compo W naszym scenowym podsumowaniu roku 2014 pisałem, że "warto obserwować team Pacif!c, bo jeszcze nie raz mogą nas w przyszłości pozytywnie zaskoczyć". I miałem rację. Rok później na miejscu dziewiątym rankingu mieliśmy ich kolejne demo (Oh Five!), a teraz wskoczyli jeszcze wyżej. Monomateria to produkcja utrzymana w ich ulubionym oldskoolowym klimacie, ale podana całkiem zgrabnie i chrupiąco, bez pleśni, mchu i nadmiernego sentymentalizmu. Nareszcie wypełniono braki kadrowe zatrudniając do pikseli Malmixa, który z powodzeniem zadbał o stronę wizualną. Tradycyjnie mamy tu dbałość o detal, świetne synchro, dopracowane przejścia między efektami oraz przyjemny soundtrack. I nawet pomimo tego, że mamy tu kilka sucharów (tunel z punktów, plazma itd.) to demo broni się jako całość, a niektóre smaczki (jak chociażby Lenny Kravitz wchodzący przy dźwiękach gitar, glitche na wektorkach czy przejście w efekcie z Protrackerem) są wprost wyborne. (slay) Świetnie dopracowany oldschool, podany z lekkim odejściem od standardów. Broni się na tyle nieźle, by na mocno obsadzonym Datastorm 2017 (Winter) zająć #2 miejsce. Myślę, że spora w tym zasługa Malmixa (występ gościnny), który doprawił całość przyjemnymi paletami i grafiką, zapewne wymuszając również na koderze ładne przejścia między częściami. Niektóre efekty, choć “znane i lubiane”, dostały nowego sznytu, co wraz z dobrą synchronizacją bardzo je uatrakcyjniło. Całości dopełnia świetna muzyka Waspa, który moim zdaniem idealnie trafia w oldschoolowe klimaty i zawsze stanowi mocną stronę produkcji duetu (zazwyczaj) Pacif!c. (sachy) Eleganckie, oldskulowe demo „sucharowych” braci – Deadguya i Waspa. Mimo że nie jestem fanem estetyki retro to muszę przyznać, że lubię Monomaterię, a nawet uważam za najlepszą produkcję Pacif!c jak dotąd. Bardzo mi się podobało przejście wskaźników wysterowania w wektory 3D, ładny kolorowy twister, zgranie efektów z dźwiękiem (wybuch sześcianu, pojawienie się obrazka z Kravitzem przy akompaniamencie Hendriksowskiej gitary), grafika i dobrane ze smakiem palety. Tunel z punktów i plazma trochę za bardzo jednak walą sucharem... Ale zatykam sobie wtedy nos aromatyczną kępką torfu i delektuję się przyjemną muzyczką Waspa, która przywodzi na myśl piękne, złote czasu amigowego modularstwa. Gdyby takie demo ukazało się w 1993 roku, wywołałoby masową histerię, a skrzynki pocztowe autorów byłyby pełne damskiej bielizny. (jazz) Miejsce 7 Singularities - Unique Kod: Dodke Grafika: Raymon, Dodke Muzyka: Glxblt Tools: Chemic Link: http://www.pouet.net/prod.php?which=69702 platforma: Amiga 060 AGA party: Revision 2017, pierwsze miejsce w Amiga Demo Compo Grupa Unique w końcu dopieła swego i nareszcie wygrała (po kolejnym krwawym boju) niemieckie party Revision. Singularities to nowoczesne i epickie demo na dopalone Amigi, które dzięki podwyższonej rozdzielczości wygląda naprawdę nieźle na leciwej babci AGAcie. Produkcja ma swój klimat (bezbłędnie dobrana ścieżka dźwiękowa), kosmiczny, dostojny, i zahacza nawet nieco o "pecetowy feeling" (dla jednych jest to plus, dla innych minus). Scenki 3d są dopracowane i ładnie oteksturowane, a wszystko chodzi płynne na 060. Uwagę zwraca spójna kolorystyka i bardzo zacny - dodany tu i ówdzie - postprocessing (szumy, światła itd.). Solidne demo, które dowodzi, że Dodke to dziś jeden z topowych amikoderów. (slay) Mocne demo, z trochę oklepanym pomysłem przewodnim (kosmos), ale solidnie zrealizowane. Podoba mi się już sam niemal Pinkfloydowski początek (motyw muzyczny narzuca mi jakoś takie skojarzenie), który z czasem przechodzi w typową “techniawę”, ale w końcu to jest demo i tego należy się przecież spodziewać. Wśród pokazanych efektów szczególnie podobają mi się świetnie zrealizowane tunele wypełnione dodatkowymi elementami na pierwszym planie (oświetlane lub przezroczyste wektorowe bryły i filtr “krzyżykowy” na ekranie, przypominający fotografie z lądowników księżycowych, z dodanymi “zabrudzeniami od odcisków palców operatora kamery” - bardzo fajny zabieg). Demo zaprojektowane na duże ekrany i można polecać je właśnie na takie okazje jak “noce z demosceną” w kinach czy podobnych miejscach. Tam zaprezentuje się najlepiej i zrobi na widzach na pewno ogromne wrażenie. (sachy) Demo z gatunku tych, które od pierwszych sekund chwytają człowieka za gardło (ewentualnie stopę, łokieć bądź inny organ) i nie chcą puścić. Już sam wstęp i pulsująca razem z LFO poświata zapowiada coś niesamowitego. Pojawiająca się dalej majestatycznie wirująca galaktyka, której towarzyszy muzyka w klimacie space age sprawia wrażenie sceny wyjętej wręcz z Kosmicznej Odysei. Co za rozmach! Dalej mamy ze smakiem dobrane palety, zabawy światłem, przezroczystości, dopracowane tekstury w tunelach. A scena finałowa to tzw. instant classic (nie mylić z instant coffee). Warto zwrócić uwagę na soundtrack. Jest nie tylko ciekawy sam w sobie (kiedy ostatnio słyszeliście organy w kawałku scenowym?), ale doskonale współgra z narracją dema - motywy muzyczne zdają się być powiązane z konkretnym efektami, co powoduje, że produkcja sprawia wrażenie przemyślanej. Podoba mi się również organiczne, niewymuszone synchro. Minusy? Jak dla mnie ciut za dużo scenek. Mimo że stoją na bardzo wysokim poziomie, odczuwam lekki przesyt. Przydałoby się też coś, co by spoiło wszystkie efekty. Owszem, łączy je w jakiś tam sposób ogólny, kosmiczny klimat, ale chciałbym, żeby jeden efekt wynikał z drugiego albo żeby chociaż była w nich jakaś logika. Tak czy owak jedno z najlepszych dem na AGĘ w ostatnich latach. (jazz) Miejsce 6 Baby Steps - Booze Design Kod: Jackasser Grafika: Grip, Graphics Muzyka: Virgill Link: http://www.pouet.net/prod.php?which=70596 platforma: Amiga OCS party: Gubbdata 2017, pierwsze miejsce w Amiga Demo Compo Gubbdata to szwedzkie party kojarzone dotychczas głównie ze sceną C64. Zeszłoroczna edycja przyniosła jednak również i kilka amigowych produkcji. Największym zaskoczeniem było Baby Steps wydane przez - kultową na scenie C64 - grupę Booze Design. Koder Jackasser to między innymi współtwórca dema Andropolis, uważanego przez niektórych za jedno z najlepszych dem na C64 w historii. Pomimo tego, że oldskulowe, Baby Steps jest przyjemne, ma niezły kod, dobre przejścia (widać wpływ sceny 8-bit) to szósta pozycja w rankingu nieco dziwi. Być może głosujący dali Booze Design kredyt zaufania licząc na kolejne - już w pełni dojrzałe - amigowe produkcje. (slay) Pierwsza produkcja Booze’ów na Królową Maszyn i od razu na wysokim poziomie. Panowie nie tyle nie wstydzą się komodorowskiego pochodzenia, co po prostu mocno je akcentują - bo dlaczego nie mieliby tego robić? Efektem tego jest stylistycznie bardzo komodorkowa produkcja (przejścia, niektóre palety, “SIDowa” muzyka), co mnie osobiście bardzo się podoba. Kod (jak na debiut, powiedzieć o nim, że “solidny” to mało, a “rewelacyjny” - trochę za dużo) na bardzo dobrym poziomie, cała produkcja dopracowana, może z lekko odstającym poziomem obrazkiem z końcowych napisów (choć tam chodziło zapewne o zaoszczędzenie dwóch bit-plane’ów by pokazać wektorowego pół-glenza w tle). Ilość pozytywnych komentarzy i wysokie miejsce na Top10 to zapewne pewien “pakiet powitalny” Booze’ów na scenie amigowej jako nowych kumpli w naszej ulubionej piaskownicy. (sachy) Najbardziej podobają mi się w tym demie przejścia. Dopracowane i z pomysłem. Teksturowany sześcian też jest niezły. Najsłabsze punkty to dla mnie fatalny obrazek końcowy, masakryczne fonty i brak jakiegokolwiek zgrania z muzyką, co jednak może być zabiegiem celowym, mającym przywołać ducha staroszkolnych dem na c64. Niemniej obecność tej produkcji w top 10 jest dla mnie dużym zaskoczeniem….(jazz) Miejsce 5 Blast From The Past! - Lemon. & The Deadliners Kod: Dan, Soundy, Oriens Grafika: Facet, Made, Magic, Titan Muzyka: Dascon, Virgill Link: http://www.pouet.net/prod.php?which=69688 platforma: Amiga OCS party: Revision 2017, drugie miejsce w Amiga Demo Compo Oldskul, ale zrobiony ze smakiem. W demku zwracają przede wszystkim uwagę ciekawe patenty designowe jak np. odsłanianie drucianego, szarpanego gliczami logosa, cząsteczki wylatujące z tęczówki oka czy rozbijające się obrazki. Moim ulubionym efektem jest oświetlona niepokojącym fluorescencyjnym światłem twarz. Czuć niestety pośpiech towarzyszący składaniu produkcji i brakuje mi większej ilości przejść między efektami, tak jak to ma miejsce pod koniec dema, gdzie Blitterowe paski płynnie przechodzą do finałowego efektu. Nader efektowny zabieg! Demo przypomina mi trochę stare produkcje Anarchy. Tam też nigdy nie było urywających członki efektów, za to całość epatowała spokojną, leniwą elegancją i w dużej mierze bazowała na przyjemnej muzyce i ładnych pikselach. Ale co w tym dziwnego, skoro głównym koderem jest powracający na scenę Dan :) Muzyka to przyjemne disco w stylu starszych modułów Nuke’a (Spacemana) – wydaje mi się nawet, że instrument prowadzący został wzięty z jego kawałka „Rott !”. Przeszkadza mi tylko trochę zbyt diskmagowy feeling. W demie mamy sporo świetnej grafiki Faceta. Szkoda tylko, że niektóre fullscreeny (klaun czy ekran końcowy) są zbyt statyczne; aż prosiło by się je ożywić. Ogólnie całkiem przyzwoite demo w staroszkolnym stylu. Gdyby dodać nieco dynamiki i dopracować przejścia byłoby o klasę lepsze. (jazz) Powrót i aktywność ekipy LEMON. (point!) kilka lat temu oraz ostatnio Dana (ex. Anarchy, Slipstream) to dla mnie symboliczny łącznik “starej” amigowej sceny i tej teraźniejszej. O ile w 2016 byłem lekko rozczarowany produkcją Cytrynek (120 hours - ładna, ale za krótka i jakby skąpa w treści), to w 2017 było czym się pozachwycać. Jest kilka nietuzinkowych pomysłów, takich jak pasek z glitchem na tytułowym logo, oświetlana rozbłyskami twarz czy dwa ładnie efekty wbudowane w grafikę źrenicy oka oraz (dawno nie oglądany na XXI-wiecznych bigscreenach) całoekranowy, bitmapowy i zoomowany sinus-scroll (tu Jazzcat zapewne biega do łazienki po miskę lub zapobiegawczo łyka garść Aviomarinu). Graficznie wszystko ładnie dopracowane, choć prawdę mówiąc po Facecie, Madzie i Titanie spodziewałem się trochę bardziej detalicznej grafiki, np. takiej jak “kryształowe” fonty w pozdrowieniach. Całość okrasza przyjemna muzyczka “z epoki” (czyli okolic ‘92/93), za którą odpowiedzialni są Virgill i Dascon. Może trochę za spokojna, ale przecież Lemon. nie musi nic udowadniać nikomu i jeśli chce na polu demoscenowej bitwy stawić się zamiast w ciężkiej zbroi - w klapkach, bermudach i z drinkiem z parasolką w ręce, to kto mu tego zabroni? Ja na pewno nie i będę wyczekiwał kolejnych spokojnych acz ciekawych produkcji z ich legendarnej manufaktury (a wróbelki ćwierkają, że maszyny w ich kuźni są pod pełną parą - zobaczmy ile w tym prawdy być może już nawet pod koniec tego kwartału - oby!). (sachy) Gdyby kilka lat temu ktoś mi powiedział, że w podsumowaniu roku 2017 będę recenzował nowe demo zakodowane przez Dana, z grafiką Faceta i muzyką Virgilla, kazałbym mu zmienić przyjmowane leki. A jednak - stało się. Amigowa demoscena to taki fenomen, że nawet grupy i ludzie już dawno uznani za całkowicie zmumifikowanych i martwych mogą po latach wstać z grobów, otrzepać kurz z marynarek i usiąść znów przy Amidze. Nawiasem, to ciekawe - podczas gdy amigowi gracze tęsknym wzrokiem wypatrują gier pokroju Cannon Fodder czy Chaos Engine i muszą zadowalać się gniotami pisanymi w Backbone, na demoscenie ciągle ukazują się demowe odpowiedniki SWOS czy Lotusa, a powrót grupy Lemon. to jeden z takich przykładów. Blast From The Past! może się podobać już od pierwszych sekund. Stylizowane jakby na ostatnie produkcje Spaceballs intro z migającymi pseudo trójwymiarowymi barami sugeruje, że będzie nowocześnie, choć to nie do końca prawda. Demo stara się bowiem łączyć oldskool z newskoolem i wychodzi mu to całkiem nieźle. Efekty podano w atrakcyjny sposób, a najciekawszym z nich jest chyba scena z dynamicznie oświetlanym miastem. Za stronę wizualną odpowiada trójka graficznych mocarzy: Facet, Made i Titan. Nic więc dziwnego, że grafika w demie jest zacna. Razi tylko czasem brak ręcznego pikselowania, a miejscami zbyt widoczny jest dithering i efekty uboczne konwersji. O ile taka produkcja grafiki jest akceptowalna w demach na AGE, o tyle na OCS (szczególnie w demach tradycyjnych) lubię widzieć kontrolę na poziomie pojedynczego piksela. Muzyka to nieco nostalgiczna podróż o dwie i pół dekady wstecz, ale brzmiąca nad wyraz dobrze, choć może brak jej większego pazura. W Blast From The Past! widać nieco niedoróbek (np. urwane zakończenie i relatywnie mało kontentu), ale ponoć następne demo ma już zerwać gacie razem z nabiałem. Czekam więc na nie z niecierpliwością w pozycji słowiańskiego przykucu. (slay) Miejsce 4 Rise And Shine - Elude Kod: Kiero Grafika: Substrate, Ubik Muzyka: Chaser Link: http://www.pouet.net/prod.php?which=71742 platforma: Amiga 060 AGA, Windows party: Riverwash 2017, drugie miejsce w PC Demo Compo Stare porzekadło mówi, że “ładnemu we wszystkim ładnie”, a Elude ładnie nawet w różowym (no dobra, być może są to odcienie fioletu - nie znam się). No i dla mnie ta stara prawda nadal ma moc, bo demo w takich nieoczywistych paletach ogląda się wyśmienicie. Być może właśnie one nadają mu lekko odrealnionego klimatu, tak samo jak zastosowane “rybie oko” czy ogólnie “rasterowy” i rozmyty wygląd ekranu. Nie dość, że w różowym im elegancko, to jeszcze wyhodowali pieczarki na wektorach - to już naprawdę ekscytujące. Żeby jednak nie było aż tak pięknie - pod koniec dema panowie zaprezentowali niezbyt zadbany, wektorowy trawnik, na szczęście niezbyt jasno oświetlony, więc można przymknąć oko na to zaniedbanie ;) Wracając jednak do trochę poważniejszego tonu, całe demo jest świetne, ma fajny flow niesiony muzyką w klimacie New Retro Wave (Chaser wymiata!). Wśród tylu świetnych efektów mój osobiście ulubiony następuję między “listą płac” a wspomnianym “trawnikiem” - nazwałbym go magmowym krajobrazem z lewitującymi kulkami, ale najlepiej obejrzeć to samemu, na dużym ekranie, kręcąc gałką “volume” wzmacniacza jak najbardziej w prawo. Jak dla mnie, jest to jedno z dwóch najlepszych dem na AGĘ w tym roku, a ustalenia zwycięzcy nie podejmę się. Polecam!!! Z trzema wykrzyknikami, jak stary handlarz na Allegro. (sachy) Cieszy mnie, że Elude wreszcie zaczęli zwracać większą uwagę na palety, dzięki czemu ich dema wydają się bardziej spójne niż wcześniej. Nie każdemu może odpowiadać róż, ale wszyscy wiemy, że to właśnie ta barwa najlepiej oddaje osobowość Kiera ;-) Bardzo podoba mi się pierwszy efekt po logu tytułowym – jazda po torze z wektorowymi przeszkodami, której towarzyszy w tle odgłos kosmicznej turbiny. Z kolei pieczarki są intrygujące technicznie, ale mam wrażenie, że można było pokazać ten efekt w sposób bardziej atrakcyjny. Nie wiem, może to kwestia doboru palet? A może to dlatego, że nie lubię pieczarek. Z grzybów toleruję tylko trufle i oczywiście pleśń. Moim faworytem jest jednak efekt końcowy – niesamowite płonące trawy, nad którymi unoszą się świetliste cząsteczki. Miazga!!! W Rise and Shine nie podoba mi się to, co w większości dem Elude, a więc przede wszystkim brak stopniowania napięcia jeśli idzie o kolejność efektów. Bo często w ich demach najlepszy efekt zostaje pokazany na początku. I dramaturgia jest zachwiana. Tym razem jest lepiej, bo hajlajt, a więc trawnik mamy na samym końcu; w dodatku muzyka nabiera wtedy mocy i soczystości. Naprawdę zajebisty finał! Nadal mamy dezorientujące pauzy (np. nie widzę żadnego uzasadnienia dla zwolnienia przy efekcie z wieżowcami), zero przejść między efektami czy zamiłowanie do patetycznych tytułów, ale złapałem się na tym, że z dema na demo coraz mniej mi to przeszkadza. Traktuję to po prostu jako element stylu Elude. Soundtrack świetnie pasuje do klimatu i zgrabnie łączy omszałe italo disco ze współczesnym brzmieniem. No i bębny podobają mi się dużo bardziej niż w kawałku z Revision, więc cieszę się, że to nie tamten utwór został wykorzystany w demie. Bardzo dobry stuff! Mój prywatny tytuł: Raster Age. (jazz) Kończenie dem na party to ciężki kawałek chleba. Wiedzą o tym wszyscy wypiekacze scenowych strucli. Rise and Shine to amigowe demo, które wygrało PC demo compo na Riverwash 2017. Tak, to nie pomyłka. Podczas składania dema pojawił się problem z działaniem muzyki na Amidze, dlatego puszczono w compo wersję skompilowaną na PC. Po kilku dniach ukazała się już koszerna wersja na Amigę, wywołując przy okazji - dość absurdalne nawiasem - "zarzuty", że dema na duże Amigi to "software rendering" (nawet jeśli, to co z tego?). Demo zabiera nas w podróż w lata 80. do - coraz popularniejszej - estetyki New Retro Wave. Mimo tego, że w popkulturze i na innych platformach trwa już spory hype na te klimaty, na Amidze za wiele tego typu produkcji nie mieliśmy. Przychodzą mi na myśl na pewno dwa niezłe dema z ostatnich lat zakodowane przez Shadeza: Master Control Program wydane przez Desire i Feeling Blue grupy Australian Drug Foundation. Elude znacznie lepiej odrobili jednak prace domową, wyciskając z tej szufladki więcej niż ich poprzednicy. Demo jest spójnie, nieco psychodelicznie (ach, ten fiolet przechodzący momentami w niebezpieczny róż :) i przyjemne w odbiorze. Już jedna z otwierających scen "przelotu nad doliną" robi spore wrażenie. Mój faworyt to jednak projekcja mokrego snu Roberta Makłowicza - obiekty 3d z pączkującymi na nich plantacjami pieczarek białych - wyborne! Niewiele osób wie, że pieczarka ma sporo cennych właściwości, na przykład błonnik pokarmowy, dzięki czemu posiada świetne działanie detoksykacyjne dla jelit. Być może właśnie dlatego mogę oglądać tą część raz za razem. Innym moim faworytem jest końcowy efekt z trawą - już dawno nie widziałem czegoś tak ciekawego w amigowych demach. Podobają mi się te wszystkie post-processingowe patenty, które koledzy z Elude zaczynają ostatnio w swoich prodkach stosować. O ile w poprzednim demie (Dolor Sit Amet) mieliśmy ciekawe wykorzystanie szumów, które nadawały efektom głębi i klimatu, tak tym razem użyto filtrów idealnie współgrających z wybraną estetyką. Efekt przeplotu obrazu, wszechobecne glitche, fisheye czy świetliste poświaty świetnie pasują do całości. Chaser tradycyjnie oprawił demo w prawilną ścieżkę dźwiękową, a synth wave w jego wykonaniu bezbłędnie współgra z obrazem. Nie mogę pozbyć się jednak wrażenia, że gdyby demo zawierało - jego pierwotnie planowany kawałek, czyli jeszcze lepszy Neon Daydreams którym wygrał Streamig Music Compo na Revision 2017 - byłoby jeszcze wyborniej. (slay) Miejsce 3 Makt - Spaceballs Kod: Slummy Grafika: Slummy Muzyka: Lug00ber Link: http://www.pouet.net/prod.php?which=68878 platforma: Amiga OCS party: Datastorm 2017, pierwsze miejsce w Amiga OCS Demo Compo Niesamowite wrażenie musiał zrobić na Datastormie Makt tuż po wszystkich tych grzecznych i uładzonych demach w stylu Monomaterii. Niczym goły jaskiniowiec, który pierdząc na cały regulator i wydzierając się wniebogłosy wpada na wieczorek poetycki studentek trzeciego wieku. A później cytuje Kanta, Platona i z pasją opowiada o równaniach różniczkowych. Bo Makt to nie tylko mroczny, „barbarzyński” klimat, ale i zaawansowany koding par excellence. U Slummy’ego nie zobaczymy glenzów, starfieldów czy prostych wektorowych brył, zobaczymy za to odważne próby zrobienia czegoś nowego, czego na Amidze 500 jeszcze nikt nie pokazał. Ale ma to swoje minusy. Nowatorskie podejście Slummy’ego do efektów, zwłaszcza w połączeniu z zimną, „monochromatyczną” kolorystyką, rezygnacją z grafiki i agresywną, bezkompromisową muzyką powoduje, że nowe dema Spaceballs pozostają niedocenione. Dla wielu ludzi, zwłaszcza tych, którzy wracają do Amigi po latach, ideałem dema pozostały na zawsze Desert Dream i Enigma… Ale jest światełko w tunelu. Recepcja Makt jest lepsza niż wcześniejszych, podobnych produkcji Spaceballs w rodzaju Emperor of the North Pole czy Straff. Myślę, że to w dużej mierze zasługa czachy. Bo o ile tamte dema były mocno osadzone w abstrakcji, o tyle tutaj wspomniana czaszka jest swoistym lajtmotiwem i czymś, czego można się uchwycić – o Makt można mówić, że „to jest to demo z czachą”. Swoją drogą Makt bardziej przypomina współczesny glitch art niż produkcje demoscenowe, co jak dla mnie jest wielką zaletą. Zajebiste demo! Don’t fool with the old skull! (jazz) Początek roku 2017 przyniósł na demoscenie dwie glitchartowe perełki. Słowacki Demobit wygrało pecetowe demo Esocentrica ASD & Satori (ze świetną muzyką naszego krajana Chasera), natomiast na szwedzkim Datastorm zwyciężyło pięćsetkowe demo Makt grupy Spaceballs. Od razu powiem, że, jak dla mnie, jest to demo roku 2017 i jedno z najlepszych dem ostatniej dekady na małą Amigę. Ja wiem, że dla pewnej grupy amigowych ortodoksów "scena skończyła się na Czarnym Albumie". Wiem, że wszystkie dema, po roku 1996 / 1993 / 1991 / 1410 (niepotrzebne skreślić) nie są warte funta kłaków, ale... Panie i Panowie, może warto spojrzeć na współczesne produkcje z nieco szerszej perspektywy? Makt jest wyjątkowo ciekawym "studium takiego przypadku", ponieważ stoi za nim grupa Spaceballs. Nie twierdzę, że jest to State of the Art / 9 fingers 2017, wszak kontekst tych produkcji jest inny, ale ciężko nie oprzeć się paru paralelom. Zarówno SOTA jak i Makt wyrastają z poszukiwania nowej formy na ograniczonej scenowej platformie. Jedna i druga produkcja raczej nie pozostawia widza obojętnym, jest estetycznie bezkompromisowa i podana w dynamiczny, świetnie zmontowany (synchro!) sposób. No i wreszcie, zarówno dzisiejsi malkontenci, jak i ówcześni krytycy State... (tak tak, byli i tacy) zarzucają, że oba dema w zbyt dużej mierze opierają się o oszustwach / animacjach. Tak, jakby zapominali o tym, że demoscena od zawsze żywiła się sprytnymi trikami, a najważniejszy był efekt końcowy, który to w przypadkuu Makt jest wyborny. Glitch art, zwany przez niektórych “estetyką usterki”, okazuje się idealnym środkiem artystycznego wyrazu dla dem na OCS. Ułomność sprzętu, niska rozdzielczość ekranu i niewielka ilość kolorów mogą być dzięki temu świetnie zamaskowane. Makt to również pierwsze od dawna demo (na A500), które pokazane przypadkowemu widzowi może uchodzić na nowoczesny, awangardowy teledysk, a nie kolejne “retro-glenzenie” majora Sucharskiego. (slay) Spaceballs - grupa, która od początku kojarzyła mi się z produkcjami przełamującymi “punkty oporu technicznego”. Już Wayfarer (zwycięzca The Gathering 1992) zszokował mnie swoimi rozbudowanymi wektorowymi światami, potem nastąpiły te "taneczne" dema, które pokazały, że na A500 możliwe są do zbadania zupełnie nowe, niespodziewane obszary, i które pchnęły demoscenę ogromny krok do przodu. Przyznam się tutaj do głęboko skrywanego bluźnierstwa - nie lubię SOTA ani 9 palców, nie trafiają do mnie, a w zasadzie nudzą. Jednak doceniam ich techniczne i historyczne znaczenie. Prawdę mówiąc, nadal wolę stare suchary, przy których "postępowi scenowcy" mają objawy ciężkiej infekcji rotawirusami. To, co jednak od kilku lat pokazują Kosmiczno-Jajowcy przełamało u mnie wyłącznie sentymentalne podejście do sceny A500 i pokazało, jak wiele potencjału nadal drzemie w poczciwej staruszce. Na amigową scenę wróciłem z sentymentu i chęci pobawienia się "jak za dawnych lat", a nowe produkcje Spaceballs pokazały mi, że oprócz tego można (a nawet trzeba) spróbować wymyślić coś nowego. Że scena Amigi to nie tylko sentyment, ale i świetne miejsce na kreatywność i pokazywanie "rzeczy niemożliwych". Dokładnie tak, jak oni robili to za dawnych lat i robią nadal, choć już w innym składzie osobowym. O ile Emperor of the North Pole nadal w jakiś sposób utrzymuje połączenie z efektami sprzed lat (widać, gdzie głównie Copper, a gdzie głównie Blitter się poci), to Makt zrywa nie tylko przysłowiowe gacie, ale i z typowymi piećsetkowymi efektami. Zrywa oczywiście w przenośni, bo nadal jest to standardowy konfig i chipset, tylko że to, co widzimy na ekranie zupełnie odbiega od tego, co do tej pory pokazywane było na A500, gdzie procesor ledwo człapie, a główną robotę odwalają custom chipy. Gdyby nie początkowe informacje o konfigu (7.09MHz, 512/512k RAM, OCS), a i poprzednie dokonania Slummy'ego, byłbym niemal pewny, że to produkcja na 030+. Po prostu tutaj dzieją się na ekranie rzeczy po A500 zupełnie niespodziewane. Oczywiście są to triki koderskie, ale scena zawsze na nich bazowała i dla mnie to właśnie one mają większą wartość scenową niż implementacje książkowych algorytmów graficznych. To są zupełnie nowe pomysły na efekty i ich estetykę. Korzystając z muzycznych paraleli - Makt to punkowa dynamika opakowana wizualnie w grunge'owe klimaty. Tak jak na początku lat 90. Nirvana pokazała moc (z norweskiego “makt”) "pudel-rockowym" kapelom (takim jak KISS, Motley Crew, Twisted Sister, Bon Jovi, Europe czy Whitesnake) co można zrobić z gitarą i dobrze rozkręconym wzmacniaczem, tak Makt wbija się brutalnie w sentymentalną estetykę oldskoolu i wybija zęby tym, którzy na A500 je "zjedli i widzieli już wszystko". Na dokładkę, zapewne w celach edukacyjnych i popularyzatorskich, Slummy w internecie spokojnie opisuje "jak to się robi". Chwała mu za to ("Live long and prosper", a po wolkańsku: "dif-tor heh smusma!"). Dla mnie jest to nie tylko jedno najważniejszych dem A500 ostatnich lat, ale na A500 w ogóle i mam wielką nadzieję, że bracia ze Spaceballs nie powiedzieli jeszcze ostatniego słowa. I wcale nie przeszkadza mi, że mogę sobie na A500 odpalić RSi MegaDemo, Enigmę czy Desert Dream, a zaraz potem Makt czy Emperora. Cieszę się jak to się wszystko pięknie rozwinęło i że nadal demoscenowy magik jest w stanie wykrzesać coś zaskakującego ze zmurszałego i zwapniałego krzemu Pani Babci oraz że Staruszka, odpowiednio nakarmiona, ciągle daje radę niejednego zaskoczyć. I właśnie dlatego uważam, że amigowa scena nadal żyje i ma się całkiem dobrze (Skål!). (sachy) Miejsce 2 Beam Riders - Ghostown & Haujobb Kod: Hellfire, Noname Grafika: Slayer, Codi Muzyka: Muffler, JazzCat Link: http://www.pouet.net/prod.php?which=71976 platforma: Amiga 060 AGA party: LOADERROR 2017, drugie miejsce w Amiga Demo Compo O ile w 2015 roku kooperacja polsko-niemiecka zostawiła pewien niedosyt (mimo ogromnej sensacji z powodu samego zaistnienia), to w 2017 dostaliśmy pełne, a nawet 2-częściowe, niemal mistyczne demo. Już sama powtórka owocnej kooperacji nie na Revision czy inne znane zachodnie party, a drugi raz z rzędu do Gdańska był małą sensacją (z krajowego punktu widzenia). Uberklimatyczne demo, dopracowane w każdym szczególe, z wypielęgnowanymi paletami i detalami, które zauważa się dopiero po jakimś czasie. W zasadzie brak tu rzeczy przypadkowych - każdy dźwięk współgra z elementem ekranu. Jest tutaj to, czego brakowało mi z demie Skarli - emocje. Od rozpoczynającej demo zoomowanej a “rozedrganej” czaszki martwego astronauty, przez wplecione w tło niemal astrologiczne ilustracje faz Księżyca, przykryte chmurą blobowych oparów, grupujących się w nieprzypadkowe formacje. Są i druciaki (hahah!), tyle że są to wektorowe obiekty sumujące swe kształty w bardziej złożone struktury 3D na tle starannie wypikselowanej grafiki. Mamy i pędzący w kosmosie tunelowo-wektorowy (tytułowy?) beam ride (druciane wektory wracające do łask? ;). Piękne i płynnie przechodzące w siebie palety, zgrane z muzyką i dynamiką ekranu. Całość przypomina kocioł lub szklaną kulę czarownicy, której gotuje się magia. Wszystko jest płynne, ale żywe jakąś obcą energią nie z tego świata. Monochromatyczne, ale w wielu dynamicznych odcieniach, niemal rentgenowskie naświetlenia; zubożone palety, by wycisnąć jakąś głębię w obrazie, doprawione uderzającą w punkt muzyką Mufflera (kolejny powrót po latach). Takie właśnie odczytuję emocje w tym demie, gdzie technika jest elementem przekazu, a wszystko współgra i pasuje do siebie. Dobrze zgrane i ładnie zaprezentowane “kredyty” nie osłabiają dynamiki a dopełniają ją, tak samo jak zahaczające o abstrakcje kalejdoskopy z końca części pierwszej. I jedynym niepasującym mi tu trochę elementem (zakładam, że powstałym w wyniku braku czasu) jest part z tytułem dema. Fajny pomysł z siatką wektorową “BEAM” podany jest jakby w niższej rozdzielczości, gdzie owa wektorowa siatka jakoś nie przystaje do całej reszty dema. Jest tu fajne synchro poziomych Copper barów z muzyką, ale całość jest trochę zbyt statyczna i jakby niewygładzona, co dla mnie stanowi kontrast w stosunku do reszty dema. Tej części jakoś nie przyswajam, ale na szczęście dość szybko zmienia się w świetne wizualnie “kredyty” i nie burzy za bardzo odbioru całości. Część kalejdoskopowa zapewne na długo zostanie zapamiętana, bo kto by pomyślał, że ten efekt można podać w takiej formie i wyantyaliasowanej jakości. Kurtyna opada, brawa na sali, przedstawienie wydaje się zakończone… A jednak - nie. Przy wyciemnionym ekranie, z mroku zaczynają dobiegać do nas dynamiczne dźwięki fortepianu. Jazzcat, niczym uczestnik konkursu chopinowskiego serwuje nam zaskakujący jak na demo podkład muzyczny, który na długie tygodnie po party wkręcił mi się w mózg (i pewnie tam zabłądził w idealnej próżni). Ekran wypełnia wielka i wpisana w kosmos źrenica, która powoli się oddalając pozwala kolejnym elementom oka (a potem i innym), zaistnieć na ekranie. I tu następuje jeszcze jedna moja ulubiona część tego dema - na ekran, wśród niemal mistycznych symboli wpływają dwie daty: 21.10.1992 i 21.10.2017. Ta druga to data wydania dema i imprezy RetroKomp/LOAD ERROR 2017, na której produkcja się ukazała. A pierwsza to data premiery Amigi 1200. Okazuje się bowiem, że demo miało swoją premierę dokładnie w 25. rocznicę urodzin naszej scenowej bohaterki (kosmiczny zbieg okoliczności, pięknie wykorzystany przez twórców dema). Pojawiają się również ikony A1200 i RK/LE Party, a poniżej symboliczny podpis: “25 LIGHT YEARS”. I pomimo tego, że z czysto fizycznego punktu widzenia rok świetlny jest miarą odległości, a nie upływu czasu (o czym jestem pewien, że autorzy wiedzieli), to tutaj, przy tak emocjonalnie naładowanym przekazie, ten zabieg doskonale się sprawdza, dodatkowo działając na wyobraźnie odbiorcy. Dźwięki fortepianu zostają wzbogacone o nostalgiczne akcenty (w tym i chyba rzadko spotykane w amigowych demach instrumenty smyczkowe), wraz z “nieskończonym zoomem” pojawia się postać przewodnia medytującego, kosmicznego mistyka, po czym falując wpływają na ekran: tytułowe logo (niestety), informacje o autorach i pozdrowienia. Przyznam się, że w trakcie całego end-part mam zawsze ciarki na plecach, a futro na rękach zaczyna się jeżyć. Piękne zakończenie świetnej produkcji. Mój niedosyt z 2015 zniknął i mogę spokojnie zapaść w sen zimowy, oczekując kolejnej produkcji spod skrzydeł Towarzystwa Przyjaźni Polsko-Niemieckiej. (sachy) Miejsce 1 Zener Drive - Altair Kod: KK Grafika: KK, Mi-Ku, Malfunction Muzyka: X-Ceed Link: http://www.pouet.net/prod.php?which=71996 platforma: Amiga OCS party: LOADERROR 2017, pierwsze miejsce w Amiga Demo Compo To niesamowite ile można jeszcze wyciągnąć z druciaków. Do niedawna wydawało się, że efekty oparte na drucianych wektorach są w stanie zainteresować jedynie zasuszonych fanów najbardziej sucharowego oldskulu. A tu takie zaskoczenie. Zanim przystąpimy do oglądania warto związać ciało solidnymi łańcuchami, bo demo po kolei urywa wszystkie członki, zaczynając od tych kluczowych. Najbardziej podoba mi się, że efekty są wielowarstwowe i przestrzenne; sporo dzieje się również na drugim i trzecim planie. Poza tym one „żyją” – ciągle coś dochodzi, porusza się, zmienia. Jakaż to niesamowita odmiana po wszystkich tych retro-produkcjach, gdzie autorzy każą podziwiać nudny wektorowy sześcian albo, pardon le mot, glenza przez 20 sekund… Doskonałe synchro dodaje całości organicznego feelingu. O wiele bliżej temu demu do współczesnych produkcji na PC niż np. Enigmy czy Desert Dream. Muzyka to solidne, typowo podkładowe techno w stylu lat 90. Twarde i bezkompromisowe. Bezlitosne bębny są niczym słupy, na których KK rozwiesza misterną, drucianą siatkę swojego talentu, a my wszyscy pokornie dajemy się w nią złapać. I chcemy jeszcze. Jako że to powrót X-ceeda po latach, postanowiłem zapytać jak wspomina pracę nad tym modułem. “Muzyka do Zener Drive - mówi X-ceed - powstała w nietypowy sposób. KK'owi bardzo pasował mój stary moduł Interfere, zrobiony jakieś 15 lat temu do dema Endzeit, które nigdy nie wyszło. Tamta wersja wymagała jednak przerobienia, choć bardziej pod kątem kompozycji niż brzmieniowym. Spędziłem kilka dni wyrzucając to, co nie przetrwało próby czasu (sporo tego było ;), dopisując nowe patterny, przerabiając stare. Powstała nowa aranżacja. W międzyczasie KK i Mi-Ku zrzucali efekty do krótkich animacji i mogłem na żywo testować jak to wygląda z muzyką. Wtedy też czasem pojawiały się nowe pomysły, dyskutowaliśmy co można zrobić pod kątem designu i tak dalej”. Można się czepiać, że demko jest ciut za długie, że ekran mały, ale nie zmienia to faktu, że Zener Driver to jedno z najlepszych OCS-owych dem tego wieku. (jazz) KK to postać, której nie trzeba chyba specjalnie przedstawiać. Koder, który potrafi zrobić urywające dupsko demo zarówno na toster (patrz Chiphead na Atari VCS), jak i na nowoczesnego grzyba (pecetowe intra pod szyldem DMA). Ku radości fanów amisceny KK nie pogardził także i małą Amigą. Po świetnie rokującym debiucie wydanym na RKLE 2015, tym razem mamy już killera z prawdziwego zdarzenia. Zener Drive pokazany na zeszłorocznej edycji gdańskiego party po prostu wgniótł widzów w fotele (a może raczej w ławki). Już od pierwszych sekund wiemy, że będzie ostro - żadnych odgrzewanych twisterów, spleśniałych sinus scrolli czy zbutwiałych plasm. Dostajemy za to ultranowoczesne, perfekcyjnie zmontowane, świetnie "budowane” druciane scenki, które - jak na Amige 500 - robią spore wrażenie stopniem skomplikowania i złożoności. Demo zupełnie nie przypomina tradycyjnych OCS-owych produkcji. Widać duży nacisk na "postprocessing", dodatkowe szumy, glitche czy też inne przeszkadzajki. Zener Drive napędza dynamiczna ścieżka dźwiękowa X-Ceeda (kolejny dawno niewidziany gość na scenie), co, wraz z mroczną atmosferą dema, nasuwa analogie z Hallucinations and Dreams - Union. Ale najwięcej skojarzeń i tak być musi z - opisywanym wyżej - demem Makt. Nareszcie Slummy doczekał się (i to w kraju nad Wisłą) godnego siebie koderskiego rywala w kategori "newschool OCS". Oba dema mają ze sobą bardzo wiele wspólnego. Starają się pokazać coś zupełnie nowego i wypełnione są w zasadzie efektami opartymi o jeden sprytny patent. KK, używając zapomnianej dziś nieco techniki "unlimited bobs" wyczarował nową jakość. Być może to właśnie wpływ kodowania na innych platformach zaowocował spojrzeniem na amigowe bebechy z innej, szerszej perspektywy? Czy w Zener Drive coś bym zmienił? Tak, grafikę 2d. Nie ma jej tam za wiele, ale przez to tym bardziej zwraca uwagę fakt, że jest wykonana niedbale, z kiepską typografią. Ale to w sumie pierdoła; większość widzów - z pozycji kolan - nawet tego nie zauważy ;) (slay) Po demie Wildcat z 2015 troszeczkę obawiałem się zarzutów (z tej czy innej strony) że podkradamy (tej czy tamtej scenie) “Kej-Keja” i trzeba będzie stoczyć krwawy, internetowy bój o wolność i “demo”-krację na scenie. Na szczęście nie było to konieczne, bo KK niczym młody Anakin Skywalker ma w sobie tyle scenowych midichlorianów, że jest w stanie każdą z nich nakarmić swoim talentem. I to bez obniżania jakości ani o krztynkę. A to rozbije bank na Atari VCS, a to dowali konkurencji na pececie, po drodze wrzucając coś jeszcze na Komodę. Bardzo byłem ciekaw, co pokaże nam 2 lata po bardzo udanym debiucie, a to, co zobaczyłem, daleko przeszło moje oczekiwania. Wiele już napisano o Zener Drive - od totalnej euforii nad nowatorstwem po krytykę wąskiego ekranu i “dema jednego triku”. W tych wszystkich opiniach trochę brakuje mi zauważenia jednego (a zdecydowanie ważnego) aspektu tej produkcji - że cała technika służy nie sobie samej, a genialnej dynamice (boleśnie idealna synchronizacja!) i świetnym “scenkom” zbudowanym na tym arcyciekawym engine. Bo dla mnie najlepsze w tym demku jest to, jak budują się poszczególne części (“reżyseria!”), ile w nich jest elementów, które ciekawie “przyrastają” (tak, technika “unlimited bobs” sprzyja temu) i jak ciekawie poruszają się w obrębie swojej sceny, jak świetnie dopasowują się do muzyki i jak glitche dodatkowo (a nie nachalnie) wzmacniają odbiór całości. Każdy element jest przemyślany i uzupełnia kolejną część układanki. Dzięki temu demo ma wysoki walor “re-watch”. Bo o ile faktycznie produkcja bazuje na jednej głównej technice prezentacji, to dużą przyjemnością jest odnajdywanie tych małych detali, których wcześniej się nie zauważyło. Do tego świetnie pasuje mi cyberpunkowy klimat i to właśnie druciane wektory go tej produkcji nadają, przywodząc na myśl legendarne konsole Vectrex czy laboratoryjne oscyloskopy (a jak wiadomo, scena i te urządzenia zdołała już zagospodarować na swój użytek). Całość idealnie uzupełnia zimne i przybrudzone techno, a powrót X-ceeda (aka Snoopy) na scenę amigową po chyba kilkunastu latach jest dla mnie powodem do otwarcia dobrego single malta z pancernych zapasów na szczególne okazje. Osobiście jako zaletę traktuję fakt oparcia całej produkcji na jednym efekcie, bo tak samo jak w muzyce - czasem lepiej jest jedną technikę “wyeksplorować” na maksa, ale z pomysłem i smakiem, niż nawciskać kilkanaście niewspółgrających motywów i udawać “że to taki dżezz” ;) Dla mnie to świetne demo, które dołącza do moich ulubionych w całej historii dem amigowych i na pewno wielokrotnie będę do niego wracał oraz prezentował je znajomym zadziwionym, co można nadal fajnego na 30-letnim sprzęcie zrobić. (sachy) Extras Rok 2017 był tłusty dla amigowej sceny; wyszło sporo porządnych produkcji, a wśród nich parę dem, które od razu stały się klasykami. Jak co rok, kilka godnych uwagi produkcji nie weszło do top 10 Poueta. Oto mój prywatny salon odrzuconych. Alien Apparat Carriona zwraca uwagę przede wszystkim świetnymi paletami; wygląda wręcz jak demo na AGĘ. Dorzućmy do tego niewymuszony humor, dobre synchro, typową dla Acemana, skoczno-przaśną muzyczkę i dostajemy bardzo przyzwoite demo, które ogląda się z przyjemnością. Efekty są proste, ale widać ogromny postęp, jaki Carrion poczynił od Teapot Genie. A teksturowany sześcian więcej niż przyzwoity. Naughty grupy Nature czaruje przede wszystkim świetnymi, wysmakowanymi paletami, światłem i przezroczystościami. Twister z sześcianów zostaje w pamięci na długo, a wszystkie efekty emanują elegancją i świeżością. Poza tym sporo się dzieje w tle. Plnx/Attention Whore z kolei to chyba najlepsze jak dotąd demo Losso. Efekty wydają się inspirowane współczesnymi demkami na C64, co, paradoksalnie, nadaje produkcji świeżości i nowoczesnego sznytu. Niektóre patenty designerskie wręcz natchnione. A świetne, dopracowane przejścia między efektami sprawiają, że do Plnx chce się wracać. Natomiast Coco/Unique to bardzo przyjemna OCS-owa produkcja oparta na efektach Copper chunky. Falujące kafle 80 ways to jak dla mnie rewelacja! Neon Carrier/Moods Plateau uwodzi cyberpunkowym klimatem i znakomitą grafiką. Bardzo podoba mi się w tym demie połączenie grafiki z efektami i niebanalne podejście do trybu Copper chunky. Polecam obejrzeć wersję final! (jazz) Patrząc przekrojowo na rok 2017 można dojść do wniosku, że był to naprawdę udany scenowo okres. Mimo, że analizując sinusoidalną krzywą aktywności amiceny, mój wrodzony sceptycyzm każe mi patrzeć raczej bez optymizmu na rok 2018, to póki co cieszmy się tym co jest, otwierając kolejnego szampana na demoscenowym Titanicu, bo naprawdę jest co opijać! Z powyższego top 10 wyciągnąć można przynajmniej dwa ciekawe wnioski. Po pierwsze, lokalny patriotyzm nakazuje krzyknąć donośnym głosem: "Teraz Polska!". To doprawdy sytuacja bez precedensu, że w pierwszej czwórce roku znalazły się aż trzy (!) polskie dema (no dobra, jedno polsko - niemieckie ;). Co więcej, dema te zostały wydane na polskich imprezach, a dwa pierwsze miejsca ukazały się na jednej tylko imprezie, czyli gdańskim Retrokompie/LOADERROR 2017. Najwyżej notowane demo wydane na prestiżowym party Revision 2017 ulokowało się dopiero na pozycji piątej (Lemon.). Po drugie, odnoszę wrażenie, że amigowa scena na dobre już złapała równowagę pomiędzy produkcjami OCS i AGA. Przedtem bywało z tym różnie. Po trwającej lata dominacji dem na AGĘ, przyszedł z kolei wysyp dem na OCS, a teraz oba te nurty zaczęły wzajemnie się balansować. To świetnie, zwiększa to tylko atrakcyjność Amigi jako scenowej platformy, która powinna mieć silne swe “obie nogi” (OCS i AGA). Kilka osobnych zdań należy się polskiej amiscenie. To był dla niej chyba najlepszy okres od ładnych paru lat. Nie dość, że mieliśmy okazję odwiedzić szereg świetnych imprez (Amiparty x2, Decrunch, Riverwash, Retrokomp/LOADERROR), to w dodatku ilość i jakość polskich produkcji zasługuje na spore uznanie. Oprócz trzech dem wymienionych w Top 10 oraz demie Carriona z RKLE, o którym pisał JazzCat (i z którym mogę się w zasadzie niemal w całości zgodzić, Carrion - tak trzymać!) były i inne. Pozostając w temacie Gdańska, to kolejną swoją produkcję wydała tam grupa Crapteam (przemianowana z DRRM). Mandi i ekipa wypuścili w 2017 roku aż pięć dem, stale podnosząc sobie poprzeczkę, a najnowsze - bardzo przyjemne w odbiorze - CrapTro 4: Don't let craptro win the compo pokazało, że najwyższy czas na usunięcie z seryjnych nazw słowo "crap". Aktywność utrzymał także Phibrizzo wydając na RKLE pod szyldem Broken Cube swoje chyba najlepsze 4k intro The Wave, a wcześniej na Riverwash kolejną czwórkę The Glitch. Świetne intro z minimalistycznym, estetycznym designem wypuściła też w Gdańsku grupa Wanted Team. Klimatyczne i chłodne Nullae z kodem Sachy’ego i znakomitą ścieżką Mccnexa może się podobać. Na początku roku Panowie z Wanted Team zaznaczyli jeszcze swoją obecność na Datastorm wydając OCS-ową invitkę Retrokomp & Load Error 2017 Invitation, a na majowym Decrunch symbolicznego compo fillera. To jednak nie koniec polskich produkcji wydanych w Gdańsku. Całości dopełnia 40k intro Richie on the Moon grupy Ghostown (pierwszy koderski owoc współpracy Tygrysa i Cahira, przy małym wsparciu Codiego) oraz wyczekiwany amigowy debiut grupy Dreamweb, czyli intro The Test (niestety wciąż nie doczekaliśmy się finalnej wersji). Z kronikarskiego obowiązku trzeba dodać, że grupa Dreamweb zrealizowała w roku 2017 także kilka pchełek w kategorii "4K Procedural Graphics". Może za 2 lata zaszaleją i zrobią 8-kilówkę? RKLE było bezapelacyjnie największym sukcesem i najważniejszym amiscenowym wydarzeniem w Polsce w roku 2017. Impreza doczekała się statusu międzynarodowego i zaczęła być wspierana przez szereg grup i osób spoza granic naszego kraju (Haujobb, Resistance, The Electronic Knights, Zymosis, Prowler, Void czy Y-Crew.itd.). Zostało to nawet zauważone przez dwa niezależne “media prasowe”. Magazyn “Irregular Review” w numerze czwartym cały osobny dział poświęcił opisom produkcji z tego party, a serwis 4sceners.de w swym corocznym podsumowaniu za najlepsze amigowe dema uznał - podobnie jak pouet.net - wydane tam produkcje Altair oraz Ghostown / Haujobb. A jak się miała demoscena na "post - amigowych" platformach? Tutaj niestety od lat trwa niemal całkowita stagnacja. Ale i w tym względzie rok 2017 przyniósł niespodziankę - a do tego stało się to u nas - na wrocławskim party Decrunch. To właśnie tam, po - jeśli dobrze liczę - 14 latach, na nowo zaprezentowała się demoscenie grupa Encore, a w zasadzie jej solista czyli MDW, wsparty przez Acemana. Morphoza to - jak sama nazwa wskazuje - demo na system MorphOS, stąd nie dziwi w nim wysokie stężenie motylków na każdy metr sześcienny. Demo opiera się głównie o efekty 3d, i mimo, że jest może nieco zbyt sterylne i koderskie to ogląda się je z przyjemnością. Najbardziej podobają mi się początkowe efekty zapalającego się loga z flar (?). Słowa uznania dla MDW za to, że nareszcie ukończył swój projekt. Miejmy nadzieję, że uda mu się namówić na powrót także swojego utalentowanego brata (Caro) i nie będziemy musieli czekać na nowe demo Encore kolejnych kilkunastu lat. O “sytuacji na świecie” napisaliśmy już wyżej całkiem sporo, jednak do puli dem, o których warto wspomnieć, dorzuciłbym Negativ Prosess, czyli drugą produkcję Ephidreny po dłuższej przerwie. To z pozoru mało przystępne w odbiorze demo, ma jednak spory awangardowy i glitchartowy urok. Nieco zbyt duża powtarzalność efektów może niektórym się nie podobać, ale nie da się ukryć, że buduje ona intrygujący, transowy klimat. Negativ Prosess zawiera także - moim zdaniem najlepszy na Amidze - efekt neonowych, świetlistych Copper barów, który po prostu trzeba zobaczyć oraz zacne rozsypujące się napisy z punktów. Końcówka roku przyniosła również niespodziankę dla fanów kultowych hiszpańskich dem grupy Ozone. Plastic Toys Are Forever może nie jest tak dopieszczone jak Smoke Bomb, ale widać tam ogromną dbałość o design i synchro, co naprawdę może się podobać. Na koniec cofnę się jeszcze raz do Szwecji, do kilkukrotnie wspomnianego już tutaj party Datastorm. To właśnie tam ekipa Focus Design wystawiła demo na AGĘ Storm Rider. Demo nie posiada ani specjalnie mocarnego kodu (jest wręcz przeciętny), ani wyjątkowej grafiki (momentami za dużo pustki na ekranie), a jednak zgrabny design i genialna wręcz ścieżka dźwiękowa (Hoffman + Daytripper) z rapowanymi wstawkami wynoszą demo ponad przeciętność. Moim zdaniem jest to jedna z najlepszych opraw muzycznych amigowych dem ostatniej dekady. Zresztą, posłuchajcie sami! (slay) Spoza przedstawionej dziesiątki i dodatkowych opisów kolegów, myślę że warto zaakcentować jeszcze takie sprawy jak m.in. “wizyty obcych w naszej galaktyce”. Oprócz opisanego już Baby Steps commodorowskiej grupy Booze Design (a to nie jedyna ich prodka na Amigę w 2017), należy też wspomnieć demo Catabasis świetnej a głownie pecetowej grupy Cocoon, wydane na gołą A1200. Panowie pokazali jaki potencjał tkwi w niedopalonym żadnym akceleratorem czystym chipsecie AGA, który sama amigowa scena lekko zaniedbała. Bardzo cieszy fakt, że znane grupy z innych scen chcą czasem zajrzeć i na nasze podwórko, wnosząc ożywczy powiew i zazwyczaj od razu na zdecydowanie wysokim poziomie. Warto wspomnieć też i inne ciekawostki, takie jak 1k intro Fluid Fire (wykonane przez Loonies & Unstable Label), które w jednym kilobajcie potrafiło zmieścić nie dość, że muzykę, to jeszcze tyle treści, że na obfitującym w produkcje zimowym Datastorm mogło nieźle namieszać nawet i w demo compo (tak, 1kB = 1024 bajty! “size coding” - sztuka sama w sobie). Najważniejszą jednak dla mnie produkcją spoza Top10 jest magazyn Irregular Review i jego kolejne wydania. Tworzony jest przez ludzi wysoce kompetentnych, nieowijających w bawełnę, nie traci miejsca na bezsensowne materiały, a integruje kreatywną scenę (czyli taką, która wypuszcza produkcje, a nie siedzi na forach czy FB) i motywuje do twórczego działania. Opiniotwórczy magazyn, będący trochę “chartsami” - tego było nam trzeba. Świetna robota. Wyczekuję każdego nowego numeru. Lektura obowiązkowa :) (sachy)

Wkręceni w piksele. Recenzja albumu "The Masters of Pixel Art"

16.09.2016 18:09

W ostatnich latach demoscena przestała być postrzegana tylko i wyłącznie jako hermetyczna i undergroundowa subkultura pokroju klubu hodowców ślimaka jadalnego. Jej dorobek zaczął intrygować także i ludzi spoza środowiska., najczęściej tych związanych z kulturą i sztuką. Mieliśmy już o niej i film dokumentalny („Moleman 2 - Demoscena: Sztuka algorytmów”), i audycje radiowe. Odbywały się wykłady na uczelniach, pisano artykuły, książki i opracowania - żeby wspomnieć tu chociażby 47 numer magazynu o kulturze współczesnej Ha!art, który to w całości został poświęcony scenie. Prace grafików, wywodzących się z demosceny, coraz częściej zobaczyć można też w galeriach. W chwili, gdy piszę te słowa, w warszawskim Pałacu Kultury i Nauki dobiega właśnie końca, trwająca prawie miesiąc, wystawa „Demoscena: Digital Art”, połączona z serią branżowych wykładów. „Masters of Pixel Art” to kolejne, ciekawe wydawnictwo dokumentujące, tym razem graficzne, oblicze demosceny. Klas Benjaminsson, znany bardziej jako Prowler, to jeden z najznakomitszych - wciąż aktywnych – demoscenowych pixel artystów. To właśnie on, we wrześniu zeszłego roku, spacerując ulicami Norrköping, wpadł na pomysł stworzenia ekskluzywnego albumu z najlepszym światowym pixel artem. Proces powstawania książki śledziłem niemal od początku, kiedy to Prowler zapytał mnie, czy nie miałbym ochoty na wzięcie udziału w projekcie. Zbiórka funduszy za pośrednictwem Kickstartera przebiegła na tyle sprawnie, że pomysłodawcom udało się zgromadzić więcej środków, niż było to pierwotnie zakładane (pozwoliło to finalnie na zwiększenie ilości stron i dodanie różnych kolekcjonerskich bonusów). Prace posuwały się zgodnie z harmonogramem (co wcale nie jest takie oczywiste w przypadku projektów finansowanych w ten sposób), w lutym 2015 książka została oddana do druku, a podczas wielkanocnego Revision wydawnictwo można było już nabyć. Album może się podobać już od „pierwszego wejrzenia”. Jest duży (24 x 30,5 cm) i ciężki, a jego okładkę zdobi estetyczne wytłoczony tytuł. Wydruki, zrealizowane na wysokiej jakości papierze kredowym, są ostre, wyraźne i dobrze odwzorowane kolorystycznie. Układ kompozycyjny stron jest przejrzysty i minimalistyczny, co świetnie współgra z soczystym pixel artem. Już samo jego kartkowanie sprawia przyjemność. Przyznam, że nie raz widziałem albumy szacownych galerii czy znanych malarzy, które prezentowały się znacznie mniej okazale. Za wykonanie techniczne „Masters...” - chapeau bas! A jak wygląda zawartość? Przeglądając „Masters...” ciężko uniknąć porównań do wydanego w 2006 roku albumu „Freax - The Art Album”. Faktycznie, obie te książki na pierwszy rzut oka mogą wydawać się podobne, różni je jednak sporo. „Freax” starał się ukazać scenowy dorobek przekrojowo. Była tam mnogość platform (od ZX Spectrum po PC) i mnogość technik (nie tylko pixel art, ale i digital paiting, grafika 3d, ascii/ansi art, a nawet tradycyjny rysunek). Autorzy postawili na ilość, szczelnie wypełniając kolejne strony scenową twórczością, rezygnując właściwie z jakiegokolwiek komentarza o samych pracach i ich twórcach. „Masters of Pixel Art” wyszedł z zupełnie innego założenia. Tutaj główną rolę odgrywa jakość, nie ilość. Klas postanowił wyselekcjonować tylko 50 - według niego - najlepszych pixel artystów z całego globu, a następnie pokazać tylko kilka (naście) najciekawszych prac każdego z nich. W tym celu skontaktował się z każdym przedstawionym w albumie grafikiem (pomimo starań, nie udało mu się dotrzeć jedynie do trójki z nich) i poprosił o komentarze dotyczące wybranych prac oraz różnego rodzaju ciekawostki dotyczące samych twórców, ich początków, inspiracji i przemyśleń o sztuce. Ten wysiłek opłacił się z nawiązką. Na bazie pozyskanych informacji powstała niezmiernie ciekawa kompilacja. Z jednej strony mamy więc bardzo starannie wyselekcjonowany i opisany pilkselartowy materiał (nazwa, tryb graficzny, data, informacje gdzie praca była po raz pierwszy pokazana lub użyta) wydrukowany z rozmachem (czasem jedna grafika potrafi w albumie zając 2/3 powierzchni strony, dzięki czemu bardzo dokładnie widać każdy jeden piksel). Z drugiej strony mamy tu całkiem sporo opowieści z pierwszej ręki. Komentarze, wspomnienia, szczegółowe opisy kwestii technicznych związanych z procesem tworzenia oraz ciekawe historie tworzące tło tych wydarzeń. To właśnie te ostatnie podnoszą bardzo, moim zdaniem, atrakcyjność albumu. Ot, chociażby opowieść, przytoczona przez niemieckiego grafika Fade One’a, który pewnego dnia jako niespełna 18 - letni młokos otrzymuje tajemniczy list pocztą (tak, tak, to jeszcze czasy grubo przed „wynalezieniem” Internetu). Okazało się, że wiadomość pochodzi od elitarnej Sega Technical Institute z USA, która oferuje mu pracę od zaraz za - bagatela - 35 tysięcy dolarów (+ dodatki). O Zieloną Kartę też nie miał się martwić. Albo ta wzmianka Jaco z Finlandii o podróży na duńskie South Sealand Party 1994. Na imprezę mieli kawał drogi. Jechali pociągiem przez Szwecję i z racji skomplikowanych połączeń dotarli na miejsce dzień wcześniej. Zmęczeni podróżą, nie mając gdzie się podziać, postanowili zdrzemnąć się na pobliskim placu, należącym do przedszkola, w małym domku zabaw dla dzieci. Miny zaskoczonych dzieciaków, które pojawiły się w przedszkolu następnego dnia rano i odnalazły ich śpiących w domku, były bezcenne. A takich smaczków jest tu znacznie więcej. „Masters of Pixel Art” to fascynująca podróż do krainy pikseli. W przeciwieństwie do wspomnianego wyżej wydawnictwa „Freax”, gdzie warunkiem koniecznym doboru autorów była ich działalność demoscenowa, tutaj nadrzędny jest po prostu pixel art. I to – warto podkreślić – nie pixel art użytkowy (czyli nie ten pochodzący z gier komercyjnych), a ten artystyczny. Oczywiście większość przedstawionych tu grafików wywodzi się lub wciąż działa na scenie, ale nie wszyscy. Książka zbudowana jest w ciekawy sposób. Twórcy poukładani są w niej według krajów z których pochodzą. Oprócz oczywistych „kopalni piksel talentów” takich jak Francja, Niemcy czy kraje skandynawskie, na graficznej mapie „Masters...” swoje miejsce zaznaczyli też, między innymi, twórcy z Indonezji, Rosji, Turcji czy Serbii. Warty odnotowania jest również i akcent polski. Na prawie 20 stronach dumnie reprezentują nas Lazur, Darklight, Jok, Rork oraz niżej podpisany. Prowler wspominał mi, że czasem otrzymywał pytania, dlaczego w albumie nie znalazł się grafik X lub Y. Przyjęty przez niego filtr wydaje się jednak sensowny. Przede wszystkim grafiki musiały być ręcznie pikselowane, po drugie nie mogły być ewidentnymi kopiami, a po trzecie nie mogły pokazywać zbyt mocno roznegliżowanych niewiast tudzież umięśnionych młodzieńców z dużymi... toporami. Dwa pierwsze punkty nie wymagają chyba komentrza, Natomiast złamanie punktu trzeciego mogło skutkować problemami na samym Kickstarterze i koniecznością przeniesienia projektu do działu „dla dorosłych”. W praktyce jednak, punkty 2 i 3 najczęściej szły w parze, o czym dobrze wie Boris Vallejo, który chyba najczęściej padał ofiarą „pikselartowych okaleczeń” swoich dzieł. „Masters...” zawiera prace powstałe na platformach 16 – 32 bitowych. Najwięcej jest, rzecz jasna, tych amigowych, ale nie brakuje również rysunków z Atari, a nawet z PC (tak tak, na grzyba również był Deluxe Paint). Jak zdrardził mi autor, niewykluczone, że za jakiś czas powstanie tom drugi wydawnictwa, poświęcony tym razem sprzętom 8 – bitowym (głównie C64, ZX Spectrum i Amstrad). Przekrój prac jest spory, najstarsze pochodzą z końcówki lat osiemdziesiątych, najnowsze z 2015 roku. Ćwierć wieku ewolucji pixel artu ujęte na 216 stronach. Uważny czytelnik bez problemu dostrzeże w grafikach odbicia różnych trendów i kierunków w projektowaniu w zależności od dat ich powstania. W wielu historiach, opowiedzianych przez artystów na kartach „Masters…” dostrzec można ogromną pasję, często trwająca do dziś. Pikselowane początki były dla niektórych początkiem drogi na szczyty graficznego biznesu. Na przykład otwierający album Austriak J.O.E. pracuje dziś w przemyśle filmowym, odpowiadając za efekty specjalne do takich filmów jak Apollo 13, Piąty Element, Titanic, Władca pierścieni, Avatar i wiele innych. Gdybym musiał koniecznie się do czegoś doczepić, mógłby to być brak spisu treści - w albumie nie podano numerów stron, na której znajdują się poszczególni graficy. Trzeba ich szukać według krajów. Można było też dodać na końcu jakiś krótki skorowidz z ważniejszymi hasłami występującymi w tekstach. Sporo jest w nich bowiem wzajemnych powiązań i referencji do produkcji. Ale to wszystko to typowe drobnostki. „Masters...” kupić można bezpośrednio od Prowlera przez sklep internetowy dostępny pod adresem: www.nicepixel.se. Co prawda, w chwili, gdy piszę te słowa, nie jest on jeszcze w pełni funkcjonalny, ale w momencie ukazania się mojego tekstu drukiem, powinien już działać. Dodatkowe informacje znaleźć też można na dedykowanej stronie: www.themastersofpixelart.com (tam również jest możliwość złożenia zamówienia). Cena albumu wynosi 350 SEK (koron szwedzkich), czyli mniej więcej 160 złotych + koszty wysyłki. Jako, że nie wiadomo czy będzie planowany dodruk, nie warto ociągać się z zakupem. Pełna rekomendacja. Zdjęcia: Prowler + Slayer Podziękowania dla Joka za osobiste dostarczenie mi albumu na czas. Aktualnie trwa już zbiórka funduszy na wspomniany tom drugi albumu: https://www.kickstarter.com/projects/nicepixel/the-masters-of-pixel-art-volume-2 Artykuł ukazał się pierwotnie w drugim numerze magazynu Retrokomp.

Wstępniak

08.02.2016 11:39

Nawiązując do starych diskmagów postanowiliśmy opisać genezę naszej inicjatywy w oldskoolowym “wstępniaku”. Skąd pomysł? Ano stąd, że lata mijają, a w Polsce jak nie było, tak nie ma żadnego sensownego miejsca skupiającego amigową demoscenę. Komodorkowcy mają, Atarowcy mają, nawet Spektrumowcy mają, a my co? Pomysł powstał kilka lat temu w trakcie jazdy na któreś Revision. Zatrzymaliśmy się w przydrożnej knajpie na skromny posiłek, rozsiedliśmy się wygodnie na dębowych ławach i między kuropatwą w sosie miętowym a ośmiornicą z truflami poczęliśmy asocjować. Na początku nasze myśli krążyły wokół zrobienia nowego, samodzielnego portalu. Jednak w pewnym momencie któryś z nas zakrzyknął z pełnymi ustami, opluwając interlokutora kawałkami bakłażana: „Zróbmy to na bazie PPA!”. Odpowiedzią było długie, pełne aprobaty beknięcie. Pomysł był genialny. Poczuliśmy radość. Natychmiast, nie zważając na ponure gęby siedzących w knajpie motocyklistów, wykonaliśmy wspólnie taniec karła z Twin Peaks, następnie szybko dokończyliśmy posiłek i ruszyliśmy w dalszą trasę. Dlaczego jako część PPA? Doszliśmy do trzech wniosków. Po pierwsze - chcąc stworzyć portal od zera musielibyśmy włożyć w to tyle czasu i energii, że zupełnie odechciałoby nam się tworzyć to, co najważniejsze czyli content, Jednym słowem cała para poszłaby w gwizdek. Po drugie - w amiświecie jest już i tak za dużo podziałow, więc po co tworzyć kolejne. Działanie w grupie zawsze przynosi lepsze rezultaty. I po trzecie - w ostatnich latach najciekawsze amiscenowe dyskusje zaczęły się naturalnie przenosić na PPA. Pomysł zintegrowania demoscenowej podstrony z PPA (ale jednak z zachowaniem pewnej niezależności) okazał się więc najlepszym i najprostszym rozwiązaniem. Choć od pomysłu do realizacji upłynęło “trochę” czasu. W tym miejscu chcielibyśmy serdecznie podziękować Grzegorzowi (Grmrksowi), bez którego pomocy, cierpliwości i dobrej woli projekt nigdy by nie powstał. Buk zapłać! Jak to działa? W swojej podstawowej funkcjonalności, SPPA jest czymś w rodzaju “nakładki” na PPA. Po wejściu na adres scena.ppa.pl wszelkie istotne treści z PPA (forum, newsy i teksty) są filtrowane pod kątem sceny. Jest to więc tak jakby “demoscenowy filtr treści”. Ale to oczywiście nie wszystko. Na SPPA obecny będzie też materiał ekskluzywny, którego nie znajdziecie na głównej stronie PPA. Duże scenowe newsy (informacje o imprezach, produkcjach z party) nadal będą publikowane na PPA, ale materiały bardziej hermetyczne albo informacje lżejszego kalibru znajdą się już tylko na SPPA. Pojawią się też wewnętrzne aktualności. Coś jeszcze? Owszem. Chcemy (powstań!) ocalić od zapomnienia (spocznij!) polską scenę i sukcesywnie przypominać Czytelnikom najlepsze diskmagi, dema, grupy, grafików, muzyków… Spróbujemy dotrzeć do wszystkich najważniejszych polskich scenowców i przy omszałej flaszy (albo trzech) porozmawiać z nimi o starych dobrych czasach. Jeszcze? Chcemy ułatwić życie debiutantom. Ośmielić ich, zachęcić i przyciągnąć do Amigi. Namnożyło się ostatnio środowisk developerskich dla scenowych koderów i chcemy je dokładnie przedstawić, tak żeby wszyscy przyszli koderzy wiedzieli jak zacząć. I oczywiście fajnie by było, gdyby nasza działalność skłoniła jakichś starych, zmumifikowanych scenowców do powrotu do świata żywych. Planujemy publikować też materiały dla osób, które chcą zacząć tworzenie amigowej grafiki i muzyki. Dla sporej części osób interesujących się demosceną niektóre tematy poruszane na PPA są równie pasjonujące co choroby wirusowe nutrii albo metody hodowli bakterii beztlenowych. Przeciętny scenowiec nie ma bladego pojęcia o tym, że toczy się jakiś “Matriksowy” bój pomiędzy MorphOS a Amiga OS 4.0, a Amiga NG to dla niego po prostu synonim Amigi PPC. Poważnie. Oczywiście tematyka demoscenowa pozostanie obecna na PPA, ale będzie nieco odseparowana. Scenowa treść zostanie - w sposób przejrzysty - uporządkowana. Nie trzeba już będzie wyłuskiwać jej z PPA. “Porywające” debaty o wyższości jednej linii neo-Amig nad drugą, o tym, “co jest prawdziwą Amiga, a co nie”, polowania na handlarzo - czarownice z Allegro czy opisy gier w Amosie, to nie są rzeczy, które interesują fanów sceny... Zdajemy sobie sprawę, że działa to w dwie strony, dlatego, jak już wspomnieliśmy, część materiałów będzie obecna tylko na SPPA. Niektórzy zapewne pamiętają, że ćwierć wieku temu w Gdyni odbyło się pierwsze polskie party z prawdziwego zdarzenia. Przez te 25 lat dużo się wydarzyło. Tak dużo, że materiałów i pomysłów na artykuły mamy mnóstwo! ps. Niektóre działy i funkcjonalności na SPPA nie są jeszcze w pełni sprawne. Strona wciąż jest "w produkcji", więc prosimy o wyrozumiałość. Kolejne funkcje będą dodawane na bieżąco. Ilustracja do tekstu: "Stunning scener" Critikill, żródło: Artcity

Czy warto przejść na SimpleMail?

03.03.2012 11:07

Konkurencja wśród programów do obsługi poczty elektronicznej na Amigę jest niewielka. Aktualnie użytkownik ma wybór w postaci YAM-a lub SimpleMaila, bo tylko te programy nadają się do użytku. O ile YAM, który prężnie rozwijał się w czasach, gdy jego rozwojem zajmował się autor programu, przyzwyczaił do siebie wielu użytkowników, tak SimpleMail zawsze był na drugim planie, choć oferował kilka ciekawych, jak na ówczesne czasy, rozwiązań. Nie zrażony tym faktem postanowiłem dać szansę SimpleMailowi (przy okazji wersji 0.38) po raz kolejny szukając alternatywy dla GMaila (którego używam w przeglądarce) i YAM-a. Program testowałem na systemach AmigaOS 4 i MorphOS. Jakie właściwie cechy wyróżniają SimpleMaila? Jest to lekki, napisany pod MUI program, który wyróżnia się obsługą protokołu IMAP, możliwością wysyłania wiadomości z wielu kont SMTP oraz wbudowaną, częściową obsługą wiadomości w formacie HTML. Główne okno programu podzielone jest domyślnie na: listę folderów, pasek narzędzi (z opcją szybkiego odfiltrowania wiadomości), listę wiadomości, treść wiadomości oraz pasek statusowy. Każdą z nich można wyłączyć z górnego menu dostosowując układ do swoich upodobań. Interfejs programu jest asynchroniczny do pobieranych i wysyłanych wiadomości (nie blokuje, co miało kiedyś miejsce w YAM-ie). filtr antyspamowy w programie działa poprawnie, użytkownik ma do dyspozycji również opcje oznaczania wiadomości jako spam. Opcje filtrów poczty przychodzącej udostępniają możliwość dopasowania pełnego lub według wzorców atrybutów wiadomości. Dla mało wymagających użytkowników niczego na tym polu nie brakuje, choć YAM ma znacznie bardziej rozbudowane ustawienia. Niestety nie ma opcji importu filtrów z innego programu, więc przy próbie przejścia należy wszystko ustawiać od nowa. W programie pocztowym nie może zabraknąć książki adresowej - w SimpleMail jest ona również prosta i jej obsługa nie wymaga stawania na głowie. Okno pisania wiadomości jest podobne do tego, które można zobaczyć w YAM-ie. Autorzy nie mieli tutaj zbyt wiele inwencji twórczej (choć wyróżnić należy opcję wyboru serwera SMTP, z którego zostanie wysłana wiadomość). Podobnie jest z oknem wyświetlania e-maila. Program niewątpliwie ma wiele ustawień, cech które można by było jeszcze długo opisywać (przedrukowując dokumentacje). Mnie zainteresowały walory użytkowe - postanowiłem przekonać się (ponownie) jak jest z jakością oferowanych przez program udogodnień. Okazało się, że nie wszystko złoto, co się świeci. Przy dłuższym użytkowaniu rozpoznałem kilka dosyć istotnych problemów i niedoróbek, które opisałem poniżej. Ograniczona obsługa wiadomości HTML Obsługa HTML jest ograniczona do podstawowych tagów i atrybutów HTML bodajże 3.2 - na pewno jest to ciekawe rozwiązanie w programie, ale nierozwijane od lat i w sumie archaiczne. E-maile w wersji HTML wyglądają zwyczajnie słabo i rozwiązaniem byłoby zapewne wykorzystanie biblioteki/klasy MUI opartej na silniku WebKit - niestety nikt takiego rozwiązania, o ile mi wiadomo, nie stworzył (a szkoda bo i nie tu by się przydało). Problemy z listą wiadomości W wersji 0.38 domyślna lista wiadomości to nie jest NListviews z MUI - jest to wewnętrzna klasa listy nieposiadająca ustawień, co dla użytkownika oznacza tyle, że brzydkiego wyglądu listy nie zmieni (choć jak zauważył Korni w komentarzach kolory używane na liście można zmienić poprzez edycję pliku .config, nie można jednak ingerować w wygląd ramek). Rozwiązaniem jest przełączenie się na widok starej listy. Niestety w ustawieniach tego nie zmienimy - należy ustawić zmienną środowiskową w systemie przez wpisanie shellu: setenv save SIMPLEMAIL_OLDMAILLIST 2 Jednak wówczas program (przynajmniej u mnie) staje się niestabilny - przełączanie wiadomości (z aktywnym widokiem podglądu) powoduje szybkie zawieszenie się programu. Niestabilny IMAP Uradowany możliwością obsługi IMAP postanowiłem sprawdzić na swoim koncie GMail działanie protokołu. Szybko się zawiodłem. Najgorzej wypadła wersja dla systemu MorphOS. SimpleMail zjadł całą pamięć systemową (zawieszając przy tym system) przy próbie wyświetlenia zawartości folderu z dużą ilością wiadomości. Niestety mój folder "Wszystkie" w GMailu zawiera ich kilka tysięcy, czego program strawić nie potrafi. Na AmigaOS4 takiego problemu nie ma, ale używanie IMAP również prowadzi do katastrofy, a właściwie zawieszenia programu (po pewnym czasie, po kilkunastu wiadomościach przeczytanych próba odczytu kolejnej zawiesiła program). Problemy z brakiem stabilności odstraszyły mnie skutecznie od używania IMAP w SimpleMail, choć w kontekście używania poczty na różnych systemach jako archiwum i tak zapewne lepiej użyć przeglądarki. Tak czy inaczej wyświetlanie folderu, który byłby miną zawieszającą wszystko nie uśmiecha mi się więc wróciłem do POP3... MorphOS i AmiSSL Na koniec jeszcze jedna podpowiedź dla użytkowników systemu MorphOS. Aby można było korzystać z połączeń szyfrowanych w SimpleMail na systemie MorphOS, należy zainstalować wersję m68k pakietu AmiSSL. Najlepiej będzie zainstalować po kolei wszystkie trzy pełne wersje (od pierwszej do trzeciej) instalacyjne AmiSSL (dla świętego spokoju, choć SimpleMail korzysta tylko z jednej). Czy warto zatem przejść z YAM-a na SimpleMail? Moim zdaniem nie warto i użytkownicy są raczej skazani na YAM-a, który oferuje więcej i działa stabilniej. SimpleMail to wieczna beta - program, którego ślady słomianego zapału autorów dotyczące rozwoju zostały na stronie. Czytamy tam od blisko dekady przechwalania się, że program rozwija się szybko i może niedługo być lepszy od YAM-a. Na pewno konkurencja jest dobra, choć zapewne życie zweryfikowało ile czasu można poświęcić na realizację swoich planów (jak autorzy wspominają w FAQ dołączonym do dokumentacji, program zaczęli rozwijać w czasach studenckich, aby zdobyć doświadczenie w pisaniu własnego mailera). W ostatnich latach nowe wersje SimpleMail pojawiają się rzadko - z częstotliwością jedna lub dwie aktualizacje na rok, które wnoszą głównie poprawki zauważonych błędów. Nie wróży to dobrze dla programu, a co gorsza nie pomaga fakt, że jego źródła są dostępne i każdy może wesprzeć projekt (jak widać sama idea otwartych źródeł niewiele wnosi do sprawy w naszym środowisku). SimpleMail zawsze pozostanie dla mnie ciekawostką, programem nienadającym się do użytku, choć nadal zawierającym kilka cech, których YAM nie posiada.

Cieniowanie ikon

23.10.2011 16:18

Wszystkie standardowe ikony w MorphOS-ie, oprócz swojego charakterystycznego trójwymiarowego wyglądu, cechują się rzucanym na tło cieniem. Cień ten jest półprzezroczysty, wykorzystuje kanał alfa obrazka PNG. Dzięki temu cień ten wygląda dobrze na dowolnym tle. Tworząc ikonę do własnego programu natkniemy się na problem cienia. Mimo że większość ikon jest tworzona w programach do modelowania 3D, cień nakładany jest oddzielnie. Prosta z pozoru operacja okazuje się być nie tak łatwa do wykonania, bo jak to zwykle bywa, diabeł tkwi w szczegółach. Chciałbym w tym artykule przedstawić skuteczny sposób dodawania do ikon estetycznych cieni za pomocą programu... ShowGirls. Ta niepozorna, wydawałoby się, przeglądarka do obrazków, we wprawnych rękach jest znakomitym narzędziem do przetwarzania obrazu. Zaczynamy oczywiście od źródłowego obrazka. Pochodzenie dowolne, obrazek przykładowy (ikona programu DateCalc) wymodelowałem i wyrenderowałem w Blenderze. Został on wyrenderowany w rozmiarze 256 x 256 pikseli i zapisany w formacie PNG z kanałem alfa. Na rys. 1. widzimy go po załadowaniu do ShowGirls. Pierwszym krokiem jest otrzymanie maski obrazu, czyli jak gdyby "wyciągnięcie" z niego kanału alfa. Zaczynamy od operatora 'HSV Balance' i suwakiem 'Value' zjeżdżamy na zero. W efekcie otrzymujemy czarny kontur kanału alfa jak na rys. 2. Drugi krok to podłożenie białego koloru w miejsca przezroczyste narzędziem 'Blender'. Efekt obserwujemy na rys. 3. Co właściwie zrobiliśmy, to kanał alfa obrazka przenieśliśmy w kanał luminancji (jasności). Kolejny krok będzie specyficzny dla ikonek zrobionych w Blenderze. Program ten ma dość irytującą cechę zapisu wygenenerowanych obrazów. Mianowicie kolor "świata" czyli tło, włazi na piksele na brzegach renderowanych obiektów. Możnaby się spodziewać, że np. na krawędzi czerwonego obiektu wszystkie piksele będą czerwone, a tylko kanał alfa będzie wycieniowywał krawędź. Niestety, jeżeli tło jest, powiedzmy, standardowo granatowe, piksele na krawędzi będą miały różne odcienie fioletu. Gdy umieścimy obrazek na jasnym tle, zobaczymy dookoła fioletową obwódkę. Dobrze ilustruje to rys. 4., gdzie poszarpana krawędź białej kartki z kalendarza umieszczona na białym tle powinna być niewidoczna. Wyraźnie widzimy jednak niebieską obwódkę. Możnaby ustawić w Blenderze jasny kolor tła, ale wtedy jasną obwódkę zobaczymy wokół ciemnego kalkulatora po umieszczeniu ikony na ciemnym tle. Skutecznym rozwiązaniem tego problemu jest lekkie "skurczenie" maski. Można to na szczęście prosto zrobić za pomocą ShowGirls. Zaczynamy od rozmycia brzegów maski operatorem 'Gaussian Blur'. Rozmiar blura ustawiamy na 1,00. Teraz jesteśmy gotowi do operacji skurczania. Wykonujemy je narzędziem 'Curves', podnosząc krzywą do góry jak widać na rysunku 5. Im bardziej podniesiemy krzywą, tym skurczenie będzie silniejsze, nie warto jednak przesadzać, bo jednocześnie brzegi maski stają się ostrzejsze i bardziej poszarpane. Efekt zaaplikowania przykładowej krzywej widzimy na rysunku 6, na dolnej krawędzi przedmiotu najlepiej widać skurczenie się maski. Po tej operacji zapisujemy maskę do pliku, np. jako 'maska.png'. Teraz pora na zajęcie się cieniem. Przede wszystkim należy pamiętać o tym, że nawet głęboki cień nie jest stuprocentowo czarny, a to przez rozproszenie światła w powietrzu i odbicia od otaczających przedmiotów. Dlatego naszą maskę cienia musimy osłabić. Z pomocą ponownie przyjdzie narzędzie 'Curves', tym razem podnosimy krzywą tak, jak na rys. 7. W celu uzyskania linii prostej usuwamy trzy pośrednie punkty prawym przyciskiem myszy. Nasza maska z czarnej staje się szara (rys. 8.). Teraz pora na zmiękczenie krawędzi. Zanim to jednak zrobimy, zauważmy, że cień nie jest przecież symetrycznie rozmieszczony dookoła ikony, a naturalnie przesunięty w prawo i w dół. Trzeba więc naszą maskę przesunąć. Można to łatwo zrobić operatorem 'Resize' używając opcji dodawania ramki dookoła obrazu. Niezbędne ustawienia widzimy na rys. 9., szczególną uwagę należy zwrócić na ramkę 'Border'. Ramka jest włączona, oryginalny obrazek zostanie umieszczony w prawym dolnym rogu, a więc białe obrzeże zostanie dodane od góry i od lewej. Przy wielkości obrazka 256 x 256 pikseli przesunięcie powinno wynosić około 10 pikseli, stąd nowy rozmiar ustawiony jest na 266 x 266. Dla większych obrazków przesunięcie trzeba proporcjonalnie zwiększyć. Po przesunięciu maski czas na rozmycie brzegów - wszak cień musi być miękki. Po raz drugi posłużymy się operatorem 'Gaussian Blur', tym razem jednak rozmiar maski ustawiamy na 10,00 (proporcjonalnie więcej dla większych obrazków). W efekcie otrzymujemy rozmytą plamę cienia (rys. 10.). Teraz maskę cienia należy połączyć z maską przedmiotu zapisaną przez nas wcześniej na dysk. Wykorzystamy w tym celu możliwość wstawienia jednego obrazka jako kanał alfa drugiego. Dokładniej wstawimy ostrą maskę z dysku jako kanał alfa naszej plamy cienia. Uruchamiamy operator 'Insert Alpha', wybieramy wcześniej zapisany plik z maską, włączamy 'Use image luminance'. 'Negative' i 'Resize to fit' powinny być wyłączone. W efekcie w naszej plamie cienia powstanie przezroczysta dziura w kształcie przedmiotu (rys. 11.). Dziurę należy wypełnić kolorem czarnym, korzystając z używanego już wcześniej narzędzia 'Blender'. Gotowa maska wygląda już prawie jak ikona, ale zamiast przedmiotu jest czarna plama (rys. 12.). Ostatnią operacją jest użycie maski na pierwotnym obrazie. Zaczynamy od zapisania właśnie wykonanej maski do kolejnego pliku. Teraz możemy ponownie wczytać oryginalny obrazek. Kolejna operacja zdecyduje o kolorze cienia. Po raz trzeci mianowicie trzeba użyć narzędzia 'Blender' i wypełnić przezroczyste tło kolorem cienia. Normalnie będzie to kolor czarny, ale żądni eksperymentowania mogą się pobawić innymi kolorami, chociaż z reguły efekt nie będzie zbyt naturalny. Przygotowany do maskowania obrazek widzimy na rys. 13. Po raz drugi sięgamy po operator 'Insert Alpha'. Opcje bez zmian, ale tym razem aktywujemy 'Negative' (rys. 14.). I oto proszę, nasza ikona ukazuje się nam w pełnej krasie (rys. 15). Pozostało nam przeskalować ją do rozmiarów standardowych dla Ambienta, czyli 64 x 64 piksele. Robimy to oczywiście operatorem 'Resize', tym razem wyłączając opcję 'Border' i włączając odpowiedni filtr, osobiście preferuję 'Lanczosa'. Przeskalowana ikona zaprezentowana jest na rysunku 16. Dodatkowo - niczym ostatnie pociągnięcie pędzla mistrza - można ją delikatnie wyostrzyć, ale naprawdę delikatnie. W operatorze 'Sharpen' suwakiem 'Strength' nie powinniśmy wyjechać poza 0,15, z doświadczenia polecam wartości z zakresu 0,05 do 0,10 (rys. 17.). Trzeba pamiętać o tym, że im mniejszy obrazek, tym brutalniejsze jest działanie tego operatora. Wyostrzona ikonka pokazana jest na rys. 18, a na rys. 19. widzimy gotową ikonkę wyciętą z okna Ambienta, na klasycznie amigowym szarym tle. Korzystając z faktu, że ShowGirls posiada port ARexxa, można spróbować zautomatyzować wszystkie podane czynności. Wtedy cienie pod ikonami można dodawać nieomalże kliknięciem myszy. Jest to jednak temat na oddzielny artykuł. Artykuł oryginalnie pojawił się w trzecim numerze Polskiego Pisma Amigowego.

Stephen Fellner (Wrzesień 2009)

20.09.2009 15:54

Dziękuję, że zgodziłeś się na tę rozmowę. Na początek, czy mógłbyś się przedstawić i powiedzieć czym zajmujesz się w naszej społeczności? Wydaje mi się, że odpowiedź na to już znasz :) Masz rację, ale to jest pewnego rodzaju rutynowe pytanie. Obiecuję, że reszta nie będzie już taka stereotypowa (mam przynajmniej nadzieję) ;) Nazywam się Stephen Fellner i tworzę programy dla AmigaOS 4. Konkretnie są to DvPlayer i WarpView. Jestem również betatesterem i deweloperem AmigaOS 4. Pracowałem m.in. nad Picasso96 oraz sterownikami dla kart ATI Radeon. Zacznijmy od tego ostatniego elementu. Pracowałeś, tzn. że już nie jesteś zaangażowany w rozwój tych elementów? Nie, nadal się nimi zajmuję, lecz nie jestem głównym programistą tych komponentów. Wykonuję jedynie konkretne zadania oraz poprawki związane z odtwarzaniem wideo. Dla przykładu, zaimplementowałem potrójne buforowanie dla overlaya z synchronizacją pionową, co jest bardzo ważne dla płynnego odtwarzania obrazu. Pozwala to obejść te drażniące tzw. "raster cuts", które sprawiają, że animowana grafika na PC wygląda tak fatalnie w porównaniu z amigową. W końcu my zawsze mieliśmy podwójne/potrójne buforowanie i synchronizację pionową (synchronizacja animacji do wygaszania pionowego monitora). Dodałem również obsługę kilku nowych modeli barw YUV, co zapewnia szybsze odtwarzanie. Jak dotąd, udało mi się uzyskać około dziesięcioprocentowe przyspieszenie w odtwarzaniu wideo na Sam440, przy wykorzystaniu modelu YUV. Przyczyniłem się również do innych programów dla AmigaOS 4, lecz głównie skupiam się na rzeczach związanych z odtwarzaniem obrazu. Dzieje się tak głównie dlatego, że jest to obszar Twoich zainteresowań, prawda? Powiedz nam więcej o tym. Kiedy i w jakich okolicznościach zdecydowałeś się tworzyć narzędzia do odtwarzania plików wideo? Czy było to spowodowane brakiem podobnych programów, a może próbowałeś coś komuś lub sobie samemu udowodnić? Muszę przyznać, że grafika komputerowa to jedno z moich głównych zainteresowań. Programy dla Amigi zacząłem pisać w roku 1998. Wówczas poznałem Laszlo Toroka, autora programu do odtwarzania plików wideo AVid (później przemianowanego na MooVId), który wprowadził mnie w to wszystko. Na początku napisałem kilka procedur renderowania obrazu (chunky-to-planar oraz "Storm" - procedurę renderowania obrazu opartego na trybie HAM w czasie rzeczywistym), które wysłałem do Laszlo, aby dołączył je do MooVida. Jego program spisywał się doskonale odtwarzając pliki w formatach AVI i Quicktime (MOV), ale nie istniało nic, co radziłoby sobie z odtwarzaniem z akceptowalną prędkością plików MPEG. Były jakieś odtwarzacze typu AmiPeg oparte na otwartych źródłach innych programów, lecz były zbyt powolne na średnio rozbudowanych Amigach. Przystąpiłem więc do pracy nad własnym programem, który napisałem w całości w asemblerze. To było spore techniczne wyzwanie i jednocześnie bardzo czasochłonne zajęcie. Nauczyłem się jednak wiele, a Amiga otrzymała naprawdę szybki program do odtwarzania plików MPEG. Szczerze mówiąc jednak, liczyłem na to, że będzie szybszy. Tak to się właśnie zaczęło. Dla tych co nie wiedzą, mówisz o programie RiVA - całkiem niezły program do odtwarzania plików MPEG dla Amig klasycznych (może pamiętasz (lub nie), że pomagałem rejestrować ten program u Ciebie osobom z Polski). Pamiętam :) Jaki wpływ miał rozwój programu RiVA na Twój kolejny projekt, którym był DvPlayer? Za czasów RiVY wiele osób pytało o program w wersji dla procesorów PPC. Stworzenie czegoś takiego zajęłoby mi mnóstwo czasu, gdyż całość napisana została w asemblerze 68k. Przepisanie tego na PPC zajęłoby lata, a poza tym nie miałem wówczas karty z procesorem PPC. Poza tym nie byłem zadowolony z faktu, że RiVA nie posiadała GUI i między innymi z tego powodu nie spełniała do końca oczekiwań, jeśli chodzi o nowoczesny program do odtwarzania filmów. Z uwagi na bardzo mocno zoptymalizowaną budowę programu, rozszerzenie go o GUI było rzeczą trudną i czasochłonną. Zdałem sobie sprawę, że zabrnąłem w ślepą uliczkę. Pewnego dnia rozmawiałem z Csaba Simonem (Chip), który pracował nad portem biblioteki avcodec na potrzeby nowej wersji MooVIda. Powiedział mi jak można ją wykorzystać w odtwarzaczach. MooVId miał być wówczas częścią AmigaOS 4. Napisałem więc krótki przykładowy kod, który dekodował kilka klatek z pliku MPEG. Okazało się to zaskakująco proste. Kodek obsługiwał także MPEG2 (RiVA potrafiła odtwarzać jedynie MPEG1), co oznaczało, że poradziłby sobie z SVCD i plikami VOB znajdującymi się na płytach DVD. To wszystko było jeszcze pod WarpOS - nie wydano wtedy jeszcze AmigaOS 4 - tak po prawdzie, to nie sądziłem wówczas, że kiedykolwiek ujrzy on światło dzienne. W końcu się to udało i co więcej, DvPlayer był tym programem, który był do niego dołączony oraz wyparł MooVIda. Czy było to zamierzone? Spodziewałeś się tego? Co stało się z MooVIdem (bądź co bądź, był dołączony do systemu w wersji pre-release)? DvPlayer miał uzupełniać MooVIda. Plan był taki, aby MooVId służył do plików AVI/MOV, a DvPlayer do MPEG, VideoCD i DVD oraz być może też innych, z którymi MooVId by sobie nie radził. Jesteśmy z Laszlo (autorem MooVIda) dobrymi przyjaciółmi i nie chcieliśmy ze sobą rywalizować, pracując nad obsługą tych samych formatów. Niestety Laszlo przestał interesować się Amigą, a w związku z tym rozwój MooVIda nie potoczył się tak, jak oryginalnie planowano. Dostrzegłem potrzebę posiadania programu do odtwarzania filmów, który posiadałby GUI oraz radziłby sobie z formatami, których obsługi początkowo nie planowałem. Tak więc DvPlayer obsługuje AVI i WMV, a Quicktime (MOV) i być może FLV zamierzam dodać w przyszłości. Czy traktujesz MPlayera jako konkurencję dla DvPlayera? Zasadniczo oferuje on to samo, co Twój program. Jest oparty na otwartym kodzie źródłowym, co wielu uważa za zaletę. Jaki jest Twój punkt widzenia w tej kwestii? MPlayer z całą pewnością stanowi konkurencję. Niemniej jednak uważam, że DvPlayer jest znacznie wygodniejszy i prostszy w obsłudze dla użytkownika. Nie zmienia to jednak faktu, że bardzo się cieszę, iż mamy MPlayera, który umożliwia odtwarzanie formatów, z którymi DvPlayer sobie nie radzi (np. MOV i FLV). Program ten również pomógł mi w pracy nad DvPlayerem. Mając problemy z jakimiś plikami wideo, mogłem je testować właśnie na MPlayerze, aby sprawdzić czy on radził sobie z nimi podobnie. W ten sposób mogłem sprawdzić czy problemem jest uszkodzony plik, czy też musiałem skupić się na odnalezieniu błędu w DvPlayerze. Ile czasu upłynęło, zanim DvPlayer stał się w pełni użytecznym, niezawodnym w działaniu programem? Kilka lat z przerwą. Po paru miesiącach od rozpoczęcia prac, zepsuła się moja A4000. Zajęło mi trochę czasu odszukanie osoby, która potrafiłaby ją naprawić. Jeśli dobrze pamiętam, trwało to łącznie dziewięć miesięcy. Gdy dostałem komputer z powrotem, przez kolejnych kilka miesięcy mogłem pracować dalej. Wtedy też nadszedł moment, gdy zostałem betatesterem AmigaOS 4 i mogłem zacząć wykorzystywać jego możliwości. Niestety, sprzęt znowu dał o sobie znać - padła moja karta PPC. Duże wsparcie otrzymałem od Hyperion-Entertainment. Zaoferowali się, że naprawią moją kartę za darmo i wyślą wczesną wersję MicroA1, z której będę mógł w tym czasie korzystać. Okazało się, że karty nie można wskrzesić, więc pozwolono mi zatrzymać MicroA1, która wbrew całej propagandzie związanej z układem Articia, którą wówczas przerabialiśmy, okazała się najbardziej niezawodnym amigowym sprzętem jaki kiedykolwiek miałem. Od tego momentu rozwój DvPlayera postępował bez żadnych problemów. Czy pracując nad DvPlayerem osiągnąłeś wszystko co chciałeś, czy też jest coś, co po prosto wykracza poza Twoje możliwości lub jest nieosiągalne na amigowym sprzęcie? Trudno powiedzieć. Sądzę, że osiągnąłem więcej niż pierwotnie zakładałem. Ale jak to bywa ze wszystkimi większymi projektami, świat idzie do przodu, zaczynają obowiązywać nowe standardy, tak więc oglądanie się za siebie i przeglądanie starych założeń nie ma sensu. Trzeba podążać za postępem technologicznym. Obecnie coraz popularniejsze jest High-Definition i na pewno chciałoby się, aby komputer sobie z tym radził bez żadnych problemów. Niemniej jednak, nawet w świecie PC, maszyny low-end nie są wystarczające, aby cieszyć się najnowszymi standardami/kodekami. Najpopularniejszy obecnie kodek h264 wymaga przynajmniej procesora G5 Dual lub Quad Core, aby zapewnić komfort oglądania. W przypadku słabszego procesora niezbędna jest karta graficzna na złączu PCI-Express z funkcją dekodowania h264. Aparat cyfrowy, który zamierzam kupić, nagrywa filmy w rozdzielczości FullHD 1080p w formacie MOV (Quicktime). Będę więc dążył do tego, aby DvPlayer go obsługiwał (planuję to od dłuższego czasu), lecz bez odpowiedniego sprzętu, nie będzie zbytniego pożytku z odtwarzania filmów w takiej rozdzielczości. Odsuńmy się nieco od DvPlayera i porozmawiajmy o WarpView. Po co kolejna przeglądarka obrazków? Co posiada Twój program, czego nie mają inne? Pierwotnie WarpView nie miał być przeglądarką obrazków. Kiedyś zgłębiałem tajniki tworzenia silników 3D i w jaki sposób radzą sobie z ograniczeniami sprzętu w przypadku rozmiarów tekstur (rozmiary tekstury muszą być wartością będącą potęgą dwójki, a ponadto mamy górny limit, taki jak na przykład 256 na kartach Voodoo - z tego co pamiętam). Wymyśliłem w jaki sposób podzielić obrazy na mniejsze tekstury i bez widocznego miejsca styku połączyć je ze sobą krawędziami (sztuczka polega na wykorzystaniu bilinearnej interpolacji). Gdy przykładowy program zadziałał prawidłowo, zdałem sobie sprawę, że mogę w ten sposób skalować i obracać obrazy w czasie rzeczywistym. Wszystko to odbywało się bardzo płynnie, praktycznie bez obciążenia procesora. Pomyślałem więc, dlaczego nie wykorzystać tego do zrobienia przeglądarki obrazków, która robiłaby użytek z procesora karty graficznej. No i tak się to zaczęło. Z tego co wiem, WarpView jest jedyną aplikacją dla AmigaOS, która potrafi coś takiego. Ważną cechą programu jest również obsługa informacji EXIF zaszywanych przez aparaty cyfrowe w zdjęciach. Zdaje się, że poza WarpView, jedynie AmiPhoto to obsługuje. Jestem również bardzo dumny z funkcji zmiany wielkości oraz przycinania obrazów. Algorytm skalowania "Lanczos" zaimplementowany w WarpView jest jednym z najlepszych obecnie dostępnych i chyba nie jest wykorzystywany przez żaden inny program dla AmigaOS. Nawet ImageFX korzysta ze starej metody uśredniania, która traci więcej szczegółów podczas zmniejszania. Spędziłem dużo czasu na optymalizacji tego elementu, a w efekcie otrzymałem coś bardzo szybkiego w działaniu. Skłaniam się ku rozszerzeniu programu o funkcje przetwarzania obrazu. Większość osób posiada dzisiaj aparat cyfrowy i chciałaby poprawić nieco swoje zdjęcia (zmniejszyć, przyciąć, wyostrzyć). Już istnieje wbudowany w program filtr "Unsharp Mask", który wyostrza obraz. Sporo czasu spędziłem na analizowaniu tematu algorytmów redukcji szumu (ziarnistości), gdyż w świecie fotografii cyfrowej jest to powszechnie występujący problem. Czy zasadniczo jesteś zadowolony z poziomu sprzedaży WarpView i DvPlayera? Czy obecnie trudno jest sprzedawać programy na licencji shareware? Amigowy rynek jest niezmiernie mały, tak więc nikt, kto rozwija jakieś oprogramowanie na tę platformę, nie ma wysokich oczekiwań dotyczących sprzedaży. Z pewnością na tym rynku nikt się nie wzbogaci :). Jeśli spojrzę przez pryzmat czasu, jaki poświęciłem na rozwój swoich programów i porównam to z liczbą rejestracji, wówczas można się rozczarować. Te kilka okazjonalnych klientów jednak pomaga mnie zmotywować, choć większe znaczenie ma pozytywny wydźwięk i opinie. Przyjemnie jest poczytać o ludziach zadowolonych i robiących ciekawe rzeczy moimi programami. Muszę przyznać, że właściwie to właśnie to odgrywa dla mnie największą rolę i sprawia, że warto. Czy pracujesz nad czymś nowym lub masz taki zamiar? Czy mógłbyś podzielić się nieco informacjami z tym związanymi? Przyglądałem się MiniGL, gdyż planowałem odejść od Warp3D i zrobić z tego użytek w WarpView. W efekcie powstał, tak dla zabawy, prosty silnik gry. Nie miałem jednak jeszcze czasu, aby zamienić go w coś poważnego. Obecnie w systemie mamy kompozycję obrazu i zdaje się, że ta funkcja będzie znacznie bardziej nadawała się do wykorzystania w WarpView niż MiniGL. Zastanawiam się również nad oprogramowaniem do obróbki filmów, lecz to nie jest zadanie dla jednej osoby i prawdopodobnie będzie wymagało pracy jakiegoś zespołu. Poza tym chcę najpierw ukończyć kilka rozpoczętych projektów (np. obsługa plików MOV w DvPlayer) zanim zacznę robić coś tak dużego. Twoim zdaniem, jaka przyszłość czeka AmigaOS i systemy pochodne? Moim zdaniem AmigaOS i jemu podobne systemy powinny korzystać ze swoich "niskozasobowych wymagań", które stają się ogromną zaletą na urządzeniach przenośnych, gdzie moc oraz żywotność baterii są ograniczone. Czy zostaniemy czymś zaskoczeni? To zależy od oczekiwań. :) Sądzę jednak, że zdarzy się kilka rzeczy, które dla wielu osób będą wielką niespodzianką. Jakie są Twoje życzenia dotyczące Amigi i AmigaOS? Chciałbym, aby w naszej społeczności pojawiło się więcej deweloperów, abym mógł odejść na emeryturę. :) Poważnie jednak mówiąc, potrzeba nam więcej ludzi do pisania oprogramowania lub tworzenia portów. Cieszę się, że kilka osób próbuje tego dokonać. Sądzę, że AmigaOS to najlepsza platforma dla deweloperów-hobbystów. Z prostej przyczyny - na tej platformie nawet proste programy są bardzo mile widziane, w przeciwieństwie do systemów wiodących, gdzie są setki różnych aplikacji robiących to samo. Tutaj programiści mogą naprawdę wiele zdziałać, nawet niskim nakładem pracy. Stephen, było mi naprawdę miło móc z Tobą porozmawiać. Dziękuję za odpowiedzi na wszystkie moje pytania. Życzę Ci powodzenia w pracach nad Twoimi projektami. Czy na zakończenie chciałbyś coś jeszcze powiedzieć, co ładnie by wszystko podsumowało? Dziękuję. Mnie również było miło. To dobrze, że tacy ludzie jak Ty, których pamięta się ze starych czasów, nadal są z nami. Ostatnie dziesięć lat było trudnym okresem dla Amigi i to w zasadzie cud, że pomimo tylu nieszczęśliwych wydarzeń, udało się tej platformie przetrwać. Rozwój w każdym obszarze (sprzęt, system, oprogramowanie) nadal trwa, a grupa użytkownikom powolutku znowu rośnie. Chciałbym podziękować wszystkim, którzy ciężko pracowali na to, aby Amiga nadal żyła oraz tym, którzy nie stracili wiary i nadziei w najgorszym okresie i nadal są z nami. Korekta: Konrad Czuba i Aleksander Chyliński

WinUAE - konfiguracja

19.09.2005 19:45

I. Wstęp Wiele osób chciałoby pograć w stare, amigowe gry albo odpalić amigowy system nie mając dostępu do naszego komputerka. W erze wszędobylskich pecetów, to nie stanowi problemu. Wystarczy ściągnąć z internetu jeden z wielu dostępnych emulatorów Amigi i po chwili można cieszyć się swoimi ulubionymi gierkami. My zajmiejmy się tutaj opisem WinUAE w wersji 1.0.0. Jest to moim zdaniem jeden z lepszych emulatorów Amigi jaki powstał na "blaszaka", a więc do dzieła. II. Instalacja i konfiguracja Przed instalacją proponuje na dysku stworzyć katalog o nazwie Amiga i tam instalować wszystko, co będzie potrzebne emulatorowi. Instalacja WinUAE nie powinna sprawiać problemów, klikamy na ikonkę, wybieramy katalog i po chwili mamy emulator na naszym dysku. Po uruchomieniu, pojawi nam się takie okno jakie widać na obrazku obok. Klikamy na TAK i czekamy parę chwil, aż WinUAE przetestuje sobie naszą kartę graficzną. Okno to pojawiać się będzie tylko przy zmianie sterowników do karty graficznej pod Windowsem, zmianie karty graficznej lub po instalacji WinUAE. Kiedy przejdziemy pomyślnie test karty graficznej, to pojawi nam się kolejne okienko (poniżej, po lewej). Widać tutaj masę opcji, ale opiszę te najważniejsze na przykładzie starej gry Wing Commander I AGA. A więc zaczynamy. Nasza gra w oryginale mieści się na trzech dyskietkach, które w naszym przypadku zobrazkowane są jako pliki o nazwach wc1.adf, wc2.adf, wc3.adf. Wchodzimy do zakładki Disk Drives (rysunek powyżej, po prawej stronie), do DF0: "wkładamy" plik wc1.adf, do DF1: - wc2.adf, a do DF2: - wc3.adf. (Uwaga! Nie każda gra/program obsługuje kilka napędów. Pomimo umieszczenia w slotach DF1:, DF2:, czy DF3: obrazów dysków, program nadal może domagać się zmiany dysku). Jak już udało nam się zamontować dyskietki, to musimy teraz naszej amulowanej Amidze przydzielić trochę pamięci RAM. Spójrzmy na obrazek po lewej stronie. Jak widać mamy tam kilka pozycji: CHIP - to pamięć tzw. graficzna, dostęp do niej mają wszystkie kości specjalizowane w prawdziwej Amidze (kość graficzna OCS, ECS lub AGA, układ dźwiękowy, blitter, CPU). Maksymalna ilość tej pamięci to 2MB w prawdziwych Amigach - tutaj możemy ustawić nawet 8 MB, ale nie polecam tego, ponieważ przy tej ilości wiele programów/gier źle działa albo w ogóle się nie uruchamia. Najlepiej ustawić 2MB SLOW - pamięć ta, to pamięć stosowana jedynie w A500, w rozszerzeniach tzw. pod klapkę. Wynikało to z ograniczeń konstrukcyjnych w A500. Pamięć ta jest potrzebna dla naprawdę starych gier, np. Storm Swiv nie odpali się jeżeli nie będziemy mieli 0.5 MB SLOW. FAST - ta opcja dotyczy pamięci stosowanej w A1200 w rozszerzeniach tzw. pod klapkę. Możemy ustawić tylko 8 MB tej pamięci, bo takie ograniczenia mają karty pamięci stosowane w A1200. Proponuję ustawić tą pamięć dla gier pisanych pod A1200 (np. Breathless, Banshee, Gloom/Gloom Deluxe), ponieważ ustawienie tylko Z3-FAST powoduje częste wieszanie się starszych gier dla A1200. Z3-FAST - ta opcja pozwala nam na ustawienie dowolnej ilości pamięci FAST. Jest to pamięć stosowana na tzw. kartach turbo. Pamięć ta przyda nam się jeżeli będziemy chcieli pograć w bardziej wymagające gry np. Napalm, Quake I, Payback. Gry te wymagają przynajmniej 16 MB RAM, a zalecane to 32/64 MB. Należy jednak pamiętać, żeby nie ustawiać tyle pamięci, ile mamy jej w pececie, np. mając 512 MB RAM w pececie ustawmy 128 MB, maksymalnie 256 MB, dla Amigi. Większa ilość nie spowoduje przyspieszenia działania, tylko znacznie ją ograniczy, ponieważ emulator zajmie cały dostępny RAM, a w tym momencie Windows zacznie korzystać z pamięci wirtualnej, co z kolei spowolni emulację. RTG - jest to pamięć, która będzie wykorzystana w emulowanej karcie graficznej. Nie chodzi tutaj o kości OCS/ECS lub AGA, tylko o karty graficzne wkładane do slotów ZorroII/III lub PCI. Przydatne jest to kiedy chcemy zainstalować amigowy system i grać w nowsze gry. Wystarczy nam tutaj 8 MB. Dla naszej gry ustawiamy 2 MB CHIP i 4 MB FAST (nie dla każdej gry ustawiamy tak samo, np. wspomniany Storm Swiv wymaga 0.5 MB CHIP i 0.5 MB SLOW). Kolejną opcją po pamięci RAM jest wybranie odpowiedniego ROM-u (rysunek na prawo). 99% starych gier wymaga ROM-u 1.3 i taki musi zostać wczytany z pliku, a do zabaw z sytemem musimy ustawić ROM 3.1. Teraz przyszła kolej na ustawienie kości graficznych w naszej emulowanej Amidze (rysunek poniżej, na lewo): OCS - kości stosowane w A1000, A2000 i A500 - ustawiamy dla naprawdę starych gier, ECS - kości z A500+, A600 i A3000, nieznacznie szybsze od OCS mające te same możliwości. Dla starych gier proponuję je ustawić w pierwszej kolejności. OCS ustawmy dopiero wtedy, kiedy gra nie chce się uruchomić z ECS. AGA - kości z A1200, A4000 i CD32. Ustawiamy ją tylko dla gier przeznaczonych dla tych komputerów, w innych przypadkach ustawienie tej kości może powodować problemy. Dla naszej gry ustawiamy oczywiście AGA, zaznaczamy także opcje "Immediate Blitter" oraz "Sprites and Sprites vs. Playfield". Jeżeli mamy szybki procesor (min. 1GHz) to dźwięk ustawmy na "Emulated, 100% accurate". Następnie otwieramy zakładkę CPU (rysunek powyżej, na prawo) i ustawiamy tam odpowiedni typ procesora: 68000 - dla starych gier z A500, 68010 - to prawie ten sam procesor co powyższy, jednak w większości przypadków sprawia problemy, więc lepiej jego nie zaznaczać, 68ec020 - procesor stosowany w A1200 i CD32. Większość gier dla A1200 wymaga tego procesora, a gry dla CD32 bezwzględnie go wymagają, 68ec020 + FPU - procesor + FPU, czyli jednostka arytmetyczna, tzw. koprocesor. W grach raczej nieprzydatna, 68020 - tzw. pełna wersja procesora, od 68ec020 różni się tym, że ma wbudowane MMU, czyli jednostkę do zarządzania pamięcią wirtualną. Ustawienie tego procesora umożliwia wykorzystanie JIT-a, co sprawia że emulacja CPU jest znacznie szybsza, umożliwia nam także użycie pamięci Z3-FAST i RTG, 68020 + FPU - to samo co wyżej procesor + kooprocesor, 68040 - najszybszy z tu obecnych i przydatny do zabaw z systemem i odpalania lepszych gier (Quake I, Myst, Napalm, Exodus, Payback, Earth 2140 itd.) Dla naszej gry ustawiamy procesor 68020 i zaznaczamy następujące opcje: "JIT", "Cache Size" ustawmy na 8 MB i zaznaczmy także opcję "Fastest possiblie but maintain chipset timing", CPI IDLE zostawmy tak, jak jest. Dla starych gier z A500 ustawiamy CPU 68000 zaznaczając opcje "More compatibile" i "Match A500 speed". Kiedy uporaliśmy się z konfiguracją komputera, należy ustawić resztę, czyli opcje wyświetlania, kartę muzyczną itd. Wszystkie te opcje są w zakładce HOST, pierwsza to Display: Screen - domyślnie ustawione jest na "Główny sterownik ekranu", ale warto to zmienić na kartę graficzną taką, jaką posiadamy. Jako że ja mam Radeona 9000 PRO, to ustawione mam "Hightech Excalibur radeon 9000pro". Rozdzielczość ustawiamy w zależności od tego, jak będzie chodzić gra. Ustawianie rozdzielczości dotyczy tylko i wyłącznie kości OCS/ECS i AGA. Posiadając kartę graficzną ustawmy własną rozdzielczość. Najlepiej - 800x600 16bit, jednak tutaj polecam poeksperymentować. Settings - wybieramy "Full Screen", Refresh - tutaj wszystko zależy od naszego peceta. Jak mamy szybkiego, to dajemy "Every Frame", jeżeli posiadamy wolniejszy sprzęt, to musimy ustawić na wyczucie. Przy maszynach poniżej 1.5 GHz polecam ustawić "Every second frame", a poniżej 1GHz "every third frame". Kolejna zakładka to Sound. Tak samo jak w przypadku grafiki, tutaj też jest ustawione "podstawowy sterownik dźwięku". Proponuję jednak to zmienić na kartę jaką posiadamy. W moim przypadku to SB Live. Reszty opcji nie zmieniamy, ustawmy tylko na sound "Enabled, 100% accurate". Jeżeli mamy słabszy sprzęt, to ustawiamy opcję "Enabled". Jeżeli mimo to dźwięk nam się "tnie", to ustawiamy opcję "Disabled, but emulated". Kiedy już wszystko mamy ustawione proponuję przejść do zakładki Configuration. W pole Name wpisujemy nazwę naszych ustawień np. wing, a potem naciskamy SAVE i teraz nie musimy za każdym razem ustawiać wszystkiego od początku. Opisałem większość opcji jakie są dostępne w WinUAE. Pozostały nam jeszcze dwie ważniejsze. Pierwsza to Hard Drives. Tutaj ustawiamy wirtualne dyski twarde naszej emulowanej Amigi. Mogą to być katalogi na dysku pecetowym, np. na dysku D: mamy katalog Amiga, gdzie zainstalowaliśmy WinUAE. Tworzymy tam katalog HD, a w katalogu HD tworzymy katalog WORK. Naciskamy klawisz "Add directory", wskazujemy nasz WORK i od teraz pod emulatorem będzie widziany jako DH0:Work. Opcja ta jest przydatna, gdy chcemy zainstalować system amigowy. Proponuję też zaznaczyć opcję "Add PC Drives at startup". Spowoduje to, że z poziomu emulatora będziemy mieli dostęp do dysków pecetowych. Kopiowanie artykułu w całości lub fragmentach bez zgody autora lub redakcji PPA ( www.ppa.pl ) zabronione. Kolejna opcja to Misc. Ustawiamy tutaj parę rzeczy, które są przydatne, a więc: UAEscsi.device - potrzebne, kiedy chcemy emulować CD-ROM na Amidze, BSDsocket.library emulation - to natomiast umożliwi nam łączenie się z internetem z systemu amigowego bez konieczności instalowania dodatkowego oprogramowania (takiego jak Miami czy Genesis). Use CTRL-F11 to quit - włączenie tej opcji sprawi, że naciśnięcie tych dwóch klawiszy w trakcie pracy emulatora spowoduje jego natychmiastowe zakmnięcie. Pozostało nam już tylko omówienie reszty opcji: Quickstart - są to przygotowane przez autorów pewne konfiguracje sprzętowe, jednak moim zdaniem mało przydatne. Paths - ustalamy tutaj ścieżki dostępów do plików konfiguracyjnych itd. Program sam to zrobi, przydatne to jest wtedy kiedy zmienimy lokalizację plików. Game & I/O Ports - ustawiamy tu drukarkę, porty COM, myszkę (lepiej zostawić standardowe ustawienia) oraz joystick, jeżeli takowy posiadamy. Input - ustawiamy "skróty klawiszowe". Lepiej pozostawić tak jak jest, chyba że posiadamy joystick albo te, które są ustawione, nam nie odpowiadają. Output - przy wyborze tej opcji nasze zabawy będą zgrywane do pliku avi. Filter - ustawiamy filtr obrazu. W skrócie, jest to rozmycie obrazu pochodzącego z kości OCS/ECS i AGA, mało przydatne w grach. Disk Swapper - podmiana dyskietek "na gorąco", czyli możemy zmieniać dyskietki nie wyłączając emulatora. Priority - ustawiamy ile czasu procesora ma dostać emulator, lepiej zostawić jak jest. Artykuł został napisany w oparciu o WinUAE 1.0.0, jednakże większość opcji jest dostępna także w starszych wersjach tego programu. Program został przetestowany na pececie z procesorem Celeron 2GHz/1 GB RAM/Radeon 9000PRO/SB Live z systemem operacyjnym Windows XP Prof+SP1 i Windows XP prof+SP2. Życzę miłej zabawy z emulowaną Amigą. Do działania z emulatora wymagane jest posiadanie oryginalnych obrazów kickstartów.

Kurs języka C - część 8

20.02.2005 14:05

Witam w kolejnym odcinku kursu C. Dziś lepiej przyjrzymy się operatorom i wyrażeniom przypisania oraz wyrażeniom warunkowym. Napiszemy także prosty przykład pokazujący działanie kwalifikatora "const", który poznaliśmy w poprzednim odcinku kursu. CONST Spróbujmy może napisać prosty przykład: #include <stdio.h> main() { const int a = 5; printf("a=%d\n",a); a = a +10; printf("a=%d\n",a); return(0); } Na początku naszego programu deklarujemy zmienną "a" typu "int", która będzie stała ("const") i będzie miała wartość równą "5". Dalej funkcja "printf()" wypisze wartość zmiennej "a". W następnej linijce zmiennej "a" przypiszemy wartość "a+10", ale czy zmienna "a" nie była zadeklarowana jako stała ("const")? Dalej instrukcja "printf()" powinna wypisać nową wartość zmiennej "a", natomiast na końcu funkcja "exit()" zakończy działanie programu. Spróbujmy teraz skompilować nasz program. Oto co wypisze nam vbcc: Kompilator wykrył, że próbujemy przypisać zmiennej "a" (która ma być typu "const") jakąś wartość, co oczywiście jest operacją nieprawidłową. Podsumowując - każda zmienna, która została zadeklarowana z kwalifikatorem "const" nie może zmienić swojej wartości w dalszej części programu, a nawet przypadkowa zmiana tej wartości zostanie "wyłapana" przez kompilator. OPERATORY I WYRAŻENIA PRZYPISANIA Poznaliśmy już wyrażenia przypisania takie jak: a = a + 10; Zmienna która występuje po lewej stronie operatora jest zapisana jeszcze raz po stronie prawej, co można skrócić przez: a += 2; Operator += jest nazywany operatorem przypisania. Większość operatorów dwuargumentowych, czyli takich jak np. "+", może posiadać odpowiedni operator przypisania "op=", gdzie "op" jest jednym z operatorów: + - * / % lub operatorów bitowych (które poznamy później): << >> & | ^ Zatem ogólny schemat będzie wyglądał następująco: wyrażenie1 op= wyrażenie2; będzie równoważne z następującym wyrażeniem: wyrażenie1 = (wyrażenie1) op (wyrażenie2); Np. a *= a+3; będzie równoważne z: a = a * (a+3); Np. a -= a+12; będzie równoważne z: a = a - (a+12); Operatory wyrażenia mogą być przydatne przy bardziej skomplikowanych wyrażeniach, a nawet mogą pomóc kompilatorowi przy generowaniu bardziej efektywnego kodu. Dlatego warto przyzwyczaić się do takiego zapisu. WYRAŻENIA WARUNKOWE Przyjrzyjmy się programowi: #include <stdio.h> int pobierz(void); main() { int a,b; printf("Program sprawdza czy pobrana cyfra jest wieksza od zera:n"); a = pobierz(); if (a > 0) { printf("Cyfra %d,jest +\n",a); } else { printf("Cyfra %d,jest -\n",a); } return(0); } int pobierz(void) { char s[100]; int c,wynik; int i = 0; while((c = getchar()) != 'n') { if(isdigit(c) == 0 && c != '-') { printf("\nTo nie jest cyfra\n"); return(0); } s[i++] = c; } s[i] = '\0'; wynik = atoi(s); return wynik; } Zadaniem tego programu jest sprawdzenie czy podana przez użytkownika cyfra jest dodatnia czy ujemna oraz czy w ogóle jest cyfrą. Przeanalizujmy teraz kod naszego programu. Na początku pobierana jest z klawiatury cyfra, za pomocą znanej już funkcji "pobierz()". Dalej instrukcja "if" sprawdza czy spełniony jest warunek "(a>0)", czyli "a" większe od zera. Jeżeli rzeczywiście "a" jest większe od zera, to przy pomocy instrukcji "printf()" na ekranie wypisywany jest tekst, że cyfra jest dodatnia (+); jeżeli warunek nie jest prawdziwy, czyli "a" nie jest większe od zera, to na ekranie wypisywany jest tekst, że cyfra jest ujemna (-). Skupmy się na instrukcji "if", którą można zastąpić następującym wyrażeniem: [...] printf("Program sprawdza czy pobrana cyfra jest wieksza od zera:\n"); a = pobierz(); printf("Cyfra %d jest: %c\n",a,(a > 0) ? '+' :'-'); [...] Jest to wyrażenie warunkowe utworzone z trzyargumentowego operatora "? : ". Przyjrzyjmy się teraz prostszemu przykładowi. if(a > b) c = a; else c = b; Całe to wyrażenie spowoduje że zmienna "c", przyjmie wartość zmiennej o wyższej wartości ("a" lub "b"). Wyrażenie warunkowe daje nam możliwość zapisania tego w inny sposób: c = (a > b) ? a : b; Wyrażenie to jest równoznaczne z użyciem instrukcji "if" i "else". Tutaj najpierw oblicza się wyrażenie pierwsze (u nas "a > b"). Jeśli jego wartość będzie prawdziwa (czyli różna od zera), to oblicza się wyrażenie drugie (u nas zmienna "a") i jego wartość staje się wartością całego wyrażenia warunkowego. Jeżeli wartość wyrażenia pierwszego "a>b" będzie fałszywa (równa zero), to oblicza się wartość wyrażenia trzeciego (u nas zmienna "b") i to właśnie ono staje się wartością całego wyrażenia warunkowego. Czyli, jeżeli "a" rzeczywiście będzie większe od "b", to zmienna "c" przybierze wartość zmiennej "a", jeżeli natomiast zmienna "b" będzie większa od zmiennej "a", to zmienna "c" przybierze wartość zmiennej "b". Może to wydawać się trochę zawiłe, ale nie jest trudne. Teraz nic nie stoi na przeszkodzie żeby napisać sobie własną funkcję "max()", która będzie liczyła która ze zmiennych "a" i "b" jest większa: int max(int a,int b) { int c = 0; c = (a > b) ? a : b; return c; } Funkcji przekazujemy dwie wartości ("a" i "b"), zostaje zadeklarowana zmienna "c" typu "int" (integer). Następnie zmienna "c" przyjmuje wartość zmiennej, która jest wyższa od pozostałej. Zostało tutaj użyte wyrażenie warunkowe. Następnie funkcja "max()" poprzez "return" zwraca wartość zmiennej "c". Oczywiście funkcję "max()" można zapisać również przy użyciu "if" i "else": int max(int a,int b) { int c = 0; if(a > b) c = a; else c = b; return c; } Jak widać pierwsza wersja funkcji "max()" jest krótsza. Taki zapis daje nam bardziej zwięzły kod programu, ale czasem lepiej jest użyć instrukcji "if". Wybór należy już do osoby piszącej dany program. Obie wersje funkcji "max()" mają pewien minus, a mianowicie nie zinterpretują poprawnie sytuacji w której zmienna "a" będzie równa zmiennej "b". Spróbujcie dodać do funkcji obsługę takiego zdarzenia. Analogiczna sytuacja ma miejsce w programie wypisującym czy dana zmienna jest większa czy mniejsza od zera. Co stanie się jeżeli zmienna przyjmie wartość "0"? Wróćmy teraz do naszego wcześniejszego przykładu: printf("Cyfra %d jest: %c\n",a,(a > 0) ? '+' :'-'); Tutaj warunek wklejony jest wprost do instrukcji printf. Jeżeli zmienna "a" jest większa od zera, to zwracany jest jeden znak "+" (plus), a w przeciwnym wypadku "-" (minus). Funkcja "printf()" wypisuje ten znak poprzez deklaracje "%c", co oznacza jeden znak "char" (tekstowy). Jeśli elementy w wyrażeniu warunkowym miałyby inne typy (np: "float" i "int") to typ wyniku będzie przekształcony zgodnie z regułami przekształceń, np: "f" jest typu "float", "a" jest typu "int". (a > 0) ? f : a Tutaj wartość wyrażenia będzie typu float i nieważne jest to czy wartość "a" będzie dodatnia czy ujemna. Spróbujmy teraz napisać program obliczający mandat, jaki musi zapłacić osoba, która przekroczyła prędkość. Skorzystamy tutaj z następującej skali: A oto nasz program: #include <stdio.h> #define PREDKOSC1 60 #define PREDKOSC2 80 #define PREDKOSC3 100 #define PREDKOSC4 120 #define MANDAT1 100 #define MANDAT2 150 #define MANDAT3 200 int pobierz(void); main() { int predkosc,mandat; printf("Prosze podac predkosc: "); predkosc = pobierz(); if(predkosc < PREDKOSC1) { mandat = 0; } else if(predkosc < PREDKOSC2) { mandat = MANDAT1; } else if(predkosc < PREDKOSC3) { mandat = MANDAT2; } else if(predkosc < PREDKOSC4 || predkosc >= PREDKOSC4) { mandat = MANDAT3; } printf("Mandat za predkosc %d km,wyniesie %d zl\n",predkosc,mandat); return(0); } int pobierz(void) { char s[100]; int c,wynik; int i = 0; while((c = getchar()) != 'n') { if(isdigit(c) == 0 && c != '-') { printf("\nTo nie jest cyfra\n"); return(0); } s[i++] = c; } s[i] = '\0'; wynik = atoi(s); return wynik; } Skompilujmy teraz nasz program i spróbujmy go uruchomić. Na początku naszego przykładu występuje deklaracja kilku stałych symbolicznych ("#define"). Są tutaj zadeklarowane wartości prędkości ("PREDKOSC1", "PREDKOSC2", itd) oraz wysokości mandatów ("MANDAT1", "MANDAT2", itd). Dalej deklaracja znanej już nam z poprzednich odcinków funkcji "pobierz()", która będzie pobierać z klawiatury liczby całkowite ("int"). Przejdźmy do funkcji "main()". Na wstępie deklarujemy zmienne "mandat" i "predkosc" jako "int", następnie "printf()" zachęca nas do podania wartości prędkości: printf("Prosze podac predkosc: "); Dalej zmienna "predkosc" przyjmuje wartość zwróconą jej przez funkcję "pobierz()" i następuje ciąg instrukcji warunkowych "if". Kolejno zostaje sprawdzany warunek czy zmienna "predkosc" jest mniejsza od zadeklarowanych wcześniej stałych, np: if(predkosc < PREDKOSC1) { mandat = 0; } co oznacza że, jeżeli wartość zmiennej "predkość" jest mniejsza niż wartość stałej PREDKOSC1 (kierowca nie przekroczył 60 km), to wartość zmiennej "mandat" będzie wynosić zero (kierowca nie przekroczył prędkości, więc nie zapłaci mandatu). else if(predkosc < PREDKOSC2) { mandat = MANDAT1; } Jeżeli zmienna "predkosc" będzie mniejsza niż stała symboliczna "PREDKOSC2" to wartość zmiennej "mandat" będzie równa MANDAT1. W tym przypadku kierowca nie przekracza 80 km, ale z racji tego że poprzedni warunek został ominięty (nie był prawdziwy), to musiał on przekroczyć prędkość 60km. Czyli prędkość z jaką się poruszał, będzie się zawierać w przedziale 60-80km, czyli takiej prędkości odpowiada mandat 100 zł (MANDAT1). Jeżeli prędkośc z jaką poruszał się kierowca, będzie zawierać się w przedziale 100-120 km, to mandat będzie wynosił 200 zł, ale co jeśli kierowca będzie jechał np. 150 km? Nie dostanie mandatu wcale? Przyjmijmy że dostaje wtedy mandat w wysokości 200 zł Ma to odwzorowanie w naszej instrukcji warunkowej "else if" else if(predkosc < PREDKOSC4 || predkosc >= PREDKOSC4) { mandat = MANDAT3; } jeżeli wartość zmiennej "prędkość" będzie mniejsza, równa bądź większa niż stała symboliczna "PREDKOSC4" (120 km), to kierowca otrzyma mandat w wysokości "MANDAT3" (200 zł). Nasz program można napisać bez użycia stałych symbolicznych, ale z nimi jest on bardziej otwarty na przyszłe zmiany, np. jeśli wartości mandatów spadłyby, to trzeba by było zmienić wpisy tylko przy "#define", a nie szukać ich po kodzie programu. Gdyby natomiast użyć zmiennych (np: typu "int"), to program wymagałby więcej pamięci. OPERATORY BITOWE W języku C istnieje sześć operatorów, które pozwalają na manipulację bitami. Mogą one być stosowane jedynie do argumentów char, short, int, long, tak samo ze znakiem liczby, jak i bez znaku: & - bitowa koniunkcja (AND) | - bitowa alternatywa (OR) ^ - bitowa różnica arytmetyczna (XOR) << - przesunięcie w lewo >> - przesunięcie w prawo ~ - dopełnienie jedynkowe (operator jednoargumentowy) Być może ktoś z was spotkał się już z podobnymi operatorami np. w Amosie. Nie będe tutaj opisywał zasady działania każdego z operatorów gdyż chciałem tylko zasygnalizować ich występowanie w języku C. Można powiedzieć krótko że służą one do zasłaniania i ustawiania odpowiednich bitów. Pokaże tutaj tylko krótki przykład wykorzystania tych operatorów. UWAGA! Poniższy program będzie działał prawidłowo tylko na Classic Amidze. Nie będzie działał np. na Pegasosie, czy AOne. Program ten odwołuje się bezpośrednio do hardware`u Amigi, a mianowicie włącza i wyłącza filtr dolnoprzepustowy Amigi. Co to jest i do czego służy? Amigę wyposażono w filtr dolnoprzepustowy o częstotliwości granicznej rzędu 7 kHz. W wyniku tego wysokie częstotliwości dźwięku zostają obcięte. To w nich powstają szumy. Niestety filtr działa jednocześnie na czterech kanałach dźwiękowych co czyni dźwięk "przytłumionym". Włączenie filtru objawia się przyciemnieniem diody LED Amigi. filtr ten włącza się ustawiając bit #1 w rejestrze $bfe001. Oto przykład: #include <stdio.h> main() { int *led; led = 0xBFE001; printf("Naciśnij enter aby wyzerowac bit 1\n"); getchar(); *led = *led & 0x11111110; /* ************************************************** */ printf("Nacisnij enter aby ustawic bit 1\n"); getchar(); *led = *led | 0x00000001; /* ************************************************** */ printf("Koniec\n"); return(0); } Nie będe opisywał na razie co to są wskaźniki itd. Tym zajmiemy się w następnych odcinkach kursu. W programie podkreślone są linijki kodu w których zastosowano operatory bitowe, a mianowicie bitową koniunkcję (AND, u nas "&" oraz bitową alternatywę (OR, u nas "|"). Program czeka na naciśnięcie klawisza enter (funkcja "getchar()"), a następnie zeruje pierwszy bit adresu $bfe001. Proszę spojrzeć na diodę LED Amigi i zobaczyć co się stanie. Po ponownym nacisnięciu entera pierwszy bit zostaje ustawiony (zobacz diodę LED). Ten prosty programik prezentuje praktyczne wykorzystanie operatorów bitowych. Na razie nie będą nam one potrzebne i nie będziemy się nimi zajmować, ale na pewno do nich wrócimy i wtedy je szerzej opiszę. I to tyle na dzisiaj. W razie kłopotów proszę o kontakt.

Kurs języka C - część 6

20.02.2005 14:01

W poprzednim odcinku dowiedzieliśmy się jak budować swoje funkcje oraz napisaliśmy program który pobierał z klawiatury znaki. Dzisiaj napiszemy coś bardziej skomplikowanego. W poprzednim odcinku opisane było pobieranie znakow z klawiatury i przekształcanie ich na typ int, czyli na liczby dziesietne. Przyjrzyjmy sie teraz danemu przykładowi, aby przybliżyć sobie pisanie i wykorzystywanie własnych funkcji: #include <stdio.h> int pobierz(void); main() { printf("Podaj jakąs liczbę: "); printf("\nOto ta liczba:%d\n",pobierz()); return(0); } int pobierz(void) { char s[100]; int c,wynik; int i = 0; while((c = getchar()) != '\n') { if(isdigit(c) == 0 ) { printf("\nTo nie jest cyfra\n"); return(0); } s[i++] = c; } s[i] = '\0'; wynik = atoi(s); return wynik; } Na początku programu pojawia się deklaracja funkcji pobierz(), która ma zwracać wartość dziesiętną (int) i nie oczekuje żadnego argumentu (void). Następnie funkcja printf prosi o podanie dowolnej liczby, a później przenosi kursor do nowego wiersza "\n" i wywołuje funkcje pobierz, by następnie wypisać na ekranie wartość zwróconą przez pobierz(). Budowa funkcji pobierającej znaki z klawiatury i przekształcającej je na liczby dziesiętne była opisana w poprzednim odcinku. Warto tylko wspomnieć, że funkcja ma "filtr" sprawdzający czy aby na pewno zostały podane cyfry, a nie inne znaki. W poprzednim odcinku kursu napisany był program, który dodawał do siebie dwie liczby, a użyta tam była funkcja dodaj(): /* definicja funkcji */ int dodaj(int a,int b) { int suma; suma = a + b; return suma; } Warto wiedzieć, że w języku C wszystkie argumenty jakie będziemy przekazywać funkcji (tutaj int a, int b) są przekazywane przez wartość. Oznacza to, że funkcja nie będzie mogła zmienić bezpośrednio wartości zmiennej w funkcji wywołującej (zmiennej a lub b), a jedynie swoją prywatna kopię tej zmiennej. Dzięki temu takie argumenty mogą być traktowane jako zmienne lokalne (czyli takie które dziąłają tylko na terenie danej funkcji). W naszym przykładzie zmiana zmiennej a: /* definicja funkcji */ int dodaj(int a,int b) { int suma; a = 5; /* zmiana wartości a */ suma = a + b; return suma; } nie wpłynie na zmianę zmiennej a poza obrębem funkcji dodaj. Aby zmienić wartośc argumentów przekazywanych funkcji, można posłużyć się wskażnikami, ale poznamy je dopiero w następnych odcinkach... ZMIENNE ZEWNĘTRZNE Zmienne zadeklarowane w funcji main(), np: main() { int liczba; int zmienna; int zmienna2; } są zmiennymi, których wartości nie może zmienić żadna inna funkcja, ponieważ nie ma do nich bezpośredniego dostępu, gdyż są one zadeklarowane wewnątrz main(). Tak samo jest ze zmiennymi zadeklarowanymi w innych funkcjach np: zmienna suma w funkcji dodaj, którą napisaliśmy wyżej. Takie zmienne są zwane zmiennymi automatycznymi, gdyż powstają one wraz z ich zadeklarowaniem przez funkcje, a znikają po skończeniu danej funkcji. Jężeli wartość funkcji nie zostanie zadeklarowana, to zmienna ta będzie zawierać śmiecie: #include <stdio.h> main() { int zmienna; printf("Oto wartość zmiennej :%d\n",zmienna); return(0); } Program ten wypisuje wartość zadeklarowanej zmiennej. Można zobaczyć co będzie wypisane jeżeli nie będzie zadeklarowana wartość funkcji. Istnieje jeszcze inny typ zmiennych, zwanych zmiennymi zewnętrznymi. Zmienne te są przeciwieństwem zmiennych automatycznych, gdyż nie znikają wraz z zakończeniem działania funkcji, ale istnieją w programie przez cały czas. Zmienne zewnętrzne muszą być zadeklarowane na zewnątrz wszystkich funkcji: #include <stdio.h> void test(void); int zmienna = 5; main() { printf("Oto wartość zmiennej :%d\n",zmienna); printf("Wywołanie funkcji test\n"); test(); return(0); } void test(void) { printf("Oto wartość zmiennej: %d\n",zmienna); } Program ten demonstruje działanie zmiennych zewnętrznych. Na początku następuje deklaracja funkcji test oraz zmiennej "zmienna", której jednocześnie przypisywana jest wartość 5. W funkcji main() funkcja printf() wypisuje wartość zmiennej "zmienna", następnie informuje o wywołaniu funkcji test i następuje samo wywołanie. Funkcja test przy użyciu printf także wypisuje wartość zmiennej "zmienna". Jak widać dostęp do zmiennej mają wszystkie funkcje w programie. FUNKCJA SYSTEM Teraz poznamy bardzo prostą funkcję przy użyciu której możemy uruchamiać inne programy: #include <stdio.h> main() { system("C:dir c:"); return(0); } Działanie tej funkcji jest proste, funkcja ta wykonuje linijkę zawartą między nawiasami. Jej deklaracja jest następująca: int system(const char *) Funkcja przekazuje tekst zawarty w s (słowo const oznacza stały, tzn. że zmienna nie zmienia swojej wartości) jako polecenie do wykonywania przez interpretator poleceń (shell)...

CAM 9 - Roadshow, stos TCP/IP

18.02.2005 23:01

Oto "Roadshow" - nowy stos TCP/IP dla AmigaOS - autor: Olaf Barthel 1. Wprowadzenie 1.1 Boże narodzenie 2000 Co robiliście podczas tych dłużących się dni między wigilią a pierwszym dniem nowego, 2001 roku? Ja czytałem książkę Petera Bogdanovicha "This is Orson Welles" i zaczynałem pracę nad portowaniem stosu TCP/IP dla Amigi. Dlaczego? Jak zapewne pamiętacie, AmigaOS3.5 dostarczany był ze specjalną, ograniczoną wersją programu Holgera Kruse - Miami, posiadającego zintegrowany stos TCP/IP. Pełen stos TCP/IP został dołączony w AmigaOS3.9 pod postacią "AmiTCP Genesis". Jednakże, kwestia tego kto właściwie był właścicielem "AmiTCP" i czy mógł on zostać legalnie dołączony do AmigaOS3.9, doprowadziła do wielu komplikacji. W czasie, gdy zacząłem pracę nad moim małym projektem, trudno było powiedzieć czy jakikolwiek amigowy stos TCP/IP jest nadal dostępny do kupienia i/lub nadal jest rozwijany. Zaciekawiło mnie, jak trudne będzie przeportowanie stosu TCP/IP na Amigę. 1.2 Krótka historia amigowego sieciowania Po raz piewszy o stosie TCP/IP dla Amigi usłyszałem w roku 1990 podczas mojej rozmowy z miejscowym sprzedawcą Amig. Dostępny był wówczas w sklepach nowy produkt Commodore zwany A225, który reklamowano jako implementację stosu TCP/IP dla Amigi przy wykorzystaniu kart ethernetowych produkowanych przez Ameristar (które Commodore adaptowało jako kartę ethernetową A2065). Później dowiedziałem się, że ze strony Commodore była to próba wypełnienia luki wynikającej z potrzeb: karty ethernetowe były dostępne w sprzedaży przed pojawieniem się właściwego dla nich oprogramowania. Pierwszym oficjalnym, amigowym stosem TCP/IP był port kernela BSD UNIX wraz z zestawem narzędzi i nawet klientem systemu plików dla Sunowskiego NFS-a (Networked File System). Niemniej jednak oprogramowanie było bardzo "surowe". Pamiętam, że tylko kilka aplikacji wykorzystywało ten stos, a wśród nich była gra firmy Maxis, Inc. "Robosport". W grze kilku graczy mogło konkurować w rozgrywce po sieci. Celem było zniszczenie robotów przeciwnika. Przy wykorzystaniu opcji null modem można było grać "po sieci" przez kartę ethernetową A2065/Ameristar. To czego brakowało wówczas Amidze to standardowy sterownik, który mógł zostać wykorzystany do podłączenia dowolnego sprzętu "sieciowego". Sterownik ten przybył pod nazwą SANA (Standard Amiga Network Architecture). Będąc bardziej dokładnym, była to druga edycja tego standardu, znanego obecnie jako SANA-II. Premierę swoją miał w roku 1991, ale zajęło trochę czasu zanim przyjął się na dobre. Dla przykładu, w roku 1992 firma Oxxi wydała pakiet oprogramowania umożliwiający Amidze zintegrować się z sieciami Novellowymi. Amigowy klient tego oprogramowania pojawił się po opublikowaniu specyfikacji standardu SANA-II, jednak nie zawierał obsługi tego standardu i wymagał do pracy odrębnym sterowników. Wśród pierwszych produktów obsługujących standard SANA-II znajdował się Commodorowski "Envoy" - program z rodziny peer-to-peer i do obsługi drukarek sieciowych zarazem. Nadal nie istniał jednak stos TCP/IP, który obsługiwałby standard SANA-II. Ludzie pracujący nad Envoy'em, pracowali również nad ulepszoną wersją swojego oryginalnego portu stosu TCP/IP. Nazwali go "AS225R2" (można domniemywać, że S to skrót od "shared library" - współdzielona biblioteka). Nowy stos zaprojektowany był na podobieństwo współdzielonej biblioteki zwanej "socket.library", w której zaimplementowano API BSD UNIX (wówczas będące standardem). Niestety Commodore zdecydowało, że projekt rozwoju tego elementu zostaje zamknięty, a osoby nad nim pracujące zostały przeniesione do pracy nad innymi zadaniami. To zatrzymało rozwój zarówno Envoy jak i AS225R2. Ta decyzja sprawiła, że Amiga pozostała bez adekwatnego stosu TCP/IP. Sprawy nabrały innego obrotu w roku 1993 gdy pewien student z Uniwersytetu w Helsinkach stworzył pierwszy stos TCP/IP dla Amigi, który bił na głowę AS225R2. Narodził się AmiTCP. Podobnie jak AS225R2, korzystał z kernela BSD UNIX i z nim powiązanych narzędzi. Jednakże interfejs był zgoła odmienny. Oprogramowanie musiało być specjalnie zaadoptowane, aby mogło być obsługiwane lub móc obsługiwać AmiTCP. Zdecydowanie nie był to zamiennik AS225R2. Przez lata rosła konkurencja dla AS225R2 i AmiTCP. AS225R2 odrodziło się jako komercyjny produkt wydany przez Interworks. INet-225 i AmiTCP połączono i wydano pod nazwą jednego, komercyjnego produktu AmiTCP 4.0. Niektóre aplikacje obsługiwały interfejsy zarówno AS225R2 jak i AmiTCP, lecz w miarę upływu czasu coraz więcej oprogramowania obsługiwało tylko AmiTCP. W roku 1996 dwa kolejne stosy TCP/IP stały się dostępne dla Amigi: "TermiteTCP" spod szyldu Oregon Research oraz "Miami" autorstwa Holgera Kruse. Obydwa były kompatybilne z AmiTCP. Wkrótce Miami, a później MiamiDeluxe stały się standardowym interfejsem obsługi stosu TCP/IP. 1.3 Obecna sytuacja Podobnie jak kiedyś było ważnym i trudnym do osiągnięcia, aby Amiga posiadała dostęp do internetu, tak obecnie ważnym i niemożliwym do osiągnięcia jest kupno stosu TCP/IP, jak i karty ethernetowej przystosowanej do Amigi. AmiTCP nie można obecnie kupić, a autor Miami nie akceptuje nowych użytkowników zainteresowanych rejestracją ograniczonej wersji jego produktu. 2. Portowanie stosu TCP/IP dla Amigi 2.1 Ciekawość Byłem bardzo ciekawy jak trudnym byłoby przeportowanie stosu TCP/IP dla Amigi. Gdy zacząłem badać ten temat, mogłem przyjrzeć się ostatniej dostępnej za darmo wersji AmiTCP, tj. 3.0. Zanim stała się produktem komercyjnym, wypuszczono jej kod źródłowy na zasadach licencji GPL. To umocniło mnie w przekonaniu, że będzie to dobry punkt zaczepienia, gdyż wyjaśniało jak "od środka" działa interfejs. Niemniej jednak i tak musiałem zaczynać od szczątków. Kod AmiTCP oparty jest na BSD UNIX Net/2 z wykorzystaniem kernelu MACH, w który był zintegrowany. W 2000 roku kod ten liczył już sobie 10 lat. Pomyślałem, że można się lepiej postarać. Nie uznałem również za lojalne stworzenie komercyjnego produktu na bazie adaptacji kodu objętego licencją GPL. Wziąłem na warsztat ostatnią wersję 4.4BSD Unix i zacząłem wyciągać z tego kod. W projekcie AmiTCP można znaleźć zarówno funkcjonalność centralnego socketa I/O jak i funkcje dostępu do bazy danych (dla nazw usług i nazw domen). Musiałem to wyciągnać z kernela i współdzielonych bibliotek. Oddzielenie właściwego kodu było pierwszym krokiem przy portowaniu. 2.2 Pamięć i przerwania System operacyjny Amigi i typowy kernel Unixa nie mają nic wspólnego. AmigaOS możemy nazwać "mikrokernelem", w którym usługi takie jak przekazywanie wiadomości i dostarczenie sygnału łączą aplikacje i system operacyjny. W kernelu Unixa istnieje specjalny protokół dla aplikacji, który uzyskuje usługi kernela poprzez wymuszenie funkcji sieciowych. Wewnątrz kernela przerwania (kontrolowane przez warunki sprzętowe i programowe) kierują przetwarzaniem danych przychodzących i wychodzących. Portując stos TCP/IP oparty na Unixie należy zaadaptować kod kernela w architekturę AmigaOS. Dla przykładu, jeśli pakiet danych przybywa z sieci, na systemie Unixowym przerwania przejmują kontrolę powodując rozpoczęcie procesu przyjmowania danych. Na Amidze pakiet przybywa w formie wiadomości, która musi zostać przetworzona. W kernelu BSD UNIX, który próbowałem przeportować, można zauważyć, że hierarchia poziomu przerwań zarządza przetwarzaniem danych przychodzących i wychodzących. Ta poziomowa hierarchia działa niczym mechanizm arbitralny: jeśli ustawimy wyższy poziom przerwań, przerwania na niższych poziomach są blokowane do czasu gdy nie przestawimy ich na obsługę poziomu niższego. Mechanizm oddziela np. transmisję pakietów danych przychodzących/wychodzących od przetwarzania danych, które te pakiety zawierają. Cecha arbitrażowa jest podobna do funkcji Forbid/Permit z systemu operacyjnego Amigi, które są typowymi dla współdzielonych systemów operacyjnych lub Task resources. W rzeczywistości AmiTCP wykorzystuje Forbid/Permit do emulacji wielopoziomowej hierarchi przerwań kernela Unixowego. Kolejną własnością kernela BSD UNIX jest jego system zarządzania pamięcią. Dane TCP mogą zostać pofragmentowane, wysłane i otrzymane poza ustalonym porządkiem, z pominięciem niektórych sekcji, powielone lub ponownie wysłane. Musi być możliwe powtórne złożenie tych danych do ich oryginalnej postaci i właśnie tutaj do pracy przystępuje system zarządzania pamięcią. Prostym jest tasowanie i łączenie pofragmentowanych danych. Jednakże, aby zarządzać efektywnie pofragmentowaną pamięcią i aby możliwym było zwolnienie niewykorzystywanej pamięci w tym samym czasie należy wykorzystać element alokacji pamięci kernela Unixowego. Działa on na zasadzie alokowania bloków pamięci w "strony", które są przypisywane określonym adresom pamięci. Ta cecha nie istnieje w systemie operacyjnym Amigi i musi być emulowana. 2.3 Próba ognia Nad pierwszą wersją portu stosu TCP/IP pracowałem prawie dwa tygodnie. Polepszałem go pod względem prędkości i stabilności, lecz nadal występowały tajemnicze zawieszenia, których nie potrafiłem wyjaśnić. Zdarzało mu się jednak działać raczej stabilnie przez dłuższe okresy czasu, więc zdecydowałem się zabrać ten prototyp na coroczne spotkanie MeKa na uniwersytecie w Karlsruhe, które odbyło się na początku stycznia 2001 roku. Przywiozłem ze sobą moją A3000UX i monitor A2024. Żadnej karty graficznej ani monitora VGA. Fakt, wykorzystania tylko tego co posiada w sobie Amiga (układy specjalizowane) okazał się bardzo pomocny. Gdy testowałem prototyp stosu TCP/IP zauważyłem dziwne wzorki tworzące się na ekranie. Coś niczym wędrujące mrówki. Badając problem, którego wcześniej nie widziałem pracując na Picasso IV, zauważyłem, że system zarządzania pamięcią, który napisałem był błędny i powodował zaśmiecanie pamięci chip. Zajęło mi trochę czasu naprawienie tego problemu, lecz wydarzyło się wtedy coś, co stało się momentem zwrotnym tego małego projektu: ogólna stabilność wzrosła znacząco, a efektywność dosłownie osiągnęła swój szczyt. Niecały tydzień później mój port stosu TCP/IP przebił zarówno "AmiTCP Genesis" jak i "MiamiDeluxe". Przeszedł bojowe testy w mojej lokalnej sieci. Nadszedł czas, aby poważnie pomyśleć o przemianie tego stosu w komercyjny produkt. 3. Mówiąc poważnie 3.1 Zestaw cech MiamiDeluxe autorstwa Holgera Kruse ustanowiło standard funkcjonalności amigowego stosu TCP/IP. Stos TCP/IP musiał obsługiwać automatyczną konfigurację sieci przez DHCP (Dynamic Host Configuration Protocol), musiały istnieć sterowniki do połączenia dial-up (PPP) oraz do szerokopasmowego dostępu do internetu (PPPoE), firewall, filtr pakietów IP i obsługa NAT (Network Address Translation), obsługa lokalnych serwerów, zoptymalizowana implementacja protokołu SSL (Secure Socket Layer), a wszystko to musiało być osiągalne przez graficzny interfejs użytkownika. To bardzo dużo i wydaje mi się, że tylko MiamiDeluxe posiadało obsługę wszystkiego w jednym pakiecie. Siła przychodzi jednak z ceną: MiamiDeluxe to szczelny zintegrowany program, rozmiaru rzędu 500 kB plus dodatkowe narzędzia i sterowniki. Odkąd na mojej liście zadań do wykonania było kilka innych projektów, zdecydowałem się podejść do stosu TCP/IP w trochę mniejszym zakresie. Chciałem spróbować zapewnić obsługę tego co stanowi esencję amigowego stosu TCP/IP przy wykorzystaniu koncepcji modułowej. Chciałem również skoncentrować się na jądrze stosu i zostawić innym pracę nad projektowaniem graficznego interfejsu użytkownika. Od momentu gdy niektóre elementy zintegrowane w MiamiDeluxe stały się dostępne w osobnych pakietach (np. klient telnet/ssh, secure socket layer) napisanych przez tzw. third parties, postanowiłem, że nie będę ich sam pisał od nowa. Cechy, które narodziły się podczas etapu planowania, są następujące: kompatybilność z API "AmiTCP" 4.0 typowo amigowe narzędzia konfiguracji w odróżnieniu od trudnych w opanowaniu narzędzi Unixowych stos TCP/IP powinien być raczej pojedynczą współdzieloną biblioteką konfiguracja DHCP dla urządzeń ethernetowych; obsługa Zeroconf dla alokacji adresów Obsługa sterowników ethernet i PPP Pełna obsługa standardu SANA-IIR3, włącznie z dostępem DMA Obsługa Berkeley Packet Filter filtr pakietu IP i obsługa (NAT) obsługa urządzenia "TCP:" Rozszerzone API umożliwiające programistom posiadanie większej kontroli nad stosem TCP/IP, włącznie z możliwością monitorowania i filtrowania pakietów Integracja z systemem AmigaOS na etapie instalacji; pliki konfiguracyjne wędrują do DEVS:, nie wymagane jest przypisanie urządzenia "Roadshow:" "Prosta" konfiguracja: jedna, prosta komenda shell powoduje uruchomienie sieci; nie wymagane skomplikowane narzędzia konfiguracyjne Konfiguracja sterownika podobna do plików mountujących urządzenia występuje w Startup-Sequence. Rozszerzony i ulepszony zestaw oprogramowania dla programistów, która zawiera pełen kod źródłowy wszystkich narzędzi konfiguracyjnych i przykładowych programów. Zmiany w plikach konfiguracji globalnej są śledzone; uaktualnienia nastają zaraz po wykryciu zaistnienia modyfikacji Obsługa lokalnych serwerów Obsługa Multicast Pełna lokalizacja wszystkich narzędzi i komunikatów błędów Portowalność, umożliwiająca przebudowę na użytek pod PowerPC Mniej więcej z takim zestawem cech rozpocząłem pracę i w obecnej wersji nie brakuje żadnej z nich. Jako programista wiedziałem, że zestaw oprogramowania dla programistów i kontrola jaką ci powinni mieć nad wewnętrzną zasadą działania stosu powinna być najważniejsza. Produkty amigowe były w przeszłości bardzo użyteczne, właśnie przez to, że umożliwiały programistom ich rozbudowę na podstawie funkcjonalności jaką oferowały, a także pozwalały tworzyć nowe aplikacje o jakich oryginalni projektanci nawet nie śnili. Dla przykładu, rozszerzone API umożliwia napisanie własnego firewalla (jeżeli nie chcemy korzystać z tego wbudowanego). 3.2 Połączenie dial-up W miarę postępu prac nad stosem TCP/IP, który stawał się z dnia na dzień coraz bardziej użytecznym, zauważyłem, że było coś czego w nim brakowało. Modułowy stos TCP/IP nie zawierał wbudowanego sterownika dla połączeń przez protokół PPP. Wówczas istniały tylko trzy takie sterowniki dla Amigi: AmiPPP autorstwa Thomasa Bickela i dwie różne implementacje ppp.device autorstwa Holgera Kruse i Emmanuela Lesueur. Do żadnego z nich nie posiadałem praw na ich wykorzystanie. Z całą pewnością alternatywą było napisanie od podstaw własnego sterownika PPP. Okazało się to dla mnie wielkim wyzwaniem, biorąc pod uwagę fakt, że wszyscy próbowali adaptować lub portować istniejący Australian National University PPP daemon. Kod rozwijany był pod Unixem a środowisko amigowe niekoniecznie jest do niego adekwatne. Napisanie sterownika i przetestowanie go zajęło mi większość roku 2001. Gdy postanowiłem do mojego nowego mieszkania dociągnąć łącze ADSL, do projektu włączyłem również obsługę protokołu PPPoE, który jest usługą umożliwiającą zwijanie danych PPP do pakietów ethernetowych. Są również inne protokoły umożliwiające powyższe (np. PPPoA, PPTP i L2TP), ale trudno było mi je zaimplementować z powodu braku odpowiedniego sprzętu. Dużą przeszkodą było również skomplikowanie tych protokołów, w szczególności L2TP. Podczas prac nad sterownikiem PPP zauważyłem, że specyfikacja SANA-II nie zbyt dobrze precyzowała obsługę sterownika do połączeń dial-up. Gdy opracowywano specyfikację ten standard nie był jeszcze tak ważny. Typowy dostęp do sieci zapewniany był przez ethernet lub ArcNet, przy pomocy stałej konfiguracji. Dynamiczne adresy konfiguracji dokonywane przez sterowniki dial-up (PPP lub SLIP) były poza obszarem zainteresowań oryginalnego projektu. Istniejące sterowniki stosowały różne dziwne sposoby na konfigurację parametrów, jak i na komunikowanie się z aplikacjami. Dla przykładu, powszechne w użyciu było przechowywanie parametrów w zmiennych środowiskowych, które były odczytywane przez plik skryptowy. Plik skryptowy wykorzystywał narzędzia konfiguracji stosu TCP/IP do przetłumaczenia zawartości tych zmiennych na parametry interfejsu sieciowego. W tym momencie narodziła się czwarta edycja standardu SANA-II, który obsługują zarówno Roadshow jak i sterowniki PPP. Z uwagi na to, w jaki sposób sterownik PPP ewoluował, stosunkowo prostym było zaimplementowanie obsługi protokołu PPPoE. Jako dodatek, implementacja stała o jeden poziom wyżej od obecnie istniejących projektów. Podczas gdy niektóre sterowniki musiały odebrać i przepakować czyste pakiety PPP w formę PPPoE, mój sterownik PPPoE generuje i przetwarza pakiety PPPoE w locie, bez potrzeby przeprowadzania dodatkowej konwersji. Sterowniki PPP i PPPoE zostały zaprojektowane tak, aby współgrać z programem-wrapperem. Ten program wykonuje operacje połączenia i dokonuje konfiguracji sterownika, zespalając wszystko ze stosem TCP/IP. Podstawową cechą zestawu sterowników PPP jest porównywalność z innymi dostępnymi rozwiązaniami. Dla przykładu obsługiwana jest kompresja nagłówków Van Jacobsona jak również uwierzytelnienie MS-CHAPv1. Kompresja danych nie jest jednak wykonywana z powodów prawnych i ogólnej dostępności tejże cechy. Podobnie jak stos TCP/IP, sterowniki są portowalne, aby można je było przebudować na potrzeby PowerPC. 3.3 Składając wszystko razem Rdzeń pakietu składa się z następujących elementów: dwie współdzielone biblioteki (bsdsocket.library i usergroup.library) pliki konfiguracji dla potrzeb: routing, name resolution, usług internetowych i inetd-style superserver narzędzia konfiguracyjne i administracyjne stosu TCP/IP narzędzia konfiguracyjne i administracyjne filtru pakietów IP i NAT-u dwa sterowniki PPP (ppp-serial.device i ppp-ethernet.device) narzędzia do wykonywania połączeń i operacji uwierzytelniających niezbędnych to połączenia przy pomocy sterowników PPP To są podstawowe funkcjonalności objęte licencją. Napisano jednak dla AmigaOS4 wiele innych apliacji, które w znacznym stopniu rozszerzają podstawowe możliwości dostępne w głównym pakiecie. Dołączono również edytor ustawień stosu TCP/IP obejmujący kilka przykładowych plików konfiguracyjnych. Wersja podstawowego pakietu dla AmigaOS4 została przepisana pod PowerPC z bibliotekami i sterownikami pracującymi natywnie pod tym procesorem. 3.4 Jak to działa? Wyjątkowość Roadshow polega na tym, że próbuje wyłamać się z ustalonego tradycyjnego podejścia jakie zapewniało AmiTCP, polegającego na złożeniu całego stosu TCP/IP w jeden program, który konstruował centralną "bsdsocket.library" w pamięci. W rzeczywistości koniecznym było uruchomienie programu do możliwości pracy ze stosem TCP/IP. Stos był aktywny tak długo, jak długo działał program. W mojej implementacji zastosowałem sztuczkę wykorzystaną w AS225R2 i umieściłem wszystko w standardowych współdzielonych bibliotekach. Jak wejść "na sieć"? Dla pakietów takich jak Miami jest to stosunkowo proste: wybierasz właściwy interfejs sieci i wciskasz odpowiedni przycisk, który łączy się z właściwymi komponentami sieci, których nazwy i ich szczególne informacje przechowywane są w pliku konfiguracyjnym. W tradycyjnym podejściu Unixowym, musisz wywołać zestaw komend z poziomu shella, które konfigurują interfejs sieci i mogą wywołać inne programy, które negocjują adresy IP i przeprowadzają operacje uwierzytelniające. Kolejny program zostaje uruchomiony i stabilizuje połączenie i wszystkie ścieżki. AmiTCP wykorzystuje takie właśnie podejście. Roadshow to połączenie obu tych sposobów. Na początek trzeba poinformować stos TCP/IP o interfejsie sieci, a następnie możemy go ręcznie skonfigurować lub nakazać konfigurację automatyczną. Zasadniczo działa to podobnie do mountlist, które znajdują się w "DEVS:DOSDrivers" - zamiast plików konfigurujących systemy plików mamy pliki konfiguracyjne interfejsów sieci, których obecność wyłapywana jest w Startup-Sequence. Dla sterowników ethernetowych, interfejsy mogą być już skonfigurowane zaraz po ich zamountowaniu. Interfejs może wykorzystywać statyczne adresy lub może wykorzystać wbudowane DHCP, aby te adresy ustalić, znaleźć nazwę domeny serwera i ustabilizować połączenie (alternatywnie, lokalny adres IP może zostać przypisany przez protokół Zeroconf). Domyślne informacje na temat połączenia i nazwa domeny serwerów mogą być zmieniane w dwóch lokalnych plikach konfiguracyjnych (w przypadku gdy nie wybierzesz konfiguracji DHCP). Roadshow śledzi zmiany w tych plikach, tak więc możliwe jest przekonfigurowanie sieci w locie. Wszystko to dzieje się w momencie gdy system się uruchamia. Jedna linia w Startup-Sequence sprawi, że Amiga będzie w sieci. Tak właśnie z tego korzystam w pracy i w domu. Włączam Amigę, czekam na moment gdy pojawia się Workbench i już jestem w sieci, bez potrzeby uruchamiania innego programu czy wciskania jakichś przycisków. 3.5 Firewall Na potrzeby Roadshow zaadoptowałem pakiet "IP filter" autorstwa Darrena Reeda, który idealnie wpasował się w kod istniejącego stosu TCP/IP. Pakiet obsługuje zarówno podstawowe zasady filtrowania, maskaradę jak i tłumaczenie adresów sieciowych. Konfiguracja jest trochę skomplikowana, ale wszystko działa jak należy. Można wykorzystać Amigę jako firewall lub pozwolić jej na dzielenie połączenia PPP z innym komputerem w tej samej sieci. W rzeczywistości tak właśnie robiłem w domu, do czasu gdy nie założono u mnie połączenia ADSL. Roadshow posiada wbudowaną funkcjonalność umożliwiającą pisanie kodu, który będzie dokonywał filtrowania i przepisywał pakiety IP. Aby stworzyć własnego firewalla można wykorzystać te same punkty wejścia jak te we wbudowanych filtrze IP. Obsługiwane są również hooki odpowiedzialne za monitorowanie aplikacji, które próbują ustabilizować połączenia zewnętrzne. Monitorowane są również połączenia wewnętrzne. 4. Przyszłość Roadshow to moja pierwsza próba przeportowania stosu TCP/IP i napisania sterowników PPP. Było to bardzo cenne doświadczenie, które zrodziło coś pożytecznego: rozwiązanie na bazie którego można tworzyć aplikacje. Z całą pewnością stanowi kontrast do zintegrowanych pakietów stosu TCP/IP takich jak Miami, które są popularne do dzisiaj. Mówiąc prawdę, podczas gdy sterowniki PPP, obsługa DHCP i protokołu Zeroconf były pisane od początku, stos TCP/IP nie był. Pracę rozpocząłem na kodzie kernela BSD UNIX, który jest stosunkowo nowy w porównaniu do tego na bazie którego powstało AmiTCP. Jest jednak starszy od tego wykorzystywanego w nowoczesnych systemach operacyjnych BSD UNIX takich jak OpenBSD, NetBSD czy FreeBSD. Oznacza to na przykład, że IPv6 nie jest obsługiwane. Brak obsługi IPv6 to jedna z wad, którą mam nadzieję szybko usunąć przez przeportowanie bardziej nowoczesnego stosu TCP/IP. OpenBSD zdaje się być bardzo trafnym wyborem. Biorąc jednak pod uwagę, że zajęło mi prawie dwa lata przeportowanie kernela 4.4BSD-Lite2, nie mogę wiele obiecać, że pracę rozpoczną się niebawem. W międzyczasie mam nadzieję, że Roadshow spełni wasze oczekiwania. Dużo ciężkiej pracy zostało w niego włożone. P.S.: Skąd wzięła się dziwna nazwa "Roadshow"? Bezpośrednio z książki "This is Orson Welles", gdzie Welles stale powtarza, że "he would enjoy going on a roadshow again." Tłumaczenie na podstawie Club Amiga Monthly - Sebastian Rosa. Translated and reproduced by kind permission of Amiga Inc. Not for distribution beyond this site. Przetłumaczone i opracowane za zgodą Amiga.Inc. Dystrybucja wyłącznie na stronach PPA. Club Amiga logo concept and artwork by Mark Rickan & Mohamed Moujami, winners of the Club Amiga Logo Contest. Submitted text and images reproduced in Club Amiga Monthly are copyright by their respective authors. All other text and images reproduced in Club Amiga Monthly are copyright 2003 Amiga Inc. Content may not be reprinted or reproduced in part or in whole without express written consent of Amiga Inc.

AmiNetRadio3

13.02.2005 13:04

Czy lubisz słuchać radia w trakcie pracy czy zabawy na Amidze? Jeżeli tak, to powinieneś zapoznać się z obiektem badań, na którym skupiliśmy się w tej recenzji. Mowa będzie o AmiNetRadio. Wbrew pozorom nie ma to nic wspólnego z Aminetem, lecz stanowi pewnego rodzaju skrót od Amiga Network Radio i jest to program do odtwarzania strumieni Shoutcast. Strumienie Shoutcast to enkodowane "w locie" dane dźwiękowe, które możliwe są do pobrania z serwerów stacji radiowych na całym świecie. Niektóre z nich to prawdziwe stacje radiowe, do których możemy dostroić nasze klasyczne odbiorniki radiowe, lecz znaczna większość to wyłącznie tzw. radia internetowe, które nadają tylko na falach "światłowodów i kabli" i raczej nigdy nie zagoszczą w eterze. Amiga na polu oprogramowania przeznaczonego do tego celu, nie pozostaje w tyle. Istnieje wiele programów (większość już nierozwijanych) umożliwiających słuchanie radia internetowego, lecz pomimo tego, że spełniają powierzone im zadanie, nie są wyposażone w chociażby podstawowe elementy umożliwiające zarządzanie stacjami radiowymi, tudzież sprawiającymi, że słuchanie radia staje się trochę bardziej przyjemne. O stabilności większości z nich już nawet nie wspominając. Autorzy programu, panowie z #AmigaZeux, powinni być amigowcom dobrze znani. Bądź co bądź ich produkty (AmiTradeCenter, dynAMIte) należą do jedynych w swojej klasie i z całą pewnością można o nich powiedzieć, że są kawałkiem dobrego, amigowego rzemiosła. Oczywistym więc jest, że skoro zabrali się za program do streamingu, podejście do tematu od strony jakości musiało być identyczne. WYGLĄD Zaraz po uruchomieniu programu naszym oczom ukazuje się w zasadzie panel radia. Już w tym momencie warto zwrócić uwagę na pewien "bajer". Wygląd wszystkich guziczków, suwaczków i wszelkich innych widocznych elementów możemy dowolnie ustalić przez wybranie odpowiedniej "skórki" dla całego programu. W ten sposób sprawiamy, że program, mimo iż ten sam, u każdego może wyglądać inaczej. AmiNetRadio obsługuje wiele rodzajów skórek, w tym skórki z AmiNetRadio2 oraz z pecetowego WinAmpa. O ile w przypadku poprzednich wersji programu niektóre skórki, a konkretnie ich elementy, niektórym osobom, zwłaszcza korzystającym z wyższych rozdzielczości, mogły wydawać się za małe i program mógł tracić co nieco ze swojej funkcjonalności, o tyle wersja trzecia programu wyszła ku temu na przeciw. Autorzy stworzyli system nazwany ANRNG. Autorzy skórek tworzonych w tym środowisku mają pełną swobodę działania. Elementy mogą być rozmieszczane dowolnie. Wielkość i kształt także nie jest określony, więc jedynym ograniczeniem jest wyobraźnia. Co więcej, każdy rodzaj GUI można dodatkowo konfigurować tj. zmieniać rozmycie dla equalizera, ustawiać efekty które rozjaśniają GUI po kliknięciu na nie lub reagują na położenie kursora myszy (to tylko w MorphOS 1.5). Generalnie możliwości są ogromne. Należy jeszcze dodać, że oskórowane jest tylko okno główne. Reszta programu, czyli lista, wyszukiwarka stacji jest po prostu w MUI. Czas zająć się tym co najważniejsze - czyli uruchomieniem i słuchaniem radia, chociaż może najpierw warto przez moment przyjrzeć się ustawieniom. USTAWIENIA Podzielone są one na sześć części: Players, GUI, Audio, Shoutsearch, Playlists oraz Hotkeys. W pierwszej zakładce konfiguruje się dekodery. W zależności od formatu ustawia się częstotliwość i jakość dla mp3 i shoutcast, filtr dla modułów, device i unit naszczego cd-romu w przypadku CDDA i wiele innych mniejszych rzeczy. O GUI wspomnieliśmy w poprzednim akapicie. Warto jednak tylko dodać, że podobnie jak dekodery ustawienia GUI również są podzielone na kilka podmenu. W zakładce Audio ustawia się rozmiar bufora (aby nie było przerw w odsłuchu podczas np. operacji dyskowych (to na słabszych maszynach)) oraz tryb AHI. Shoutsearch to w zasadzie tylko adres serwera proxy dla wyszukiwarki radia. Kolejną zakładką jest Playlists. Jak sama nazwa wskazuje ustawia się tam wszystko co dotyczy listy utworów. Ostatnią zakładką jest Hotkeys. Można tutaj zdefiniować skróty klawiszowe do praktycznie każdej części programu. Przydaje się to w szczególności gdy używamy skórek z ANRv2, które nie posiadają przycisku pauzy. Zabawa z ustawieniami programu może dostarczyć niemalże tyle samo rozrywki co sam odsłuch i może do niego już przejdźmy. NIECH ZABRZMIĄ DŹWIĘKI Na początek należałoby wybrać stację radiową. Wbrew pozorom nie trzeba "googlać" w celu poszukiwania adresów. AmiNetRadio sam wyszukuje strumieni shoutcast. Grupuje je w zależności od rodzaju granej przez stację muzyki. Dodatkowo każda z pozycji posiada własny opis, zazwyczaj hasło radiowe oraz nazwę aktualnie nadawanej piosenki. Wyszukiwarka, z której możemy skorzystać umożliwia wyszukiwanie w każdej ze wspomnianych kategorii, a także wyszukiwanie pod kątem bitrate w jakim nadawany jest strumień. Ta ostatnia opcja pozwala dostosować "fale radiowe" do prędkości naszego połączenia z internetem, a i nawet sprzętu. Niektóre stacje radiowe posiadają kilka serwerów zebranych w klastry, które umożliwiają nasłuch dla większej ilości słuchaczy. AmiNetRadio również obsługuje tę możliwość. GDY GRA I BUCZY Gdy już z głośników dobiegają do nas jakieś dźwięki, zabawa z programem i jego opcjami może trwać dalej. Program wyświetla wszelkie informacje na temat stacji radiowej (nazwa, rodzaj granej muzyki, hasło radiowe, nazwa granej aktualnie piosenki). Po kliknięciu na nazwę stacji radiowej otworzy się jej domowa witryna internetowa (obsługa przez OpenURL). Na temat odtwarzanej piosenki program również "powie" nam trochę ciekawego: bitrate, stereo/mono, czas utworu. Wszystko to jednak są suche informacje. Bardziej ciekawe jest to, w jaki sposób są prezentowane. Występują tutaj wszelkiego rodzaju efekty takie jak zoom, blur. Graficzne przedstawienie muzyki w oknie programu może działać w siedmiu różnych trybach. Dodatkowo AmiNetRadio posiada osobne pluginy do wizualizacji odgrywanej muzyki. Działają także pluginy z programów Amplifier i AmigAMP. AmiNetRadio potrafi zapisać w formacie MP3 aktualnie "nadawany" strumień dźwiękowy. Program można tak skonfigurować, aby automatycznie cały czas zapisywał dobiegające do nas dźwięki czy też zapisywał poszczególne utwory do osobnych plików. Dodatkowym atutem ANR jest możliwość odtwarzania zwykłych plików MP3, Ogg, modułów w formacie ProTrackera, AHX, Soundmon, które posiadamy na dysku czy płycie. Skoro mowa o płycie to dochodzi jeszcze możliwość odtwarzania ścieżek audio z płyt. Grzechem byłoby nie omówienie bardziej szczegółowo listy utworów. Jest ona dość wyjątkowa ze względu na to, że składa się z dwóch paneli. Po lewej tworzone są katalogi, w których znajdują się stacje radiowe czy też pliki muzyczne. Dodatkowo można je grupować za pomocą belek tak, aby całość była czytelna. Jedynym mankamentem listy jest to, że zawsze sortowana jest według widzimisię programu i nie można zapisać własnego ustawienia. Ta rzecz ma miejsce tylko po stronie prawej, czyli zawartości katalogów. Utworzona lista utworów może zostać zapisana na dysk i uruchomiona w dowolnym momencie, jak również na starcie programu. Nie warto chyba wspominać o tak oczywistych opcjach jak możliwość powtarzania utworu, przewijania go, losowego odtwarzania utworów z playlisty, a także następnego i poprzedniego. COŚ JESZCZE? Jak wiadomo, dobry program nie byłby wystarczająco dobry, gdyby nie posiadał stosownej dokumentacji. Z uwagi na to, że AmiNetRadio jest programem freeware można co najwyżej liczyć na dokumentację elektroniczną. Przygotowana jest ona w formacie amigaguide i prezentuje się naprawdę bardzo dobrze. Znajdziemy w niej praktycznie wszystko - począwszy od wprowadzenia, przez obsługę, konfigurację, aż po opis rozwiązań najczęściej pojawiających się problemów. Cała dokumentacja napisana jest żartobliwym tonem sprawiając, że czyta się ją z naprawdę ogromną przyjemnością. Jak na razie dostępna jest wyłącznie w języku angielskim. Może kiedyś doczekamy się wersji polskiej. ZŁE WIADOMOŚCI Przygoda z AmiNetRadio staje się tym bardziej sensowna, im bardziej sensowna jest nasza konfiguracja, zarówno ta dotycząca samego sprzętu, jak i połączenia z internetem. Aby móc osiągnąć absolutne minimum "odsłuchu" należy posiadać co najmniej dobre połączenie modemowe 56k. Niestety jakość nie będzie wówczas zbyt wysoka, a i odetniemy się praktycznie całkowicie od wszelkich innych czynności "sieciowych", które chcielibyśmy wykonać w tym samym czasie. Od strony sprzętowej także należy liczyć się z pewnymi problemami. Program korzysta z mpega.library. Teoretycznie 040 wystarczy, aby posłuchać radia, niemniej nie jest tajemnicą, że wówczas praktycznie niemożliwa staje się normalna praca na komputerze bez wyraźnie zaznaczającego się dyskomfortu (no chyba, że ktoś wykorzystuje komputer jako maszynę do pisania). Zalecane więc jest posiadanie PPC, które zajmie się dekodowaniem przybyłego po kablach strumienia. Autorzy rozwijają program na Pegasosach z systemem MorphOS 1.4 i zalecają właśnie taką konfigurację. Niemniej program działa także na AmigaOne i klasycznych Amigach. Warto jednak mieć na uwadze, co autorzy również wyraźnie zaznaczają w dokumentacji, że nowsze wersje nie są testowane na niczym innym niż Pegasos. Należy się liczyć z tym, że któraś z nowszych wersji może nie zadziałać lub mogą pojawiać się drobne błędy, jak np. już zauważone niektóre elementy GUI, które są niepoprawnie wyświetlane na systemach innych niż MorphOS ("dziurawe" okna). Wówczas należy cofnąć się do starszej wersji. Duża krecha dla programu należy się także za włażenie w nieswoją pamieć. Dzieje się to sporadycznie, ale fakt pozostaje faktem. Prawdopodobnie dlatego ANR czasem przestaje grać i pomaga tylko reset. DOBRE WIADOMOŚCI Szczerze powiedziawszy, AmiNetRadio jest jednym z lepiej dopracowanych programów. Za wyjątkiem tych wspomnianych, ciężko doszukać się w nim jakichś szczególnie drażniących uchybień. Kiedyś z zazdrością patrzyliśmy na pecetowe odtwarzacze, lecz teraz naprawdę nie ma czego się wstydzić, a nawet są powody do dumy. Matthias "UltraGelb" Bocker i cała reszta chłopaków z #AmigaZeux włożyli naprawdę dużo pracy w ten program. Posiadając dostęp do tak ogromnej ilości internetowych stacji, nawet najgorszy muzyczny malkontent znajdzie coś dla siebie. Wiadomo jednak, iż nic nie jest za darmo. Pomimo, że program jest darmowy, są pewne inne warunki, które należy spełnić, aby móc nim się cieszyć. Mowa o konfiguracji sprzętowej i połączenia internetowego, o której wspomnieliśmy w poprzednim akapicie. NA KONIEC Mała rada dla posiadaczy Pegasosa 1. Czasem można zauważyć zarywanie dźwięku, które na maszynie takiej klasy nie powinno mieć miejsca. Jest na to oczywiście rada. Należy w tooltype'ach ikonki ustawić priorytet dekodera na 20 (DECODERPRI=20) i w preferencjach programu, w zakładce Players/mpega.player/Read Mode ustawić Ram/Load All. Proszę się nie przerażać ładowaniem mp3 do RAM-u. Trwa to ułamek sekundy, a zarywanie nigdy więcej nie powróci. Archiwum z programem można znaleźć na stronie http://anr.amigazeux.net. Więcej na temat strumieni Shoutcast znajdziemy na stronach http://www.shoutcast.com/ oraz http://www.shoutcast.prv.pl/.

Packet Radio - część 3

08.02.2005 16:53

Funkcje AmiComa Tym razem zajmiemy się funkcjami AmiComa, których nie opisałem w poprzednim odcinku. Zaczniemy od komend TNC. Od razu wyjaśniam, że wszystkie komendy kierowane do TNC czy baycommodemu zaczynają się od przyciśnięcia klawisza ESC w nowej linii okna TX. Znaczenie podstawowych komend: » c - połączy z wybraną stacją (bramka, węzeł, bbs, etc.) Połączenie można realizować na dwa sposoby, wybrać funkcję Connect... z menu Function i wpisać znak węzła lub z linii poleceń w oknie TX. Pierwsze rozwiązanie jest proste i oczywiste. Drugie wygodniejsze choćby dlatego iż dużo szybsze. Na przykład, chcę połączyć się z moim lokalnym węzłem SR9ZDN który znajduje się w Tychach. Od nowej linii raz naciskam ESC pojawi się znak: "»" Dalej piszę "c", znak węzła "sr9zdn" i return, czyli: "» c sr9zdn" W oknie monitora pojawią się informacje o próbie połączenia (SABM+). Jeżeli sprzęt działa jak należy i dobrze skonfigurowałeś AmiComa a węzeł w zasięgu, połączenie prawie gwarantowane. Po połączeniu, węzeł wita tekstem powitalnym który czasem zawiera ciekawe informacje. » d - natychmiastowe rozłączenie. » pac (rozmiar) - rozmiar pojedynczej ramki, zakres 16-256. Wartość ta jest ustalona na stałe w pliku "konfig.ac". Jednak można ją modyfikować w trakcie połączenia. Dzięki temu istnieje możliwość ustalenia dokładnie jaki ma być rozmiar ramki. Przed pierwszym połączeniem (najlepiej z bbsem), ustaw minimalny rozmiar czyli 16. Teraz zaadresuj wiadomość do siebie, sposób w jaki to należy zrobić zawiera help bbsa, który otrzymasz po komendzie "h". BBS-ów jest wiele i wiele jest odmian oprogramowania które na nich pracuje, opisanie wszystkich metod wysyłania, odbierania, przeglądania wiadomości czy listów jest niewykonalne. Opiszę tylko jeden najpopularniejszy sposób, działający prawie wszędzie. Zaadresowanie listu prywatnego wygląda tak: sp sq9hyq @ sr9zdn.ka.pol.eu (tytuł:) to tytuł (treść) tutaj treść a na końcu /ex "SP" wysłanie listu prywatnego, do osoby o znaku "sq9hyq" (to ja) która posiada skrzynkę na bbsie sr9zdn.ka.pol.eu. "/ex" zakończenie, jest to równoznaczne z wysłaniem wiadomości. Przy okazji wyjaśnię jak wysłać biuletyn: sb amiga @ pol (temat) (treść biuletynu) /EX "SB" to skrót od Send Bulletin, oznacza że wysyłasz biuletyn który może przeczytać każdy. "amiga" to dział tematyczny, dyskusji prowadzi się wiele na różne tematy, jednych interesuje UFO drugich Amiga. Dzięki podziałowi można ustawić sobie filtr wiadomości, który wyświetli tylko te które nas interesują. To pozwala zaoszczędzić czas na przeszukiwanie wielu kilobajtów tekstu. "@pol" dla polaków, taki list nie wyjdzie poza granice kraju, zostanie rozesłany po wszystkich polskich BBSach. Można zaadresować @ww czy @eu, wtedy wskazane jest aby biuletyn był w języku angielskim. Chyba nie trzeba wyjaśniać dlaczego. (temat) to temat. (treść..) piszesz od ręki lub wysyłasz wcześniej przygotowany tekst, za pomocą funkcji File->Send File-> Text, pojawi się requester gdzie wybierasz plik i OK. Kiedy prześlesz wszystko co chciałeś, w nowej linii napisz "/EX" zakończenie, jest to równoznaczne z wysłaniem biuletynu. Myślę że wszystko jest jasne, żadnej w tym filozofii nie ma. Wracamy do parametru "pac". Kiedy już zaadresujesz list, poszukaj pliku tekstowego wielkości około 10 kB który wyślesz do siebie. Nie zastanawiaj się co mi chodzi po głowie, zaufaj mi i czyń co piszę. Wyślij przez (menu) File->Send File-> Text. W oknie RX pojawi się tekst koloru białego. W tym momencie uważnie obserwuj ramki które wysyłasz np.: fm SQ9HYQ to SR9DKA ctl I72^ pid F0 any new software on Packet Radio fm SQ9HYQ to SR9DKA ctl I73^ pid F0 for Amiga? i te którymi BBS potwierdza twoje np.: fm SQ9HYQ to SR9DKA ctl RR7- fm SQ9HYQ to SR9DKA ctl REJ7- Jeżeli BBS potwierdza ramki jedna po drugiej, tekst idzie bez dłuższych przestojów, możesz zwiększyć parametr "pac" do 32, czyli piszesz: "» pac 32. Jeżeli BBS nadal dobrze odbiera dane, nie ma powtórek (REJx-), możesz dalej zwiększać parametr. Może zaistnieć sytuacja że ustawisz maksymalną wielkość 256 a BBS dalej świetnie będzie odbierał. Wtedy należy cieszyć się, masz wspaniałe połączenie. Ale kiedy BBS zaczyna potwierdzać twoje ramki prośbą o powtórzenie, wtedy należy wrócić do przedostatniej wartości i na stałe wpisać ją w konfig.ac. Po ustawieniu "pac" możesz skasować list który wysłałeś sam do siebie. » max (ilość) - ilość ramek wysłanych za jednym razem, zakres 1-7. Parametr ten już jest ustawiony w pliku konfig.ac, jednak czasem zachodzi konieczność aby zwiększyć/zmniejszyć ilość przesyłanych ramek naraz. Proponuję abyś poeksperymentował trochę, zobaczysz w czym rzecz. » t (wielkość) - czas opóźnienia (txdelay) od momentu włączenia nadawania do modulowania paczek z danymi. Wielkość tą zmieniasz wtedy kiedy, węzeł poinformuje cię że twój txdelay jest za długi (***txdelay to loong!) i rozłączy cię. Wtedy zmniejszasz wartość o 2 i próbujesz ponownie i tak aż do skutku. Kiedy już węzeł nie będzie miał zastrzeżeń a połączenie będzie utrzymane, końcową wartość parametru txdelay ustaw w konfig.ac. Może zaistnieć sytuacja że txdelay będzie za krótki, objawy są takie że ty wołasz a węzeł nie odpowiada pomimo że poziom twojego sygnału będzie wysoki. Prawdopodobnie twoje lub węzła radio ma dłuższy czas reakcji na "zadziałanie" niż ustawiony txdelay. Wtedy wydłużaj txdelay co 4. » i (znak) - zmienia aktualny znak użytkownika na inny. Czasem przydaje się kiedy odwiedzi cię ktoś kto również ma licencję krótkofalarską minimum drugiego stopnia, nie ma w domu dostępu do PR a chciałby pobiegać sobie po sieci. Po ponownym uruchomieniu AmiComa, twój znak z powrotem wróci na każdy port. Jeśli zapamiętasz powyższe komendy, wszystko stanie się prostsze. Na zakończenie tego etapu kilka rad. BBS-y to stacje które mają w swoim znaku "-8", mój HOME BBS to SR9ZDN-8. Przy pierwszym połączeniu z BBSem, zazwyczaj zanim będziesz mógł wysyłać biuletyn, maile itp. BBS zapyta cię o kilka istotnych danych, które należy podać zgodnie z prawdą. Bramki internetowe najczęściej mają na końcu znaku "-10" np.: SR9ZAA-10. Teraz kiedy już umiesz wysyłać listy i biuletyny, czas abyś nauczył się odbierać i wysyłać Dane Binarne czyli pliki graficzne, dźwiękowe, archiwa itd. Dla przykładu ściągnę jakiś plik z dysku BBSa sr9zdn-8. Tradycyjnie wpierw należy połączyć się, po ramce powitalnej naciskam "d" i enter. Jestem na dysku, poruszam się po nim tak samo jak na PC'towym DOSie, help dostępny po "?" lub "h". Ściągnę plik C:PICTURESSQ9OT1.JPG. Z menu AmiComa wybieram File->Read File-> Auto w requesterze wybieram katalog w którym ma się nagrać plik i wpisuję nazwę pliku taką samą jaka widnieje na dysku BBS-a. Na dolnej belce programu pojawi się RA <nazwa pliku> 0 - to znaczy że AmiCom jest gotów do odbierania danych. Piszę "bget (nazwa pliku)" czyli "bget sq1ot1.jpg" i enter. Pozostaje tylko czekać aż wszystko przejdzie. Wysyłanie jest bardzo podobne. Na dysku BBSa piszesz "bput (nazwa pliku)" i enter. Później z menu programu File->Send File-7gt; Auto, pojawi się requester w którym wybierasz plik który chcesz wysłać i OK. BBS-a mamy z głowy, ale jak przesłać dane binarne np. kumplowi? Nic prostszego, dla przykładu połączę się z kolegą Marcinem SQ7GDB, który mieszka w Łodzi (JO91RR) i prześlę mu plik Autobinem. Po połączeniu z Marcinem, piszę //WA czyli np.: //WA plik.lha i enter. W odpowiedzi dostałem coś takiego; (AC): Ready for automode-filetransfer. tzn. że program Marcina jest gotowy do odbioru danych w trybie Autobin. Z menu AmiComa File->Send File wybieram Auto, w requesterze wybieram plik.lha i OK. Teraz pozostaje mi tylko czekać aż całość przejdzie przez sieć Packet Radio i wyląduje na dysku Marcina. Proste? Jasne że tak! Teraz nauczysz się wysyłać dane binarne w postaci poczty prywatnej, ale zanim to się stanie, najpierw musisz nauczyć się obsługiwać program 7+. To koder/dekoder podobny w działaniu do programu UUencode z Internetu. Nie będę cię drogi czytelniku zanudzał opisem wszystkich dostępnych komend programu. Skupimy się jedynie na przygotowaniu 7plusa do codziennego użytku. Jestem pewien że na codzień korzystasz z jakiegoś File Menagera. Odkąd DOpus4.14 jest darmowy a Jacek Rzeuski dalej rozwija ten wspaniały program, razem przygotujemy w nim specjalny przycisk z programem 7+, który będzie przygotowywał dane binarne do wysyłki jako poczta prywatna lub biuletyn na BBSa. A więc skopiuj opowiedni dla twojego procesora plik 7plus_xxx który znajduje się w tym archiwum do C:, zmień nazwę pliku na "7plus" i uruchom DOpusa. Z menu Project wybierz Configure. Kliknij na Buttons i wybierz jakiś pusty przycisk. W oknie "Button edit screen" odszukaj pole tekstowe "Name" i wpisz obok "7+". Kliknij na New entry, następnie klikając na przycisk Command ustaw "AmigaDOS", obok w polu tekstowym napisz "C:7plus -p -sb 11000" i enter. Flagi: CD source, Output window i Rescan source. Kliknij na OK i Save. W DOpusie wybierz sobie jakiś plik binarny np. jakieś archiwum.lha. Zaznacz i kliknij na przycisk 7+ który utworzyłeś. Po chwili zobaczysz zakodowany jeden plik o nazwie takiej samej jak archiwum z rozszerzeniem .7pl ale jeżeli plik jest dłuższy niż 11000 zostanie on podzielony na części o nazwie archiwum.p01, ..p02, ..p03 itd. Kiedy będziesz ściągał jakieś dane z BBSa zakodowane programem 7+ zostaną one zapisane w katalogu "BIN" AmiComa. Będą w postaci ASCII. Aby zamienić je na postać zjadliwą dla komputera czyli zdekodować, zaznacz plik.7pl lub pierwszą część (...p01) wieloczęściowego np. archiwum.p01 i kliknij na przycisk 7+. Program poskłada wszystko w całość i zamieni na gotowy plik. 7+ ma pewne ograniczenia, może dzielić pliki o dużych rozmiarach max. na 255 części o zdefiniowanym rozmiarze. Może się zdażyć że wielkość pliku który chcesz przepchnąć kumplowi na skrzynkę przekroczy możliwości 7plusa, musisz wtedy zdefiniować większy rozmiar cięcia niż 11000, który wcześniej ustawiliśmy. Ale i tu jest ograniczenie, więc nie przesadzaj. Wróćmy do wysyłania danych 7+. Teraz kiedy już wiesz jak przygotować dane, czas w końcu je wysłać. Adresujesz list, w tytule wpisz nazwę "pliku" 7+, dalej w treści możesz wstępnie napisać kilka słów do adresata co to jest, następnie z menu AmiComa File->Send File wybierz "7plus". W requesterze kliknij na plik.7pl, jeżeli jest więcej plików .p01... p02... itd. zacznij od pierwszego .p01 i OK. Czekasz, aż przejdzie i gotowe lub wysyłasz kolejny kawałek adresując nowy list. Ufff... komendy TNC, wysyłanie i odbieranie danych mamy z głowy. Czas zająć się pozostałymi funkcjami AmiComa nie opisanymi w poprzednich częściach. Funkcja Undo (Function->Undo) służy do powrotu do poprzedniego znaku jaki rozpoznał AC przy połączeniu. Może prościej na przykładzie, jesteś połączony z lokalnym węzłem np. sr9zdn, dajesz rozkaz M po którym łączysz się z BBSem, na ekranie pojawia się napis "*** connected to SR9ZDN" to tekst po którym AC rozpoznaje znak połączonej stacji. Niestety taki tekst lub "*** reconnected to SR9ZDN" może wystąpić np. w jakimś biuletynie który ściągasz z BBSa. Wtedy AC głupieje, myśli że połączył się z kolejną stacją i zmienia znak wyświetlany na górnej belce okna TX (port) na znak który był zawarty w odbieranym tekście. W tym momencie przydaje się funkcja Undo, która cofa o znak wstecz wyświetlany na aktywnym porcie. Funkcję Clipboard (Function->Clipboard->...) która niezałapała się na opis w poprzednim odcinku. Clipboard inaczej Schowek chyba wszyscy wiedzą do czego służy. Przechodzimy więc odrazu do przykładu jak wyciąć interesujący kawałek tekstu z okna RX. Przyciśnij RAmiga+l (prawy klawisz "Amiga" + "l") lub wybierz z menu, funkcję "Function->Clipboard-> Mark Block". Na listwie MH (na samym dole) pojawi się napis *** STOP *** MARK BLOCK *** w oknie RX za pomocną myszki zaznaczasz text który chcesz skopiować do schowka, raz kliknij myszką na początku następnie dwa razy na końcu tekstu. Przez moment tekst podświetli się na niebiesko po czym wszystko wróci do normy ale! na listwie RX (środkowa) pojawi się litera "L". Tekst który umieściłeś w "schowku" można wysłać przez "File->Send Clipboard" lub nagrać na dysk "Function->Clipboard-> Save...". Można też wydrukować "Print" lub skasować "Clear" wtedy "L" znika. Kolej na funkcję "BoxCheck". Aby spełniała swoje zadanie, BBS z którego korzystasz musi zezwalać na korzystanie z funkcji Boxcheck. Zapytaj o to operatora twojego BBS-a. Przykład dla BBS-ów z FBB: Wylistuj pocztę np. L 48700-48710, wylistuje 10 maili z przedziału od 48700 do 48710. Następnie przyciśnij klawisze prawy Amiga + B lub wybierz z menu funkcję Function->BoxCheck-> Boxcheck Show. Zamiast okna RX pojawi się okno z listą wiadomości. Myszką zaznacz biuletyny, które chcesz przeczytać, następnie naciśnij klawisz R - AmiCom sam wyśle żądanie przeczytania wiadomości, które zaznaczyłeś. Dzięki funkcji "Boxcheck" nie trzeba ręcznie wklepywać numeru wiadomości która nas interesuje np. r 48700. I tak dotarliśmy do ostatniej funkcji "Standardtext" która zamyka serial o AmiComie. Funkcja ta służy do podwieszania pod klawisze różne teksty np. podpisy, gotowe zestawy komend (po co klepać jedno i to samo w kółko) jakieś dodatkowe informacje. Wszystko co napiszesz w text.ac będzie wysłane po przyciśnięciu odpowiedniego klawisza. Po wywołaniu funkcji z menu na samej górze pojawi się tekst "Standard-text: Press A-Z" teraz naciśnij klawisz C, I, N, P lub Q zostanie wyświetlone to co zostało umieszczone pod nimi tj. w pliku text.ac który został omówiony w poprzednich odcinkach. Na tej samej zasadzie możesz cokolwiek przypisać pod resztę klawiszy. Dla przykładu stworzę pod klawiszem "B" swój podpis którym podpisze się pod listem do kumpla Marcina SQ7GDB :) A więc, tworząc nową komendę pod klawiszem "B" robię tak. Na końcu pliku text.ac za konfiguracją komendy #quit, za tekstem od nowej linii piszę; #B _ //Pozdrawiam Vy73! od Darka - Do spotkania na WW /ch 4000 _ //AX.25 : SQ9HYQ @ SR9ZDN.KA.POL.EU //Ampr.org: sq9hyq@wloclawek.ampr.org - tylko tekst! /e-mail : darek.k.fm@interia.pl /ex I zapisuję plik. Teraz wyślę z BBS-a list do Marcina SQ7GDB i podpisze się pod nim tak jak to widać na załączonym screenie. Chciałbym poinformować iż na AmiComie można pisać i czytać z polskimi znakami w standardzie AmigaPL. Wystarczy że skopiujesz spolszczony font dla AmiComa w miejsce starego. Nie zapomnij zaktualizować indexu (FixFonts) i już możesz pisać z ogonkami. Font znajdziesz również w archiwum z program 7plus. Nasz serial dobiegł końca ale od AmiComa są dużo lepsze programy do Packet Radio. Opisanie samego AHP, który swoimi możliwościami wielokrotnie przewyższa AmiComa, zajęłoby wiele odcinków. Jeżeli nadal interesuje was ten temat, mogę opisać Amiga Host Packet czy ProfiPacket. Wszystko zależy od was. Muszę mieć bodziec aby zasiąść do dalszej pracy. Ten bodziec to wy drodzy czytelnicy. Jeżeli otrzymam odpowiednią ilość listów od chętnych na ten temat, nauczę was korzystać z AHP lub ProfiPacket czy też, opiszę emulator AmigaTNC v1.3.

Wyszukiwarka

Wyniki