Moje wypowiedzi mają w 100% charakter opinii o które prosiłeś forumowiczów, zanim postanowiłeś się na nich obrazić gdy te opinie w smak Ci nie były. Kolejny FAIL.

to cudo by się rozeszło jak ciepłe bułeczki nawet jakby dzisiaj wyszło

a że wolniejsze od UAE to co? UAE nie ma duszy...

Chodziło mi raczej o kwestię typu chunky2planar gdy mówiłem o procesorze, w CD32 Akiko sprzętowo wykonuje tą operację i gry 3D działają szybciej, biorąc pod uwagę przewagę ilości gier 3D tryb planar mógłby być kulą u nogi, chyba, że byłby układ robiący to sprzętowo, druga sprawa to ilość operacji na danym kolorze. W trybie chunky chcąc zmienić kolor piksela wpisujemy nową wartość do danej komórki (jedna operacja procesora) i to wszystko, w trybie planar ile jest planów, tyle komórek trzeba zmienić wykonując operacje na bitach, np w trybie 64 kolorowym jest 6 planów, co oznacza, że trzeba zmienić bity w 6 komórkach (6 operacji).

Zresztą jak ktoś chce poczytać o tych trybach zapisu grafiki, ich wadach i zaletach i zna angielski to zapraszam tutaj: http://stason.org/TULARC/pc/amiga/faq/3-1-What-are-chunky-and-planar-displays.html

Tryb planar ma sens gdy ilość bitów określających rozmiar tablicy kolorów jest mniejszy niż iloczyn liczby 8, ale jak już mówiłem ten tryb był stosowany by oszczędnie przechowywać grafikę w pamięci, a dzisiaj mamy jej tyle, ze nie ma potrzeby stosowania takich operacji.


Rafqc coś ty się przyczepił do tych kineskopów

Arkadyy, ty chyba trochę nie zrozumiałeś o czym ja pisałem, bo na pewno nie pisałem o jakości obrazu. Obraz może być żyleta i nawet ładnie wyglądać, ale na monitorze lub TV LCD ten obraz nie będzie wyglądał tak jak na starym zestawie AMIGA + TV CRT lub AMIGA + dedykowany monitor CRT, większość z nas wychowała się na takich zestawach i obraz przez nie generowany ma charakterystyczny wygląd (głównie ze względu na odbiornik). Wojox jest chyba jednym z takich użytkowników, którzy lubią pracować przy takim obrazie, niestety mimo, że można uzyskać zbliżony efekt za pomocą filtrów na winUAE na LCD, to jednak zawsze pozostanie on tylko "zbliżony" a dla niektórych "prawie" robi dużą różnice. Jednak nie jest to wina emulatora a samego monitora LCD, który nie jest w stanie idealnie odwzorować takiego efektu (i to jeszcze przy skalowanej grafice) jaki wywoływał luminofor, poza tym nie wiem czy wiesz, że ilość kolorów, które potrafi wyświetlić LCD jest ograniczona, najwierniej oddają kolory odbiorniki CRT, LCD mogące im dorównać kosztują ciężkie pieniądze.

okazało się że na niektórych widać pikselozę kwadraty na całym ekranie

lol, skonfiguruj sobie kodeki

Jedyna przewaga dekodowania sprzętowego to szybkość działania, procesor robi wszystko krok po kroku a sprzętowy dekoder ma zazwyczaj kilka jednostek, które działają równolegle i nie potrzebują takiej mocy obliczeniowej by wykonać to samo co procesor, najprostszym przykładem są odtwarzacze mp3, które działają na jednym paluszku 8 godzin gdzie do dekodowania tej muzyki trzeba było mieć coś w stylu pentium 66MHz i więcej w zależności od parametrów mp3. Przewagą dekodowania programowego jest możliwość jego konfiguracji i rozszerzania, po prost dogrywasz co trzeba. Jeśli coś działa lepiej na sprzęcie niż w programie, to znaczy, że program jest niedopracowany lub brakuje mocy obliczeniowej.



Ostatnia modyfikacja: 12.04.2011 21:48:17

Domyslam sie :), przewaga trybu chunky jest tam gdzie trzeba duzo operowac na pojedynczych pikselach (nie tylko gry 3D), natomiast w przypadku gdy operuje sie glownie na blokach pikseli bedacych wielkorotnoscia 8,16,32 pikseli, to praktycznie nie ma wielkiej roznicy, baa, w trybie planar mozna nawet zaoszczedzic i zwiekszyc wydajnosc operacji graficznych, bo grafiki zrodlowe nie musza byc dok. w takiej samej ilosci bitplanow jak ekran. Oczywiscie to dt. wyswielania w trybach maks. maksow. 8 bit, powyzej, tryby bitplanowe nie maja zwyczajnie sensu...



Ostatnia modyfikacja: 12.04.2011 22:49:23

Bitplane nie ma sensu dla 8bit trybów. W grach 3d widać to ewidentnie a w 2d się maskuje tylko i wyłącznie dlatego że blitter jest bardzo wydajny i z łatwością obsługuje tryb planar. Gdyby to procesor miał całą grafikę mielić to natychmiast okazałoby się że nawet dla 5bit trybu te 3 bity przeboleć i lepiej dać jeden piksel w jednym bajcie. A ostatecznie te 3 bity można by było tak czy siak wykorzystać jeśli ktoś uznałby że mu koniecznie potrzebna ta pamięć bo nie byłyby tracone przecież (no chyba że układ byłby głupio zaprojektowany...)

podobnie jest w PC. Kiedyś się zastanawiałem jak zmieniłem kartę z Virge'a który miał 24bit na VooDoo Banshe który miał 24bit i 32bit po co te 32bit skoro kolorów jest identyczna ilość... Benchmarki szybkości operacji GUI szybko pokazały że te 1/4 pamięci mimo że się marnuje to 32bit FTW :)



Ostatnia modyfikacja: 13.04.2011 11:21:53

W grach 3d widać to ewidentnie

bo tu operuje sie najwiecej na pojedynczych pikselach.

blitter jest bardzo wydajny i z łatwością obsługuje tryb planar. Gdyby to procesor miał całą grafikę mielić to natychmiast okazałoby się że nawet dla 5bit trybu te 3 bity przeboleć

w tym sensie, nie ma to znaczenia, czy to blitter, czy procesor, chodzi tylko o to, czy uklad bedzie operowal na pojedynczych pikselach, czy na blokach pikseli bedacych wielokrotnosica 8,16,32x1 pikseli w (pionowe nie ma znaczenia) np: jezeli beda to 32x1 bitowe bloki, wydajnosc bedzie identyczna w trybie planar i chunky dla 8bit trybu wyswietlania, wystarczy jak takich operacji bedzie wiekszosc, zeby tryb chunky nie oplacal sie dla 8bitowego trybu wyswietlania.

porownanie wyswietlania 24bit do 32bit nie ma z tym nic wspolnego.



Ostatnia modyfikacja: 13.04.2011 11:58:31

jezeli beda to 32x1 bitowe bloki, wydajnosc bedzie identyczna w trybie planar i chunky dla 8bit trybu wyswietlania, wystarczy jak takich operacji bedzie wiekszosc, zeby tryb chunky nie oplacal sie dla 8bitowego trybu wyswietlania.

Zbytnio upraszczasz. Jezeli wezmiesz jeszcze pod uwage np. cache procesora, to nagle okaze sie, ze jednak tryb chunky sie bardziej oplaci.

Jezeli wezmiesz jeszcze pod uwage np. cache procesora

hmm. w jaki sposob wezme pod uwage ?

Pixle kontra ładne bitplanowe przejścia i tego nie da się zasymulować programowo w sprzęcie typu chunky-pixel....
Bitplany to nie taki przestarzały pomysł. Weź sobie 8 przeźroczystych kartek i na każdej rysuj różne rysunki, wyciąganie i wkładanie tych kartek powoduje niesamowite efekty których próżno szukać w trybie chunky-pixel. Gdyby dodać dzisiejsze prędkości to gry (oprócz 3D) wygladaly by bajecznie. Mi osobiście przejadły się "zabijanki" 3D,,, a to dzisiejsza domena...

Bitplany w ogóle nie są już potrzebne. W 3D można zrobić więcej, lepiej, szybciej i ładniej. Weź sobie 8 płaszczyzn, oteksturuj je "różnymi rysunkami", ustaw je sobie w przestrzeni równolegle, prostopadle, jak chcesz, poruszaj je wzgledem siebie i możesz mieć i parallax scrolling i bóg wie co jeszcze, nawet te wyciąganie kartek przejrzystych.

8 bitowe tryby chunky tez sa w ogole niepotrzebne, kto ich dzisiaj uzywa :). Operowanie na pikselach przy uzyciu CPU tez nie jest juz potrzebne/niezalecane w epoce jednostek przetwarzania pikseli, czyli tak od ponad 10 lat :D

Świat amigowy zmienia się... i to na gorsze. Jak widzę takie teksty jak ten do Ciebie to mam ochotę duże Atari sobie kupić (małe już mam). A za chwilę będą Cię prosić o pomoc z WinUAE to taka ironia losu amigowca.



Ostatnia modyfikacja: 13.04.2011 18:45:26

Dajmy na to że mamy obok siebie dwie hipotetyczne amigi 500/600, jedna z trybem chunky zaproponowanym przezemnie a druga oryginalny planar.

1. rysowania ukośnej linii, 10 pikseli do wyświetlenia
a) chunky: wyliczenie adresu zapisu i 10 operacji zapisu do pamięci
b) planar: wyliczenie do którego segmentu się odwołujemy i przygotowanie bitu który będziemy zmieniać, wczytanie segmentu, zapodanie odpowiedniej operacji logicznej (zapewne motorola ma do tego jakieś fajne instrukcje ale nie wykonują się one w czasie jednego taktu i tak...), zapisanie całego segmentu. I tak 5 razy dla każdego bitplanu... W sumie 10 pikseli da 100 operacji na pamięci

2. przykład z gry: rysowanie przeźroczystego obrazka 32 x 32 w pozycji (4, 4). Obrazek leci z innego obrzaru pamięci i jest zorganizowany tak samo jak tryb wyświetlania
a) chunky: 32*32 = 1024 operacji odczytu pamięci i 1024 operacji zapisu pamięci. Ale że mamy procesor z szyną danych 16bit to mamy operacji tylko 1024 w sumie. Bit przeźroczystości bierzemy z tych "zmarnowanych" 3 bitów per piksel i w razie gdyby był aktywny to operacji zapisu nie wykonujemy więc te 1024 to w przypadku gdy obrazek jest 100% opaque a w przypadku gdy jest przeźroczysty to operacji jest tylko 512

b) planar: aby nie dobijać zakładam że obrazek siedzi ładnie zaalignowany w pamięci a więc 32x32x6 (6 bo jeszcze bit przeźroczystości) to będzie 5120 bitów, ale że 16bit procek to czyta po 16 bitów na raz więc operacji 384. Szybciej? Zobaczymy...
Pozycja 4.4 nie jest optymalna (optymalna trafia się tylko 1/8 przypadków...) więc trzeba wczytać po 48 bitów * 32 linie to daje 480 operacji odczytu. Teraz porównujemy bity i zapisujemy czyli kolejne 480 operacji na pamięci. W sumie 384 + 480 + 480 = 1346 operacji. W najlepszym przypadku gdy ładnie umieścimy piksele to otrzymamy 384 + 320 + 320 = 1024 operacje

Można też sprawdzić czy w ogóle trzeba rysować całe dwa segmenty (16 pikseli w poziomie). W najlepszym przypadku gdzie nie trzeba nic rysować to będzie 384 operacje. Oczywiście ta oszczędność wiąże się z implementowaniem dodatkowego sprawdzania czy akurat 16 pikseli w linii jest przeźroczyste co samo w sobie zajmuje czas procesora i się może nie opłacać. W chunky sprawdzamy i tak i oszczędność wychodzi sama.

Na trybie planarnym Amiga ma "oszczędność" maks 120KB pamięci w trybie 640x512. Jeśli doda się EHB to będzie 64KB. Oczywiście pamięć tą można wykorzystywać, jak choćby w podanym przezemnie przypadku gdzie można wrzucać tam dodatkowe informacje czy jako liniowa pamięć na rzeczy mniej potrzebne. Te 120KB z ekranu i tak się odczyta milion razy szybciej niż np. dyskietkę :)

No i w trybie chunky nie ma szans aby się kolory dziwne robiły jak w planarnym gdzie jak się nie wyrobiłeś z wszystkimi operacjami na wszystkich bitplanach to kolory migały

Amiga była tak zrobiona, ale to nie znaczy że odrazu to dobry pomysł był... W AGA jakakolwiek oszczędność pamięci była 0 bajtów a przeładowanie operacjami jeszcze większe niż OCS/ECS. Całkowity bezsens wynikający z tego że łatwiej było ECSa rozszerzyć niż robić od nowa logikę dla chunky...



Ostatnia modyfikacja: 13.04.2011 19:36:38

A tatko mówili... (w momencie 21:30) -> klik

(dobra, z pytaniem zaczyna się od 20:40)



Ostatnia modyfikacja: 13.04.2011 20:15:04

Nie zapominaj o tym że układy takie jak OCS,ECS czy nawet AGA projektowane były w czasach kiedy nikomu nie przyszło do głowy że będą robione programy rozrywkowe chodzące w systemie chunky.A w sumie to one były zrobione do innych zadań co im wychodziło bardzo dobrze.I nie zapominaj o takich wynalazkach jak karty graficzne na których są takie same procki jak na kartach do pc. :D

Widac, ze nie rozumiesz trickowego programowania na Amidze :). Na Amidze pewne rzeczy robi sie zupelnie inaczej niz na PC/XT/AT/386, w ogole nie liczy sie pewnych masywnych operacji...

Ad.1 zalezy czy rysujesz linie pozioma, czy linie pozioma dla wypelnienia - wtedy jeden piksel w lini poziomej. Przy czym ilosc operacji dla CPU ogranicza sie do wyliczenia i zapisania odpowiednich rejestrow blittera - taki powiedzmy koprocesor map bitowych dzialajacy rownolegle do CPU. Zobacz sobie tez efekty scenowe o nazwie glenz vectors, zeby moze zrozumiec, dlaczego w wielu przypadkach np: przezroczystosc nic nie kosztowala, tyle co ustawienie odpowiedniej palety barw.

Ad.2 znow ten sam problem, rysowanie obrazka z 1 bitem przezroczystosci kosztowalo CPU tyle co wlasciwie zapisanie odpowiednich rejestrow blittera... Nawet jak wyswietlany jest obraz w 8bit planar, to obrazki zrodlowe moga miec mniej.. tajemnica kryje sie w organizacji i zarzadzaniu paleta barw...

Kolejna sprawa. Uklady spec. dysponowaly specjalnym trybem wyswietlania tzw. dual playfield, odp. 8(OCS,ECS) i 16(AGA) kolorowym... mozna bylo zrobic na tym fajna plynna przezroczystosc, efekty parallax ze sprzetowym skrolingiem itd.. reszte robilo sie duszkami, copperem, blitterem, muzyczka grala... ;). Gdyby robic takie przeliczenia jak proponujesz, wyszloby, ze jest to niemozliwe na 7Mhz 68000 i golym 8bit chunky - sam skrolling 50fps zjadlby cala moc, a co mowic o reszcie...

co do Twoich wyliczen na CPU; to spojrz na to prosciej.

pozycja 0,0. 32x1x8planar i 32x1x8chunky wymaga dok. tyle samo odczytow i zapisow CPU na ekranie. W planar masz 1 odczyt/zapis x 8bpp dla 32 pikseli, w chunky 8 odczyt/zapis, po 4 piksele kazdy, dla 32 pikseli. Tyle samo dla obu trybow. Dla 1bit przezroczystosci w planar tez nie trzeba odczytywac lub zapisywac za kazdym razem.

Co do wyrownania, w planar co 32 piksele, chunky co 4 piksele, 8x czesciej, tylko znow sa warunki np: ile bitow ma grafika zrodlowa i obszar docelowy - najczesciej jest to mniej niz 5 bitow, wiec traci to na znaczeniu w tym porownaniu.

Dochodza jeszcze detale zwiazane z obliczeniem pozycji, wyrownaniem...

Oczywiscie takie operacje na A500/600/1200 robi sie blitterem, ktory wyrownuje wszystko do 16bitow, a nie 32bitow.

Tryby chunky moze w A1200 przydalyby sie bardziej niz kolejne 2 bitplany, coz, poszli po namniejszej lini oporu zeby pokazac 256 kolorow z palety 16mln. w 1992roku, dobrze to i zle, choc watpie zeby dodanie golego trybu 8bit chunky cos znaczaco poprawilo, TO STANOWCZO ZA MALO!!! przy tym CPU - to nadal lata 80, operowanie przy pomocy CPU na pikselkach, w polowie lat 90 to bezsens???, wzglednie prosty koprocesor robi to lepiej i znacznie szybciej... Patrz.N64 w 96 roku. Tak mniej wiecej powinna wygladac A1300, tylko z 68k, nawet gdyby byla wolniejsza, ale miala nowy koprocesor graficzny do chunky, to juz cos :)



Ostatnia modyfikacja: 14.04.2011 00:43:55

Ja nie twierdzę że Amiga nie radzi sobie dobrze z planarnymi wynalazkami tylko że gdyby nie było blittera i kolegów to by się CPU prędzej zapłakał niż płynnie gry wyświetlił czyli tak jak to jest na Atari ST

Przykładem dobrego kompromisu wydajność vs ilość pamięci jest VGA. Tam masz tryby planarne dla wysokich rozdzielczości a tryby 8 bitowe są tylko i wyłącznie chunky. Blitter i inne funkcje wspomagające pracują zarówno w trybach planar jak i chunky i problemu nie ma. I to wszystko już w 1987 roku... 5 lat przed wyjściem A1200/A4000 :o

Dać to się dało, ale zapewne tak było taniej a taniej = lepiej dla firmy która miała problemy finansowe...

Więc o co chodzi? Ano o to że chunky i tak dużo lepiej by się w amidze sprawdził. Że są tricki do bitplane'ów to nie znaczy że nie byłoby podobnych jak nie lepszych dla chunky...

VGA z 1987r. nie ma blittera, to prosty bufor ramki - 320x200x8bit najczesciej. Taki tryb chunky to bylaby porazka w Amidze, do tego potrzeba min. pelnego procesora 68020/16Mhz (nie EC) i 0.5MB RAM nie najwolniejszej pamieci, dla najnizszej amigowej rozdzielczosci 320x256, zeby w ogole dalo sie uzywac.

To byl kompromis, zeby Amiga byla uzywalna na 68000/7Mhz 256/512/1024KB. Tryb chunky praktycznie jest nieuzywalny na takiej Amidze. 4 proste bitplany z VGA to znow za malo kolorow (16), a dodanie jednej wiecej mapy bitowej nie obciaza 2x systemu.., za to daje 2x wiecej kolorow (32), to duzo wiecej, dodano jeszcze kolejna mape bitowa i powstal tryb EHB (64), HAM, DualPlayfield, duszki..., plus do tego copper i nagle robi sie na ekranie setka kolorow... System nadal nie jest tym strasznie obciazony...

Blitter (najszybszy uklad) mogl teoretyczna przeniesc ok. 4MB/s, jak sobie wyobrazasz obsluge trybu 8bit chunky tym ukladem, przeciez to masakra, caly komputer zamulilby sie na kilku prostych operacjach ?. Pozostaje wiec powiekszyc piksele, to wlasnie robi sie tworzac tryby chunky w trybach planar, tylko zamiast 8bitow jest 4-5bitow.. hmm. choc mozna tez zrobic 12bitow, trick...:). Reasumujac. Tryb 8bit chunky nie mial racji bytu na Amidze. Wszystko staloby w miejscu i taka bylaby zabawa w tym trybie, na tym polegalby ten trick z trybem chunky, ktory wg. Ciebie "lepiej by sie sprawdzil", tylko napisz moze do czego, bo na pewno nie do tego wszystkiego co mozna zobaczyc na "golej" Amidze 500/600/1200 ? :)

Karty turbo min. 68030/50Mhz upowszechnily sie w 1994 roku, wtedy potrzebna byla nowa Amiga z trybami chunky, wieksza i szybsza pamiecia CHIP, jakims nowym koprocesorem, bo operowanie procesorem w trybach chunky nigdy nie mialo przyszlosci... nawet w 1995 roku.



Ostatnia modyfikacja: 14.04.2011 03:10:06

I znowu...
Nie mam nic do planarnego trybu w OCS/ECS tylko do 8bit planarnego trybu w A1200! Dla blittera, coppera jest wszystko jedno na jakich danych operuje. Duszki można było równie dobrze zaprojektować dla chunky. AGA powinna mieć chunky 8bit i nie przekonasz mnie że nie...

Problem był taki że x86 zabijało sprzedaż wszystkiego innego i już w 1990 było wiadomo że dobrze nie będzie... nie patrzono w przyszłość aż tak mocno jak w <1985... Za to patrzono na cenę, parametry papierowe i czas wydania sprzętu. Chunky tutaj nic nie dawał...

a jak przy VGA jesteśmy to akurat ta karta była bardzo fajna i mimo swojej niby prostoty doczekała się całej kolekcji sztuczek które dawały sporego kopa w wielu operacjach typowych dla gier 2d i poligonowych/wireframe 3d. Jak te gry by chodziły z takim VGA na 12MHz 68EC020 to nie wiem bo nie widziałem w sumie gier na 286 a'la 12MHz tylko dopiero 386 33MHz...



Ostatnia modyfikacja: 14.04.2011 23:27:34

Dla blittera, coppera jest wszystko jedno na jakich danych operuje. Duszki można było równie dobrze zaprojektować dla chunky. AGA powinna mieć chunky 8bit i nie przekonasz mnie że nie...

Nie jest wszystko jedno, dla blittera wazne jest na jakich danych operuje, bo dostepny operuje na slowach i bitach(operacje logiczne), takze niezbedne w tym momencie jest skonstruowanie nowego blittera. AGA powinna miec tryby chunky, ale nie gole 8bit chunky z indeksowana paleta - maly pozytek i przezytek, mogli sobie ten nedzny tryb 8bit z VGA/87 darowac, tylko 16bit chunky (16 bit w konfiguracji 4-4-4-4(alfa), 5-6-5...) z nowym chunky blitterem... O tym kazdy wie.



Ostatnia modyfikacja: 15.04.2011 13:36:06

a jak przy VGA jesteśmy to akurat ta karta była bardzo fajna i mimo swojej niby prostoty doczekała się całej kolekcji sztuczek które dawały sporego kopa w wielu operacjach typowych dla gier 2d i poligonowych/wireframe 3d. Jak te gry by chodziły z takim VGA na 12MHz 68EC020 to nie wiem bo nie widziałem w sumie gier na 286 a'la 12MHz tylko dopiero 386 33MHz...

VGA w 1992-3 roku to juz byla staroc. W 1995 roku takie gole 8bit chunky nie nadawalo sie praktycznie do czegokolwiek - nawet w OS. Nikt nie konstruowal wtedy sprzetu z mysla o trybie wyswietlania 8bit chunky. Na Amidze tez dalo sie robic ciekawe rzeczy, nawet w 3D. Na szybszych CPU, od 040 w gore, ladnie latala juz konwersja c2p do ham8... co w takim przypadku daje gole 8bit chunky, bez konwersji ani rusz, a skonczy sie tylko na 256 kolorach ?:)



Ostatnia modyfikacja: 15.04.2011 14:07:40

mów co chcesz ale VGA to dobra konstrukcja. Dlatego też chodzi na niej każda gra z DOSa czy to ta z 1987 czy 1997 :D Pulpit 800x600 256 kolorów na VGA też lepiej chodzi od PAL High Res Laced na AGA...

Co do 16bit to gry 3d w 16bit to albo z akceleratorem 3d jak w PlayStation albo przy procesorach a'la 060 grubo ponad 100MHz... Gdyby Commodore nie padło to kolejny chipset miał mieć chunky i funkcje do wspomagania 3d...

mów co chcesz ale VGA to dobra konstrukcja. Dlatego też chodzi na niej każda gra z DOSa czy to ta z 1987 czy 1997 Pulpit 800x600 256 kolorów na VGA też lepiej chodzi od PAL High Res Laced na AGA...

to raczej dosc kiepska konstrukcja, praktycznie nieuzywalna w wyzszych rozdzielczosciach - 8bit chunky.

PS. VGA to byla dobra, w czasach 386 i 320x200, na 486 to juz krolowala SVGA z trybami VESA 16bit...

Co do 16bit to gry 3d w 16bit to albo z akceleratorem 3d jak w PlayStation albo przy procesorach a'la 060 grubo ponad 100MHz..

16bit hicolor (chunky) jest najlepsza z minimalnych opcji dla 3D, to 8bit chunky w VGA jest dziwactwem trudno uzywalnym w 3D. grubo??? ponad 060/100Mhz do 16bit, to nie zgadza sie z tym co napisales o 8bit chunky, wg. Ciebie jest uzywalny juz na 020/14Mhz :), a 16bit uzywalne dopiero na grubo ponad 060/100Mhz ????. Zastanow sie czasami nad tym co chcesz napisac, bo akurat 16bit jest wydajniejszym trybem do 3D, jezeli to ma byc cos wiecej niz tylko prosty teksturowany szescianik i rozne tego wariacje.

No, kończcie oftopa i do domu. Zamykamy.