In a world of 3D cards Is there any point in programming a software mode any more?

Yes! It''s fun, and I learned lots from it.

Is there a solid 3D standard? Does everybody have a 3D accelerator?
If not, and you have your own software rendering engine, you can implement strange fx, and probably have it running faster than using an API!

The only reason is for learning experience. I do not think you can get it faster than an api, unless the api is emulating and not using hardware. But you will never get it faster than a 3d accelerator. I think it is just as fun to program in an api or in software.

*** Triality ***

One reason to use software engines is so that you can try some really cool alternative rendering techniques (like voxels).

--TheGoop

-------------------------

This is more of a general question. I was just interested in people’s views on it.
I my self am happy enough to leave my Pascal days behind me and take full advantage of OpenGL and Direct X. Because why reinvent the wheel when you can not only save a lot of time not having to make a 3D API. But you can also take advantage of hardware acceleration.
It is interesting to see that near all new games (For example Unreal Tournament) still support a software mode when they require a machine only a couple years old to run it at a playable frame rate in software mode. Also standard graphics cards have come with some sort of 3D accelerator built in for the past 3 years.

I think that Unreal Tournament only used D3D and OpenGL for the rendering. i.e. They transformed, clipped and lit their entire scene with their own code. So that meant that to use different APIs all they had to do was change their rendering function to use either D3D, OpenGL, glide or software. Therefore it wouldn''t have taken them that long to write a sofware rasteriser.

-- Kazan - Fire Mountain Games --

Another reason to think of is this:
If you only program using the API, you''ll never end up inventing really radically new stuff. Yes, it will be slower than a HW implementation, but sometimes there IS no HW implementation available, and you have to prove the concept in software mode .


#pragma DWIM // Do What I Mean!
~ Mad Keith ~

It is not right that you cannot make new things using the APIs. If you really have some brilliant idea then the only high performance way to do it is through a 3D API.

For instance, if you invent some new illumination algorithm then you can implement this via the APIs by setting the textures to the right colors and dynamically change the textures to fit your model. This can be done faster (haven''t tried it though) than doing it all 100% in software because the hardware is still used for most of the rendering pipeline. For instance, OpenGL does not support Phong shading, but I once saw a demo using OpenGL to make Phong shading that achieved this by configuring the textures in the right way.

So in my opinion, software rendering could be skipped altogether. Everybody has a 3D card by now, anyway. Even my old Matrix Millinium 2 card, which didn''t have any 3D capabilites, included a Direct3D driver, enabling it to play 3D card only games.

Jacob Marner

1. I don''t have a graphics accelerator :-)
( there goes your argument of "everybody has a 3D card these days" )

2. The phong demo you mention, I think I know about this one. I believe it''s a multitexturing example with a stock lightmap resembling phong lighting. It actually is very far from what Phong lighting actually does.

The actual point I wanted to get at is that there seems to be confusion between the following two terms:
- Hardware
- API
Using an API doesn''t guarantee the use of hardware, necessarily. It is simply a set of useful functions, some of which may be unloaded onto hardware. It is certainly true that you can still do original things, using just the functionality supplied by the API, but it WILL limit you in possibilities. The best example was given earlier - standard API''s provide no easy way to do Volume rendering in a fast way.
Using the hardware, is something even a software renderer will do at some point. Everything on your screen has to pass through a video card at some stage. Now, some of those cards provide a bit more than a simple "put your pixel here in this colour" functionality. (In fact, all of them do, even my S3Trio32/64, I programmed part of a driver for it. )
Using this functionality, instead of writing everything by hand, will improve performance tremendously, but you will lose portability. That''s why the API''s were developed, they give you a unified interface to hardware, without needing the specifics, so that your code will work on ( most ) cards, provided their API drivers were implemented correctly.

The problem with API''s, is that they are often narrowminded.
One thing I''ve had trouble with, is that OpenGL joins two of the stages in a standard polygon pipeline together, where I''d like to do something inbetween.
Writing your own software renderer to fit in between these stages is a challenge, and will enable you to do things faster, or more elegantly, than using the API.
If your software "hack" turns out to be important enough, they might add API functions for direct interfacing with the hardware, so some parts of your functionality may be offloaded from the main CPU in the system.


#pragma DWIM // Do What I Mean!
~ Mad Keith ~

ray.tracing
scanlinerendering/bad



-kertropp

C:\Projects\rg_clue\ph_opt.c(185) : error C3142: 'PushAll' :bad idea
C:\Projects\rg_clue\ph_opt.c(207) : error C324: 'TryCnt': missing point