Portál AbcLinuxu, 14. května 2024 02:32

Rozhovor: Ryan C. Gordon (icculus)

8. 3. 2011 | Luboš Doležel
Články - Rozhovor: Ryan C. Gordon (icculus)  

Ryan C. Gordon je jeden z nejvýznamnějších programátorů linuxového světa, co se portování týče. Pracoval na řadě portů her včetně Quake III Arena, Unreal Tournament 2004, America's Army, Postal 2, Braid nebo Serious Sam 2, ale přinesl na Linux i Google Earth a pracuje i na knihovnách SDL nebo PhysicsFS a má za sebou i méně úspěšný projekt FatELF. Zeptali jsme se na zkušenosti s portováním, OpenGL/Direct3D, open source ovladače GPU a další témata.

1) Mohl byste se našim čtenářům nejprve představit?

Moje jméno je Ryan a portuji počítačové hry na Linux. Když zrovna nedělám tohle, trávím čas psaním nástrojů, které portování her na Linux usnadňují. Také provozuji server icculus.org, kde hostuji open source projekty desítkám vývojářů.

Trávím také mnoho času přemýšlením, jak udělat Linux lepším systémem, a doufám, že jednoho dne k tomuto nějakým malým, ale smyslupným způsobem přispěji.

Ryan C. Gordon

2) Jak jste se dostal k Linuxu a vývoji pro Linux? Kde všude jste pracoval?

Někdy dávno v roce 1994 nebo tak nějak jsem byl už několik let hardcore uživatelem OS/2. Já asi vždycky bojuji proti dominantnímu systému, ale tehdy jsem byl namyšlený kvůli tomu, o kolik byl můj OS lepší než MS-DOS a Windows 3.1, což bylo hloupé, protože se každou chvíli měly přiřítit Windows 95. Věděl jsem to, a přesto jsem stále bojoval s nevyhnutelným.

Dočetl jsem se o OS/2 v nějakém časopise a chtěl jsem ho, protože měl dobré technické vlastnosti, ale důvodem, proč jsem na něm zůstal tak dlouho, byl bezplatný program, který běžel na OS/2 a jmenoval se EMX. Byl to free C kompilátor a mohli jste si jej stáhnout z FTP, což bylo skvělé, protože Microsoft, IBM, Borland,... všichni chtěli stovky dolarů za kompilátor C a já byl chudý teenager.

EMX byl program pro příkazovou řádku a spouštěl se vyťukáním tří magických písmen: gcc.

Někteří lidé poznají svobodný software náhodou. Já jsem ten super kompilátor miloval a neustále jsem ho používal, ale o GPL jsem neměl páru. Zdrojové kódy malých hloupých programů, které jsem napsal, se dostaly na FTP servery, ale neměl jsem žádnou představu o svobodě softwaru. Prostě jsem měl za to, že tohle je to, co by lidé měli dělat s malými hloupými programy, které nestojí za zpeněžení. Moc se mi líbila představa, že by se z nich možná mohl někdo něco naučit.

A tak je tomu doposud.

V té době jsem si začal hrát i s Linuxem, asi protože jsem už měl po krk restartování OS/2 (neustále to zamrzalo kvůli návrhové chybě, která zapříčinila, že to – upřímně – nebylo o moc lepší než Windows 3.1). Hrabal jsem se ve Slackware a asi jsem se do něj zamiloval, jakmile jsem zjistil, že si tam můžete sestavit vlastní jádro (sranda je, že se děsím toho, že bych to teď měl dělat). Potěšilo mě, že GCC tam byla norma. Později jsem byl očarován Enlightenmentem. Připadalo mi, že je to jako Budoucnost, kde všichni používáme takovéhle úžasné stroje a jezdíme v létajících autech.

Ještě nějakou dobu jsem pak zůstával na OS/2, ale věděl jsem, že je s tím ámen; Windows 95 je zabily v domácnosti a NT je zabily v kanceláři. Jednoho dne mi to bez zjevné příčiny sešrotovalo MBR a to byla poslední kapka. Kompletně jsem se vyhnul Windows a nainstaloval jsem Red Hat namísto zbytků mého oddílu s OS/2.

Po vysoké škole jsem začal pracovat ve vývoji pro Linux a Mac, protože nikdo jiný nic takového nedělal. Loki, firma, která prodávala hry pro Linux, pořádala takovou soutěž, kde jste si po 48 hodin mohli hrát se zdrojovým kódem jednoho z jejich produktů, takže jsem jel do Atlanty zúčastnit se a tak nějak se to přihodilo, že jsem pro ně začal pracovat.

Bla bla bla, jedno vedlo k druhému a tady mě máte. Asi mě víc bavíc kecat o OS/2 než o sobě samotném. :)

3) Co jste měl za první počítač?

Commodore 64! Používal jsem ho snad celé moje dětství, často jsem mu dával přednost, i když u nás doma už byly stroje s MS-DOSem.

Většinu času na C-64 jsem trávil hraním her. Nevím, odkud to bral, ale můj táta byl v té době aktivním počítačovým pirátem, takže jsme měli desítky krabic plných okopírovaných disků. To bylo v dobách, kdy člověku každá hra připadala naprosto jedinečná a úžasná a nic nebylo nemožné.

Technologie se posunula, ale nevím, jestli budu mít z hraní ještě někdy takový pocit. I přechod na „skutečné“ herní systémy jako 8bitové Nintendo mi připadal jako krok zpět, a to v mnoha směrech.

4) Jaké linuxové distribuce používáte?

Ubuntu, a to výhradně. Prošel jsem za ta léta mnoha distribucemi a kompletně jsem se vyhnul Debianu, ale jakmile jsem jednou narazil na apt-get, věděl jsem, že s ním budu šťastnější, než jsem byl kdy předtím. Ubuntu mi navíc přijde jako ze všech nejvíc zaměřené na budování systému pro koncové uživatele. Nevím, jestli se jim to povede, ale v současnosti mi přijde, že mají největší potenciál...a popularitu, což je v tomto případě skoro stejně důležité jako potenciál.

5) Které API si myslíte, že je z pohledu vývojáře lepší? OpenGL, nebo Direct3D? A proč?

Z OpenGL mám prostě lepší „pocit“, což není nic, co bych dokázal dobře vysvětlit těm, co neprogramují, ale myslím si, že teď ani nesejde na tom, jaké API si člověk zvolí. Obě API jsou na tom z hlediska funkčnosti více méně stejně, u obou byla napáchána řada návrhových chyb a obě dělají pár věcí o trochu příjemněji než to druhé z nich.

Direct3D samozřejmě nelze zapomenout to, že funguje jen na Windows. Kdyby to bylo skutečně multiplatformní, neměl bych nic proti tomu, aby se používalo. Ale protože pro OpenGL můžete programovat skoro kdekoliv a pro Direct3D skoro nikde, přijde mi jako špatná volba.

Kdybych psal software jen pro Windows, určitě bych používal Direct3D, a kdybych psal pro snad cokoliv jiné, určitě bych zvolil OpenGL.

Vím, že je sranda hádat se o věcěch jako co je lepší API nebo lepší distribuce nebo textový editor, ale tyhle věci jsou jen takové rozptýlení; namísto toho se zaměřte na vytváření krásných věcí s nástroji, co máte, nebo se zaměřte na tvorbu lepších nástrojů pro tvorbu krásných věcí.

6) Co si myslíte o kvalitě open source grafických ovladačů? Co máte za grafiku?

Myslím si, že ještě nejsou hotové, a myslím si, že jsme v nebezpečné situaci, kdy s nimi distribuce zacházejí, jako by byly.

Používám uzavřené ovladače Nvidia na GeForce 9800GTX. Moje příští GPU bude výkonnější karta GeForce s uzavřenými ovladači. Věci, na kterých pracuji, to vyžadují.

Navíc mi přijde naprosto směšné, že vydáváme open source OpenGL ovladače bez podpory S3TC kvůli obavám z patentů. To je jako by teď někdo vydával webový prohlížeč bez podpory .jpg!

V téhle věci jsem hodně pragmatický; zařazování open source ovladačů jen kvůli dogmatickému postoji ke svobodě softwaru vychází Linux, jakožto ekosystém, draho. Myslím si, že jediná cesta k open source ovladačům, jakou se nám podaří najít, je, pokud Nvidia (a další) začnou vyvíjet své vlastní ovladače jako open source od začátku, jako plnohodnotní členové komunity.

Nežeru nikomu postoj, že vývoj ovladačů pro GPU je _tak těžký_, že to obyčejní smrtelníci nedokážou, a tudíž nemá smysl, aby byly otevřené. Zároveň si ale myslím, že není možné psát s každou generací hardwaru, co se dostane na trh, všechno od začátku. Čistším řešením je otevřít ovladače, o kterých už víme, že fungují, a nechat všechny – výrobce hardwaru, distribuce, lidi samotné – pracovat na jednom stromu. Bylo by to všem ku prospěchu.

Neustále sním o lepším světě. :)

7) Před pár lety se zdálo, že trh s hrami pro Linux vzkvétá, portovalo se hodně her a další tituly měly podporu pro Linux plánovanou. Ale v posledních letech se linuxové binárky nedočkaly žádné velké tituly. Co si myslíte, že se stalo?

Chodí to ve vlnách. Dostáváme se na vrchol vlny, kde si každý myslí, že konzole jsou superbomba.

Nintendo má konzoli se zoufalým výkonem a Microsoft a Sony si zjevně myslí, že Kinect a Move jsou přijatelná nouzová řešení, která prodlouží současnou generaci konzolí, namísto aby přišli s novou. Hádám, že nevzali v úvahu, že se vývojové plány neustále prodlužují, takže životnost konzole se musí prodloužit, aby se tomu přizpůsobila.

Xbox 360 a PS3 tu s námi jsou už přes pět let a Wii je převážně hardware z Gamecube! Vývojáři si dříve či později uvědomí, že už ten hardware nedotlačí k tomu dělat, co chtějí, a vrátí se zpět k PC. Tohle se děje každých pár let.

Právě tehdy zase uvidíte na Linuxu tituly se zvučnými jmény. Stejně tak uvidíte více titulů pro Mac a více titulů pro Windows.

8) Navíc to vypadá, že jste vývojář číslo jedna v portování her, ale v poslední době jsme o vás neslyšeli. Je to následek nebo příčina této situace? :-)

Velkou část loňského roku jsem strávil prací na neherním titulu, to mi vzalo většinu času, ale dal jsem i tak do kupy několik titulů pro první dva Humble Indie Bundle.

Jestli jsem já jediným člověkem, kdo posouvá hraní na Linuxu, tak máme závažný problém. Mám radost z toho, čím jsem přispěl, ale byl bych raději, kdybych žil s vědomím, že hraní na Linuxu bude pokračovat, i kdyby mě srazil autobus. Jsou tu i další lidé, kteří dělají to, co já. Měl byste je také vyzpovídat. :)

9) Co vidíte jako největší překážku pro to, aby se hraní na Linuxu rozproudilo?

Vnímání. Dezinformace. A komunita je také někdy svým nejhorším nepřítelem.

Většinu z toho by vyřešil správný marketing. Bohužel, pokud vím, tak není žádný dobrý způsob, jak to zvládnout. Apple může mluvit za Mac OS X a Microsoft může propagovat svá Windows, jakkoliv uznají za vhodné. Kdo je zodpovědný za poselství posílaná za Linux?

10) Jak často vás osloví herní firma s tím, že od vás chtějí nějaké portování?

Má to nějakou pravidelnost, ale hodně z toho je jen na dedikované servery nebo takovou nebo makovou součást a ne na komplet hry běžící jako linuxové klienty.

Dřív jsem práci hledal, teď is obvykle hledá mě. Ale jsem dost takový nájemný pracant. Často po mě chtějí pracovat na věcech, které mají ke hrám daleko.

11) Pracujete teď právě na něčem? Je to něco velkého?

Vždycky na něčem pracuju. :)

UT3 mě naučilo nikdy nemluvit o něčem, dokud nemáte jistotu, že to bude také vydáno. Některé věci, na kterých dělám, jsou docela vzrušující, ostatní jsou běžná šeď. Ale budete si muset počkat, co se vynoří.

Co se open source týče: hodně jsem se teď zaměřil na MojoShader. Nikdy v životě jsem nepsal kompilátor, takže psaní kompilátoru pro tento projekt mě naučilo mnoho, včetně toho, jak se vzdát snahy o čistý a elegantní kód. Vývoj kompilátorů vás naučí, jak sáhnout po kráse, ale přijmout nedokonalost. Je to dost pokořující zkušenost; doporučil bych to každému.

Rád bych také někdy vydal novou velkou verzi PhysicsFS, strávil více času na MojoSetup a pomohl dotlačit SDL 1.3 ke skutečné verzi 2.0.

12) Nejsem si jistý, jestli tohle můžete zveřejnit, ale proč UT3 pro Linux nikdy nespatřilo světlo světa?

Bez komentáře. Je mi líto, o UT3 nemluvím.

13) Abchom viděli, jak zdatný programátor jste, jak dlouho vám trvalo přeportovat UT2004 na Linux?

UT2004 trvalo pár týdnů, ale většina práce už byla udělaná v UT2003, což bylo mnohem náročnější. Při portování UT2003 jsem spal pod stolem v kanceláři v Epicu, pracoval dlouhé dny v kuse, žil z jídla z mikrovlnky a fast foodů, hackoval jsem celé noci a pak se nadechoval čerstvého ranního vzduchu na balkóně budovy, zatímco vycházelo slunce.

Je to kus mé nejlepší práce. Žil jsem tím kódem; stal se mou součástí a já zase jeho.

Tenhle způsob vývoje vás stojí hodně z osobního hlediska, což tu teď nemůžu začít vyčíslovat. Každý člověk by měl někdy v životě na takovém projektu pracovat, když nemá co ztratit, vyjma povědomí o sobě samotném. A potom už to nikdy neopakovat.

Takže, abych odpověděl na vaši otázku: UT200x trvalo několik měsíců. A několik dekád.

14) Co je tou najčastěji se opakující „překážkou“ při portování, se kterou se setkáváte a opravujete? (Např. zpětná lomítka namísto dopředných)

To se zpětnými lomítky, to je hodně častý problém. Lidé také hodně očekávají, že souborový systém nerozlišuje velikost písmen, nebo že je v pořádku zapisovat do adresáře, kam je hra nainstalovaná, namísto někam pod $HOME (ačkoliv tohle se v poslední době zlepšilo, protože dokonce i Microsoft si na tenhle poslední problém stěžuje).

Tyhle problémy není těžké opravit, ale vynořují se skoro v každém projektu.

Dalším z nejhorších problémů je nutnost přepsát kód pro grafiku/zvuk nebo přijít na to, jak se vypořádat s tím, že není k dispozici nějaký middleware.

Statické konstruktory C++ se také ukazují být docela problematické. Občas se setkáte s něčím vyloženě šíleným, jako například se hrou, která cosi dělá se správcem paměti Windows nebo něčím takovým. Viděl jsem snad už každou příšernost, co jde vymyslet, ale řada stejných, méně hrozných problémů se objeví v každém projektu.

15) A jaký je vlastně váš postup portování? Jak začnete na kódu pracovat a jak ho testujete, když vám gcc chrlí tisíce chyb?

Prvním krokem je samozřejmě vyřešit ty chyby. :)

Jak kód postupně protlačuju skrz gcc, rozděluje se do dvou kategorií: opravit nebo napsat stub kód.

Pokud je to nějaká drobná zvláštnost v syntaxi C++ ve Visual Studiu, na které kód závisí, nebo se tam includuje windows.h nebo něco takového, opravím to rychle a jdu dál. Pokud je to něco složitějšího – tady chce třeba program zavolat nějaké Win32 API se spoustou datových typů, které nemáme – zakomentuju to a dám tam makro STUBBED. Tohle makro jen zapíše na stderr, když je spuštěno. Divili byste se, často ten kód není vůbec nikdy spouštěn, takže není třeba jej portovat.

Jakmile to máte všechno zkompilované a spustíte to, dostanete spoustu varování na stderr a za chvíli pravděpodobně i pád. Pak to začnete jedno po druhém procházet.

Některé věci jsou jednoduché (logování pro účely ladění, které chce vědět, kolik RAM je na stroji? Koho to zajímá?), něco může být pořádná nálož (přepsání celého rendereru), ale, zjednodušeně řečeno, většina práce je čištění těchto stubů, dokud hra nefunguje.

16) Přijde vám psaní multiplatformního kódu snadné?

Ano. Je to mnohem snazší než _portování_ kódu, to rozhodně.

Zjišťuji, že pokud hned od začátku píšete pro Windows, Linux a Mac OS X, váš kód bude pravděpodobně fungovat kdekoliv jinde, kde to pak zkusíte.

Není to tak dlouho, co lidé říkali, „Proč se s tím párat? Všichni používají Windows!“ Pak ale konzole získaly na důležitosti. A menší studia pořád mohou říkat „Stejně nám o ně nejde!“ Ale teď by najednou byli rádi, kdyby měli port pro iPad. Nikdy nevíte, co bude zítra důležité!

Psaní multiplatformního kódu hned od počátku vyžaduje větší disciplínu, ale zjišťuju, že to za tu námahu stojí. Vyžaduje to i trochu těžce získaných znalostí, což znamená, že to párkrát musíte pokazit, než přijdete na to, jak to dělat správně.

17) Co za oblíbenou hru máte na Linuxu? Kolik času běžně trávíte hraním her (včetně Wii a podobných)?

Mojí oblíbenou linuxovou hrou je teď bez pochyby Braid. Miloval jsem ji, ještě než jsem na ní pracoval. Dokonce jsem navrhl udělat Mac/Steam verzi zadarmo, jen abych měl příležitost nahlédnout do hlavy Jonathana Blowa.

Kolik času trávím hraním her? Přichází to v cyklech. Stanu se posedlým hrou na libovolné platformě a několik týdnů zkoumám všechny její kouty. Za to pravděpodobně může poškození mozku z mládí způsobené Metroidem.

Pak zase dlouho nehraju _nic_. Pro mě je snadné být vtažen do hry a přijít na dlouhou dobu o produktivitu. Mám tu velkou hromadu her, které čekají na to, abych je začal hrát, ale snažím se odolat. Mám tu tolik důležité práce, kterou musím udělat.

(Jen tak mimochodem: Strávil jsem celé dětství hraním her. V jednom kuse. Furt. Tisíce her po tisíce hodin. Ničeho z toho nelituji.)

18) Co si myslíte o Wine? Je to ta správná cesta nebo jen poslední možnost...

Poslední možnost. Myslím si, že to bude minimálně velmi užitečné k archeologickým účelům, podobně jako DosBox byl pro hraní Wing Commander. Ale je to jistě známé i jako spása s moderními tituly.

Ale mít to jako obecně přijatý způsob hraní her na Linuxu je naprosto nepřijatelné z několika důvodů, jak technických, tak morálních.

Děkujeme za rozhovor!

Ryan C. Gordon is one of the most significat Linux developers, at least as far as porting goes. He has worked on a host of game ports including Quake III Arena, Unreal Tournament 2004, Postal 2, Braid, or Serious Sam, but has also brought Google Earth to Linux, and works on the SDL or PhysicsFS libraries. He is behind the less acclaimed FatELF project as well.

1) First of all, could you please introduce yourself to our readers?

My name is Ryan, and I make video games run on Linux. When I'm not doing that, I spend time writing tools that make porting games to Linux easier. I also run a server, icculus.org, where I host open source projects for dozens of developers.

I spend a lot of time thinking about how to make Linux a better system, and hope that someday I will make some small but meaningful contribution towards that goal.

2) How did you get to Linux and Linux development? What's your job history?

Way back in 1994 or so, I had been a hardcore OS/2 user for a few years. I'm always struggling against the dominant system, I guess, but at the time, I was very smug about how much better my OS was than MS-DOS and Windows 3.1, which was stupid, since Windows 95 was about to steamroll in. I knew this, and continued to struggle against the inevitable.

I probably read about OS/2 in a magazine somewhere and I wanted it for technical features, but the reason I stuck with it for so long was a free program that ran on OS/2, named EMX. It was a free C compiler and you could download it via FTP, which was awesome, because Microsoft, IBM, Borland, all wanted hundreds of dollars for a C compiler and I was a teenager with no money.

EMX was a command line program, and the way you launched it was by typing three magic letters: gcc.

Some people get introduced to Free Software by accident. I loved this awesome compiler and used it all the time, but I didn't understand anything about the GPL. The source code to silly little programs I wrote got posted on FTP sites, but I didn't have any concept of software freedom. I just thought this is what people should do with silly little programs that aren't worth selling. I really liked the idea that someone could maybe learn something from them.

I still do.

I started playing with Linux around this time, too, probably because I was sick of rebooting OS/2 (it froze up all the time, due to a design flaw that made it--honestly--not much better than Windows 3.1). I was tinkering with Slackware, and was probably in love as soon I saw that you could build your very own customized kernel (comically, I cringe at the idea of doing that now). I was pleased that GCC was the standard there. Later, I would be blown away by Enlightenment's desktop. It felt like The Future, where we would use these glorious machines and drive around in flying cars.

I stuck with OS/2 for some time after that, but I knew it was doomed; Windows 95 had killed it in the home, and NT had killed it in the office. One day it ate my master boot record for no apparent reason, and that was that. I bypassed Windows entirely, installing Red Hat over top of the remains of my OS/2 partition.

Out of college, I was hired to do Linux and Mac development, because no one else did that. Loki, a company that sold Linux games, had a contest where you could play with the source code to one of their products for 48 hours, so I drove to Atlanta to participate, and somehow ended up working for them after that.

Blah blah blah, one thing led to another, and here I am today. I guess I'm more interested in blabbering about OS/2 than I am about myself. :)

3) What was your first computer?

A Commodore 64! I probably used it my whole childhood, frequently favoring it, even once there were MS-DOS machines in my house.

The vast majority of my time on the C-64 was spent playing video games. I don't know what his hookup was, but my Dad was a prolific software pirate back in the day, so we had dozens of boxes stuffed full of copied disks. This was back when every game felt wildly unique and brilliant and anything was possible.

Technology advanced, but I don't know that I'll ever feel that way about gaming again. Even moving to "real" game systems like the 8-bit Nintendo felt like a step down, in many ways.

4) Which Linux distribution(s) do you use?

Ubuntu, exclusively. I moved through many distros over the years, and missed the Debian boat completely, but once I stumbled into apt-get, I knew I was going to be happier than I'd ever been. Ubuntu seems to be the most focused on building a system for end-users, too. I don't know if they'll get it right, but right now, it feels like they have the most potential...and popularity, which is almost as important as potential in this case.

5) From developer's point of view, which API do you think is better? OpenGL or Direct3D? And why?

I happen to like the "feel" of OpenGL more, which isn't something I can explain well to those that aren't programmers, but I don't think it matters much at this point which API one chooses. More or less, you have feature parity between both APIs, both have made a handful of design mistakes, and both do a few things in slightly more pleasant ways than the other.

Of course, the unforgivable thing about Direct3D is that it only works on Windows. If it was truly cross-platform, though, I wouldn't really object to using it. But since you write OpenGL almost everywhere, and Direct3D almost nowhere, it seems like a false choice to me. If I were writing Windows software, I would definitely use Direct3D, and if I were writing almost anything else, I would definitely use OpenGL.

I know it's fun to fight about things like the better API, or the better distro or text editor, but those arguments are distractions; instead, focus on building beautiful things with the tools you have, and failing that, focus on building better tools to make beautiful things.

6) What do you think about the quality of open source graphics drivers? What graphics hardware do you use?

I think they aren't ready yet, and I think we're in a dangerous position where distros are treating them as if they are.

I use Nvidia's closed-source drivers on a GeForce 9800GTX. My next GPU will be a more-powerful GeForce card with closed-source drivers. The things I work on require this.

Also, I find it completely ridiculous that we're shipping open source OpenGL drivers without S3TC support because of patent concerns. Today, that's like shipping a web browser without .jpg support!

I feel very pragmatic about this; open source video drivers being shipped simply for dogmatic attitudes towards software freedom is costly to Linux as an ecosystem. I believe the only way that we'll ever find a reasonable way to have open source drivers is if Nvidia (etc) start developing their drivers as open source from the start, as first class members of the community.

I don't buy this attitude that GPU driver development is just _so hard_ that mere mortals can't do it, and thus there's no value to being open. But I do think there's no way that open source drivers can keep starting from scratch as each new generation of hardware hits store shelves. The cleaner solution is to open up the source to drivers we already know work, and have everyone--hardware vendors, distros, individuals--working in the same source tree. Every one would win.

I continue to dream of a better world. :)

7) A few years ago the Linux gaming market appeared to bloom, there was quite a lot of games getting ported and other titles had Linux support in planning. But in the past couple of years, there have been no major gaming titles getting a Linux binary. What do you belive has happened?

It comes in waves. We're cresting the wave where everyone thinks that game consoles are super-awesome.

Nintendo has a seriously underpowered console, though, and Microsoft and Sony seem to think Kinect and Move are acceptable stop-gaps to extend the current console generation instead of introducing a new one. I guess they didn't consider that development schedules just get longer and longer, so a console's lifespan needs to increase to accomodate.

The Xbox 360 and PS3 are over five years, and the Wii is mostly Gamecube hardware! Sooner or later, developers are going to realize that they can't get the tech to do what they want anymore, and come back to the PC. Happens every few years.

That's when you'll see big-name Linux titles showing up again. Same as you'll see more Mac titles, and more Windows titles.

8) It also appears that you are the developer number one in game porting, but we haven't been hearing from you recently. Is this is the reason or the result of the situation? :-)

I spent a lot of last year working on a non-game project, which took most of my time, but I did push out several titles for the first two Humble Indie Bundles, too.

If I'm the only one pushing Linux gaming, we have a serious problem. I'm happy for the contributions I've made, but I would be happier to know that Linux gaming can continue if I get hit by a bus. There are others out there doing what I do. You should interview them too. :)

9) What do you see as the biggest hurdle preventing Linux gaming from getting some major traction?

Perception. Misinformation. And, sometimes, the community is its own worst enemy.

The right marketing would solve much of this. Unfortunately, there isn't a good way, as far as I can tell, to handle this. Apple can speak for Mac OS X and Microsoft can market Windows however it sees fit. Who's in charge of the Linux message?

10) How often do you get approached by a game studio to do some porting?

I get approached with some frequency, but a lot of it is for dedicated servers, or some component or another and not full games running as Linux clients.

I used to look for work, now it usually comes looking for me. But I'm pretty mercenary. Lots of times, I'm asked about working on things that aren't games at all.

11) Are you working on something right now? Is it a big one?

I'm always working on something. :)

UT3 has taught me to never, ever talk about something until you know it's going to ship. Some things I'm working on are quite exciting, others are pretty mundane. You'll just have to see what pops up in the future, though.

As for open source: I'm very focused right now on MojoShader. I've never written a compiler before, so building one for this project has taught me a lot, including how to surrender the pursuit of clean and elegant code. Compiler development will teach you to reach for beauty but accept imperfection. It's a humbling experience; I'd recommend it to everyone.

I hope to get a major revision of PhysicsFS out at some point, spend more time improving MojoSetup, and help push SDL 1.3 to a real 2.0 release.

12) Not sure if you can disclose this sort of information, but why UT3 for Linux never got to see the light of the day?

No comment. Sorry, I don't talk about UT3.

13) Just to see how skillful a programmer you are, how long did it take you to port UT2004 to Linux?

UT2004 took a few weeks, but most of the work was done for UT2003, which was a much more intense effort. For UT2003, I found myself asleep under desks in Epic's offices, working for stretches of days at a time, living off microwave meals and take-out food, hacking all night and then breathing the morning air off the building's balcony as the sun rose.

It was some of my best work. I lived in that codebase; it became part of me, and I became part of it.

There's an enormous personal cost in this sort of development, which I can't begin to quantify here. Everyone should work on a project like that at some point in their lives, when they have nothing to lose except their own sense of self. And after that, never again.

So, to answer your question: UT200x took a few months. And a few decades.

14) What's the most recurring portability "hurdle" you get to see and fix? (E.g. backslashes instead of forward slashes)

The backslash thing is a big one. There's a lot of expectation that the filesystem is case-insensitive, too, or that it's okay to write to the game's installed directory instead of somewhere under $HOME (although that's gotten better recently, since even Microsoft is complaining about that last issue now, too).

These aren't hard to fix, but they crop up on almost every project.

The next worst problem is having to rewrite the video/audio code, or figure out how to deal with some middleware that isn't available.

C++ static constructors turn out to be surprisingly painful.

Occasionally you get something truly crazy, like a game that wants to manipulate the Windows memory manager or something.

I've seen every insane, nasty thing in the book, but a lot of the same, less-nasty problems crop up on every project.

15) Also, what's your porting procedure? How do you start working on the code and testing it, if you've got gcc spewing thousands of errors?

Naturally, the first step is resolving those errors. :)

As code gets pushed through gcc, it falls into two categories: fix it, or stub it.

If it's some little C++ syntax quirk in Visual Studio that the code had come to rely on, or it wants to include windows.h or whatever, I fix it quickly and move on to the next issue. If it's something more complicated--here the program wants to call some Win32 API with a bunch of data types we don't have--I'll comment it out and put a macro called STUBBED there. All this macro does is write to stderr when I hit this code. You'd be surprised, some times that code is never actually used, so there's no need to port it.

Once you get everything compiled and running, you'll get a big pile of warnings on stderr, and probably a crash soon after. Then you start going through them one at a time.

Some of them are simple (debug logging that wanted to know how much RAM is in the machine? Who cares?), some might be massive undertakings (rewrite the entire renderer), but, on some simple level, the bulk of the work is cleaning out each of these stubs until the game runs.

16) Do you find it easy to write multiplatform code?

Yes, I do. It's much easier than _porting_ code, to be certain.

I find if you're targeting Windows, Linux, and Mac OS X right from the start, your code will probably work anywhere else that you might try it later.

Not to long ago, people would say, "why bother? Everyone runs Windows!"

But then the consoles became important.

And smaller shops might still say, "well, I'm not targeting those anyhow!"

But now they wish they had an iPad port.

You never know what will be important tomorrow!

Writing code that is cross-platform from the start requires more discipline, but I find it is worth the effort. It also requires a little hard-learned knowledge, which is to say you have to do it wrong a few times before you know how to do it right.

17) What's your favorite Linux game? How much time do you usually spend playing games (incl. Wii and the like)?

My favorite Linux game at the moment is Braid, without a doubt. I loved it before I was working on it. I actually offered to do the Mac/steam version of Braid for free, just so I'd have an opportunity to look inside Jonathan Blow's brain a little.

How much time do I spend playing games? It goes in cycles. I'll get obsessed with a game on whatever platform, and I'll explore every corner of it for a few weeks. This is probably brain damage from my youth, caused by Metroid.

Then I won't play _anything_ for a long time. It's really easy for me to get sucked in and lose productivity for way too long. There is a huge pile of games waiting for me to start, but I try my best to resist. There's just so much important work I have to get done.

(fwiw, though: I spent my entire childhood playing video games. All the time. Constantly. Thousands of them over thousands of hours. I regret none of this.)

18) What do you think of Wine? Is this the way to go or is it just the last resort...

The last resort. I think it will be, at a minimum, incredibly useful to archeology, like DosBox has been for playing Wing Commander. Certainly it has been known to save the day with modern titles, too.

But to have it as the agreed-upon way to how you play video games on Linux is completely unacceptable for several reasons, both technical and moral.

Thank you for your time!

Další články z této rubriky

Michal Švec ze SUSE na téma Virtualizace a SLES
Rozhovor s Radkem Špimrem, IBM na téma nových serverů IBM Power Systems LC
Zpověď startupu na vlně IBM
ČVUT jako MIT? Lendl, Navrátilová, Jágr, Sáblíková, nebo absolvent FELu?
Práce vývojáře je dobrodružství

ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.