strona główna     -     okładka numeru     -     spis treści     -     archiwum fahrenheita     -     napisz do nas
 
Tomasz Zieliński Para - nauka i obok
<<<strona 24>>>

 

Przestrzeni! Przestrzeni!

 

 

 

Temat dzisiejszych rozważań nasunął mi się na myśl podczas instalacji dużego narzędzia programistycznego, rozprowadzanego na czterech płytach CD. Trzeba spędzić przy komputerze przynajmniej pół godziny, wkładając do napędu kolejne nośniki. Weterani powiedzą - czymże są cztery płyty wobec 32 dyskietek z Windows 95. Też pamiętam. Zepsuta była zawsze przedostatnia.

Zastanowimy się, na co zużywamy dostępne nam nieprzeliczone gigabajty pojemności pamięci masowych. Bo gigabajty kosztują dziś grosze, a konkretnie około 75 groszy za 4.5 GB, no chyba że promocja, wtedy taniej. Widać więc, że z jednej strony miejsca jest w bród, a z drugiej strony niewygodnie jest grzebać w stosie kiepsko opisanych i nieposegregowanych płyt, którego to stosu dorobił się chyba każdy posiadacz nagrywarki CD/DVD. Dojdziemy zaś do niejasnego wniosku, że w sumie wykorzystujemy miejsce z rozsądkiem a jednak marnotrawimy je tysiąckrotnie.

Pamięć komputera to - jak wszystkim wiadomo - zera i jedynki. Nazywamy je bitami. Osiem bitów tworzy bajt, przyjmujący wartości całkowite od 0 do 255 (dopuszczalne są też inne interpretacje kombinacji bitów w bajcie, np. reprezentacja wartości od -128 do 127). Współczesne procesory liczą na liczbach 32- albo 64-bitowych, i choć są to wartości bardzo duże, to czasem trzeba operować większymi zakresami. Wtedy trzeba kombinować, dzielić na kawałki i tak dalej. Dobrym ćwiczeniem jest dla młodego programisty napisanie programu mnożącego dwie liczby złożone z miliona cyfr każda. Co polecam uważnemu czytelnikowi.

Niewielu użytkowników komputerów zastanawia się, ile rzeczywistego wysiłku programista włożył w program, którego wersja instalacyjna zajmuje całą płytę CD. Zastanówmy się więc. Najlepiej na konkretnym przykładzie, bo tak łatwiej. Każdy pamięta jak się liczy pierwiastki rzeczywiste trójmianu kwadratowego, więc od tego wyjdziemy.

Konieczne jest zastrzeżenie - taki program, zależnie od użytego języka programowania, może zajmować jedną niezbyt długą linijkę kodu. My jednak spojrzymy na całą rzecz tak, jak widzi ją centralna jednostka obliczeniowa komputera, czyli znany wszystkim mikroprocesor. "Mikro-" w nawiązaniu do zamknięcia całej logiki w jednym układzie scalonym, procesor jako taki można skonstruować z bramek logicznych dowolnej budowy - tranzystorów, lamp próżniowych, dźwigienek i zębatek, rur i zaworów pneumatycznych i co tam jeszcze może zmieniać stan na życzenie. Z trudem powściągamy szarpiącą się dygresję i wracamy do tematu.

Tak więc nasz program będzie złożony z pojedynczych, elementarnych instrukcji procesora. Nie zawsze wykonują się one w jednym takcie zegara, ale to nas nie interesuje. Oczywiście przyjmujemy skrajnie uproszczony model obliczeń, który mimo wszystko jest w stanie wypełnić treścią niejeden semestr studiów informatycznych. Ośmiobitowe procesory, jak Z-80 firmy Zilog, miały nie więcej niż 256 instrukcji, więc jedna komórka pamięci kodowała jeden rozkaz procesora (rzadko spotykane rozkazy dwubajtowe ignorujemy, żeby nie zaburzać przekazu).

Znaczna większość instrukcji potrzebowała jednego lub dwóch parametrów, np. po odczytaniu polecenia "skocz do przodu" procesor doczytywał z następnej komórki pamięci parametr określający, ile bajtów należy ominąć pobierając następny rozkaz do wykonania.

Wewnątrz samego procesora obecna jest pewna liczba komórek pamięci używanych do przechowywania argumentów i wyników obliczeń matematycznych. Nazywamy je rejestrami. Odczyt i zapis wartości w komórkach pamięci RAM wymaga umieszczenia w jednym z rejestrów adresu (numeru) żądanej komórki pamięci. Mnogość trybów adresowania pomijamy, wystarczy nam wiedza że komunikacja z RAM-em to osobne instrukcje.

Tych wszystkich informacji potrzebujemy, by oszacować rozmiar naszego programu i jego relację do produkcji współczesnych. Droga do pierwszego wniosku jest dość żmudna, ale prościej się nie da. W przypadku znudzenia proszę przeskoczyć do drugiego akapitu za kolorową tabelką.

Weźmy więc trójmian kwadratowy w postaci ogólnej a*x^2 + b*x + c = 0

Zmienne a, b i c to dane wejściowe. Zakładamy, że ich wartości będą jeszcze potrzebne, więc na wynik rezerwujemy trzy kolejne zmienne: n (liczba rozwiązań), x1, x2. Będziemy też potrzebować zmiennych pomocniczych - delta, temp1, temp2.

W naszym programie argumenty i wyniki będą przechowywane w pamięci RAM. Zmienne pomocnicze - delta, temp1, temp2 - umieścimy w rejestrach. Nasz model procesora zakłada istnienie osobnych instrukcji arytmetycznych dla każdego rejestru, dzięki czemu np. rozkaz delta = temp1 * temp2 to jedna instrukcja (wpisanie wyniku mnożenia do rejestru delta) z dwoma parametrami (rejestr pierwszego argumentu i rejestr drugiego argumentu).

Wyposażeni w odpowiednią wiedzę jesteśmy gotowi stawić czoło algorytmowi.

delta = b^2 - 4*a*c

jeśli delta < 0; brak rozwiązań

jeśli delta = 0; jedno rozwiązanie: x1 = - b / 2a

jeśli delta > 0; dwa rozwiązania: x1 = (-b-sqrt(delta))/2a; x2 = (-b+sqrt(delta))/2a


Teraz popatrzmy na program:

operacja opis bajty
1 temp1 = b pobranie wartości rejestru 1+1
2 temp2 = b pobranie wartości rejestru 1+1
3 delta = temp1 * temp2 przypisanie wyniku mnożenia 1+2
4 temp1 = a pobranie wartości rejestru 1+1
5 temp2 = 4 * temp1 przypisanie wyniku mnożenia 1+2
6 temp1 = c pobranie wartości rejestru 1+1
7 temp2 = temp2 * temp1 przypisanie wyniku mnożenia 1+2
8 delta = delta - temp2 przypisanie wyniku odejmowania 1+2
9 jeśli (0 <= delta) JEDNO skok warunkowy 1+2
10 n = 0 przypisanie wartości 1+2
11 koniec zakończenie procedury 1
JEDNO etykieta
12 jeśli (0 < delta) WIELE skok warunkowy 1+2
13 temp1 = 0 pobranie wartości rejestru 1+1
14 temp1 = temp1 - b przypisanie wyniku odejmowania 1+2
15 temp2 = a pobranie wartości rejestru 1+1
16 temp2 = 2 * temp2 przypisanie wyniku mnożenia 1+2
17 temp1 = temp1 / temp2 przypisanie wyniku dzielenia 1+2
18 x1 = temp1 przypisanie wartości 1+2
19 n = 1 przypisanie wartości 1+2
20 koniec zakończenie procedury 1
WIELE etykieta
21 delta = SQRT(delta) obliczenie pierwiastka kwadrantowego 1+1
22 temp1 = 0 - b przypisanie wyniku odejmowania 1+2
23 temp1 = temp1 - delta przypisanie wyniku odejmowania 1+2
24 temp2 = 2 * a przypisanie wyniku mnożenia 1+2
25 temp2 = temp1 / temp2 przypisanie wyniku dzielenia 1+2
26 x1 = temp2 przypisanie wartości 1+2
27 temp1 = temp1 + delta przypisanie wyniku dodawania 1+2
28 temp1 = temp1 + delta przypisanie wyniku dodawania 1+2
29 temp2 = 2 * a przypisanie wyniku mnożenia 1+2
30 temp2 = temp1 / temp2 przypisanie wyniku dzielenia 1+2
31 x2 = temp2 przypisanie wartości 1+2
32 n = 2 przypisanie wartości 1+2
33 koniec zakończenie procedury 1
RAZEM 86 bajtów

Widzimy, że pisząc program do wyznaczenia pierwiastków trójmianu kwadratowego potrzebowaliśmy 86 bajtów pamięci operacyjnej. Nie poruszaliśmy wcześniej kwestii rozmiaru zmiennych i rejestrów, ale można przyjąć że każda z sześciu zmiennych (rejestry się nie liczą) to 2 lub 4 bajty. Czyli przekraczamy sto bajtów. Ponadto w powyższym listingu jest ordynarne oszustwo - brakuje kodu liczącego pierwiastek kwadratowy. Jeśli obliczenie to nie jest dokonywane sprzętowo (przez koprocesor arytmetyczny, od czasów i486DX zintegrowany z procesorem w jednej kości), należy dodać kolejnych 25-30 rozkazów i kilka komórek pamięci.

Czas na niezbędne zastrzeżenia:

  • program w pseudo-asemblerze został przygotowany ręcznie, zaś dla celów edukacyjnych różnokolorowe bloki (części algorytmu zależne od delty) zostały całkowicie rozdzielone. Można spodziewać się, że analogiczny program przetłumaczony przez kompilator z języka C byłby dwu-, trzykrotnie mniejszy
  • nie sprawdziliśmy, czy parametr a jest różny od zera. Próba dzielenia przez zero spowoduje załamanie pracy programu albo zawieszenie komputera
  • niekonsekwentnie przyjęliśmy, że stałe liczbowe mają 1 bajt
  • w naszym modelu operowaliśmy na liczbach całkowitych, pracowicie ignorując reszty w dzieleniu i błędy przepełnienia w dodawaniu i mnożeniu. Skutek jest łatwy do przewidzenia - poprawny wynik zdarzy się tu w niewielkim procencie obliczeń


    Osoby, które przeskoczyły kilka ostatnich akapitów, proszone są o uwagę. Przed chwilą powiedzieliśmy sobie, że pisząc prymitywny i całkowicie nieodporny na błędy program (zwracający na dodatek niewiarygodne wyniki) służący do obliczania pierwiastków trójmianu kwadratowego, zajęliśmy około 100 bajtów pamięci operacyjnej komputera.

    Teraz cofnijmy się o niemal 25 lat, gdy w sprzedaży były mikrokomputery ZX-80 i ZX-81, dziadek i ojciec znanego ZX Spectrum, wszystkie trzy z ośmiobitowym procesorem Z-80 na pokładzie. Komputery ZX-80 i ZX-81 były wyposażone w... 1 KB pamięci RAM. Tak, dokładnie 1024 bajty. Czyli program odrobinę tylko bardziej skomplikowany niż nasz, zająłby całą dostępną pamięć operacyjną. Ale to nie ten fakt stanowił główny problem[1], bo mimo tak drastycznych ograniczeń automatyzacja i interaktywność[2] obliczeń były wystarczającą nagrodą, ale brak miejsca na dane wejściowe i wyjściowe.

    Autorzy gier na popularne ośmiobitowce potrafili zmieścić wielką liczbę danych w bardzo niewielkiej objętości. Dzisiaj większość zasobów programu, np. obraz chmurki na niebie, zapisuje się w postaci zdjęcia lub rysunku. Dawniej stosowano inny sposób - od obrazka z chmurą znacznie mniej miejsca zajmuje opis sposobu rysowania typowej chmury. Efekt jest mniej realistyczny, ale oszczędność pamięci niebagatelna. Doskonałym przykładem może być gra labiryntowa Montezuma's Revenge, zajmująca 17 KB (w takiej objętości mieści się cała grafika, obsługa joysticka, sterowanie zachowaniami przeciwników itd.). Mapa labiryntu zapisana w mocno skompresowanym formacie PNG ma aż 177 KB, czyli 10 razy więcej! [mapa] Podobny trick zastosowano w znanej grze River Raid - tam długie kilometry nabrzeża rzeki są opisane iteracyjnym algorytmem (funkcją) o zadanych argumentach początowych.

    Patrząc z historycznego punktu widzenia, prawdziwym majstersztykiem było graficzne środowisko GEOS dla komputerów Commodore 64 i 128. Powstało w roku 1984 czyli rok przed Microsoft Windows 1.0, od których nie odbiegało zresztą zbytnio funkcjonalnością. Dość powiedzieć, że w skład GEOS[3] wchodził edytor tekstu, arkusz kalkulacyjny, baza danych czy program do składu niewielkich publikacji. Możliwe było np. osadzanie grafiki w dokumencie tekstowym i podgląd wydruku. Niestety, ograniczona pamięć nie pozwalała na edycję zbyt długich dokumentów a sam program działał wolno. System zajmował jedną stronę dyskietki 5.25" rzadkiej pojemności, większe programy - tak samo. Razem kilkaset kilobajtów. Plus 64 KB pamięci RAM.

    Komputery serii Amiga przyniosły nową jakość w grafice komputerowej. Gry były piękniejsze i animowane bardziej płynnie, niż kiedykolwiek wcześniej. Używane w Amigach dyskietki o pojemności 720 KB pozwalały na użycie pełnoekranowej grafiki o dużej rozdzielczości i pełnej palecie barw. Było to jednocześnie błogosławieństwem i przekleństwem graczy, bo przy produkcjach zajmujących kilka dyskietek normą było wachlowanie nimi i dłuższe chwile oczekiwania, podczas których gra doładowywała żądane zasoby. Amigowe gry i programy użytkowe miały już po kilka megabajtów.

    A potem pojawiła się płyta kompaktowa standardu CD-ROM (Yellow Book) i dyskietki wiatr historii zdmuchnął w przeszłość...


    Doszliśmy do chwili, gdy warto wskazać różnice między sposobami, w jaki traktowana jest pamięć operacyjna (RAM) i pamięć masowa. W pamięci RAM mamy system operacyjny, kontrolowane przez niego programy i dane przetwarzane przez te programy. Na dyskach... też. Ale inaczej. Dwie fundamentalne różnice to: trwałość danych i czas dostępu.

    Trwałość - rozumiana jako zdolność przeżycia bez prądu. W popularnym dysku twardym informacje są posadowione fizycznie w postaci namagnesowanych tak czy inaczej kawałków nośnika (czyli napylonej na powierzchnię aluminiowego talerza substancji magnetycznej). W pamięci RAM dane są nietrwałe, kilkadziesiąt tysięcy razy na sekundę trzeba je odświeżać żeby nie znikły. Starczy przez chwilę nie odświeżać i... cała zawartość kości pamięci idzie do nieba dla bajtów.

    Czas dostępu do danych jest równie ważny. Współczesne kości pamięci potrafią dostarczyć informację ze wskazanego adresu w ciągu 4-5 nanosekund, czyli miliardowych części sekundy. Czas makabrycznie krótki. Dysk twardy musi najpierw przesunąć ramię nad potrzebny obszar dysku i ustabilizować głowicę (średnio niecałe 10 milisekund, tysięcznych części sekundy), potem poczekać aż żądane dane dojadą do miejsca odczytu (następne 5 milisekund) potem je prędziutko odczytujemy. Kilka milionów razy wolniej. Milionów! Jasne, mechanizmy buforowania zapisu i odczytu mogą polepszyć wyniki, niechby i dwadzieścia razy. To nadal przepaść.

    Tak więc przy uruchomieniu aplikacji część lub całość pliku wykonywalnego jest przenoszona z dysku (lub innej pamięci masowej) do pamięci RAM. No dobrze, w tzw. środowiskach osadzonych, jak specjalizowane komputery przemysłowe, palmtopy czy choćby telefony komórkowe, program wykonywany jest "w miejscu", czyli z pamięci stałej, nieulotnej, zazwyczaj niezapisywalnej (lub dającej się modyfikować tylko w trybie serwisowym, przy aktualizacji oprogramowania). Ale my nie o tym, tylko o zwykłym komputerze z biurka, czy to pecet, czy makówka.

    Program jest przenoszony do pamięci i rozpoczyna się jego wykonywanie. Oto jednak pamięć masowa w naturalny sposób rozszerza pamięć operacyjną i to na dwa różne sposoby. Od czasów Windows 3.0 i tzw. 32-bitowych ekstenderów w DOS-ie (np. dos4gw) możliwe stało się mapowanie pewnego obszaru (fizycznie nieistniejącej) pamięci na dysk twardy - plik lub partycję wymiany. Ta ostatnia jest zwyczajowo zakładana przez instalatory dystrybucji Linuksa. W tej technologii zajęte, lecz rzadko używane bloki pamięci RAM są zapisywane na dysku a odzyskane miejsce oznacza się jako wolne. Działa to dobrze do chwili, gdy uruchomione aplikacje żądają jednocześnie dostępu do bloków, których nie da się naraz pomieścić w RAM-ie. Znamy już różnicę w prędkości działania kości pamięci i dysku twardego, żądania wymiany momentalnie się kumulują, programy zamierają w oczekiwaniu na dane, wydajność systemu załamuje się.

    Druga z metod oparta jest bardziej na architekturze aplikacji, niż systemów operacyjnych. Pamięć masowa (dysk twardy, CD-ROM, DVD) może przesyłać dane w sposób ciągły, tak, by były one przetwarzane na bieżąco. Dzięki temu plik wykonywalny gry ma kilka megabajtów, animowana sekwencja czytana bezpośrednio z płyty - kilkadziesiąt, zaś łączna zajętość RAM-u pozostaje na rozsądnym poziomie kilkunastu MB koniecznych do buforowania i dekompresji danych.


    No dobrze. Powiedzieliśmy sobie co i jak, ale wciąż nie wiadomo dlaczego. Nasz program, mimo swych niedociągnięć, miał 100 bajtów. Po uzupełnieniu o procedury prostego wejścia/wyjścia, wraz z wywołaniami funkcji bibliotecznych (o nich później) cały plik wykonywalny zajmie ze 2-3 KB. Ale to program wywoływany z linii komend. Adam Cebula takie lubi, ja też, lecz przeciętny użytkownik woli poklikać. I tutaj nieprzygotowanego widza czeka spora niespodzianka, okienkowy program z klikanymi guzikami, korzystający wyłącznie z Win32 API będzie miał jakieś... 3-4 KB. A jak się za to weźmie ktoś z ambicjami, to i połowę wspomnianego rozmiaru.

    Skąd więc biorą się wielomegabajtowe kobyły? Odpowiedź jest prosta - z pogoni za kosztami. Ręczne przygotowanie aplikacji okienkowej może przyprawić o wielogodzinny ból zębów, tyczasem programowanie myszką w nowoczesnym środowisku programistycznym to 10 minut - a i instalator się sam wygeneruje. Środowisko takie, jak C++Builder, Delphi czy inne-jakie-niepotrzebne-skreślić, wnosi w wianie kilka warstw pośrednich, ulokowanych w programie pomiędzy systemem operacyjnym a okienkiem klikanym przez użytkownika. I tak na przykład kod obsługujący zaawansowane lub nietypowe elementy interfejsu (np. animowany przycisk ekranowy) jest włączany do programu nawet, gdy owe elementy nie zostały użyte.

    Tak jest jednak taniej i szybciej. Owszem, mozolne dłubanie, by wycisnąć dodatkowe kilka procent wydajności, bywa ważne np. w bazach danych, gdzie przetwarza się miliony komunikatów dziennie. Tam warto a czasem i trzeba się przyłożyć. Ale w aplikacji dla Zwykłego Użytkownika nie liczy się wydajność, liczy się koszt wytworzenia. A umiejętność równoważenia tych dwóch sprzecznych wymagań powinna znaleźć się w programie kształcenia pracowników branży informatycznej, aż nazbyt często widuje się efekty zbyt dużego nacisku na którąś ze stron.

    Na koszty można też spojrzeć od strony użytkownika a nie twórcy programu. Bo fakt, że akceptujemy programy o rozmiarach nieadekwatnych do realizowanych zadań, zajmujące niechby i gigabajty, jest bezpośrednią konsekwencją cen dysków twardych - jeden gigabajt HDD kosztuje dziś na rynku pierwotnym około 2 zł. W ciągu ostatnich dziesięciu lat wszystkie najistotniejsze parametry typowego peceta, jak wydajność procesora, rozmiar RAM-u i pojemność twardego dysku, zwiększyły się około stukrotnie. Sto razy szybciej, sto razy więcej. A płyta CD-ROM? Ha! Mamy ją. Płyta CD-ROM o nieogarnionej kilkanaście lat temu pojemności 650 MB stoi w miejscu. Choć powinna mieć dziś jakieś 75 GB. Tymczasem DVD, następca krążków CD, ma 4.5 GB (nośnik jednowarstwowy) albo 9 GB (dwuwarstwowy), płyty dwustronne nie przyjęły się. Póki jednak jedna trzecia[4] komputerów nie jest wyposażona w czytnik DVD, bezpieczniej jest wytłoczyć i sprzedać program na kilku CD, co zresztą zauważyłem na początku tekstu.


    Dobrą ilustracją wzrostu objętości danych jest muzyka komputerowa. Dawno temu, za czasów ośmiobitowców (ech, to były piękne czasy[5]) dźwięki generowano metodą syntezy FM, zazwyczaj dwu-, trzykanałowo, monofonicznie. Efekty miały bardzo "elektroniczne" brzmienie, ale zaletą było małe zużycie pamięci - jednemu dźwiękowi (nucie) odpowiadały 2-4 bajty. Sekwencje można było dzielić na bloki i zapętlać, tworząc ciekawą muzykę zajmującą raptem kilka kilobajtów.

    Pewną wariacją na ten sam temat były karty dźwiękowe z tabelą próbek brzmień (wavetable), które z pliku typu MIDI (coś jak opis nut, ale z ustandaryzowanym przypisaniem dźwięków do instrumentów) robiły muzykę naprawdę wysokiej jakości. Wielokanałowe zbiory MIDI miały kilkanaście-kilkadziesiąt KB.

    Równolegle rozwijały się formaty, w których próbki brzmień były osadzone obok sekwencji "nut", np. MOD (i słynny wówczas amigowy edytor ProTracker). Na podstawie jedno- lub kilkutonowych, wzorcowych dźwięków trąbki, fortepianu czy perkusji odtwarzano muzykę dość wiernie naśladującą oryginał. Tu objętość plików sięgała niekiedy kilkuset kilobajtów, zależnie od liczby i jakości próbek. MOD-y i muzykę tworzoną na ośmiobitowcach (najpopularniejszy format SID) można posłuchać w Winampie, po zaopatrzeniu go w odpowiednie pluginy[6].

    Następnym krokiem była prawdziwa muzyka zapisana ze źródeł analogowych. Problemem była jej duża objętość, odpowiadająca nieskompresowanym plikom typu WAV czy AIFF (dziesiątki megabajtów). Do zagadnienia podchodzono więc dwojako - zapisując oprawę dźwiękową gry jako dużej objetości pliki zasobów lub w postaci ścieżek audio, odtwarzanych bezpośrednio z płyty CD. Dopiero, gdy moc obliczeniowa komputerów pozwoliła na jednoczesne generowanie grafiki, obsługę świata gry, sztucznej inteligencji i dekompresję spakowanego, przestrzennego dźwięku, sytuacja okrzepła i ustabilizowała się. Dziś stratne formaty kompresji MP3 czy OGG umożliwiają zapis minuty muzyki wysokiej jakości w jednym megabajcie danych, dostępne są też specjalizowane kodeki służące np. do kompresji mowy ludzkiej.


    W grafice komputerowej trudno o tak czytelną linię rozwoju, bo rozwój ten był wielotorowy, najeżony pułapkami i ślepymi uliczkami. Więcej było też prób wyprzedzenia epoki, przykładem jest nieco wymuszona multimedialność wczesnych wersji encyklopedii Encarta. Nieliczne klipy wideo miały rozmiar znaczka pocztowego i - wskutek niedostatków technologii i mocy obliczeniowej - zajmowały bardzo dużo miejsca. Bez tego jednak nie wytyczono by nowych ścieżek rozwoju multimediów. Dziś sytuacja zmieniła sie o tyle, że to właśnie producenci gier napędzają rozwój dużej części branży. Typowe oprogramowanie biurowe działa bez problemu na komputerze sprzed trzech lat, nowa gra 3D działa płynnie na komputerze który powstanie za rok.

    Realistyczna grafika komputerowa do dziś pozostaje świętym Graalem naukowców zajmujących się cyfrowym modelowaniem praw natury. Owszem, wiele jest modeli oświetlenia, odbić, rozpraszania czy załamania światła, niektóre pozwalają na wygenerowanie obrazów uderzająco rzeczywistych, jednak większość algorytmów sprawdza się tylko w określonych zastosowaniach. Wciąż daleko do chwili, w której będzie można pomylić aktorów w kinie z ich cyfrowymi dublerami - problemem jest nie tylko animacja postaci czy odtworzenie mimiki, ale i takie detale jak rozpraszanie światła w różnych warstwach skóry czy precyzyjna interakcja z otoczeniem.

    Do interaktywnej grafiki trójwymiarowej, mającej na celu przedstawienie obiektów przestrzennych rzutowanych na powierzchnię dwuwymiarowego ekranu, zabrano się już kilkadziesiąt lat temu. Na początku była to niewypełniana, "druciana" wektorówka, potem eliminowano zasłonięte krawędzie, na jednokolorowe ściany nakładano obrazki, następnie algorytmy realizujące te czynności zaszyto w sprzęcie, żeby działały szybciej. Kosztujące grube tysiące dolarów stacje graficzne miały na pokładzie dodatkowe procesory przetwarzające wyłącznie grafikę 3D (zaprojektowane do bardzo wydajnego obliczania przekształceń macierzowych), w 1996 roku technologia trafiła pod strzechy za sprawą karty Voodoo Graphics firmy 3dfx.

    Od tamtego czasu podstawowe idee nie zmieniły się - trójwymiarowa scena składa się z usytuowanych w przestrzeni trójkątów na których rysowane są tzw. tekstury (obrazki określające wygląd obiektów tak, jak tapeta definiuje wygląd ściany), na ekranie wyświetlane są tylko widoczne fragmenty powierzchni, nadal najwięcej problemów sprawia symulacja oświetlenia. Wydajność wzrosła za to miliony razy, przetwarzanie danych jest realizowane równolegle, na jedną powierzchnię można nałożyć wiele tekstur jednocześnie (również półprzezroczystych, np. na murze z "ceglaną" teksturą może być nałożony obrazek z graffiti a na to ślady pożaru przyciemniające fragmenty muru), sprzętowo realizowane jest wyznaczanie odbić światła i propagacja cieni. Do tego dochodzi zestaw efektów specjalnych, jak mgła czy flary (rozbłyski światła w nieistniejącym obiektywie) albo transformowanie wierzchołków według zadanych algorytmów (vertex/pixel shader) [obrazek].

    Wektorowo-teksturowa grafika 3D jest w powszechnym użyciu, bo oferuje obecnie najlepszą wypadkową jakości obrazu, wydajności przetwarzania, wymaganych umiejętności programistów i innych zmiennych tego typu. Inne techniki nie przetrwały próby czasu, choć miały swoje 5 minut w historii. Przykładem jest wyprodukowana w 1992 roku gra "Comanche: Maximum Overkill", helikopterowa strzelanina, gdzie strukturę górzystego krajobrazu generowano na podstawie dwuwymiarowej mapy wysokości [obrazek]. Technika o nazwie VoxelSpace uniemożliwiała zdefiniowanie jaskini czy skalnego mostu, za to lot wirtualnym kanionem był płynny już na procesorze 386. Z kolei w grze Ecstatica ciała bohaterów, animowane płynnie i z wdziękiem, składały się z kilkudziesięciu elipsoid [obrazek].

    Tak trochę poszliśmy w dygresje, ale związek z tematem jest dość istotny. Mówimy o zajętości pamięci masowych, w czym grafika ma swój wielki udział. I nie chodzi tu tylko o gry, choć rozległe wirtualne światy i fotorealistyczne tekstury zajmują setki megabajtów, a o filmy.


    Właśnie ruchome obrazy były główną przyczyna powstania i upowszechnienia standardu DVD. Był to bowiem pierwszy nośnik, który mieścił dwugodzinny film z wysokiej jakości ścieżką dźwiękową. Cel ten osiągnięto drogą długą i krętą - pierwsze napędy optyczne pojawiły się już pod koniec lat 70' i były znane pod marką LaserDisc. Strumień wideo zapisywano analogowo (odczytywane z płyty zera i jedynki kodowały modulacją czestotliwościową sygnał analogowy). Zaletą był brak artefaktów znanych z kompresji MPEG - wyraźnie oddzielonych prostokątów widocznych zamiast gładkich przejść tonalnych. Wadą - niewielka pojemność wielkiego nośnika. Płyta mieszcząca na jednej stronie 30-60 minut filmu (zależnie od stałej prędkości kątowej lub liniowej obrotu nośnika) miała 30 cm średnicy [foto]. Odtwarzacze LaserDisc zadomowiły się w Japonii, Ameryka i Europa na dwa dziesięciolecia przyjęły kasetowy format VHS.

    Pierwszym zwiastunem cyfrowego kina domowego był format VideoCD (White Book). Pojawił się w roku 1987, oferował obraz o rozdzielczości 352×288 pikseli, skompresowany w formacie MPEG-1, ze stereofonicznym dźwiękiem. Nie było to wiele, ale ówczesne komputery (a więc i dedykowane układy wbudowane w odtwarzacze stacjonarne) nie poradziłyby sobie z dekodowaniem obrazu wyższej jakości. Od strony technicznej VCD to zwykła płyta kompaktowa a zastosowana kompresja ogranicza czas odtwarzania do około 70 minut. Typowy film wciąż musiał być rozprowadzany na dwóch krążkach.

    Pod koniec lat dziewięćdziesiątych gwałtownie spadły ceny nagrywarek CD-R, zaś moc obliczeniowa komputerów wzrosła do takiego poziomu, by 100 minut skompresownaego obrazu zmieściło się na jednej płycie CD. Przez krótki czas w użyciu był format ASF firmy Microsoft, szybko jednak porzucono go na rzecz szerokiej gamy kodeków MPEG4 (DivX, XviD). Tak zaczęła się era masowego piractwa kinematograficznego. Dotąd zjawisko to prawie nie występowało w domach, bo po pierwsze trzeba było mieć dwa magnetowidy, po drugie każda kolejna kopia traciła na jakości, niezbyt zresztą na początku wysokiej. Problem nie występuje przy nośnikach cyfrowych a popularyzacja szerokopasmowego Internetu tylko wzmaga falę piractwa.

    Objętość płyty CD nie mogła jednak zapewnić jakości, jakiej pragnęli koneserzy - wielokanałowego dźwięku i wysokiej rozdzielczości. Te wymagania spełniła płyta DVD. Widać jednak, że i jej pojemność nie wystarcza do realizacji wszystkich zachcianek widzów - ekskluzywne wydania filmów, opatrzone wielogodzinnymi wywiadami, reportażami z planu i komentarzami twórców, są dystrybuowane na kilku płytach.


    W najbliższych miesiącach czeka nas początek kolejnej wojny formatów, podobnej do starcia VHS z Betamaxem (wygrał VHS) czy DVD-Audio z Super Audio CD (prowadzi, sądząc po asortymencie sklepów, DVD-Audio). Tym razem do boju staną HD-DVD (15/30 GB jedno/dwustronnie) i Blu-ray Disc (25/50 GB jedno/dwuwarstwowo). Nowe nośniki będą zawierały materiał wideo w wysokiej rozdzielczości, nawet do 1920x1080 pikseli. Warto spostrzec, że obraz taki wyświetli rzadko który monitor a projektory o odpowiednich możliwościach kosztują majątek. Podobną rozdzielczość (zdolność odwzorowania szczegółów) mają skądinąd filmy kinowe rozprowadzane na taśmie 35mm, do których efekty specjalne przygotowuje się w rozdzielczości poziomej 1000-4000 punktów.

    Zapowiadane 50 GB to dość dużo, nieco tylko mniej niż przeskalowana do dzisiejszych czasów pojemność CD-ROM. Prawdziwą rewolucją ma jednak szanse zostać HVD (Holographic Versatile Disc) o pojemności mającej sięgnąć jednego terabajta (1 TB = 1024 GB). I dopiero taki skok można uznać za postęp, a nie tylko dreptanie w ślad ewolucji. Po czym to poznać? Elementarne, drogi Watsonie, otóż takiej przepastnej przestrzeni nie da się wprost zapełnić.

    Współistnienie formatów DVD-RAM, DVD-R oraz DVD+R nie doprowadziło do wyłonienia lidera, za to istotnie opóźniło upowszechnienie nagrywarek DVD. Ich sprzedaż ruszyła na dużą skalę dopiero wtedy, gdy opracowano tanie napędy nagrywające nośniki "minusowe" i "plusowe". Być może tak samo będzie z nowymi technologiami i już wkrótce doczekamy napędów combo: HD-DVD & Blu-Ray & HVD. Z opcją zapisu. I wodotryskiem.

    A jeśli chodzi o niezmierzoną przestrzeń jednego terabajta, to zastosowania znajdą się szybko. Weźmy taką "Encyklopedię filmu science fiction" zawierającą omówienia przeszło 500 pozycji filmowych. Książka na pewno zyska na atrakcyjności, gdy w komplecie dostaniemy... kolekcję tychże filmów. Owszem, wszystkie nie zmieszczą się na HVD. Trzeba będzie dołączyć kilka płytek.




    [1] autor niniejszych słów nie może tego pamiętać, ale wysłuchał wiele opowieści o dziurkowaniu programów na papierowych taśmach i zanoszeniu ich do centrum obliczeniowego, gdzie po kilku dniach okazywało się, że jedna dziurka nie wycięła się dość dokładnie i program poszedł w maliny

    [2] interaktywność rozumiana nieco inaczej niż dziś, wyliczenie i wydrukowanie zbioru Mandelbrota w rozdzielczości 1024x1024 zajęło pewnemu studentowi fizyki tydzień nieprzerwanej pracy komputera ZX-81 z pamięcią rozszerzoną do 32 KB http://www.hanssummers.com/computers/mandelbrot/zx81/index.htm

    [3] więcej tu:http://www.c64.slonca.net/?strona=geos

    [4] źródło - ankieta CHIP Online, prowadzona od 2004-10-07 do 2004-10-12, głosów: 3875, odpowiedzi "DVD-ROM", "Combo rw/dvd" i "nagrywarka DVD" sumują się do 66%

    [5] na podstawie przedmiotu nostalgii możemy dość precyzyjnie określić, w której dekadzie autor felietonu zaczął swą przygodę z komputerami

    [6] na przykład tutaj: http://ftp.fukt.bth.se/pub/os/win2k/Winamp/in_sid/

  • Spis treści
    451 Fahrenheita
    Literatura
    Bookiet
    Recenzje
    Spam (ientnika)
    Galeria
    Ludzie listy piszą
    Permanentny PMS
    Wywiad
    W. Świdziniewski
    Andrzej Zimniak
    Andrzej Pilipiuk
    M. Kałużyńska
    Adam Cebula
    Adam Cebula
    Piotr A. Wasiak
    Adam Cebula
    Tomasz Pacyński
    M. Koczańska
    Magdalena Kozak
    Adam Cebula
    Tomasz Zieliński
    Tomasz Pacyński
    Zuska Minichova
    Magdalena Popp
    Natalia Garczyńska
    Paweł Paliński
    K. Ruszkowska
    PS
    Miroslav Žamboch
    Anna Brzezińska
    Robin Hobb
    Marcin Wolski
     
    < 24 >