Od kuchni - Amiga i PC, czemu Amiga nie mogła...

29.12.09, 01:36
Na życzenie @don_wroc_love skleciłem ten tekst wink

Reprezentacja koloru na Amigach jak zauważyłeś była zupełnie inna niż na PC.
Obraz reprezentowany był przez tzw. bitplany, przez co pojedynczy bajt
reprezentował po jednym bicie 8 kolorów. W ten sposób potrzebne było kilka
buforów pamięci by reprezentować pojedynczy piksel, a dokładnie tyle buforów (
bitplanów ) ile bitów reprezentowało kolor. Oczywiście reprezentacja samego
koloru to też inna bajka, bo na Amidze paleta była indeksowana i prawdziwy
TrueColor24 był reprezentowany jedynie przez paletę 16mln kolorów, ale użyć
ich maksymalnie ( przy kościach AGA ) ich 256. Skoro jesteśmy przy AGA, to
przy wykorzystaniu 256 kolorów potrzeba było 8 bitplanów. Każda sekwencja
bitów reprezentowała indeks koloru z palety. Teraz wyobraź sobie przykładowe
nie 8 a 4 bitplany dla uproszczenia ( wartości losowe z głowy ):

1 1 1 1 0 1 1 1 - bitplan 3
0 1 1 1 0 1 1 1 - bitplan 2
1 0 1 0 1 0 0 0 - bitplan 1
1 1 0 0 1 1 0 0 - bitplan 0

Otrzymamy więc 8 indeksów kolorów: 11, 13, 12, 3, 13, 12, 12

Na wyliczenie każdego indeksu składa się sięgnięcie po 4 komórki pamięci,
wykonanie maskowania bitu oraz złożenie z tego liczby i przeszukanie palety.
Sporo z tego robił oczywiście hardware, ale wyobraź sobie teraz proste
putpixel() i getpixel() od strony programistycznej, dla postawienia dosłownie
jednego piksela potrzebna była spora gimnastyka ( szczególnie, że stawiając 1
pixel trzeba zabezpieczyć pozostałe 7 wartości bajtu poprzez dodatkowe
operacje logiczne - a to wszystko to cykle, cykle i jeszcze raz cykle ).

Dlaczego w 2D to działało szybko? Odpowiedzią jest Blitter, który świetnie
radził sobie z kopiowaniem obszarów pamięci, jednak kopiowanie to było tym
lepsze im obszary pamięci były większe. Technicznie wielkiego znaczenia nie
miało czy kopiujemy obszar 128x128 czy 16x16. Blitter robił to niemal tak samo
szybko, ale... nie wystarczająco szybko. W grach 2D, gdy były one złożone z
tzw. 'tile', czy bardziej po polsku "bloków grafiki" nie trzeba było rysować
aż tak dużo, blitter doskonale dawał sobie radę z narysowaniem nowych
elementów poziomów i przescrollowaniem świata ( przekopiować bufor w lewo czy
prawo i dorysować nowy rząd tile'ów, zrobić update sprite'ów itp. ). Gdyby nie
blitter, to Amiga by po prostu na tym polu nie dała rady nawet z prostymi
grami 2D, blitter potrafił też szybko wypełniać bufory przez co np.
wypełnianie kolorem w takim Deluxe Paint odbywało się błyskawicznie.

Ale do semi-3D to nie wystarczyło. Dlaczego napisałem 'semi'? Dlatego, że
wówczas wszysct walczyli o to, by stworzyć Wolfenstein3D dla Amigi, który mimo
tytułu 3D wcale nie był. To był "raycaster engine", który nie wymagał
"floating point" i był dosyć lekki jeśli chodzi o przetwarzanie sceny, ale
wymagał szybkiej możliwości stawiania pikseli.

Przejdźmy teraz do PC. Na PC kolor reprezentowany był przez bajt lub ciąg
bajtów, zależnie od formatu. Obecnie jeden kolor jest zwykle reprezentowany
przez 3 ( 24bity, czyli wszystko co nie jest przezroczyste, np. finalny
framebuffer ) lub 4 ( z kanałem alpha, np. tekstury ) bajty. W tamtym czasie
również PC często korzystał z palety indeksowanej i w czasie gdy był już
Wolfenstein3D możliwości były porównywalne z układem AGA. Dlaczego więc
ówczesne PC nie radziły sobie z platformówkami 2D? Bo nie miały blittera. Nie
miały układu, który szybko będzie kopiował całe bufory oraz wykonywał między
nimi często potrzebne operacje logiczne, np. kiedy stawiany był sprite gracza,
hardware nic nie mógł zrobić, wszystko trzeba było napisać samemu. Gry 2D w
dla PC w tamtym czasie stanowiły problem wydajnościowy ( zresztą Wolfenstei3D
również miał swoje wymagania i mimo, że działał też słabym na 286, to jednak
grać dało się po zmniejszeniu viewportu dopiero ).

Przejdźmy teraz do W3D. Wyobraź sobie 320 pionowych kolumn pikseli. Horyzont
postaw sobie pośrodku, a więc w linii 100 ( biorę pod uwagę 320x200 ). Jak
Wolfenstein dał sobie radę z rysowaniem? Wykorzystał swoją największą wadę
dotyczącą 2D i problemów z szybkością kopiowania w połączeniu z operacjami
logicznymi jako zaletę - mógł postawić jednym rozkazem asemblera dowolny
piksel w dowolnym miejscu z efektem natychmiastowym, bez dodatkowych obliczeń.
Owszem, screen tearing i niższy framerate również na słabszych PC było widać w
Wolfenstein3D, ale nikomu to nie przeszkadzało, bo zastosowano sporo tricków
jak np. wycięcie podłóg i sufitów oraz skalowanie tylko połowy ściany. Jeśli
zwrócisz uwagę jak wyglądały ściany w W3D, to jeśli zdejmiesz tekstury i
poprowadzisz prostą linię poziomą przez środek ekranu to okaże się, że to co
jest na górze jest symetryczne z tym co jest na dole. Skoro więc policzyliśmy
który piksel z tekstury zdjąć po jednej stronie, to wystarczy prostym
odejmowaniem ( kolejny jeden rozkaz asemblera ) odszukać piksel tekstury, jaki
musimy postawić w części dolnej. Co dalej? Tekstury przygotowane są od razu do
wklejenia - bierzemy zawartość komórki pamięci i wklejamy ją od razu we
właściwą komórkę framebuffer. Relacja między tekstura - wklejanie piksela w
przypadku Amigi również stanowiła właśnie "bottleneck". Blitter był mocny, ale
nie dawał sobie rady, jeśli musiał kopiować osobno pojedyncze piksele.
Wykonanie 30-40 operacji kopiowania dla gry 2D zapewniało płynny gameplay, ale
wykonać ich np. 1000? Już niestety nie. Oczywiście liczby niekoniecznie
pokrywają się z rzeczywistością, chodzi mi raczej o zaprezentowanie skali
zjawiska.

Wyciągnięcie pojedynczego koloru piksela z tekstury to było kolejne wyzwanie.
Powiedzmy, że na PC piksel textury reprezentował 1 bajt. Jeśli tekstura była w
rozmiarach 64x64 ( takie były w W3D ), to wyciągnięcie piksela o współrzędnych
(x,y) wymagało prostej operacji: offset + ( y * 64 ) + x. Ponieważ szerokość
była potęgą dwójki ( zresztą to też był powód dlaczego karty graficzne
późniejszych generacji wymagały, by tekstury w szerokości zawsze były potęgami
dwójki wink ), można było mnożenie zastąpić przesuwaniem bitów w lewo co czyniła
znowu jedna instrukcja asemblera czyli: offset + ( y << 6 ) + x. Mamy więc 2
dodawania ( 2 rozkazy ) i jedno przesunięcie ( 1 rozkaz ). Dopieramy się do
piksela w 3 rozkazach po czym kolejnym kopiujemy go na framebuffer.

Teraz Amiga. Robimy tak samo, jeśli teksturę zachowamy w postaci takiej jaka
była w przypadku W3D czyli ciągły bufor z wartościami pikseli jako bajtami.
Tylko, że wkopiowanie tego w jeden piksel ekranu oznaczało przekonwertowanie
wartości na bitplany, a w jaki sposób to można było zrobić? Prosty algorytm (
z głowy co prawda, ale powinien zobrazować sytuację ) ( zakładam rozdzielczość
320x200 ):

value = offset + ( y << 6 ) + x;
screen_x = 100; // przykladowa wspolrzedna docelowa x na ekranie
screen_y = 100; // przykladowa współrzędna docelowa y na ekranie

bytes_per_row = ( 320 >> 3 ); // to akurat będzie stała
byte_in_row = ( screen_x >> 3 ); // sprawdzamy, który bajt w rzędzie zawiera
nasz pixel (
operujemy na liczbach całkowitych, przy screen_x = 100, wyjdzie 12)
bit_in_byte = screen_x - ( byte_in_row << 3 );

// teraz każdy bitplan trzeba zupdatować
byte_bpl_1 = byte_bpl_1 | ((((( tex_color & ( 1 << 0 ) ) >> 0) ) & 1 ) <<
bit_in_byte );
byte_bpl_2 = byte_bpl_2 | ((((( tex_color & ( 1 << 1 ) ) >> 1) ) & 1 ) <<
bit_in_byte );
byte_bpl_3 = byte_bpl_3 | ((((( tex_color & ( 1 << 2 ) ) >> 2) ) & 1 ) <<
bit_in_byte );
byte_bpl_4 = byte_bpl_4 | ((((( tex_color & ( 1 << 3 ) ) >> 3) ) & 1 ) <<
bit_in_byte );
byte_bpl_5 = byte_bpl_5 | ((((( tex_color & ( 1 << 4 ) ) >> 4) ) & 1 ) <<
bit_in_byte );
byte_bpl_6 = byte_bpl_6 | ((((( tex_color & ( 1 << 5 ) ) >> 5) ) & 1 ) <<
bit_in_byte );
byte_bpl_7 = byte_bpl_7 | ((((( tex_color & ( 1 << 6 ) ) >
    • j_uk_dev Re: Od kuchni - Amiga i PC, czemu Amiga nie mogła 29.12.09, 01:36
      Specjalnie nie napisałem tego w pętli, oraz nie uwzględniłem poprawienia
      kolejności bitów ( w przykładzie powyżej jest odwrotna wink, ale nie chciałem
      komplikować tego bardziej niż jest ). Co my tu mamy? 8 linii dla każdego
      bitplanu w których mamy następujące operacje wykonywane w tej kolejności ( każda
      to jeden rozkaz asemblera ): SHL, AND, SHR, AND, SHL, OR. Każdy wyliczony bajt
      trzeba wpisać we właściwy offset w każdym bitplanie. I to wszystko 8 razy dla
      256 kolorów, z którymi PC poradziłby sobie tak:

      fb_offset = screen_x + ( 320 * screen_y );
      &fb_offset[0] = tex_color; // w c wpisujemy wartość koloru do komórki, co
      odpowiada jednemu rozkazowi asemblera - MOV, to wszystko

      Dodatkowo 320 * screen_y optymizuje się do dwóch przesunięć bitów i sumy, co i
      tak wypada o wiele szybciej w ogólnym rozrachunku niż to co musiałaby zrobić Amiga.

      Mam nadzieję, że detalicznie wyjaśniłem źródło problemu.
      • j_uk_dev Re: Od kuchni - Amiga i PC, czemu Amiga nie mogła 29.12.09, 01:56
        Aj... w pierwszym poście i tak ucieło trochę pseudo-kodu, ale nie szkodzi, tam
        powinno być 8 linii, a nie 7. Coś jeszcze sobie przypomniałem. W grach jak W3D
        na PC nigdy nie było potrzeby zmiany wielkości piksela. W przypadku Amigi na
        pewno gracze pamiętają, że większość gier ( Cytadela, Gloom, Breathless, Alien
        Breed 3D ) miały zawsze opcję zmiany wielkości piksela od 1-4. Generalnie
        maksymalnie 4 piksele mogły reprezentować jeden kolor i to dawało niezły
        "boost", bo Amiga jak na 16/32 bitowy komputer ( zależnie od wersji ) mogła
        liczyć mniej w ten sposób i szybko zaadresować od do 4 bajtów na raz kopiując w
        nie tą samą wartość. Wyglądało to paskudnie, ale dawało naprawdę niezłego kopa.
        Na PC o ile mnie pamięć nie myli, chyba nigdy taka sztuczka nikomu nie przyszła
        do głowy, bo i po co?

        Później pojawiła się AmigaCD32, która miała chipset C2P chyli chunky2planar,
        chipset odpowiedzialny za konwersję koloru podobną jak pseudo-kod, który
        pokazałem. Miało to skusić programistów PC do przesiadki na Amigę i CD32 miała
        "obrodzić" w gry jak Wolf czy Doom. Niestety było to za późnio, a sam układ C2P
        okazał się po prostu nadal powolny. No to tyle wink Sam się dziwię, że to wszystko
        jeszcze pamiętam devil
        • j_uk_dev Re: Od kuchni - Amiga i PC, czemu Amiga nie mogła 29.12.09, 04:14
          Skoro jeszcze nie śpię to was pozanudzam trochę wink ( ciekawe czy ktoś to w ogóle
          przeczyta ). Celowo skupiłem się na chipsecie AGA oraz 8 bitplanach. PC jednak
          szybko przestały używać indeksowanej palety, natomiast Amiga niestety nie - to
          był kolejny gwóźdź do trumny jeśli chodzi o grafikę 3D ( i w sumie 2D też ). Nie
          wspomniałem co prawda o trybach HAM i HAM8, ale to dlatego, że były one
          praktycznie bezużyteczne jeśli chodzi o gry, bo powstawały straszne artefakty,
          gdy jakiekolwiek obiekty poruszały się w trybie HAM. Ciekawym natomiast było to,
          że były próby wykorzystania HAM6 ( HAM ) również do gier FPP, bo obraz musiał
          być wygenerowany i tak wcześniej, niż został wyświetlony i programowo dało się
          kontrolować artefakty jakie powstawały przy kompresji. Pewnie mało osób wie o
          tym, ale Amiga miała jeden z pierwszych układów graficznych kompresujących
          grafikę w czasie rzeczywistym i pozwalającą zapisać na 6 bitach 4096 kolorów,
          natomiast na 8 bitach - 262144. Co więcej, kompresja ta technicznie była
          zbliżona delikatnie do jpeg ( i również była stratna, czego następstwem były te
          artefakty ) smile Niestety poprawianie artefaktów okazało się zbyt kosztowne i
          obniżało wydajność gier, toteż pomysły z wykorzystaniem HAM upadły bardzo
          szybko. Sam również bawiłem się tym i poza playerem do filmików w HAM nie udało
          mi się wykorzystać tego trybu do niczego sensownego.

          Może będzie to stwierdzenie przesadne, ale świetny układ graficzny, w momencie
          gdy Amiga powstała i w latach jej świetności, który jej służył i pozwolił zdobyć
          popularność, to w momencie rozwoju gier i PC był jej gwoździem do trumny wink

          Tak, nudzę się i nie mogę coś spać wink Chyba jakiś film obejrzę devil

          @don, pomyśl dwa razy nim następnym razem poprosisz o "techniczne wyjaśnienie" devil
          • wypisany Re: Od kuchni - Amiga i PC, czemu Amiga nie mogła 29.12.09, 04:28
            Gwoździem nie był układ graficzny, tylko brak rozwoju. Układ pozwolił na
            zdominowanie rynku (na krótko, ale jednak), przynajmniej technologiczne, ale
            nikt tego nie wykorzystał, nie poszedł za ciosem. Pamiętam dyskusje nad systemem
            operacyjnym, który miał się pojawić w Amidze K2 - czy to ma być na kernelu
            linuksa, czy może jednak pisać coś swojego. Cała ta gadka nie miała sensu, bo
            już dawno było po ptokach, ale pokazywała główną słabość właścicieli Amigi -
            nieumiejętność podejmowania decyzji. Jak już coś postanowili, to już było po
            zawodach. Tak było z wprowadzeniem PPC, tak było z Zorro, no ze wszystkim tak
            było. Historia Amigi to historia o gigantycznym potencjale zmarnowanym przez
            fatalne zarządzanie. Aż mi się smutno zrobiło - zapraszam do mojego wątku, bo
            tutaj zaraz się zacznie stypawink
            • j_uk_dev Re: Od kuchni - Amiga i PC, czemu Amiga nie mogła 29.12.09, 04:53
              Zgadzam się oczywiście co do złego zarządzania Amigą, w tym wątku po prostu
              skupiłem się na kwestiach technicznych i celowo nie poruszałem problemów
              związanych z zarządzaniem. Rozwój Amigi zatrzymał się w pewnym momencie i CD32
              była tego dowodem. Już wtedy rok czasu to było dużo dla technologii, natomiast
              Commodore wypuścił A1200 jako konsolę z CD i tyle - a konkurencja nie spała.
              Masz rację, że Amiga to zmarnowany potencjał jednak układ graficzny ( i
              zamknięta architektura, która nie pozwalała go zmeinić, bo dodatkowe karty były,
              ale ich ceny... eh... ) jednak okazał się z czasem niedostosowany do wymagań
              graczy. Właśnie pojawienie się W3D było sygnałem, że dalej pociągnąć będzie
              trudno i trzeba coś z tym zrobić. I zrobili... CD32 suspicious
              • don_wroc_love Re: Od kuchni - Amiga i PC, czemu Amiga nie mogła 29.12.09, 08:13
                heh, dzięki za opisanie problemu - postaram się w domu na spokojnie to
                przetrawić smile
                a powiedz - czy te plotki o chipach AAA w amigach (jako następcy Agatki) (że
                ponoć były gotowe koncepty układu 3d, który miał równie nietypowe podejście do
                3d jak Aga do 2d)
                mogły być choć po części prawdziwe?
                • j_uk_dev Re: Od kuchni - Amiga i PC, czemu Amiga nie mogła 29.12.09, 21:45
                  Chipset AAA nigdy nie został ukończony, istniał co prawda prototyp, ale nie był
                  on kompletny. Miał on całkowicie pozbyć się największej wady chipsetu AGA -
                  kompatybilności i jakiegokolwiek związku z architekturą starszych kości ECS.
                  Właśnie to w mniemaniu Commodore ograniczało kości AGA najbardziej. AAA miały z
                  kolei pracować w trybach 32/64 bitowych ( podobnie jak wspomniany w wątku o
                  konsolach Jaguar - niektóre jednostki miały być 32-bitowe, inne 64-bitowe w
                  całym układzie ). Prace nad AAA zaczęto dosyć wcześnie, bo już w 1989, ale to
                  był taki hardware'owy amigowy "Duke Nukem Forever", który nigdy nie ujrzał
                  światła dziennego, a pęd do wypuszczania modeli konkurencyjnych przystopował
                  rozwój nowych modeli.

                  Architektura AAA wskazywała, że chipset będzie niewiele szybszy niż AGA ( nawet
                  nie dwa razy szybszy! ) jednak skupiono się na dodaniu takich elementów jak
                  pamięć video. Również blitterowi się "oberwało" i zmieniono całkowicie model
                  kopiowania i stawiania pikseli - teraz miało być tak jak w PC i dzięki temu
                  wreszcze blitter mógłby zadbać o te amigowe doomy i wolfy ( zresztą Amiga miała
                  otrzymać więcej trybów graficznych i mimo kompatybilności z trybami "planar" to
                  priorytetem miała być migracja do "chunky" ).

                  AAA z 3D nie miało mieć wiele wspólnego, przynajmniej nie z 3D jakie rozumiemy
                  dziś. Trzeba wziąć poprawkę, że wówczas problemem w 3D nie był "floating point",
                  obliczenia, sortowanie sceny i inne aspekty z tym związane, ale samo
                  wyświetlanie grafiki i wtedy za 3D uznano gry takie jak Wolfenstein czy Doom, a
                  trzeba zauważyć, że z 3D one nie miały wiele wspólnego. 3D w takim kontekście
                  AAA miały wspierać właśnie dzięki szybszej możliwości rysowania, trybom "chunky"
                  i pamięci video, ale nie można tego mylić z prawdziwym 3D i np. z tym co robi
                  GPU dziś. Oeracje na floating point, floating point buffer dla tekstur,
                  wspieranie operacji na wektorach, macierzach itp. - wtedy to po prostu nie
                  istniało w tamtym 3D smile. Dziś wszystko robimy przez mnożenie macierzy, wtedy
                  vertexy rzutowało się nie biorąc pod uwagę rzeczy takich jak viewing frustum,
                  różne perspektywy, near/far plane itp. wystarczyła funkcja point(x,y) = (x0,y0)
                  + (x,y)/z oraz w W3D i innych raycasterach korekta "fish bowl" smile AAA więc nie
                  miało wsparcia dla 3D, ale po prostu dla grafiki.
                  • tetlian Re: Od kuchni - Amiga i PC, czemu Amiga nie mogła 04.01.10, 00:28
                    Takie pytanie. Skoro Amiga była kiepska do 3D, to dlaczego w tamtych czasach efekty
                    specjalnie do większości filmów były robione na Amidze? Jednym z bardziej znanych
                    przykładów jest płynny T1000 z Terminatora 2.
                    • Gość: BCC Re: Od kuchni - Amiga i PC, czemu Amiga nie mogła IP: *.adsl.inetia.pl 04.01.10, 17:28
                      Te efekty specjalne były tworzone na programach graficznych (głównie LIGHTWAVE),
                      które były wtedy dostępne na Amidze a nie było ich (jeszcze) na PC. Jednak to
                      nie miało nic wspólnego z tytułowym algorytmem wyświetlania grafiki w grach, po
                      prostu Amiga miała dobre możliwości graficzne/multimedialne, więc głównie na nią
                      zaczęły powstawać pierwsze programy do modelowania grafiki 3D. Tu jednak szybko
                      zaczęło rosnąc znaczenie procesora, a wiadomo, ze PC miał także i tu dużą przewagę.
                      • j_uk_dev Re: Od kuchni - Amiga i PC, czemu Amiga nie mogła 04.01.10, 22:12
                        Masz rację. Amiga mimo, że w czasie rzeczywistym ledwo sobie radziła, to dzięki
                        trybom HAM i HAM8 oraz uzyskaniu TrueColor24 przy wykorzystaniu kart
                        VideoToaster ( to przy pomocy tych kart renderowano efekty do filmów, można było
                        je spiąć razem i przyspieszyć robotę tym samym ) Amiga królowała przez jakiś
                        czas w przemyśle filmowym, bo tam nie realtime się liczył, ale efekt końcowy.
                        Akurat z Lightwave nigdy się nie spotkałem, sam używałem Real3D i czasami
                        renderowanie jednej sceny ( postanowilśmy wówczas z kolegami renderować grafikę
                        tą metodą pracując na przygodówką point-n-click ) potrafiło zająć nawet... 2
                        tygodnie! Wyobrażacie sobie pozbyć się komputera na 2 tygodnie, bo renderuje
                        się jeden obrazek? wink Wtedy to była norma. Jako anegdota dotycząca tego faktu,
                        to w czasie powstawania tej "super-produkcji" ( która niestety nie została nigdy
                        ukończona ) byliśmy jeszcze małolatami, więc każdy mieszkał z rodzicami.
                        Wyobraźcie sobie minę kumpla, jak wrócił z liceum, a po jakimś tygodniu
                        renderowania zastał wyłączony komputer - matka pomyślała, że zapomniał i zadbała
                        o wyłączenie smile Chłopak się prawie załamał devil Później umieszczał na Amisi
                        kartkę "nie dotykać!" devil
                        • tetlian Re: Od kuchni - Amiga i PC, czemu Amiga nie mogła 04.01.10, 23:20
                          Aż mi się łezka w oku zakręciła smile Robiłem dokładnie tak samo. Ileż to godzin spędziłem i
                          nie spędziłem (czekając na wyrenderowanie się obrazu) nad Realem3D, to nie zliczę. A
                          już nawet po wyrenderowaniu obrazu istniało ryzyko, że coś się zrąbie i nie uda się go
                          zapisać na dyskietce. Zawsze dla pewności zapisywałem swe dzieła na conajmniej
                          dwóch dyskietkach smile

                        • Gość: asga Re: Od kuchni - Amiga i PC, czemu Amiga nie mogła IP: 77.255.6.* 05.01.10, 02:01
                          To pewnie kazda burze spedzal na kleczkach smile
                          • j_uk_dev Re: Od kuchni - Amiga i PC, czemu Amiga nie mogła 05.01.10, 03:30
                            Burze jednak były bezpieczniejsze od matek devil A żebyś wiedział jakie cuda
                            się działy jak nagrywaliśmy "voiceacting" wink Tak... nasza "superprodukcja" miała
                            być przygodówką "point-n-click" z pełnym voiceactingiem, gdzie każda kwestia
                            musiała się zmieścić w... 5 sekundach z powodu wymogów pamięciowych ( treningi
                            sobie chłopaki musieli robić, jak szybko "recytować" linijki ), a nie chcieliśmy
                            zbyt wiele doczytywać z dyskietek, to trzeba było się streszczać. A intro... u
                            chłopie, muzyka z Flashback idealnie się wpasowała wink No czasy to były
                            nieziemskie smile
          • Gość: asga Re: Od kuchni - Amiga i PC, czemu Amiga nie mogła IP: *.adsl.inetia.pl 04.01.10, 15:23
            > Skoro jeszcze nie śpię to was pozanudzam trochę wink ( ciekawe czy ktoś to w ogól
            > e
            > przeczyta )

            Tekst ciekawy, ale pewne rzeczy nie do konca zrozumiale czasem dla kogos kto
            konkretna sprawa sie nie interesowal... Np. o co chodzi z chronieniem
            pozostalych 7 wartosci bajtu (poczatek tekstu) nie rozumiem ....
            • j_uk_dev Re: Od kuchni - Amiga i PC, czemu Amiga nie mogła 04.01.10, 22:32
              Tak myślałem, że temat może być nieco hermetyczny ( a to wina @dona ), ale
              trudno naprawdę ubrać go w przejrzystość ( plus moje nędzne umiejętności
              tłumaczenia ludziom rzeczy nawet prostych potęgują problem wink ).

              Chronienie pozosta 7 bitów oznacza, że trzeba zadbać o to, by reszta bitów nie
              uległa zmianie, bo inaczej sąsiednie piksele również zostaną zmienione. Uprośćmy
              sprawę i skupmy się na grafice monochromatycznej - 2 kolory czyli 1 bitplan.
              Pojedynczy bit reprezentuje finalny kolor. Jeśli mamy np. 8 pierwszych pikseli w
              ogóle "niezarysowanych", to pierwszych 8 bitów pierwszego bajtu, które te
              piksele reprezentują, będą miały wartość 0: 0 0 0 0 0 0 0 0b = 0d ( b -
              binarnie, d - decymalnie/dziesiętnie ).

              Teraz zapalamy 4 piksel od lewej, ale pozostałe nie mogą się zmienić. Finalnie
              układ bitów będzie wyglądał tak: 0 0 0 1 0 0 0 0b = 16d.

              Nie możemy po prostu wstawić jednak w komórkę wartości 16, bo wtedy reszta bitów
              ( i pikseli wyzeruje się ), to całkowicie zmieni postać już zapalonych piskeli,
              więc jeśli mamy sytuację: 0 1 0 0 1 1 1 1b = 79d i zapalimy 4 bit stawiając tam
              piksel, to dostaniemy 0 1 0 1 1 1 1 1b = 95d. Wszystko ciągle mieści się w
              jednej wartości całego bajtu. Ochrona polega na zapalaniu i gaszeniu bitów
              operacjami logicznymi AND, OR, NOT.

              Jeśli zapalasz bit używasz OR, jeśli gasisz to używasz negacji NOT oraz AND i po
              jednej stronie staje zawartość bajtu, a po drugiej liczba będąca przeliczonymi
              również na podobny bajt ( czyli 8-bitowa ) bitami będąca tą "zmianą", jaką
              chcemy zaaplikować, na przykładzie z wartościami 79d i 95d ( rozpiszę znów
              binarnie ):
              ( 0 1 0 0 1 1 1 1 ) OR ( 0 0 0 1 0 0 0 0 ) = ( 0 1 0 1 1 1 1 1 )
              Ale jeśli teraz chcemy zgasić ten 4 bit, to najpierw negujemy wartość
              modyfikacji ( łopatologicznie mówiąc, OR działa tylko dla "jedynek" ):
              (NOT ( 0 0 0 1 0 0 0 0 )) = ( 1 1 1 0 1 1 1 1 ) i teraz wykonujemy operację AND
              między bajtem piksela, a tą zanegowaną wartością:
              ( 0 1 0 1 1 1 1 1 ) AND ( 1 1 1 0 1 1 1 1 ) = ( 0 1 0 0 1 1 1 1 ) <- zgaszony 4
              bit/piksel smile
              Jeśli trzeba to dla postawienia/zgaszenia pojedynczego piksela wykonać w dodatku
              przy większej ilości bitplanów, to na pewno nie napawa optymizmem.

              Swoją droga, to nie uczą w szkołach algebry Bool'a i operacji logicznych na
              bitach na informatyce? Tak z ciekawości pytam.
              • Gość: asga Re: Od kuchni - Amiga i PC, czemu Amiga nie mogła IP: 77.255.6.* 05.01.10, 01:51
                Widzisz, a ja sie glowilem, ze jak np. mam
                01000010 (42h ;d) i chce zapalic pierwszy piksel czyli
                11000010 (C2h) to gdzie tu jest jakas ochrona - po prostu myslalem w skali
                bitowej od razu, a nie tym bajtem, i do glowy mi nie przyszl zeby dac np 80h.
                Czyli ty niby masz nedzne umiejetnosci tlumaczenia, a trafiles jeszcze na kogos
                niepewnego, ktoremu zawsze wydaje sie ze czegos pewno nie zauwaza i ze jego
                myslenie ktore niby pasuje pewno jest niekompletne big_grin (z reszta bylo-
                niekompletne o to, ze mozna to wszystko zepsuc...)

                Ladne pare lat temu nie uczyli, gralismy w Zuzel... Sam pewne podstawy
                poznawalem, potem dopiero na studiach to bylo (ale tych tylko "liznelem" bo
                siana zabraklo uncertain)
      • Gość: marcin Re: Od kuchni - Amiga i PC, czemu Amiga nie mogła IP: *.wmdata.fi 04.01.10, 14:58
        Pamiętam że była koncepcja wyświetlania trybu true color (24bity) na kościach AGA w rozdzielczości 256x256
        Polegało to na wyświetlaniu w każdej linii wszystkich kolejnych rejestrów kolorów od 1-256, na końcu każdej linii cooper (koprocesor video) zmieniał zawartość wszystkich 256 rejestrów na nowe.
        Tworzenie grafiki odbywało się poprzez ciągłą modyfikacje listy rozkazów coopera, co niestety też było czasochłonne (256 x 3 bajty na rejestr + jakieś cuda z bankami).
        Niestety nie pamiętam nazwy tego trybu, wiem że został użyty w jakiś demach.
    • Gość: shalick Re: Od kuchni - Amiga i PC, czemu Amiga nie mogła IP: *.internetdsl.tpnet.pl 29.12.09, 10:51
      Programistyczny bełkot z rana jak balsam na ciało!

      (I mam na myśli "programistyczny bełkot" w jak najlepszym znaczeniu)

      Jestem pewien, że nie mówię tylko w swoim imieniu, kiedy stwierdzę, że chcemy
      więcej. Może rozwinięcie niedawnego postu o wykorzystaniu pamięci w grach? Może
      coś jeszcze innego?
      • aihs Re: Od kuchni - Amiga i PC, czemu Amiga nie mogła 29.12.09, 13:00
        Zdecydowanie posty j_uk_dev są najciekawsze na tym forum, dlatego też czekam na
        więcej (z naciskiem na wątek o pamięci właśnie).
      • j_uk_dev Re: Od kuchni - Amiga i PC, czemu Amiga nie mogła 29.12.09, 13:41
        Napiszę na pewno więcej jak wrócę do Anglii smile
        • Gość: argh Re: Od kuchni - Amiga i PC, czemu Amiga nie mogła IP: *.bb.sky.com 03.01.10, 20:44
          do zobaczenia za roksciana
          • Gość: PiotrStark Re: Od kuchni - Amiga i PC, czemu Amiga nie mogła IP: *.internetdsl.tpnet.pl 03.01.10, 23:59
            Aż łezka z oka poleciała.
    • Gość: Waupsztas Re: Od kuchni - Amiga i PC, czemu Amiga nie mogła IP: *.chello.pl 04.01.10, 22:49
      To musi być wspaniałe, bo nic nie rozumiem...

      "Obraz reprezentowany był przez tzw. bitplany, przez co pojedynczy bajt
      reprezentował po jednym bicie 8 kolorów."

      Co to właściwie są bitplany? Jak jeden bajt może reprezentować 8 kolorów
      jednocześnie (???)

      "W ten sposób potrzebne było kilka buforów pamięci by reprezentować pojedynczy
      piksel, a dokładnie tyle buforów (bitplanów) ile bitów reprezentowało kolor. "
      Co to są bufory pamięci? Dlaczego do pojedynczego piksela potrzebne było kilka
      bajtów? Czyżby pojedynczy piksel miał 8 kolorów jednocześnie?!

      Dalej już na szczęście bardziej zrozumiale.
Pełna wersja