I would like to explore realtime software based rasterization. I know everything is going towards the GPU these days but there are a few games where it still makes sense to use a software renderer.

For example: Voxeltron

Voxatron is an arena shooter that takes place in a world made of voxels (little cubes, kind of). Everything in the game is displayed in a virtual 128x128x64 voxel display, including the menus and player inventory. If you look closely, you can sometimes see the inventory (score/life/ammo) casting a shadow on some of the objects on the ground.

I've been working on voxel rendering and modeling tools for a long time now, with the ultimate goal of making a large explorey adventure game. About half a year ago it fused with work I was doing on arena shooters for Conflux, and this is the result.

It's quite a simple game at heart -- mostly just Robotron set in a 3d destructible world with goofy creatures. I'm unsure how major the implications of destructibility will be for gameplay, but it sure is fun to blast away pieces of wall. I've also added an experimental wall-building pickup you can use to construct barriers to hide from scary monsters.

The game takes place in a small set of arenas. Some of them feature rooms with set action pieces, somewhere between Knightlore and Smash TV. This is some of the original adventure based design sneaking back in, and an excuse to create thematic environments.


  • Custom software rendering with soft shadows.
  • Built-in sound and music synthesizer (also used to make the trailer music).
  • Playback & post game recording.
  • 1
    \$\begingroup\$ Neat link to a game. Note its not necessary to use a software renderer to get soft shadows on the GPU. He'll run into some performance limitations from the render loop side, not be able to run on more basic machines such as 1.6 GHz laptops or handheld devices, when he really can if he exploits available hardware. \$\endgroup\$
    – bobobobo
    Commented Sep 22, 2011 at 17:31

3 Answers 3


I am going to assume you already know some basic linear algebra, the kind involved in: 3d projections, camera setup, transforming vertices into world position, etc... If you don't, there are plenty of great places to learn from. Here are two that I like:

Game Engine Architecture

  • Brief coverage of basic linear algebra but does cover everything you need to know. The book is worth having for many other reasons too.

Real-time Rendering

  • A little bit more detailed coverage but again sticks to only what you might need to know. Again, I recommend this one for the topics covered in the rest of the chapters.

Once you know about how to represent and handle 3d objects you are ready to look at how to draw them to the screen. Typically this is done with a scan line triangle rasterization technique. It is actually a pretty simple concept. You draw one row of one triangle at a time while interpolating color and uv texture coordinates. This process is continued for all triangles on the screen. You could even implement a depth buffer to handle out of order rendering.

enter image description here enter image description here enter image description here

This is covered in more detail in these articles:

Tutorial - Introduction to Software-based Rendering: Triangle Rasterization

Software Rendering School: Part I

And just for fun, check out the following article:

Quake 2 Source Code Review 3/4 (Software Renderer)

  • \$\begingroup\$ You're welcome :] (you might also want to take a look here for a more detailed overview of the process: en.wikipedia.org/wiki/Rasterisation) \$\endgroup\$
    – zfedoran
    Commented Sep 22, 2011 at 18:20
  • \$\begingroup\$ Some good links there! \$\endgroup\$ Commented Sep 22, 2011 at 20:08

This is a pretty broad topic. There are two basic parts to it, though: the actual theory of the graphics transformation and rasterization pipeline, and the actual implementation bits that let you blast pixels on the to screen however you choose. On top of that, there is also optimization (particularly of the latter bit).

The first part is fortunately the same as the theory used for the graphics pipeline as exposed by modern hardware and APIs. If you know this already, you're set. If you don't, I recommend a good book. This one is pretty good.

There are a lot of options for the second part. They depend heavily on your OS and toolchain choices. If you're using C or C++, on Windows, you can simply plot pixels directly to a GDI bitmap (SetPixel is simple, but painfully, useless slow -- CreateDIBSection gives you a chunk of raw bytes you can manipulate at a much faster rate).

You can also acquire a DirectDraw surface and write to that, or write to a Direct3D or OpenGL texture. In these latter cases you'll still be using hardware, but as long as you do all the composition of the final image on the CPU yourself and just use the hardware APIs to copy the results to the screen, it still counts. On modern PCs you can't get access to the raw VRAM or anything directly anyhow.

If you'd like to know more, you should probably create more specific questions. I or others would be happy to answer them.

  • \$\begingroup\$ For the book: How good is "pretty good"? $84 is a fair bit of cash :) \$\endgroup\$ Commented Sep 22, 2011 at 17:59
  • \$\begingroup\$ It's the one I recommend most highly. For the cheapest option you can refer to the Direct3D documentation on the transformation pipeline. Although it is D3D specific, 95% of it is pretty applicable to the general theory. You can also check out the online copies of the OpenGL Red Book. They're outdated, but the theory (again) still applies. \$\endgroup\$
    – user1430
    Commented Sep 22, 2011 at 18:28

Okay I'm going to approach this question from the very basics; anything beyond that is way to broad for a simple QA; you need to buy a book on the subject.

The most fundamental difference between rendering in software and using a GPU comes down to plotting pixels. That is, when doing software rendering you are ultimately responsible for plotting every damn pixel, whereas with a GPU the plotting of pixels is largely automated by the hardware and you just "massage" the pixel pipeline using shaders.

For example, think about what you as a programmer have to do in order to display a 3D triangle on the screen. With a GPU, you pretty much just tell the hardware what the X,Y,Z coordinates of the vertices are and then the videocard fills in all the pixels on the screen that comprise the image of a triangle. You might use a shader to tell the GPU to change the color of every pixel based on a texture or something, but ultimately it still comes down to the GPU automatically filling in all the pixels for you.

Doing software rendering, you'd have to calculate which pixels on the screen to fill in, and then do the blitting to actually fill in those pixels. That is, you'd be doing the matrix math to transform from the coordinate space of the 3D scene to the view space, then projecting points from the view space onto the screen, etc.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .