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.
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 :-(