I did not read "Tricks of the 3D Game Programming Gurus book " but honestly I wonder who can be really interested in such a book.
Should "true programmers" actually understand how things are done underneath the surface?
In my opinion the pioneers'' era is over.
Nowadays 3 main area of specialisation can be distinguished.

a) API designer
b) Engine designer
c) Game designer

LaMothe''s book is of use for group a ( how many people???)) of some use for group b) of no use for group c ) apart an appreciable intellectual curiosity, of course

quote:Original post by Monder
You don''t have to write a fully featured extremely fast software renderer, just understand the theory and write a basic one, it will increase your understanding of 3d Graphics greatly.

What would you call a simple one? What features should a simple software renderer have, in your opinion?

Well I''d say it can render textured polygons, with back-face culling, frustrum clipping etc. Have some lighting built in and make it flexable enough so it''d be easy to add new things to it (such as bumpmapping) you may also want to experiment with other ways of describing 3d scenes such as NURBS.

I dont know if anyone is still reading this thread but I am in a similar dilemma as the OP.

I bunch of people advised me to skip all the stuff "under the hood", get with the times and learn the DirectX API.

I almost went that route, but I think I will stick with writing a software renderer for the next few months (besides which the commputer I have access to until August does not have a graphics accelerator. Yes, I know Intel and AMD have simulators available, but I dont want to go through all of that).

-Rahul

Forgive me for being sceptical, but i don't see how writing my own software renderer teaches me to use 3D APIs more efficiently.

One of the biggest issues with writing efficient 3d engines is keeping both the CPU and the GPU busy all the time. eg. prevent pipeline stalls in the 3d hardware. Also state management is very important because state changes can be expensive when doing hardware accelerated 3d. Last but not least, resource management. When to use video memory, when to use AGP memory.

Those issues are non-existent in a software renderer.
Pipeline stalls do not happen, when your only using the CPU.
State changes are (nearly) free, so state management is also not that important when using a software renderer.
Obviously the memory issues are also non-existent in a software renderer as you'll only use system memory.

Off course there are a couple of things that you'll learn from it. Things that are normally done "behind the scenes" when working with 3d APIs.
For example:
- clipping
- rasterizing
- interpolating (to calculate input value for fragments)

But these things don't affect the performance as much as the other things i mentioned at the top of my post.


Edit: forgot to mention one thing,
Writing your own software renderer IS alot of fun.
It can be very rewarding to see it doing its job when it finnished.
So if you have the time, just go for it...

Edit2: eeeeek... just realized this thread came straight out of the grave... lol

[edited by - Direct4D on May 28, 2004 12:23:13 AM]

[edited by - Direct4D on May 28, 2004 12:24:39 AM]

I found LaMothe''s second book in that series quite an enjoyable read. Not very practical for today''s environment, but still enjoyable because of all the tricks he does to make a (relatively) fast software rendering engine in this day of hardware acceleration.

Will it enable you to make that dream game you''ve been wanting to make? Probably not, but practicality isn''t the only reason to read. Maybe understanding how your hardware does things is interesting to you.

(Contrary to the opinion of some commentors who obviously haven''t actually read this book there is next to nothing that you can get from just reading the DirectX API as it an engine that isn''t dependent on it)