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.
Who has a fast enough CPU to run this game, but *doesn't* have any kind of 3d accelerated video card. That kind of userbase must be incredibly small. I'm struggling to come up with any kind of user who would want to play this that wouldn't have at LEAST a TNT2 or GeForce. And a GeForce2 can be had for what, $20? Less than the price of the game. Please tell me who this is for.
Of course maybe there's a more important reason for the software renderer, but I'm not going to read the article for fear of being proven wrong.
"Moderate drinking can help prevent amputated limbs" -- Abigail Zuger, NYTimes, 12/31/02
"If you need six passes per light with four lights at a time, or if you need 30 million triangles a second, or if you have multiple layers of alpha everywhere on the screen - in short, if you need anything like the power of the latest GeForce or Radeon - then Pixomatic is not for you."
Gee...and here I was thinking that I could get my PIII to run DoomIII like a champ... *sigh*
Sarcasm aside, I think this is pretty cool: "In fact, Pixomatic would have worked well for at least 17 and possibly as many as 19 of the top 20 PC games of 2001." For stuff that doesn't need the latest and greatest, this is nice.
buzzwords are fun. does it also have BLAST PROCESSING?
"Life is great; without it, you'd be dead." -Harmony Korine
A software renderer means that the software will still run, whereas the hardware we have right now will be gone.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"Despite the claims this has no use, my work laptop has a nice fast Pentium 3 in it, and a crap vidcard. I'm sure I'm not alone.
I'd use it. I have a speady computer with a fast ATI Radeon 9700. Unfortunatly the drivers do not support UT2K3. I get 20 FPS which sucks bigtime. I guess even the software renderer will do better.
I'd really like to see an Athlon XP 3200+ go up against a Pentium 4 3.06GHz in software rendering. Usually, when a new proc comes out, everyone benchmarks it combined with a top-of-the-line video card. I've never seen the point of that. Why not use a software renderer to see how truly fast the CPU is?
Quality or Quantity, don't tell me they're the same.
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...
The only reasons I could think of that they'd want to write their own would be:
- They wanted to optimize for the only the operations they use. Their renderer performs no lighting calculations, for instance.
- They can optimize for a specific operating system and processor. They use MMX instructions, for instance.
But that's about all I can come up with. And the compiler should optimize things for a given processor.Anyone have any other ideas why they decided not to go with Mesa?
Regardless of how fast your processor is, this game will still run SLOW with software rendering. Even on my ahtlon 1800+, half-life get's TERRIBLE FPS in software rendering mode. I can't imagine that you'd be a able to play this with acceptable framerate in any resolution over 640x480 even if you're on a 3.06ghz P4.
Of course there might be people out there willing to play with 5-50 FPS, but I'm not one of them.
There are plenty of hefty business machines out there in offices everywhere, which have nice cpu's (2ghz+) but no directx8 3d compatible gfx hardware.
Sure, not every business looks favourably on gaming at work, but hey, if it helps sell a couple of thousand more copies, it can only be a good thing.
\\ Mitch
Mesa is something of a reference implementation. As such it's mostly designed for pixel-perfect accuracy in software mode. Performance is a secondary consideration.
You make an assumption about compilers: they aren't very good at optimizing when it comes to low-level graphics work - they can be amazingly dumb. You can expect a 2 or 3x performance gain by rewriting just a few very tiny sections in assembler.
An OpenGL-alike API is also not the most ideal for a software renderer - it makes assumptions that only 3D hardware can benefit from. A specilised API can be tuned to the task at hand - in this case software rendering. I'm sure there are going to be shortcuts it's taking that you wouldn't dream of using with a hardware rendering solution. At the very least:
(1) Sharing verticies across polygons in the transform pipeline. This greatly reduces the number of verticies that have to be transformed. On hardware, verticies generally have to be duplicated because the rasteriser can't use separate sources for UV texture and XYZ position at each vertex (and this tends to not matter given the speed of the hardware geometry transform engine).
(2) Not bothering to clear the back buffer - this is important to do with a hardware Z-buffer (unless you use the cunning Z-flip trick), but completely irrelevant with software. The screen only contains color information that you're going to completely overwrite anyway.
(3) Decreased accuracy. There are all sorts of tricks you can do - from using low precision floating point, to fixed point integer math (less useful these days), to making assumptions about upper texture size limits in your rasteriser.
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.
Business, Schools, libraries, offices; places where you are suppose to work... usually have powerful computer and relatively shitty GPU.