Software Rendering

I have a couple of books...
Interestingly, the new LaMonthe book covers this topic in great detail.

Yeah I know. I was kinda hoping to play around with the topic a bit before I invested seventy some odd dollars in his book. Spinning cube or some such.

---

[My site|SGI STL|Bjarne FAQ|C++ FAQ Lite|MSDN|Jargon]
Ripped off from various people

Amazon.com used books, can''t beat ''em. I got a perfect copy of Trix of Win Game prog. 2nd for $20...

Kings of Chaos

Why would LaMothe spend so much of a new book on software rendering when so few people do it (& presumably getting less all the time)? I definitely approve of doing it for learning purposes but unless he wants you to understand for shader purposes or maybe is now ''big'' enough to get published whatever he writes & has a bee in his bonnet about software rendering...?

Software renderers may be making a come-back, of sorts. Its true that a software renderer may never achieve the quality of a good 3D card but considering that I was playing fullscreen 3D games on my old Pentium 75, I could play pretty excellent software rendered games on my P4 1.7GHz with SSE / MMX.

Even if software renderers never see the light of day, I still recommend learning how they are done. The 3D card is doing much the same things in silicon, and knowing how it works can really help you write games in OpenGL / D3D - just as knowing assembler can help you write C/C++.

Although I may just be being an old fart here. I started my career writing software renderers and I dont want that skill-set to become completely obsolete!

*graps at straws* so there''s no decent primer on the net anywhere? It''s a hard thing to google for too.

---

[My site|SGI STL|Bjarne FAQ|C++ FAQ Lite|MSDN|Jargon]
Ripped off from various people

i think there was a column on flipcode that walks you trough a simple software renderer, i believe it was DirtyPunks column or something like that...flipcode is down currently so i can't check it

Edit: ok flipcode is back, and it was the portal engine series..he begin's with wireframe cubes, polygon filling etc.




[edited by - Burning_Ice on July 23, 2003 8:58:00 AM]

Don''t get me rwong I fully agree that writing a renderer is a good idea, and that a modern p4 3GHz could do some pretty cool stuff. But a modern GPU is probably at least 10X faster in terms of AA, filtered, textured polys drawn. You do get a lot more flexibility in software but with shaders coming into force even that is becoming less of an issue. Eventully PCs may be fast enough that a GPU becomes unrequired but until then the fact a GPU can do hugely complex scenes while the CPU practically idles has huge advantages for any part of a game OTHER than the graphics!

For the guy looking for info, try finding very old graphics books from when everyone had to do software engines - say 5-8 years ago. The only problem is they may use lots of asm. The main things you need to know are:
What is triangle rasterization, and lighting calculations. TRy googling for things along those lines.

Its been a while but I''ll try a quick description.
You can look up the matricies in more details else where.

Apply world transformation matrix to all vertices in your scene. That''s the opposite of where you want your camera.

Apply a perspective matrix to the objects.

Apply a projection matrix to the scene. You should now have all the vertices of your scene in screen space.

Interpolate between the points of your polygons (must be triangles) to find where they intersect each scanline. Plot each pixel between the 2 points of each line they intersect.

You might want to look into lighting models such as phong, gouroud(sp?) and Blinn aswell. Then you have various texture mapping methods to look at...its a long subject, you''ll learn alot from doing it though.

The number one article on software rasterization is Chris Hecker''s Perspective Texture Mapping. It''s quite math heavy but trust me, it''s not getting easier. Software rendering is hard if you want to do it right.

I also highly advise you to start with wireframe rendering, and implement a clipper before continuing to filling polygons. As soon as you have a 3D clipper, you won''t draw out of the screen any more and things like camera transformation rely on this. It''s much easier to do this if you''re still using wireframes, so you can easily debug.

quote:

---

Original post by d000hg
Why would LaMothe spend so much of a new book on software rendering when so few people do it (& presumably getting less all the time)? I definitely approve of doing it for learning purposes but unless he wants you to understand for shader purposes or maybe is now ''big'' enough to get published whatever he writes & has a bee in his bonnet about software rendering...?

---

Yesterday someone on another site''s forum was arguing that NVidia cards can''t do trilinear filtering. Although he had some experience with hardware rendering, he didn''t recognise the difference between bilinear and trilinear filtering, nor did he know the formulas involved. So he made himself look very ridiculous. If he had some software rendering experience he would have understood a lot more of the principles.

It''s not a coincidence that the best game programmers once wrote their own software renderer...

quote:

---

Original post by Willm
Software renderers may be making a come-back, of sorts. Its true that a software renderer may never achieve the quality of a good 3D card but considering that I was playing fullscreen 3D games on my old Pentium 75, I could play pretty excellent software rendered games on my P4 1.7GHz with SSE / MMX.

---

Software renderers do achieve the quality of 3D cards. My Real Virtuality project is a Quake 3 map renderer, with a quality comparable or higher than a TNT 2. and that was the card most people owned when Quake 3 was released, and they never thought Quake 3 could be rendered in software. If that doesn''t convince you, have a look at my swShader project. It''s a DirectX 9 pixel shader emulator. You only see a spinning teapot but it effectively executes a ps 2.0 shader per pixel. Just experiment with the shader.txt file...

Software rendering is definitely making a come-back for less demanding games. Immensely popular games like Counter-Strike are perfectly enyojable without all the eye candy.

Seen your work C0D1F1ED. Very impressive!

Perhaps ''quality'' was the wrong word to use. Obviously software can render anything that hardware can, but dedicated silicon still beats software renderers in performance.

quote:

---

Original post by Willm
Perhaps ''quality'' was the wrong word to use. Obviously software can render anything that hardware can, but dedicated silicon still beats software renderers in performance.

---

That''s very true today, but things might cange a bit in the future. Technology like Hyper-Threading makes it possible to get increased performance on CPUs without much extra silicon. So the parallelism is increased. CPUs are still clocked much higher than GPUs so if they manage to have a 10 GHz CPU with 8x Hyper-Threading, this could beat todays graphics cards. Of course by then the GPUs will have evolved as well but isn''t there a point where we can just be ''satisfied''?

Of course, having a GPU for graphics and a CPU for the game code is of course always better than having only a CPU, but I''m of the opinion that most average games could run without GPU on future CPUs.

COD1F1ED> nice shots... it''s a shame you don''t seem handle shaders :/
but 20 fps... mmh :/ with full shader support that might drop a lot