Obsah
1. Brány Skeldalu – následovník slavných čtverečkových dungeonů
3. Chyby v překladači, extenderu či samotném DOSu
1. Brány Skeldalu – následovník slavných čtverečkových dungeonů
PT: kterou hrou či hrami jsi se při programování Bran Skeldalu nechal inspirovat? Některé věci mi v Branách Skeldalu připadají velmi originální, jiné se zase (což je pochopitelné) podobají dalším „čtverečkovým“ dungeonům či jiným RPG hrám.
ON: tak na začátek je dobré říct, že oficiálním autorem hry nejsem já, ale firma Napoleon Games, konkrétně pan Jindřich Rohlík, který s celým příběhem přišel za mnou coby za programátorem a nabídl mi spolupráci. Nebyl jsem ani prvním a jak vývoj ukázal, ani posledním programátorem, který se na celé sérii Bran Skeldalu podepsal (teď do toho zahrnuji i „dvojku“, které jsem se neúčastnil). Mne samotného nejvíc inspirovala série Eye of the Beholder, konkrétně přes hru Eye of the Beholder II jsem se dostal ke čtverečkovým dungeonům. Na tom se podepsala i tehdy začínající česká varianta hry na hrdiny, ono známé Dračí Doupě, tak nějak mne to obojí zaujalo a už nepustilo.
Obrázek 1: Eye of the Beholder II – The Legend of Darkmoon
PT: z tvých textů, které lze najít na Internetu, vyplývá, že máš čtverečkové dungeony rád a znáš prakticky všechny klasické hry této kategorie. Můžeš prosím prozradit svůj „top five“ v této herní oblasti?
ON:
- Lands Of Lore
- Eye of the Beholder (II)
- Dungeon Master 2
- Dungeon Master 1
- Wizardy VII – Crusaders of the Dark Savant
Ono je to těžké, protože jsem spíš vždy hrál s tím, že jsem koukal, jak je to naprogramované. Například ke hře Eye of the Beholder jsem si časem sehnal i prohlížeč grafiky nebo levelů, mám dokonce pocit, že existoval i editor. Ale vím, že s Lands of Lore a Eye of the Beholder jsme se jako „děti na střední“ vyblbli hodně. Hrála to tehdy půlka třídy a pěkné bylo, si vyměňovat různé poznatky s ostatními. Pamatuji si třeba na kámoše, který byl vždy o jednu lokaci napřed a vždycky mě napínal: „Počkej v katakombách, jsou tam dveře a devět tlačítek. Já to řešil celý víkend“. A pak jsem tam dorazil a strávil jsem nad tím další víkend.
Obrázek 2: Herní prostředí hry Lands of Lore využívající grafický režim 320×200×8 karet VGA.
2. Vývojové nástroje
PT: původní dungeon Brány Skeldalu byl vyvíjen pro operační systém DOS, pro nějž v té době existovalo poměrně velké množství programovacích jazyků, od Basicu (QBasic, QuickBasic, Turbo Basic) přes známý Turbo/Borland Pascal až po překladače céčka a C++, například od firem Borland, Microsoft nebo Watcom a později též DJGPP, což jsou vývojové nástroje GCC (GNU Compilers Collection) převedené do prostředí DOSu. Pro jaký programovací jazyk (či jazyky) jsi se rozhodl při vývoji Bran Skeldalu a jaké důvodu tě k tomu vedly?
ON: s (Borland) Pascalem jsem měl hodně zkušeností, protože jsem v něm dělal víceméně v té době všechno. Takže mi bylo jasné, že je to nepoužitelný jazyk. Časem jsem používal Borland Pascal jako překladač assembleru. A tak se hra napsala v céčku, protože překladače na céčko byly lepší a nabízely i lepší frameworky třeba na protect mode (tzv. chráněný režim mikroprocesoru, který mj. dovolil přístup k veškeré operační paměti – pozn. PT). Borland Pascal běhal pod DPMI a měl myslím omezení na 16 MB paměti, protože byl šestnáctibitový, zatímco ve Watcomu byl DOS4GW a byl plně 32bitový. I když určitou perličkou je, že jsem se céčko postupně učil, ale kdo kdy programoval v Pascalu, určitě si vzpomene na jednu skvělou „Učebnici jazyka C“, kde výklad probíhá směrem „Od Pascalu k C“, takže přechod vůbec nebolel.
PT: v e-mailu jsi se zmiňoval o tom, že jsi používal především C++ a ne „čisté“ céčko. Bylo to z toho důvodu, že céčko se ti jevilo pro tak velký projekt jako nevhodný jazyk?
ON: asi jsem to nezmínil přesně. Hra Brány Skeldalu je prvotně napsaná v klasickém céčku mixovaném sem tam assemblerem. C++ jsem tehdy ještě neovládal na takové úrovni. Právě že ten vývoj ukázal, že C prostě nestačí, je to jen trochu lepší assembler a zejména udržet nějakou rozumnou organizaci celého programu byl obrovský problém. Spousta „technik“ použitých v kódu jakoby supluje neexistenci objektů. Například UI obsahuje „objekt“ ve smyslu ovládací prvek a ten má tabulku ukazatelů na funkce, jenž ho implementují (podobný systém je použit například i v céčkové herní knihovně Allegro – pozn. PT). V C++ je to obyčejné rozhraní s funkcemi deklarovanými virtual. Nebo je tam rozhraní na zasílání zpráv, kam si každá část hry může zaregistrovat funkci. Dneska bych tam hodil nějaký kontejner objektů dědící jedno rozhraní.
Nevýhodou C je neexistence objektů, což dost často vedlo k tomu, že se používaly globální proměnné a s tím byly spojené problémy. Například hra zvládne mít v paměti pouze jednu úroveň. Když pak hráč chce například v mapách nahlédnout do jiné úrovně, musí se současná mapa uložit, nahrát nová mapa a při návratu se to zase nahrává zpět. Po dokončení hry jsem se tedy zcela vážně začal zabývat objekty a přešel komplet na C++. Dneska bych se k „čistému“ C už nevracel.
PT: kolik procent kódu původních Bran Skeldalu je naprogramováno v assembleru (samozřejmě odhadem)?
ON: tolik toho není, tak 20% – 30%. Většinou vykreslovací rutiny, nějaké efekty, skrolování a zoom (grafika), popř. mixovací rutinky pro zvuk. Ono to možná vypadalo větší, ale jen když do toho započítám ovladače obsahující spoustu duplicitního kódu redukující množství podmíněných jumpů (podmíněné skoky na všech moderních procesorech mohou znamenat citelné zpomalení běhu programu, a to i při použití prediktorů – pozn. PT). Takže třeba pro každý grafický režim existovala samostatná sada vykreslovacích rutin a rutin pro efekty. Mluvím o verzi určené pro systém DOS. Ve Windows verzi je velká část kódu přepsána do C/C++ a to, co zbylo, teď přepsali vývojáři pracující na portu pro operační systém Linux (na SF, podrobnosti si řekneme příště – pozn. PT).
3. Chyby v překladači, extenderu či samotném DOSu
PT: narazil jsi při programování tak velkého projektu na nějakou chybu v překladači? Borlandí překladače například po velmi dlouhou dobu špatně vyhodnocovaly hodnoty položky bitového pole v příkazu switch atd.
ON: vůbec ne, asi jsem měl štěstí.
PT: ale na nějaké chyby, které nebyly v tvém kódu, jsi určitě narazil…
Největší trápení jsem měl s extenderem a vlastně i s prostředím DOSu pod chráněným režimem. Například z nějakého důvodu DOS4GW netuneloval interrupty nad IRQ7 (oblíbený IRQ10 u SB nefungoval). DMA (přímý přístup do paměti) musel být alokován v prvních 1MB paměti, tedy se muselo jít do reálného režimu a dělat to v DOSu. Přerušení taky mohlo přijít v době, kdy byl procesor v reálném režimu, takže obsluha, zejména u časovače, musela být napsaná dvakrát, jednou v chráněném a jednou v reálném režimu. Protože ale v přerušení v reálném režimu nebylo možné přepnout do chráněného, obsluha časovače byla velice krátká a jeho události se vyzvedávaly až správcem událostí mimo přerušení. Totéž se týká ovladače pro COVOX/PC Speakera, který byl napsán dvakrát, jednou pro reálný režim a podruhé pro chráněný.
4. Grafický subsystém
PT: systém DOS dovoloval (či spíše nutil) programátory, aby ve svých programech sami obsluhovali jednotlivé součásti počítače v podstatě na té nejnižší úrovni – přímým přístupem k jejich řídicím registrům a paměti. Týká se to samozřejmě také grafických a zvukových karet. Které grafické karty a režimy byly v Branách Skeldalu podporovány?
ON: spoléhal jsem se na standard VESA 2 a tehdy oblíbené UNIVBE (rezidentní aplikace, která zpřístupňovala funkce VESA 2 i na starších grafických kartách – pozn. PT). Umožnil na víceméně libovolné kartě zprovoznit tzv. Flat Buffer, což byl kus souvislé paměti, kam se mapovala videopaměť (u starších karet se to řešilo přes výjimky, které nastaly při přístupu do neexistující stránky paměti; obslužný podprogram výjimky provedl přemapování stránek – pozn. PT). Režimy se nastavovaly také přes VESA. Časem se ukázalo, že UNIVBE není všemocný, a některé karty takhle ohnout prostě nejde. Takže se dodělala podpora bank a la VESA 1 a vznikla další duplicitní sada vykreslovacích rutin které uměly přepínat banky. Mezi další režimy, kromě původem nativního 640×480×15, byly režimy 640×480×16 (muselo se přepočítávat z patnáctibitové hloubky na šestnáct bitů), 640×480×8 (překlad tabulkou barev 15 na 8) a jako fallback režimy 320×480×8 (slavný Mode-X) a 640×480×4 (odstíny šedi) – tam nebylo možné zoomovat při pohybu.
5. Statické obrázky a animace
PT: přepínání paměťových bank v režimech VESA 1.x bylo (alespoň podle mých zkušeností) dost pomalé. Nemělo to negativní vliv na výkon celé hry? Je asi pravda, že zrovna u čtverečkových dungeonů nemá smysl honit se za co nejvyšší hodnotou FPS (frames per second), ale stejně…
ON: v zásadě ani ne. Hra používala backbuffer, jen při některých náročných operacích se kreslilo přímo na obrazovku (frontbuffer je část video paměti, která je v daný okamžik zobrazována, backbuffer naopak zobrazován není, tj. zápis do něj není ihned viditelný a programátor tak má čas si celou scénu připravit – pozn. PT). Jednalo se třeba o zoomování při pohybu, otáčení, nebo přehrávání videa. V ostatních případech se použil backbuffer a ten se posílal na obrazovku v bloku. Tam se nemuselo přepínat tak často. Také vykreslovací rutinky byly zjednodušené jen pro práci s backbufferem, nebo kreslení speciálních efektů a videa. Takže i když třeba hra běžela v grafickém režimu s osmibitovou barevnou hloubkou, backbuffer byl stále šestnáctibitový a pouze při obnovení obrázku se provedl i překlad barev. Co se FPS týče, tak ani to nebylo bez problémů. Hra má běžet s FPS 10, což na počítači s procesorem Pentium 75+ s PCI kartou (tehdejší) bylo taktak… (mně to občas na vývojovém stroji P75 jelo jen 8 FPS).
Je třeba připomenout, že většina tehdejších dungeonů byla statických, kdy se obrázek změnil jednou za sekundu – nestvůrka udělala krok o 1 čtvereček (pěkně je to vidět například na Dungeon Masterovi, kdy nejrychlejším pohybem/animací je otevírání dveří – pozn. PT). Vlastně až Lands Of Lore a Dungeon Master II měly plně animované prostředí, ale ty „jely“ v grafickém režimu 320×200×8, což představuje pouze 10% dat oproti 640×480×16. Navíc ve většině dungeonů tehdejší doby zabíral výhled maximálně 1/4 obrazovku. U Skeldalu výhled zabírá 3/4 obrazovky. Cílem bylo poskytnout hráči největší vizuální zážitek a ne nudný záběr na hromadu ovládacích prvků. V dnešní době není nikomu divné, že výhled zabírá celou obrazovku.
PT: s různými grafickými režimy (a jejich rozlišeními) souvisí i problémy se zobrazováním rastrových obrázků, tj. v případě dungeonů například textur zdí, nepřátel atd. Měl jsi pro jednotlivá rozlišení připraveny textury o různé velikosti nebo byl použitý nějaký typ filtru při zvětšování a zmenšování textur?
ON: všechny textury byly vytvořeny v základní podobě pouze zepředu a ze strany. Základní podoba byla ve stavu, kdy hráč stojí na políčku a vidí před sebou stěnu, nebo vidí postranní stěny o políčko dál. Všechny menší velikosti se zmenšovaly vynecháváním řádků a sloupců podle předpočítané tabulky. Pouze postranní stěny na políčku, na kterém stál hráč byly lehce zvětšené. Grafika musela být lehce rozmazaná, aby to netvořilo artefakty, ale není to skoro poznat. Každá textura měla několik barevných palet, podle toho, jak se při kreslení do dálky mělo ztmavovat. Pro každou vzdálenost se použije jiná paleta.
PT: existovaly textury upravené speciálně pro grafické režimy hi-color či true-color?
ON: textury byly osmibitové s optimalizovanou paletou. Při kreslení se přes paletu přepočítávaly do šestnácti bitů. Strop a podlaha se nahrávala přímo v 16bitech. Zvláštní byly akorát soubory typu *.HI, což byly obrázky přímo v šestnáctibitové hloubce a existoval pro ně konvertor z 24-bitového BMP. Obrázky se používaly jako artworky, v dialozích, v obchodech, atd.
Jeden z datadisků k Branám Skeldalu.
6. Odkazy na Internetu
- Brány Skeldalu
http://www.napoleongames.cz/main.php?… - Brány Skeldalu 2: Pátý Učedník
http://www.napoleongames.cz/main.php?… - Wikipedia: Brány Skeldalu
http://cs.wikipedia.org/…ány_Skeldalu - Brány Skeldalu: novinky
http://skeldal.vyletnici.net/main.php - The Gates of Skeldal – Sources of the legendary game
http://sourceforge.net/…cts/skeldal/
7. Co si řekneme příště?
Při čtení předchozích odstavců jste si zajisté všimli, že Ondra odpovídá na všechny otázky velmi podrobně, takže se celý jeho „výslech“ musel rozdělit do dvou částí. Ve druhé části si řekneme, jakým způsobem byl vytvořen zvukový subsystém Bran Skeldalu (velmi zajímavé téma), jak byla navržena AI (umělá inteligence nepřátel), princip ukládání mapy dungeonu v operační paměti a v neposlední řadě se budeme zabývat také otevřením zdrojových kódů Bran Skeldalu, což umožňuje vznik linuxové verze této pozoruhodné české hry.
ČLÁNKY DO MAILU