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.
Maybe for people with pretty powerful laptops, but with a horrible graphics chip. Obviously they're not going to be able to get even basic 640x480 OpenGL quality.. but they at least be able to play it.... hopefully?
You crazy man? You piss off supahfly!
UT2k3 is not a game for the 'casual' game.
Well that's how I play it. You don't have too play it like you're a sad geek with no life but practising your UT. For some people (like me) who get lousy pings, there isn't much choice. It doesn't matter how quick you are with a 300ms delay before your shot is registered. You can play defensive or with a bit of strategy to make up for it. It's actually lots of fun frustrating dextrous kiddies who know where all the powerups are (and who cheat) with a bit of stategy. The BR patterns are best for this.
Reliable, Great Value Hosting: $7.95/mo 2.4G/120G
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.
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?
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.