Názory k článku Grafický subsystém počítačů Amiga II

Jenom drobné upřesnění.
Nejedná se o Pixel Brothers, ale všem Amigistům známá Bitmap Brothers, jejichž hry jsou prostě legendární.

-=[ Amiga forever ]=-

+1 . .

Však se na Vás nikdo nezlobí :)
Když už člověk stráví 15 let s Amigou, na lecos si vzpomene.
A i česká scéna byla úchvatná partička :) že mám pravdu Marwyne, Jupitere, uF0, Fractale, FiDo, Shamane, Lopolo, Exie, Trixie, Zeku a spousty spousty dalších :)

Jojo. Na Amigu, lidi kolem ni a Amiga party nezapomenu ;) Mezi ty dalsi patri treba Lahve, Holyna, Wertexx, …

ach muj dobrys boze .. to byly casy!

nie je nad to si zapnut emulator Amigy v mobile a zaparit nejaku dobru hru :) skoda len ze emu AtariST nikto neportoval na S60

Jaka je vlastne technicka motivace pro planarni rezimy? Nenapada me zadna rozumna vyhoda (*), spis jenom komplikace. Jak je to vlastne se sekvencnim pristupem do pameti od sequencery/scanneru graficke karty? Nemusi kvuli tomu vygenerovat velke mnozstvi nahodnych pristupu (ale tehdy asi nebyl nahodny pristup do RAM tak velka zatez, jako s modernima pametma)?

U dedikovanych grafickych karet (jako VGA) byla pamet zadratovana tak, ze s planarnim pristupem pocitala (kazdy plan byl v jendom pametovem chipu, takze cteni bylo vlastne sekvencni a ‚planarita‘ byla jenom zpusobena divnym mapovanim pametovych chipu do pametoveho prostoru). Ale u architektur se sdilenou grafickou pameti a volitelnym mnozstvim planu si takovy postup dovedu jen tezko predstavit.

(*) asi by slo vyuzivat vhodne zvolene palety a pak dosahovat cilene zmeny jen zmenou mensiho mnozstvi planu a tim setrit praci. Take by slo asi vyuzit nezavisle scrollovani jednotlivych planu na cool efekty. Ale oboje me prijde jako mala vyhoda v pomeru ke komplikacim.

Plany se obecně používaly zejména k nacpaní více dat do malého kusu adresového prostoru. Nevím jak na Amize, ale na PC to často byl jediný způsob, jak adresovat grafiku, protože pokud by to nebylo realizováno přes plany, takový 640×480×4 by zabral 153KB, což se nevešlo do jednoho segmentu. Při převodu na plany byl výsledkem zabraný prostor 38KB, což se v pohodě do 64KB segmentu vešlo (vešla se tam i SVGA 800×600)

U VGA mě napadá ještě jedna vlastnost a to, že v základním nastavením bylo uspořádání kompatibilní s dvoubarevnými režimy.

> Plany se obecně používaly zejména k nacpaní více dat do malého kusu adresového prostoru.

To je ale spis specifikum VGA, nez obecna vlastnost planarnich rezimu, ne?

Mezitim ne napadly dva mozne duvody:

1) 3, 5 a 6 bpp mody by sly v ‚standardnim‘ neplanarnim rezimu realizovat jen tezko.

2) pokud ma pametovy chip podobnou sirku sbernice jako procesor a srovnatelnou rychlost, tak nema vyznam mit pametove chipy zapojene prokladane (RAID0-like), jako je tomu v soucasnych pametech, ale klidne se muzou zapojit do pametoveho prostoru za sebe, coz asi bude technicky jednodussi.

No jistě, s maximálně 6bpp režimy, které Amiga při svém uvedení měla, by chunky grafika byla neefektivní.

Na VGA byly plány za účelem primitivní akcelerace. Když jsi chtěl vypsat třeba jeden znak 8×8 do 16-barevného grafického módu, tak při planární grafice k tomu stačí 8 zápisů do paměti. Při pixelové grafice by to bylo 32 zápisů. Ale jinak s těmi plány byly jen těžkosti, tak plány na SVGA byly odstraněny. Na vměstnání velkého obrazu do malé paměti nepotřebuješ plány, SVGA to dělá přes okno.

Tady zase někdo dělá chytrého

Režim 6Ah (Int 10h) je tedy VGA v 800×600?

Jinak 16barevné režimy byly vždycky 4 planární i na SVGA. 1024×768 kombinuje jak plany, tak okna (přepínání bank). Užij si to.

Planární grafika byla méně náročná na paměť a pokud jste měli slabší procesor, pak se s ní i lépe pracovalo. S planární grafikou se dá dělat docela dost zajímavých věcí, které by jinak byly velmi náročné na přesouvaná data a výkon procesoru. A toho tehdy nebylo nazbyt. A samožejmě je naopak řada věcí, které jsou s planární grafikou prakticky nemyslitelné (prakticky vše co pracuje po pixelech).

Navíc Amiga měla blitter, který právě (a vlastně jen a pouze) s planární grafikou dokázal zázraky. Přenášení dat v obdélníkové oblasti (to jest vykreslení spritu) bylo rychlé a díky planárnímu režimu jste přenášeli jen platná data. Při 8 barvové grafice to je úspora 5/8 přenášených dat.

Z popisu blitteru to vypadá, jako by Amiga měla koprocesor pro efektivní vektorovou grafiku. Ve skutečnosti to nebylo nijak zvlášť slavné, protože vektorová grafika pracovala vždy jen v jednom plánu. Pokud jste tedy měli 32 barvový režim, těch úseček jste museli malovat více – v každém bitplánu zvlášť. To samé zmíněné vyplňování, to fungovalo rovněž po plánech. Zkrátka, papírový výkon na tehdejší dobu slušný, ale při 4 plánech ve skutečnosti jen čtvrtinový.

Vektorová grafika se na Amize používala zejména v demech a hrách, kde se vystačilo s kreslením do jednoho plánu. A nemusí to nutně znamenat jednobarevně, protože je možné kombinovat třeba 5 posledně vykreslených plánů a dělat tak různé efekty dohasínání (každý plán dostane jinou barvu) nebo rozostření (barva se stanoví podle počtu plánů s nastaveným bitem) atd.

Ani v tomto ani v předchozím díle jsem si nevšiml informace o tom, že v závislosti na rozlišení se mění i výkon procesoru MC68000. Amiga byla navržena tak, aby se v přístupu do paměti procesor MC68000 střídal s koprocesory. Jenže při generování grafiky se to občas nestíhalo.

Pro Amigu 500 platilo, že režim 320×256×4bpp bez problému stíhal vykreslovat ve svém cyklu. Při vyšším rozlišení by již koprocesor nestíhal a tak k paměti přistupoval i v cyklech, které byly jinak vyhrazeny pro MC68000. Pokud ta v té chvíli chtěla přistupovat do paměti, byla pozdržena. Při vysokém rozlišení (320×256×6bpp) byl rozdíl ve výpočetním výkonu již viditelný. Minule zmíněná Fast RAM pak měla tu výhodu, že se při přístupu do ní MC68000 s nikým nehádala a tudíž ani při vysokém rozlišení obrazu nebyla zpomalována.

autorovi dekuji za super clanky.

mohl by mi autor ci nekdo znaly prozradit, jakto ze pomoci bitovych rovin bylo snadne udelat efekt paraelne se pohybujiciho pozadi jako je ve hre Shadow of the beast ?

popsat v jakem modu to bylo nejsnadnejsi ale hlavne jake operace probihaly v palete barev ci na bitovych rovinach ?

Řekneme, že obrazovka začíná v paměti na adrese A, řádek má L bytů, z nichž se jich V zobrazí, a má se zobrazit posunuto o 0 pixelů doleva.

Až dosud klasika.

A teď jste pomocí copperu v rámci zatemnění na řádku 20 řekli, že se má obrázek zobrazit posunutý o 4 pixely.

Opět pomocí copperu jste při zatemnění na řádku 40 řekli, že posun je 0 pixelů, ale změnili jste adresu obrazové paměti o 1 bajt. Čili posun o 8 pixelů.

Atd.

Je to jakobyste obrázek horizontálně rozstříhl na 11 pásků a každým z nich mohl libovolně posouvat. Dokonce ani v paměti nemusí být za sebou.

Tak to máte pozadí a popředí. To pomocí dual playfield a copperu dáte nejprve do pozadí a na určitém řádku naopak do popředí (takže kameny v dáli jsou za hlavním obrazem, plot dole je pak před obrazem).

Hlavní postavu a potvory naanimujete klasicky v druhém playfieldu. Můžete i přihodit nějaké další objekty. Na další efekty se dají použít sprity.

Jinak s pozadím se dají dělat divy, stačí dvoubarevné, dithering a změna barvy pomocí copperu (postupně na řádku změním odstín) udělá zázraky. Pro „hlavní grafiku“ tak zbydou 4 plány a to je 16 barev.

Další populární trik je založen na starém známém „akce se odehrává jen na malém místě, nahoře je nebe, kam žádná střela nedoletí“. Takže si na horní část obrazovky uděláte dual playfield, kde jedno bude ubíhající pozadí (simulace vodorovné plochy, viz výše) a druhé budou nějaké jiné pozadí, například domy (tedy svislé plochy). V jistém místě pak pomocí copperu změníte rozložení playfieldu, necháte si jen jeden typ pozadí (který se hodí více) a v druhém playfieldu budete bojovat, střílet atd. Pak zase na nějakém řádku změníte playfieldy a budete simulovat „popředí“.

Ve zkratce:
1. Můžete měnit odkud se berou grafická data a libovolně je po pixelech posouvat (o to se stará zobrazovací koprocesor, v paměti nic neposouváte)
2. Obrazová data v paměti nemusí vypadat jako na obrazovce – zobrazovací koprocesor ví, kde data začínají, kolik z nich má zobrazit (viditelná část) a o kolik má pak skočit dál dopředu aby se dostal na další řádek. Zjednodušeně řečeno, v paměti můžete mít obrázek mnohem větší, než co pak koprocesor vlastně zobrazí.
3. Máte copper. Tedy můžete všechna nastavení kdokoliv změnit, v závislosti na poloze paprsku. Asi znáte standardní copper efekt, že? Máte dvoubarevný obrázek (dvě barvy v paletě) a pomocí copperu pak na každém řádku měníte obsah barvové palety – takže na obrazovce vidíte duhu. Takto můžete měnit nejen barvy ale i rozložení bit plánů, bitové posuny atd.

oh. tak takhle to je. ja jsem na Amize programoval pouze okeni aplikace. k takovymto hardcore vecem jsem se uz nestihl dopracovat. skoda.

kdyz jsem si precetl, ze copper ma jen tri instrukce tak mi sla brada dolu :-)

par postrehu a doplnujicich otazek.

copper tedy bezel jako (temer) nezavysly obvod. takze programator mu nejprve do pameti pripravil data (grafiku), pak nekam nahral program ktery ovladal copper a spustil ho, zatimco na CPU bezelo napriklad ovladani postavicky ? tento program se spustil vzdy pri zacatku vykresleni obrazovky ?

>takže na obrazovce vidíte duhu
tak me napadlo, da se udelat i duha horizontalni ? neboli v ramci jednoho LoRes radku ktery ma 320 pixelu zmenit barvu vsech pixelu ? stihne to copper ?

dekuju za odpoved, tedka studuju a patram po prikladech na netu a snad se mi podari dohnat tento rest z mladi a naprgam si nejaky graficky efekt.

Víceméně máte pravdu. Copper měl vlastní program, který se restartoval při vertikálním zatemnění. Instrukcí moc nepotřeboval, protože vlastně nic neuměl – jen počkal na nějakou pozici paprsku a pak zapsal data do nějakého řídícího registru.

Hlavní procesor se pak staral o dvě věci – zaprvé si hrál s daty a grafikou a zadruhé přeprogramovával copper.

Co se rychlosti copperu týká, tady v článku se píše že buď 4 nebo 8 pixelů. Tak nějak to bylo. Některá dema to využívala na relativně rychlé vykreslování plnobarevné grafiky. Jeden plán jste si vyhradil na „mřížku“ a pak copperem měnil barvu té mřížky. Mřížka vypadala třeba tak, že jste měl 3 obarvené pixely a pak jeden prázdný. Takhle se to opakovalo na celém řídku. Další řádek byl o pixel posunutý. Tím, že se nejednalo o jednolitou plochu, to zdaleka tolik netrhalo za oči.

Zdůrazňuji, že na to stačil jeden plán. V dalších jste mohl mít 16 barevný obrázek, který „animaci“ na pozadí překrýval.

Další trik pro horizontální změnu barev, který uměl copper „zrychlit“ spočíval v tom, že jste si opět vykreslil mřížku, ale tentokrát hustší (2 pixely barva, 1 pixel prázdno). A vykreslil jste si je ve 32 barvách, tedy první čárka barva 1, druhá čárka barva 2, atd. Pak jste si nastavil barevnou paletu tak, aby prvních 31 segmentů obsahovalo barvy, jaké chcete. Program pro copper pak dělal to, že jakmile se začalo vykreslovat, a tedy se vykreslila první čárka barvou 1, tak změnil barvu 1. Pak hned změnil barvu 2 atd. Barvy se střídaly po 3 pixelech, tedy rychleji, než copper stíhal přepisovat barvy, ale vždyť on měl 30 barev náskok :-) Aby si stihl připravit barvy pro další řádek, obvykle se vkládal jeden prázdný. Pokud se ale nevykresloval obrázek přes celou šířku obrazovky, mohly být pixely i hustší, protože copperu nestačil „ujet“ vlak. Navíc pak bylo při zatmění dost času si nastavit barvy pro další řádek.

A jednou jsem to celé viděl s mřížkou ve „3D“. Nejsem si jistý jak to bylo uděláno, ale předpokládám, že to bylo s použitím Halfbrite, kde místo neobarveného pixelu byl pixel s polovičním jasem.

A když už jsme u toho copperu, na Amize v některých demech byly obrázky v HAM módu, které měly neuvěřitelnou ostrost. Standardní HAM umí volit jednu barvu ze 16 nebo libovolnou změnu jedné barevné složky. Pokud tedy chcete mít vedle sebe zelenou a modrou, pak musíte mít tu modrou v barvové paletě – protože změna přes barvové složky je „zelená na 0, modrá na 15“. Bez použití palety by tam vznikl černý pixel. Pokud ale těch „strmých“ barevných přechodů máte více, dojde vám počet barev v paletě a jste namydlení. A právě zde se dal využít copper, který vám dokázal ve správnou chvíli do barvové palety dohodit tu správnou hodnotu. Akorát si tedy nedokážu představit, jak by někdo dokázal na Amize takový obrázek nakreslit. Předpokládám, že ho kreslil na nějakém jiném počítači, který uměl více barev bez problémů a pak ho „konvertoval“.

Jo, to jsou krásné vzpomínky. Jenže před 16 lety byla jiná doba, Amigu mělo hodně lidí a člověk se mohl pravidelně inspirovat (a předvádět) kupříkladu v Brně na Resetkání. Dneska by to bylo psaní tak leda do šuplíku.

Jo, tomuhle se říká hardcore. Díky moc za podobné příspěvky. Oslovují mě dokonce více než samotný (a vůbec ne špatný!) článek.

Mám pocit, že dneska se jde na všechno hrubou silou, protože tu máme truecolor, gigahertzy a gigabajty. Ale třeba se pletu a ty TOP hry používají opět řadu neskutečných vychytávek, jak ušetřit takt, bajt apod. Ale vzhledem k rozmanitosti architektury PC o tom silně pochybuju.

> Dneska by to bylo psaní tak leda do šuplíku.

A co oldschool compos? Ty porad probihaji.

Na stránke natami projektu som našiel porovnanie ako blitter pracuje v planárnej grafike a v chunky.
http://www.natami.net/qa.htm
V planárnej grafike potrebuje pre každý bitplan 4 operácie nad každým pixelom
Pri 8 bitplanoch to dáva 32 operácií.
Nevie niekto z amigistov, prečo je ich tak veľa ?