Unreal Engine Linux Ports Not Dead?

CookieMnstr|PuF writes: "Brandon Reinhart, programmer at Epic, has updated his .plan file in response to the fear that no more Unreal Engine-based games will be ported to Linux. He faults the Linux community for jumping to the conclusion that Unreal Engine games will not be a reality for the Mac and Linux. Maybe he should read beyond the headlines. "

Comments

Re:I prefer D3D now

[Bert Peers]

Well, this is only partially true. The thing is that progress in D3D often means nothing more than defining a number of new features in the docs. That's only an illusion of progress : sure, in theory you could say that D3D is more advanced than OpenGL because for instance D3D exposes 8 stage texture combiners since D3D6, while OpenGL still struggled to get multitexturing past the ARB, but on the other hand, as long as the hardware out there doesn't set the capability bits that actually make all the theoretical D3D feature *real*, all that M$ progress is just APIware. And it's just as easy for, say, NVidia, to expose a GL_EXT_thisandthat as to set a capability bit. Basically, I disagree with you saying that D3D > OpenGL, because OpenGL is open to start : any vendor can define extensions for his hardware; with D3D, everything has to come from M$.

I do agree though that D3D is currently the better environment for development when you want to build 3D engines for vast continuous levels; Windows' tendency to trash the videomemory upon a task switch forces OpenGL to waste huge amounts of memory on keeping copies of every texture. Sweeney complained about that quite a while ago, so it was evident back then that he'd either have to find a solution for it (hoping for a GL_EXT_nosystemcopy perhaps ?), or drop OpenGL for being too memory intensive.

About OpenGL being geared towards id. That's true, but it's probably a good thing. The 3D APIs of today are so complex that it's probably daydreaming to think a driver writer can optimise *everything*. The combined internal state is so huge that you cannot build an optimal path for each and every combination. One influential game that uses a limited set of the API gives driver writers an opportunity to max out performance on that path, which in turn allows other developers to write their code with that path in mind -- instead of just reading the docs and picking one of the 35 possibilities to specify their geometry, hoping it'll come out right and speedy. You're right that this situation is not without danger of getting stuck, though...