Why Pixomatic?

Why did you bother writing a 3D software rasterizer?

There are several reasons, but the biggest one is that Pixomatic brings the good parts of console programming to the PC.

When you use Pixomatic, you have only one feature set; you have only one API; you have only one driver; and you have only one hardware target, albeit one that can run at different clock speeds. Better yet, the hardware features are guaranteed never to change in the future, and you ship with the same graphics system software and driver you developed and tested on, so those can't ever change on you either.

It's as if you were programming a console that's sold with several different clock speeds, but always with identical graphics hardware and system software. As any console programmer can tell you, this simplifies life a great deal, and frees up effort for more valuable things than dealing with the ever-changing complexities of the PC graphics world.

And your software will run on pretty much every PC out there.

So Pixomatic is just like programming a console?

In terms of providing a reliable platform, yes, but we're not going to try to mislead you - software rasterization is considerably slower than the current generation of consoles and 3D cards for the PC, and offers fewer graphics features. Pixomatic is roughly an order of magnitude slower than leading-edge consoles and PC graphics cards as we write this in 2003 (although faster than any previous console generation, and more powerful overall than the first generation of PC 3D hardware as well), and supports DX7-class pixel shading. 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. Doom III is not going to run in its full glory on Pixomatic for a long time.

If, on the other hand, you're working on a game that needs or would benefit from 3D but isn't pushing the envelope, Pixomatic may meet your needs very nicely indeed. This is a category that includes a great many games, including real-time strategy games, simulations, first-person games that aren't trying to do leading-edge graphics (Quake II runs well on Pixomatic with all features enabled, so it's certainly possible to do credible, if not leading-edge, first-person graphics), and a wide variety of board and strategy games. 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.

Fine, so Pixomatic could work for a lot of games, but why would it be better for those games, when hardware is faster and free?

The answer lies in two areas - market size and the complexity of the PC graphics infrastructure - which together cause hardware rasterization not to be free at all.

The development, testing, and technical support cost of the nightmare matrix of system software, drivers, and hardware for the PC is the single biggest reason for Pixomatic's existence. There are two graphics APIs, each with frequent revisions - and when a revision is installed for one app, it becomes global for all apps that use that API. There are several major graphics hardware manufacturers, with many chip and board variations per manufacturer. (Check out the number of different video cards that Half-Life players have!) Perhaps worst of all, there's a steady stream of driver updates, each with its own bug fixes and newly-introduced bugs, which again become global to all apps when installed. In order to use PC graphics hardware, you have to program around the feature and performance differences between the various configurations, while working around the bugs, and in the end your software is still likely to run into problems because it will inevitably run on hardware and software with which it's never been tested.

With Pixomatic, in contrast, the feature set is constant, and, apart from performance, there's only one testing platform. Even with regard to performance, the range which you have to accommodate is much less than with hardware; from a PIII/500 to a P4/3000 is only about a 1:4 performance ratio, considerably less than from an average four-year-old graphics card to a modern leading-edge card.

Some familiar annoyances vanish with Pixomatic. For example, there are no texture management issues, since textures are stored in system memory. There are also no synchronization issues related to when textures can be modified or deleted, since Pixomatic is synchronous at all times. You're free to read the color and z buffers at any time, with no performance penalty.

Oh, yes - you also get source code, so with Pixomatic you'll never find yourself at the mercy of an inscrutable API.

So development is simplified, testing is simplified, technical support is permanently simplified - and your game will run on any x86-compatible Windows or Linux machine that supports MMX. That group includes pretty much every Windows or Linux machine sold since 1997 or so, including all P4, PIII, Celeron, Athlon, and K6-based machines and even some Pentiums - which is to say virtually every Windows or Linux machine owned by someone who might pay money to buy new software. To get an idea of how much Pixomatic might increase your potential market, consider that more than 40 percent of Half-Life players responding to a recent survey are using software rasterization.

Like we said, if you need the full power of hardware in order for your game to look the way you want it to, then you need hardware - no argument there. But if your game would look just as good running on Pixomatic, the benefits can be considerable.

Is there any reason I should care about Pixomatic if my game does need hardware?

Even if you do need hardware in order for your game to look its best, you may nonetheless find Pixomatic useful. For one thing, it can help sales to be able to fall back to software rasterization, simply because it increases the number of machines that can run your game. It can also be a significant plus to have a software fallback mode for those cases where the hardware isn't working for whatever reason; this can help with both technical support and avoiding returns. Implementing this for a leading-edge game requires a little work, because the game has to be configured to scale back rasterization demands (lower LOD, smaller textures, simpler shading, lower resolution) when drawing through Pixomatic, but it's not very difficult, and the return on the modest time and effort required can be surprisingly high. (Besides, you'll probably have to do most of that work anyway if you want to run on older and lower-end 3D hardware.) If you think it's unlikely that a game that makes sophisticated use of 3D hardware could also benefit from Pixomatic, you might want to think again: Epic has incorporated Pixomatic into their powerful and widely-used Unreal Tournament 2003 engine.

Also, you can use Pixomatic to render to textures that hardware will later use. This avoids the complications and hardware stalls that sometimes cause problems when using hardware to render to textures; if you're render-bound, it has the added bonus of letting you get more coprocessing by offloading some rendering work to the CPU.

Finally, you could use Pixomatic to render the depth values of the static parts of your scenes - or perhaps just the large structural triangles - to a relatively low-resolution z buffer, followed by the depth values of the bounding boxes of the moving objects in the scene, using the visibility-testing feature to see if any part of each bounding box is visible. Whenever an object's bounding box doesn't pass, you can skip sending that object to the 3D hardware, because it's completely occluded. (It's possible a few pixels may actually be visible, due to the use of a low-resolution z buffer, but that's highly unlikely to be noticeable in a real-time 3D scene.) This can help considerably in complex scenes where there are so many high-detail models that they overwhelm the hardware's triangle-handling capacity, but many of the models are hidden - for example, a city scene where all the models for blocks around are drawn, but most are occluded by nearby buildings.

Could you please sum up so we can finish this page?

Sure. In a nutshell, one answer to "Why Pixomatic?" is: if software rasterization meets all your needs, Pixomatic is simpler and more reliable than 3D hardware acceleration, and lets you move on to other, more rewarding things than wrestling with driver updates, hardware incompatibilities, system software bugs, and all the other complexities of the PC graphics infrastructure. In short, Pixomatic is an efficient and cost-effective 3D solution.

The other answer is that if your game does need 3D hardware to look its best, using Pixomatic as a fallback renderer will enable you to sell more copies, reduce technical support costs, and have fewer games returned because of hardware and driver problems.

Either way, if it meets your needs, Pixomatic can make you real money.