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

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.

jj, s tripple bufferingem mas pravdu, ten byl v mnoha pripadech nejvyhodnejsi prave z toho duvodu, ze byly k dispozici tri bitmapy:

1) jedna se prave zobrazovala
2) druha byla jiz vykreslena a cekala na sync.
3) do treti bylo mozne kreslit, protoze programator mel jistotu minimalne 1/60 nebo 1/70 sekundy, coz je hafo casu :-)

Bohuzel nesel tripple buffering delat v mem oblibenem rezimu 320×400, ktery mel oproti klasickemu x-mode 320×240 vyhodu v tom, ze pracoval v 70 Hz. A „double x-mode“, tj. 320×480 uz nedovoloval ani double buffering, protoze pocet radku byl roven 819 (<480*2).

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…

Urcite Pinball Dreams – jednicka pro vertikalni scrolling v unchained rezimu 320×200, dvojka dokazala prepinat i (vertikalni) rozliseni, takze se z kulicky stal elipsoid :-)

Z programu pak mnoho prohlizecu obrazku (Dosovy ACDSee je asi nejznamnejsi) a treba i muj oblibeny FractInt :-)

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.

Jeste si vzpominam na jeden zapeklity problem s tim souvisejici – wrapping na konci obrazove pameti.

Na klasicke VGA sel nastavit pocatek obrazove pameti treba na posledni obrazovky radek (818) a VGA si s tim poradila takto:
1) vykreslila prvni radek na obrazovce, pixely se nacitaly od odresy 818*320/4 (konec obrazove pameti)
2) doslo k preteceni citace na zacatek obrazove pameti (0000) a dalsi radky se nacitaly odsud

Takze se tim dal udelat „nekonecny“ scrolling, pri posunu obrazovky nahoru ci dolu stacilo presunout maximalne 320 bajtu, coz je v porovnani s celou obrazovou pameti skoro nic :-)

Problem vsak byl v tom, ze karty „VGA compatible“ ve skutecnosti nebyly az tak uplne „VGA compatible“, takze wrapping nedelaly. Bylo to dano napriklad tim, ze mely vice obrazove pameti (Tridenty tusim 1/2 MB atd.), takze jejich citac adres nepretikal 65535->0, ale nekde mnohem vys. Pro me v te dobe neresitelny problem :-(

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?

Mate pravdu v tom, ze barevne CRT (monochromaticke ale ne) maji masku + 3 typy luminoforu rozmistenych bud po barevnych prouzcich (in-line) nebo do trojuhelnicku (delta).

Maska je v podstate kovova desticka s dirkami, ale pocet tech direk v horizontalnim smeru neodpovida horizontalnimu poctu pixelu. Obecne je pocet direk a tim padem i maximalni horizontalni rozliseni vyssi nez to, co nabizely graficke rezimy.

To znamena, ze jeden pixel mohl byt zobrazen napriklad na dvou ci trech sousednich trojicich barevnych prouzku atd. Na zacatku vyvoje grafickych karet to nicemu nevadilo, protoze jejich rozliseni byla pomerne nizka, takze nedochazelo k nezadoucimu podvzorkovani, ktere se projevuje vznikem moare – na monitor se totiz muzeme divat jako na zarizeni, ktere na kazdem radku „vzorkuje“ signal dodavany z graficke karty na jednotlive fyzicke body (trojici barevnych prouzku).

Pokud se vsak rozliseni zvysovalo (>1000 pixelu/radek) mohlo jiz dochazet ke vzniku moare, protoze pocet fyzickych bodu (trojic bar.prouzku) se priblizoval poctu pixelu, ktere chtel uzivatel na kazdem radku zobrazit. Ale to porad neni problem klasicke VGA, na te se dalo zobrazit max. 780–800 pixelu na radek (a to jen na nekterem monitoru).

Ono mapovani pixelu presne na jednotlive body na CRT neni v podstate ani mozne protoze:

1) na VGA neni vyvedeny pixel clock (hodiny synchronizujici jednotlive pixely), coz je ostatne duvod, proc se napriklad LCD musi pri zapojeni na DVI konektor synchronizovat (takove to natahovani a posunovani obrazu, nez si LCD nastavi vlastni pixel clock).

2) i kdyby byl k dispozici presny pixel clock, tak si myslim (ale tady me asi opravi odbornici na CRT), ze zamerovani elektronoveho paprsku nemuze byt zcela presne, takze nastava chyba treba ± 2 obrazove body. I kdyby nakrasne bylo zamerovani presne, staci nejake magneticke ruseni a cely system by bylo zapotrebi znovu nakalibrovat (v podstate po kazdem zazvoneni mobilu :-).

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

Ano, presne tak. I kdyz bych mozna pro jistotu ;-) pouzil minuly cas, protoze pripojit nejaky starsi CRT s pitchem 0,27mm ke karte pracujici v rezimu napriklad 1600×480 by vedlo ke vzniku moare (on totiz CRT vlastne nic o horizontalnim rozliseni nevi, u vertikalniho ano, tam ma synchronizacni signal, ale pro ten „prepocet“ vlastne plati to same).

Jeste pridam odkaz:

http://en.wikipedia.org/wiki/Dot_pitch

A vypocet (fixme):

CRT Monitor 17", pitch 0,27mm (http://www.recycledgoods.com/…Monitor.html)

sirka obrazovky: 17"*4/5 = 13,6" = 345 mm
(vypocitano na zaklade Pythagorovy vety, predpokladam pomer sirka:vyska=4:3)

Fyzicke horizontalni rozliseni: 345/0,27=1277 bodu

Coz je temer 2× vice nez nejvyssi standardni VGA rozliseni.

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.