I have been thinking of lowering the requirements for my game, essentially not requiring a 3d-accelerator. I still need to render 3d-graphics and my current engine is based on DirectX 8. However, as I checked, there aren't any features of version 8 used so version 7 seems to be a decent choice. My questions are:

- Is there any real alternative to using DirectX 7 as the rendering engine? I want to support the range from an unnaccelerated PII to a accelerated PIV. Download size is also premium.
- How does the software rendering work? 8 has the reference device but I have no idea of the performance. Generally speaking, is the reference device how optimized?
- What Windows versions has DirectX 7 preinstalled? Can I find and distribute a version 7 runtime or do the users have to download v9?
- What technical differences are there between 8 and 7?
- Can I just program version 7 with the API specs in hand or do I have to install the SDK?
- Does installing the v7 SDK kill newer versions from my computer? Or is it just a question of linking against the correct library?

Any other experiences or caveats that I should consider?

I just got an email from someone a little earlier who said they're doing the same thing. Hopefully they'll post here with their thoughts on the matter.

And not to hijack the thread, but any approximate release date on Space Station Manager? I've been checking your site for a while now hoping to hear something.

It's better to call the process "Downgrading" :). Anyway, here are my thoughts on this:

Originally posted by Kai-Peter
- Is there any real alternative to using DirectX 7 as the rendering engine? I want to support the range from an unnaccelerated PII to a accelerated PIV. Download size is also premium.
Software rendering is almost extinct nowadays. But you can still run a search on "software rendering engine" through search engines. Also you can take a look at "Crystal Space" open-source engine at SourceForge.net. It was a pure software rendering engine formerly with hardware acceleration plugged in recently.

You can use DirectX 5 instead. It's preinstalled with Windows 98 and all higher versions of Windows have higher versions of DirectX. Download size is minimal. The drawback is that documentation states DirectX 7 as having faster software rendering. Although I'm not sure to what features that applies. It's better to test it yourself. It is possible that version 7 has faster software implementation of some "very cool" effects like single pass multiple texturing, but all in all they will be unacceptably slow still.

Originally posted by Kai-Peter
- How does the software rendering work? 8 has the reference device but I have no idea of the performance. Generally speaking, is the reference device how optimized?
Software rendering is very simple :) It just renders everything into system memory using CPU and FPU, as opposed to external GPUs and video memory in hardware accelerated rendering.

Reference device is not optimized at all. It exists solely for the purpose of comparing results of hardware rendering with expected results (produced by "reference" software driver). I think this was/is used by hardware manufactures. You should stick with RGB, MMX, or Ramp device for software rendering. The Ramp is the fastest but it only supports 8-bit surfaces. MMX is faster than RGB but cannot be used on systems with CPUs that do not support MMX instructions. RGB is the slowest, but still is much faster than Reference driver.

Originally posted by Kai-Peter
- What Windows versions has DirectX 7 preinstalled? Can I find and distribute a version 7 runtime or do the users have to download v9?
As far as I can see version 7 is preinstalled with Windows 2000. Windows XP has version 8. But I'm not sure at 100% and would like others to contribute as well.

Dig your old game CDs. One of them should have redistributable of DirectX 7. I don't think it's something illegal to allow users to download the bundle from your site.
Originally posted by Kai-Peter
- What technical differences are there between 8 and 7?

APIs have been reshuffled to a great extent. DirectDraw is no more there with version 8. DirectX 8 has introduced flexible hardware transformation and lighting pipeline with vertex&pixel shaders. Opposed to that DirectX 7 had fixed T&L pipeline.
Originally posted by Kai-Peter
Can I just program version 7 with the API specs in hand or do I have to install the SDK?

Yes. But having debug version of DX from SDK installed would certainly help. Actually I myself use debug version of DX8 and documentation from DX5 SDK. And don't forget #define DIRECTDRAW_VERSION 0x0700 before including the headers.

Originally posted by Kai-Peter
- Does installing the v7 SDK kill newer versions from my computer? Or is it just a question of linking against the correct library?
Unfortunately v7 cannot be installed over newer versions. In fact there is no way fro two different versions of DirectX to co-exist on a single system.

Originally posted by Kai-Peter
Any other experiences or caveats that I should consider?
Sure there are lots of them :) But you never know until you come across. I think we could devote a special thread for them.

DX7 is pre-installed on win98 se AFAIK.

Well, I'm in the same situation here as well. I have been working on my game now for 3 months, and actually hope to publish it here. But, my game uses DirectX8 as well. I'm thinking of downgrading to DX7 as well.

The main reason:
DirectX8 requires an 3D accelarator card

So, older devices will simply be unable to run my game. And since my game is simple 2D-tile-based-non-scrolling game, I think it will still run on a software renderer. It's a risk I'm going to take eventually. Maybe it will not work at slower machines afterall.

If you are usin DirectGraphics (dx8), porting it back to Direct3D Immediate mode (dx7) should not exactly pose a problem. Unfortunatly, it will maybe if you are using DirectGraphics with Matrices (untransformed vertices), and Visual Basic. DX7 does NOT have the D3DX Libraries for VB. That's going to give me plenty of nightwork, I think :).

Therefore, I'm going to do another conversion... first in DX8 though. Currently my game is 2D based on vertices (untransformed, working with matrices)... I'm going to convert those to TL vertices (no matrices needed anymore), and the ultimate speed increase for me: I can use DrawPrimitiveUp with a batch of tiles, instead of rendering every tile seperately!

DX7 can be installed on any system equal or lower than Win2k. DX8 cannot be installed, I believe, on Win95.

If your game is very CPU intensive, I doubt the software renderer will be worth the change... since it means the CPU will do everything what your 3D device would do normally.

Maybe it's an idea to note down your average number of vertices (I see you said that you are using 3D stuff), and create a simple DX7 program, rendering that amount of vertices in [b]software/b] mode. Then you might get an diea of the framerate...and yuo can test it on slower PC's with DX7 as well!

We are in a similar situation with our project.

After almost 12 months work (on game, engine, graphics and audio!) we have arrived at an alpha version of the game.

The problem is that the engine is based on DX7 interfaces and uses the 3D renderer for alpha-blending and sprite rotations by using transformed and lit vertices.

As our game is essentially a single screen action/puzzle game I feel that a 3D card is too high a spec-requirement and we are currently contemplating the change to DX5.

A few months ago I spent a weekend changing the display to use DX5 without the fancy DX7 effects. Turns out the game definitely loses some visual appeal but I don't think its worth the potential loss in sales.

Originally posted by Carrot
A few months ago I spent a weekend changing the display to use DX5 without the fancy DX7 effects. Turns out the game definitely loses some visual appeal but I don't think its worth the potential loss in sales.
And what is the problem with all the fancy effects under DX5? AFAIK alpha-blending and rotation can be done using DX5 software rendering devices w/o problems. What prevented you from leaving them in-place?

with a bit of software rendering you can create really cool effects on anything from pentium (hi-res modes) or 486 (8bpp modes, but how many ppl have 486 and use windows?)

Just little asm and you're done.. dx3 is enought

Sorry, I didn't explain the dilemma very well.

Its wasn't just the DX5/DX7 decision but whether to use Directdraw/Direct3D was also part of the problem.

Originally we want NT users to be able to play the game (hence the DX5/DX7 dilemma) meaning that we had to use DX5.

Your right in saying that the basic effects I mentioned can be done in D3D5 but I had concerns about the software rendering and the consistancy with various drivers available, plus the lack of several features such as anti-aliasing etc.

Now none of these were problems that couldn't be overcome somehow but the route to pick wasn't obvious at the time.

Added to this, I recently read a link to the DX9 SDK docs claiming that the newer versions of DX won't support the DX5 (or earlier)interface for sake of download size.

Hmm, Wel DirectX7 still has the software device. But DX8 or above doesn't (although the "reference rasterizer" is basically the same thing, but it's so slow that ~2 frames/second would be fast :P)

But for NT it would be better to go to <dx7 indeed, I think.

Originally posted by Carrot
Added to this, I recently read a link to the DX9 SDK docs claiming that the newer versions of DX won't support the DX5 (or earlier)interface for sake of download size.
Could you please find this link and post it here? It looks like we may have a little disaster upcoming?

The main problem I see is that I use a lot of glue code out of D3DX libraries. Especially the support for Meshes would mean I had to recode an exporter/importer and similar things. Even if the game isn't action based 3D still is one of the key features, ie. the gameplay rests on the 3D structure of the space station. My other alternative is requiring a low end (8MB) 3D card, which is well withing the current memory footprint. Does anyone have experiences with downgrades like this? How did it affect sales?

Gmicek: The planned release is during Q1/2003. The game is currently in polish mode, it depends when I am satisfied with the results, so it could be earlier.

Originally posted by MirekCz
with a bit of software rendering you can create really cool effects on anything from pentium (hi-res modes) or 486 (8bpp modes, but how many ppl have 486 and use windows?)

Just little asm and you're done.. dx3 is enought


well thats it in a nutshell really. You can achieve the same effects in some fashion no matter what is used, but the problem becomes balancing out the effort required (D3D3 is a nightmare!), the availability of the technology (which DX? MMX? 3D card?) and the visual quality you want to achieve.

The argument has always been: if the gameplay doesn't require the advanced visuals then go for the more basic technology, which seems to make perfect sence - expect for a couple of things: visuals DO actually help sell a game (its the only hook the developer has initially to pull a download), and secondly there are only so many 'nice' effects you can remove from a game before it starts to look amature-ish!

We recently made the move from dx8.1 to dx7. It was actually much easier then I thought it would be. I had a spare computer so I reformatted it and installed win98, dx7 sdk and all my build tools. It is really helpful to have the 7 sdk installed since you'll have all the sample code readily available. Most of the concepts are the same between 8 and 7. You have to do a little more initialization in 7 due to driectdraw but otherwise its pretty close.

You mentioned that you would have to rewrite your mesh loading routines. There are a couple sample programs that show you how to easily load x files (which is what we used). The texture loading was also a little different but the sample code helped there as well. In our case we had to convert some of our dds files since we had them encoded in a dx8 (or above) format.

It only took about 2 days from the time I started looking at the dx7 sdk documentation to the time we had the game up and running under dx7. We still have some tweeking to do but it seems to be running quite well. If you run into any problems I might be able to help since its all still fresh in my mind.

Originally posted by bstone
Could you please find this link and post it here? It looks like we may have a little disaster upcoming?

I've been searching for that article on backward compatibilty of DX with no luck (which is probably a good thing!).
I read it originally from a link on Gamasutra but I doubt its validity after finding this from Microsoft DX9 FAQ v5.5:


Q: What versions of DirectX are shipped with the different Microsoft Operating Systems?
A: Windows 98 comes with native DirectX 5 support. While Windows 98 Second Edition comes with DirectX 6.1a and Windows 2000 DirectX 7. Windows NT comes with DirectX 3.0a, and Windows 95 comes with DirectX 2. Windows XP comes with Direct X 8.1.

Q: Will new versions of DirectX affect older games?
A: No, as each new version of DirectX is backwards compatible with older versions.

Q: What operating systems is DirectX 9 compatible with?
A: Windows 98, Windows 98SE, Windows Me, Windows 2000(Professional and server editions), and Windows XP. DirectX 9 is NOT compatible with Windows NT or Windows 95.


...which is how you'd imagine a system based on the COM model would behave.

Vague OT ramble:

I'm specifically using OpenGL to do my 2D game (it's available all the way back since Windows 95-ish and NT 4 and hasn't changed its APIs); yes, it does require a 3D card as a result, but it allows me to do fast alpha-blended and scaled sprites.

The way I see it is that if you're going to insist on 32Mb of RAM and a Pentium 2 and Windows 98 then it's not entirely unreasonable to expect a 3D card somewhere in the mix as it is - very likely a TNT or better these days, and especially as a TNT card now costs less than the price of a game.

The use of a 3D accelerator for 2D actually has some subtle advantages which are rarely mentioned. If you are using blending or scaling to any degree then you are invariably using large amounts of CPU time instead of video card time; this is likely to push your CPU requirements much, much higher. Using a 3D card has enabled me to specify a mere 350MHz processor to shift several thousand scaled alpha blended sprites at 60FPS; a 2D card is very unlikely to support alpha blending and scaling in hardware without already being a 3D card.

You have to ask yourself whether it's likely that someone unwilling to spend $20 on a video card is going to spend $20 on a game. Especially when games are heavily graphics oriented.


Cas :)

(still waiting for someone to post actual stats about customers' machine specs instead of vague generalizations...)

Believe it when people say there are quite a few customers without any 3D cards. I just got an email from someone this weekend saying he thought my game seemed really interesting, but he can't run it on his system because he doesn't have a 3D card.

Upgrading a graphics card isn't hassle free. First off, most people would not know how to install one on their own. They would need to take it into a shop (a bit of a hassle to lug it in there, and potentially be without a computer for a while). Second, a lot of these older machines have compatability issues with newer graphics card. They don't have AGP, or they can't the bus can't supply the proper voltage, or a bios issue, or other hardware compatabilities, or too slow of a CPU (according to requirements on the box), or whatever reason. Then there is the cost. Yes there are cards for $20, but most poeple just think of Best Buy (or whatever local retailer) as their computer store, and don't look around at all the computer shops. In my case, I don't think I've ever seen a local best buy carry a graphics card regularly priced below $50. Don't expect customers to look for sales...they are told they need the upgrade, they run to the store, see it is too expensive and give up. They don't keep looking every week to find it on sale. I'm sure there are other reasons too.

Just as a side note...you mentioned using OpenGL. You might want to search back through the forums for a few of my earlier posts about the difficulties in supporting OpenGL and why I am switching away from it.

on a decent 350mhz machine you can get away with a nice 640x480x32bpp game (x16bpp if 66mhz FSB system) and it should work easily with 20fps+
For many indie games (puzzles, logic games, turnbased strategy games, simple action games etc etc) software rendering is more then enought.

Sure, you can use your 3d accel to draw 1000 scaled, rotated, alpha-blended sprites.. but do you need it?
A static background + few dozens of alpha-blended sprites/some other special effects is what most succesfull indie games can live with easily.

All in all, writing a decent 2d software engine shouldn't take you more then a week or two (month-two if you want nice asm optimizations or some cool effects)

I have got a game working (with 21fps-fixed amount-feels smooth) on 52mhz ARM cpu (about the same as 486dx50 in terms of speed).. the game is a 2d street fighting game and it works perfectly fine on a 640x200x16bpp screen (with sound effects, enemy AI, menu bar etc) and I don't use even one line of ASM code.

So yes, writing software engine will cost you some additional time.. but it's mainly a one time effort.. and you can win a lot of customers this way.

PS.NT4.0sp3 has got dx3.0 i think.. but I might be wrong here

The only issues I've come across to do with supporting OpenGL arise from poor quality drivers on some cards - Voodoo and ATI generally have bad drivers but then the DirectX drivers are also buggy too.

LordK - you have this example customer: but looking at the harsh light of reality, which is ease-of-development plus wow-factor of effects over expected audience size to reach a profit - is this one customer just an aberration? And even if he's not an unusual case - what's the demographic of the people who actually register a game once they've played the demo? In other words: is it people with more modern systems who tend to buy the full version anyway rather than the cheapskates with ancient P200 wrecks?

I mean, you've got to draw a line somewhere - "you must have a PC" being the ridiculous extreme at one end and "you must have a Radeon 8500 DV and 128Mb of RAM" being the unlikely extreme at the other. So who's got some stats? Some of you hardworking indies in here must have collected some stats on sales and systems by now...?

(By the way, I'm writing a maniacal shooter with plenty of pretty particles in it - I can quite see that 2D is much more sensible for a graphically and computationally less demanding game!)

Cas :)

Originally posted by princec
[B]The only issues I've come across to do with supporting OpenGL arise from poor quality drivers on some cards - Voodoo and ATI generally have bad drivers but then the DirectX drivers are also buggy too.[B]

There are lots of support issues revolving around drivers. Lack of drivers for many cards that have D3D support, lack of OpenGL drivers for any card with a default windows install, etc. I've given my opinion on the topic a few times here. I won't bother repeating.

Of course, you say your game is a "maniacal shooter with plenty of pretty particles in it". Just from the sound of it, it seems like you may be targeting a more hardcore (theres that word again....wrong thread) audience. On the one hand, you can generally count on that audience to be a bit more up to date on hardware and drivers. The downside is that thusfar, very few indies have seen much success in this market. One of the reasons is that you have to compete with companies like Epic, who have had a full time staff of a few dozen people evolving their engine over the last 8 or 10 years. Unfortunately, most of the gamers in this market seem to be very unforgiving if you don't have the most wizbang features and the prettiest rendering engine.

I don't have any statistics for you. As a policy, I don't gather that type of information from my customers. It would be useful, but I also feel it is a bit invasive. However, some of our difference in stance may be that I am targeting a different market than you. The customers in my market (and that of quite a few of the developers around here) don't keep as up to date as yours might. However, calling them "cheapskates" is a bit closeminded on your part. You may have hundreds of dollars to throw away on upgrades every year, but often these people have other priorities for their money (family, house, children's educations, etc). Their main purpose for having a computer is simple things like word processing, email, and web browsing (tasks for which a pentium 2 or a 3D card is not necessary). It just so happens that they like to have a little bit of fun and buy some inexpensive games now and then, but when they do they look for games that work on THEIR systems. They don't worry about custom building their machine to match the specs of the newest game. If a cool looking game doesn't work on their machine, then they just find another game that will. Your loss, another developers gain. My goal, of course, is to be that other developer.

I've heard 2 people in this thread talk about software
rendering. And other people just skip over it, I think it
would be a lot of work, but the amount of computers
you will gain from it, should justify the time. If it's
possible for you, why not create a wrapper that uses
3d accel and software rendering. This way you can
handle old vid cards, as well as new?

Originally posted by Uhfgood
I've heard 2 people in this thread talk about software
rendering. And other people just skip over it, I think it
would be a lot of work, but the amount of computers
you will gain from it, should justify the time. If it's
possible for you, why not create a wrapper that uses
3d accel and software rendering. This way you can
handle old vid cards, as well as new?

This wrapper is already written and it's called DirectX. The amount of work needed to include support for software rendering is not that large, but will require to cut off some CPU-intensive features and fall back to lower display and textures resolutions when no hardware acceleration is present.

I have actually been leaning towards software rendering. I hearthily agree with Ron in that requiring a 3D card for our marketing segment may be detrimental for sales. Thinking like that led me to this downgrade idea in the first place. A software renderer would be even better as the need for DirectX would also be removed (or requiring something like DX5). I would love to loose both the DX and video card problems.

The thing I don't want to do is create my own renderer, and probably not use the one in DX7 either. I have done several renderers back in the late eighties, early nineties, and I know I don't have to time to pull something like that at the moment. So the question is, what renderers are available. The only comercial I know of (yet) is the one by RadGameTools, because they have the running ad in Game Developer:

Pixomatic: http://www.radgametools.com/pixomain.htm

What others do you know about?

PS. Pixomatic sells for a price of 10000$ per PC game. I have no idea what they would ask for a Shareware game if you took the time to bargain with them.

Originally posted by Kai-Peter
A software renderer would be even better as the need for DirectX would also be removed (or requiring something like DX5).
I don't think that you can get rid of DirectX with pure software renderer. You need direct surface access anyway. But your requirements can drop to DirectX 3.

Originally posted by Kai-Peter
The thing I don't want to do is create my own renderer, and probably not use the one in DX7 either.
And what stops you from using software renderer in DX7 or DX5?

Originally posted by Kai-Peter
What others do you know about?
The search for "software rendering engine" I've suggested earlier brought me to www.v3x.net. Check this out. Looks like they have good support for software rendering.

Originally posted by MirekCz
[B]I have got a game working (with 21fps-fixed amount-feels smooth) on 52mhz ARM cpu (about the same as 486dx50 in terms of speed).. the game is a 2d street fighting game and it works perfectly fine on a 640x200x16bpp screen (with sound effects, enemy AI, menu bar etc) and I don't use even one line of ASM code.



So do you just use DX to grab the primary surface and do your rendering to that or do you have some other way of grabbing the display?

Also, graphics are only the start! Not using DX means you loose out on the audio/input modules that directX offers too.

Thsi thing is that I don;t really want to rewrite directX either!

We're definitely in different market segments then :) I hope I can make mine a success.

I'm quite happy to follow on at the trailing end of modern hardware; I think there are probably enough machines out there now to manage it. In fact, I wonder what has happened to the vast number of machines that were capable of putting Quake2 and Halflife on the map, because that's about my minimum spec. They must be still around somewhere.

There does seem to be an almost fanatical devotion to low system requirements amongst shareware coders but I'm not writing shareware, it's a commercial game. Maybe there's a difference here.

If I make a mere 3,000 sales over five years (not an unreasonable target) it will have been worth it purely in terms of financial reward, but I've gained so much experience and code from this first proper project it's not really the issue!

Cas :)

Carrot:this data was from SymbianOS based arm device (nokia9210 phone to be exact) - you can check the whole game by downloading it form handango and/or looking at www.bitween.com ->go to entertainment section

But I use a method pretty much like getting primary buffer address in dx, writing all data to backbuffer in sysmem, once data in bacbuffer is ready I copy it all to vidcard.

But it takes quite a lot of time to perform a single 640x200x16bpp copy.. so I used a little trick that many indie games can use - I don't draw like:

1.copy background to backbuffer
2.draw menu, sprites etc
3.copy backbuffer from sysmem to vidmem

which would have a hard time working with 20fps..
Instead 1. I always draw in backbuffer (saves sysmemory too as I don't need two buffers for background)
so drawing each sprite looks like
1.get data under sprite and save it into small buffer
2.draw sprite on screen
....the same for other sprites etc
3.display backbuffer on screen
4.draw data stored in point 1 to screen to recreate background (you do it in the opposite order then drawing so last->first and first->last)

that's the main trick used.. other tricks are using 4byte moves whenever possible, using RLE compression for sprites and small tricks for alpha-blending (ie using one mul to calculate all 3 color values) etc.
gives you really great results.

PS.sound programming, network programming.. everything is quite easy without dx. No matter if it's Windows based OS or anything else. You won't get effects like surround sound etc.. but who cares?

This wrapper is already written and it's called DirectX.

bstone - you don't have to be funny about this, I was talking
about a wrapper for Direct-X, goodness knows that anyone
using direct-x at all has to wrap at least a few functions.

Originally posted by Uhfgood
bstone - you don't have to be funny about this, I was talking
about a wrapper for Direct-X, goodness knows that anyone
using direct-x at all has to wrap at least a few functions.
Hmm... Perhaps I didn't understand you previous question. If you mean wrapping DirectX then you are automatically wrapping both hardware and software rendering. That is why I thought that you were talking about wrapping separate hardware and software rendering in your previous post (like hardware rendering through DirectX and software rendering through some other library). Thus I decided to contribute with the notion of that you can use DirectX for both. I'm sorry for this misunderstanding. The least thing I wanted to do is to be funny.

Wrapping around DirectX has 2 advantages. One is that you can easily switch to OpenGL (which is espcially good if you want to port to another platform). Another is that you can replace it with a customer software renderer. The software renderer that was included with DirectX is notoriously slow (not as slow as the reference device, but still slow). With a custom built renderer, you can do a lot more optimization because you know what features you will need to support.

Originally posted by LordKronos
Wrapping around DirectX has 2 advantages. One is that you can easily switch to OpenGL (which is espcially good if you want to port to another platform). Another is that you can replace it with a customer software renderer. The software renderer that was included with DirectX is notoriously slow (not as slow as the reference device, but still slow). With a custom built renderer, you can do a lot more optimization because you know what features you will need to support.

The DX8 software renderer (Reference rasterizer) is indeed slow.. but the DX7 or lower software render (device) is still pretty reasonable imo?

not really
all d3d software rasterizers are slow... you can be much better off writing your own

Mirek, Mirek, you are a funny Polish people. :) I think you are underestimating the work regarding rendering engines, network libraries and sound libreries, too.

Methinks, the sw renderers should die. Immediately. I still maintain my sw and glide renderers but I am also thinking about slipping my Opengl wrapper too.

The only thing holding me back is that I have 10 years hard work in them. Well, I have to learn discarding things in a blink. At which I am very weak. And it would be kewl to offer developers an all around nice fat gamedev toolkit. :)

Bernie:hehe, did you ever heard about DirectX?:-)))

Well, I LOVE software rendering... it all goes pretty "GOD..." with hardware rendering when you see a guy drawing 10 fullscreen triangles and wondering his stuff works slow:-)

Software rendering really shows if you know what you're doing or not. There are milions of ways to optimize it too... and that's fun:-)

So beat me but I run as fast as I can to other platforms so I can enjoy this part of programming.
There's not much to do that you don't have to do in HW 2d engine (you still need all the animation etc systems which take more time to code then writing few optimized routines for sprites) and HW has got few "requirements" that you would never heard about with SW system (like packing as many sprites as possible on a texture ^2 size to use space well)
It's not hard either to get a fine 3d floating around that's faster then D3D SW rendering :-)
And you really get nice possibilities this way to write cool 2d/3d effects that aren't possible with D3D

There's not much to do regarding sound lib (at least for me.. somehow implementing a dolby digital system isn't what I expect from a shareware game).
Good .wav mixer with few simple effects can play nice sounds.. add .mod/similar player (ok, this one might take some time to code when you do it for the first time, but there are tutorials and sourec code floating around) and you're pretty much done.

And Network is a separate, long subject.. getting a ping to work is simple.. rest depends on your game. Creating a good network system for quake is hard.. but how many of you are writing a quake clone?


I don't say that you will be done in a day or two with it all.. but most ppl around seem to spend about 6months on their projects, maybe even longer.
So i think that they do have a possibility to choose if they want to do it in SW or HW or mix etc.
All in all it depends on your customers. Try to find out what system specs they use and see if it would be worth to go D3D route to gain few special FX effects, higher display resolution or some time.