V kontrolním skriptu byla vylepšena detekce Linux/Ebury a přidány nově zjištěné signatury napadených webových serverů komponentou Linux/Cdorked.… více »
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!
Nástroje: Tisk bez diskuse