Slashdot Mirror
Unreal Tournament 2K3 Gets Software Renderer
Thanks to an anonymous reader for pointing out that the official Unreal Technology page has been updated with a software renderer for Unreal Tournament 2K3. This is an interesting step for those gamers with fast CPUs but inadequate 3D cards. The Pixomatic technology powering it was co-developed by Michael Abrash, John Carmack's right-hand man during the development of Quake, and a famous programmer and writer (at Microsoft and elsewhere) way before then.
Where this could come into play are corporate desktops that have 2+ GHz P4 or Celeron's using Intel's Extreme Graphics integrated video (which is a wee bit better than the poor i740/i81x stuff).
Also, look at some of the eMachines and el cheapo systems that have decent processors (1.6+ GHz is fast in most cases) but use integrated graphic too.
is that the UTV client will be done in a couple of weeks allowing virtually unlimited spectation of matches with only one "cameraman" in the server.
also Epic has said the next patch will break network compatibility with older servers/clients, but will also reduce client bandwidth requirements by 40% and server CPU utilization by as much as 50%... pretty crazy if true. Interesting they would break network compatability given that they are releasing the next iteration (UT2004) this fall, but if we get those kinds of benefits it would be well worth it. Good servers are in short supply unfortunately, in part because of their high requirements.
The Epic boys have been quite busy. I have to say I was extremely dissapointed with the buggy nature of UT2003 at release, but they have truly gone above and beyond the call of duty with these mega beefy patches and free content and extras like software rendering for example. Hopefully the 2004 release (backwards compatible with 2003 servers) will reinvigorate the online community for this franchise...
Brute force APIs (OpenGL, D3D) are not easy to implement with reasonable performance in software. In software, overdraw (drawing primitives several times over the same pixel) kills you. In hardware, overdraw is not that much of an issue until scene complexity starts climbing beyond 10 or 20 -- that's how many times the same pixel has been repainted for a single frame. That basically means your GPU can draw polygons on the screen 20x faster than your CPU. Not bad for something that's 10x slower on paper (MHz vs MHz).
Plus, the GPU can do texture mapping and projections and nowadays can run short programs for each pixel. All that is gone with the CPU if you want something that performs half-decently in terms of FPS (you want something over 30 to call it interactive and over 50 to make it playable without problems for most people).
End effect: a pure software renderer has to use a different renderer. One that is a bit smarter about overdraw. And that's not your out-of-the-box OpenGL game renderer. Games have better things to worry about than reducing overdraw.
Mesa is not anywhere near "reasonably fast" without hardware support. Software Mesa renders a frame every few seconds. Pixomatic can get 70 to 100 fps in many scenes. Then again, Mesa is meant to be a correct OpenGL implementation, whereas Pixomatic is concerned with speed over quality (and isn't an OpenGL API at all).
--ryan.
Don't say, "don't quote me," because if no one quotes you, you probably haven't said a thing worth saying.
Most cheap PCs available at Dell or BestBuy come without an AGP slot and with Intel integrated graphics though have extremely powerful CPUs. The software renderer is aimed for folks with those machines.
-- Daniel, Epic Games Inc.
The reasons for going with a commercial product aimed specifically at games, rather than an open source (or whatever Mesa is licensed as - I think it's MIT or similar) more generic software renderer should be obvious.
>And the compiler should optimize things for a given processor.