AMIGA REVIEW obsah časopisu online!
  Domov     Software     Hry     Obaly     Download  

CyberGraphX

Jaroslav Pokorný

Každý uživatel grafických karet na Amize ví, že systém CyberGraphX umožňuje používat tyto karty se všemi systémově napsanými aplikacemi. Tento článek vám detailně objasní, jak to vlastně funguje.

CyberGraphX slouží jako rozšíření systémové grafické knihovny pro nejrůznější grafické karty. CyberGraphX vznikl, protože Commodore nevyvinul grafickou knihovnu plně podporující RTG (ReTargetableGraphics - přesměrovatelnou grafiku). Systém 3.0 sice představuje první krok v tomto směru (lze přidávat monitory a nové grafické režimy do databáze, přibylo několik nových funkcí pro tento účel a vývojáři byli upozorněni na problematiku bitmap), ale grafická knihovna pořád nepodporovala jiný grafický výstup, než OCS/ECS/AA čipset. Dokonce ani pod nejnovějším systémem 3.1 není možno čistě přidat vlastní grafickou kartu do systému.
CyberGraphX přesměruje většinu z původních funkcí grafické knihovny, čímž umožňuje transparentně integrovat libovolné grafické karty do systému, pomocí standardních ovladačů monitorů, u kterých však bylo přidáno vlastní API rozhraní. Přidává také několik nových funkcí pro přímou podporu 15/16/24/32 bitových obrazovek, které nejsou k dispozici v původní grafické knihovně. Tyto funkce jsou obsaženy v nové knihovně cybergraphics.library. Další rozšíření, které sice není přímou součástí CyberGraphX, ale vhodně jej doplňuje, jsou 24bitové datatypy. I zde přibyly nové metody. Ohromný přínos CyberGraphX spočívá v možnosti i zpracovávat grafiku i ve FAST RAM. Konečně padlo omezení na 2MB CHIP RAM a také rychlost operací se neskutečně zvedla. Aktuální verze CyberGraphX a ovladačů také podporují overlay funkce grafických čipů (obraz v obraze), hardwarový zoom a také 3D funkce (ty zatím jen v samostatné knihovně, ale počítá se s jejich zabudováním do ovladačů).
Po zavedení systému je možno otevírat obrazovky hlubší než 256 barev, přičemž tyto zůstávají plně kompatibilní s intuitionem. Lze pořád používat všechny funkce graphics.library, vyjma některých speciálních použití blitteru, které závisí na planárním uspořádání dat. Blitter z grafické karty je samozřejmě použit v co největší míře, bohužel ani nejnovější grafické čipy nezvládnou takovou paletu operací, a proto je zbytek funkcí emulován softwarově. Všechny obrazovky jsou zpětně 8-bitově (myšleno 256-barevně) kompatibilní, včetně alokace per, která je ovšem v truecoloru jen fiktivní. Díky tomu většina starších, systémově napsaných aplikací bude chodit i na těchto 15/16/24/32 bitových obrazovkách. Samozřejmě můžete použít všechny další vlastnosti nových režimů - pokud to umožní funkce CyberGraphX.
Systém CyberGraphX není myšlen jako náhrada za originální grafický/intuition systém (jako je například EGS). Proto zde není potřeba speciální ovladač pro nativní čipset OCS/ECS/AGA. Veškerá funkčnost originálního čipsetu je již pokryta v původní grafické knihovně. CyberGraphX má úplně jiný cíl než EGS. V porovnáním s ním mu sice chybí některé možnosti, ale na druhou stranu je to nejsystémovější rozšíření grafiky pro počítače Amiga. Lze se po právu domnívat, že Commodore by se vydal stejným směrem, samozřejmě s tím rozdílem, že by grafická knihovna nebyla patchovaná, ale obsahovala by obdobné funkce přímo v sobě. Možná, že s příští verzí systému se CyberGraphX stane zbytečností, ostatně autoři v to pořád doufají. Dnes je však takovýto „patch“ jedinou možností, jak plně využit truecolorovou grafiku ve vašich aplikacích, v plně systémovém prostředí a s minimální námahou.
Na pravou míru by se měl uvést i často používaný termín „emulace Workbenche na grafických kartách“. V podstatě se totiž o žádnou emulaci nejedná, Workbench stále běží ten samý z ROM, dokonce ani není patchovaný. Workbench pořád volá stejné funkce grafické knihovny, u kterých je jen díky CyberGraphX rozšířena funkčnost. Znova a důrazně je třeba odlišit, že CyberGraphX není emulace Workbenche, jako jsou např. DOpus5 nebo Scalos.

Bitmapy a CyberGraphX
Před systémem 3.x neexistovala standardní metoda pro vytváření bitmap. Vše záleželo na programátorovi aplikace - od alokace paměti pro strukturu bitmapy, přes alokaci ukazatelů na bitplány s postupným voláním funkce AllocRaster(), až po inicializaci struktury bitmapy funkcí InitBitMap(). Bohužel, někteří programátoři se neobtěžovali ani s používáním těchto elementárních funkcí AllocRaster() a InitBitMap(), nýbrž jednoduše (resp. složitě :-) alokovali bitmapy pomocí všeobecné funkce pro alokaci paměti AllocMem() a inicializovali strukturu bitmapy vlastními, jednoúčelovými hodnotami. Protože zde byl pouze jeden formát bitmapy, nebyl problém s přímým zápisem do alokovaných bitplánů. Dokonce nebyl ani problém se změnou obsahu struktury bitmapy, protože aplikace měla úplnou kontrolu nad umístěním a obsahem této struktury a k ní přiřazených bitplánů. Problémy však nastaly, pokud bylo potřeba změnit nebo rozšířit strukturu bitmapy.
Do systému 3.x přibyly dvě nové funkce pro podporu vytváření a odstraňování bitmap: AllocBitmap() a FreeBitmap(). Těmito funkcemi byl učiněn první krok k umožnění i jiných formátů bitmap. K získání údajů o bitmapě přibyla další funkce: GetBitmapAttr(). Díky této funkci můžete získat informace o šířce, výšce, hloubce a dalších nastaveních bitmapy. To byl další krok k RTG cíli. Pokud funkce GetBitmapAttr(bm, BMA_FLAGS) nevrátí hodnotu BMF_STANDARD, tak přístup k takové bitmapě již nesmí být přímý a může být k ní přistupováno pouze přes rastport a všeobecné kreslící funkce, nebo použitím standardních volání blitteru v grafické knihovně.
Bohužel, opět mnoho programů nerespektuje ani tyto zásady ustanovené již firmou Commodore, ani nekontroluje flag BMF_STANDARD pod systémem 3.0 a vyšším. Dodnes mnoho programů používá metody popsané na začátku této kapitoly. To je hlavní důvod, proč si různé grafické systémy, CyberGraphX nevyjímaje musí stále složitě zahrávat s konverzí planar/chunky, protože hardware v pozadí již planární grafiku třeba vůbec nepodporuje. To vede často k dramatickým ztrátám rychlosti, které by neexistovaly, pokud by aplikace volala standardní kreslící funkce.
Takže pokud běžíte pod systémem 3.x, používejte funkce AllocBitmap()/FreeBitmap() všude, kde je to jen možné. Tato metoda vám přinese v mnoha případech velké zlepšení výkonu, pokud bude použita na grafických adaptérech třetích výrobců. Nezapomínejte používat ukazatel na friend-bitmapu, kdykoliv potřebujete alokovat kompatibilní bitmapové struktury.
Při alokaci bitmap pro datatypy musíte přidat flag BMF_MINPLANES do volání AllocBitmap(). Je to kvůli standardnímu picture.datatype, který překvapivě nekontroluje BMF_STANDARD a přímo zapisuje do bitplánu, i když alokovaná bitmapa není planární... Použití BMF_MINPLANES v prostředí bez CyberGraphX zůstává pořád kompatibilní a nemělo by vést k žádným problémům. Pokud použijete BMF_MINPLANES v prostředí s CyberGraphX, alokuje se chunky bitmapa. Chunky bitmapa se alokuje, také pokud uvedete jako friend-bitmap jinou chunky bitmapu. Způsob jakým přímo přistupovat k datům v takové bitmapě je uveden dále. Přesto nepředpokládejte, že chunky-bitmapa má nějaký pevně definovaný formát. Vše si musíte nejdříve zjistit pomocí dotazové funkce cybergraphics.library.
Metoda alokace chunky bitmap byla navíc rozšířena, aby bylo možno alokovat konkrétní pixelové formáty. S CyberGraphX totiž nejsou bitmapy omezeny pouze na planární nebo 8-bit chunky data (tento formát ostatně nebyl k dispozici ani se standardním čipsetem). Je možné alokovat a používat pixelové formáty bitmap nezávisle na konkrétním výstupním zařízení. Proto byly přidány nové bity ve 32bitovém slově flagů funkce AllocBitmap(). Pokud zadáte bit BMF_SPECIALFMT (hodnota 128 = 0x80, chybí v některých verzích include/cybergraphics.h!), potom horních 8 bitů z 32bitového slova obsahuje informaci o formátu pixelů požadované bitmapy. K dispozici jsou následující pixelové formáty:
PIXFMT_LUT8, PIXFMT_RGB15, PIXFMT_BGR15, PIXFMT_RGB15PC, PIXFMT_BGRI5PC, PIXFMT_RGB16, PIXFMT_BGR16, PIXFMT_RGB16PC, PIXFMT_BGR16PC, PIXFMT_RGB24, PIXFMT_BGR24, PIXFMT_ARGB32, PIXFMT_BGRA32, PIXFMT_RGBA32.
Mnoho z těchto formátů je závislých na konkrétním zařízení a nemělo by být obecně používáno. Doporučené formáty jsou pouze PIXFMT_LUT8, PIXFMT_RGB 16, PIXFMT_RGB24 a PIXFMT_ARGB32.
Jakmile je bitmapa alokována, můžete ji libovolně připojit k rastportu a provádět na ní kreslící funkce. Bohužel není možné připojit tuto bitmapu k obrazovce použitím SA_CustomBitmap ve volání OpenScreenTagList(). To je způsobeno zcela odlišnou architekturou grafických karet oproti nativnímu čipsetu.

Přímý zápis do bitmapy
Není dovoleno přímo zapisovat do dat bitmapy, pokud ji nemáte uzamčenou. Umístění a obsah dat bitmapy se v multitaskovém prostředí může a bude měnit a je pouze platné, pokud je bitmapa řádně uzamčena použitím funkcí LockBitmapTags()/UnLockBitmap(). K funkci LockBitmapTags() byste měli zadat taglist, který bude obsahovat ukazatele na longwordy, které se naplní platnými daty v případě, že funkce nevrátí nulu. Do bitmapy můžete přímo přistupovat, jen pokud tato funkce nevrátí nulu! Poté pomocí tagu LBMI_BASEADDRESS načtěte bázovou adresu, od které můžete přímo zapisovat. Hodnota vrácená pomocí tagu LBMI_PIXFMT obsahuje informaci, jaký barevný model (pixelový formát) musíte použít pro přímé kreslení do bitmapy. Musíte počítat se všemi možnými variantami! Další tagy vám poskytnou informace o rozložení dat bitmapy, takže byste již neměli mít žádný problém s přímým zápisem do bitmapy. Pamatujte, že všechny tyto hodnoty platí do doby, než zavoláte párovou funkci UnLockBitMap(). Poté již musíte bitmapu znovu uzamknout, abyste obdrželi aktuální data. Nezamykejte bitmapu na delší dobu, než jeden snímek. Jednodušší, ale ne vždy pomalejší je standardní volání grafické knihovny pro kopírování bitmapy do jiné bitmapy pomocí blitteru. Kopírování truecolorových bitmap do indexované chunky bitmapy (LUT8) zatím není podporováno.

Příklad alokace chunky bitmapy
V tomto jednoduchém příkladě se alokuje 256 barevná chunky bitmapa o velikosti 640x480, do které se poté nakopíruje planární bitmapa (převod p2c proběhne automaticky díky systému CyberGraphX).
struct BitMap *chunkybm;
struct BitMap *planarbm;
WORD width = 640, height = 480;
if (chunkybm = AllocBitMap(width, height, 8, BMF_SPECIALFMT|(PIXFMT_LUT8<<24), NULL))
BltBitMap(planarbm, 0, 0, chunkybm, 0, 0, width, height, 0xC0, 0xFF, NULL);

Vytlačiť článok



Pozn.: články boli naskenované ako text a preto obsahujú aj zopár chýb. Taktiež neručíme za zdrojové kódy (Asm, C, Arexx, AmigaGuide, Html) a odkazy na web. Dúfame, že napriek tomu vám táto databáza dobre poslúži.

Žiadna časť nesmie byť reprodukovaná alebo inak šírená bez písomného povolenia vydavatela © ATLANTIDA Publishing



none

AMIGA REVIEW

57 ( 11-12 / 2000 )
56 ( 9-10 / 2000 )
55 ( 7-8 / 2000 )
54 ( 5-6 / 2000 )
53 ( 3-4 / 2000 )
52 ( 1-2 / 2000 )
 
51 ( 12 / 1999 )
50 ( 11 / 1999 )
49 ( 10 / 1999 )
48 ( 9 / 1999 )
46-47 ( 7-8 / 1999 )
45 ( 6 / 1999 )
44 ( 5 / 1999 )
43 ( 4 / 1999 )
42 ( 3 / 1999 )
41 ( 2 / 1999 )
40 ( 1 / 1999 )
 
39 ( 12 / 1998 )
38 ( 11 / 1998 )
37 ( 10 / 1998 )
36 ( 9 / 1998 )
35 ( x / 1998 )
34 ( x / 1998 )
33 ( 1-2 / 1998 )
 
32 ( 11-12 / 1997 )
31 ( 9-10 / 1997 )
30 ( 7-8 / 1997 )
29 ( 6 / 1997 )
28 ( 5 / 1997 )
27 ( 4 / 1997 )
26 ( 3 / 1997 )
25 ( 2 / 1997 )
24 ( 1 / 1997 )
 
23 ( 12 / 1996 )
22 ( 11 / 1996 )
21 ( 10 / 1996 )
20 ( 9 / 1996 )
18-19 ( 7-8 / 1996 )
17 ( 6 / 1996 )
16 ( 5 / 1996 )
15 ( 4 / 1996 )
14 ( 3 / 1996 )
13 ( 2 / 1996 )
12 ( 1 / 1996 )
 
11 ( 12 / 1995 )
10 ( 11 / 1995 )
9 ( 10 / 1995 )
8 ( 9 / 1995 )
7 ( 7 / 1995 )
6 ( 5 / 1995 )

ATLANTIDA NEWS

5 ( 3 / 1995 )
4 ( 1 / 1995 )
 
3 ( 11 / 1994 )
2 ( 9 / 1994 )
1 ( 7 / 1994 )
0 ( 5 / 1994 )