Názory k článku Nestandardní textové a grafické režimy karty VGA

Třeba já jsem psycho, protože mám poruchu osobnosti.

Ty hlavne spamujes

Změna adresy první řádky se mohla provést kdykoliv, stejně platila až od nového frame.

I tak se muselo čekat na vertikální zpětný chod, aby se přepnutí potvrdilo a program třeba nezačal kreslit do stále ještě zobrazeného bufferu.

Proto se používal triple-buffering, kdy do jednoho se kreslilo, druhý čekal na zobrazení a třetí byl zrovna vidět. Tam se přepínalo kdykoliv, protože program věděl, že bude kreslit do bufferu, který určitě během přepnutí nebude vidět.

Jediný co si pa musel zajistit je, aby rychlost generování scény nebyla vyšší, než obnovovací frekvence monitoru. Což je logické, protože generovat něco rychleji, než stíhá monitor vykreslovat je stejně zbytečné plýtvání času CPU.

V 320×480, potažmo v 360×480 už opravdu doublebuffering nebylo možné dělat ale i tak se s tím dalo solidně rychle pracovat, pokud člověk nevyžadoval celoobrazovkové animace. Před „Skeldalem“ jsem si s tím hrál v pascalu a vlastně nejlepší řešení … ale to jsem se nechal inspirovat… byl softwarovy backbuffer s aktualizací pouze změnených částí. Poprvé jsem to viděl v u Warcraftu po jednom šíleném přepnutí z Windows 3.11 do DOSu se neobnovila grafická paměť a pohyb kurzoru myši odhaloval obsah videopaměti postupně.

Bohužel na SW backbuffer bylo v DOSu málo paměti i tak, a navíc věc komplikovalo segmentování. Přechodem do 32 bitů by se problém vyřešil… kdyby v tý době už nebyly k dispozici lepší zobrazovací mody :-).

A tak nakonec buďiž mé uplatnění XMode jen v DOSové verzi Bran Skeldalu jako fallback režim pro standardní VGA. Bežel tam 320×480 nahrazující původních 640×480. Na základě průměrné barvy dvou HICOLOR pixelů se vybrala z tabulky 16b na 8b barva z předpočítané palety a ta se zobrazila. Kreslilo se po rovinách, což při celoobrazovkových překreslení vypadalo, jako vertikální žaluzie :-)

Nicméně 360×480×256 byl na tehdejší dobu dost efektní, fungoval všude a měl jsem spoustu obrázků v tomto rozlišení připravených právě pro předchůdce dungeonu, jenž byl plánován také v tomto rozlišení. Fungovalo to všude, pokud si dobře vzpomínáte, i když grafické karty tehdy uměli více a lepší režimy, problémem byla vždy kompatibilita. Proto se uchylovalo k nejlepšímu režimu podporovanému všemi grafickými kartami, což byl právě 360×480. Teprve rozmach Windows a Direct X poslal tyhle režimy a celou technologii na smetiště dějin.

PS: obdélníkový pixel nevadil. Upravilo se aspect ratio a některé grafické operace vykreslovali grafické elementy se zdvojeným pixelem. I tak to bylo hladší a příjemnější na oči než 320×240. Měl jsem na to i speciální písmo. A Editor písma uměl zobrazit náhledy právě v těchto nestandardních režimech.

napadaju vas hry ktore x mody pouzivaly ?

mna napada akuat battle isle2 a settlers ale to nie som si isty

X Mode jako organizace paměti rozhodně používal Doom i s triplebuf­feringem

Co se režimu 360×480 jsem viděl snad jedině Scorcha. jinak si už nevzpomenu

Tého času nejznámější demo Second Reality je též v X-Mode, pro některé artworky dokonce přepíná do nějaké varianty 320×480. Přepínání přitom vůbec nebliká :-) – probíhá v „temných částí“ dema…

Celou sbirku x-modu podporuje take Quake pro DOS. Zkousel jsem ho na PC 486 s 8 MB RAM a 1 MB VideoRAM v modu 360×480 a prekvapive to jelo docela dobre.

Wrapping řešil registr 18h CRT. To zmiňované rozdělení obrazovky na dvě části. Jakmile bylo dosaženo konce obrazové paměti, nastavil se registr na příslušné číslo řádky a od toho se jelo od adresy nula.

Tehda jsem se s Mode X a podobnymi solidne vyblbnul v assembleru.

Takovych nas bylo vic. Pak prisly PCI grafiky s TrueColorem a bylo po srande.

Popisujete ze bylo mozne menit pocet radku/sloupcu. Neni mi ale jasne, jak se s tim vyporadal monitor. Presneji stinitko obrazovky a maska pred nim. Pokud se nepletu, tak lumifor byl nanasen ve svislych stridajicich se carach. Tim je dan natvrdo pocet pixelu na radek.
Nebo obvody v monitoru pri vykreslovani jineho poctu radku/sloupcu nez je HW rozliseni stinitka proste osvitily nejblizsi fyzicky pixel na stinitku?

Dekuji za odpoved,
zkusim Vasi odpoved laicky shrnout.
1) HW rozliseni monitoru je vyrazne vetsi nez pocet zobrazovanych pixelu.
2) paprsek kresli pres celou radku, bez ohledu zda zrovna miri na dirku v masce, nebo ne. Protoze na stinitku se zobrazi jen body co projdou maskou.

Maska tedy dela „prepocet“ rozliseni karty na HW rozliseni.

Predpokladam ze ve vertikalnim smeru je to podobne. Paprsek take kresli pocet radek podle karty a pres masku si to vzdy vybere ten spravny HW bod.

diki za vysvetlenie aj pekne zhrnutie.

tak nejak som si myslel ze to takto nejak je

kdysi jsem si hral s registry grafiky a povedl se mi rezim 400×300/256

Potreboval jsem vyssi vertikalni rozliseni nez 256bodu se zachvanim jednoduche prace s body v 256barevnem rezimu. Nakonec se mi povedl v assembleru naprogramovat logicky analyzer za pouziti pinu paralelniho portu.

St.