Making a software mode backup renderer-- some questions

[Raptisoft]

Hi all,

I'm about to put together a software renderer to sit behind my hardware rendering framework, to grab that 5% of users who don't have HW acceleration.

My experience with DirectX has been to just allow it to do what it needs to do. As a result, I have a couple questions that, if someone wouldn't mind answering, I'd appreciate it!

1) I want to operate in 16 bit mode, ONLY in software. However, the user, damn him, will probably have his desktop in 32 bit mode, right? In DirectX, is it possible to do a blt from a 16-bit software surface onto a 32-bit primary surface?

2) I'm considering doing all this without DirectX at all-- that is to say, using a DIB and a big buffer of bytes. How slow is that? I know you have to reverse the y axis when you display, so how bad is that to framework on older machines? I only want to go this route if I find out I HAVE to be prepared to work in 32-bit with DirectX.

Thanks in advance!

[James C. Smith]

What we do in our 16 bit games is use our own blitter to copy our 16 bit frame buffer to the DirectDraw back buffer (or front buffer in same cases). Of course, when running in full screen mode we set the hardware to 16 bit. But if the game is in windowed mode some translation may be necessary. If the DD buffer is 32 bit we translate each pixel as part of the blit. I don’t know if DirectDraw can do this for you. In all my years of Windows game programming I have never used direct draw to do anything other that switch video modes, clear the screen, get a pointer to video memory, and page flip. I have never used direct draw to draw anything.

I think it is safe to use DirectDraw and wouldn’t bother with GDI as long as you are use a very old DirectDraw interface such as 3 or 5. My games attempt to use Dx5 and fall back on Dx3. But who knows, maybe I am missing some potential customers who don't have a working version of Dx3.

And just to be a nitpicker, I want to point out that a backup software rasterizer isn’t need so much for users who don’t have hardware acceleration. It is more often needed for users who have the hardware but don’t have working drivers or 3D APIs

[Rainer Deyke]

1. Even though DirectDraw might be able to automatically convert between 16 bit and 32 bit, I wouldn't recommend it since this can result in a significant loss of performance. Than again, I don't understand why you would want to run in a Window instead of full-screen in the first place.

2. Even if a computer has no 3D card, it could still have 2D hardware acceleration (available through DirectDraw). This can make a big difference on older computers.

If you want to support Windows 95, you can't rely on DirectX being installed.

[Chris Evans]

Support Windows 95!?

Is that really necessary anymore? I highly doubt anyone who still has Windows 95 is going to be playing games (they're probably still using Netscape 4.0 wondering where the Internet disappeared to). I imagine Windows 95 is still only used on poorly funded library or data entry computers

I think some here get too obsessed with being backward compatible. You also need to make sure your game still looks decent on future computers as well, especially if your game has a 3-5 year life-span.

[Dominique Biesmans]

1) I want to operate in 16 bit mode, ONLY in software. However, the user, damn him, will probably have his desktop in 32 bit mode, right? In DirectX, is it possible to do a blt from a 16-bit software surface onto a 32-bit primary surface?


For copying 32 bit buffers to 16 bit you might want to take a look at Hermes :
http://www.clanlib.org/hermes/
which does just that, copying buffers of any pixel format to any pixel format.



2) I'm considering doing all this without DirectX at all-- that is to say, using a DIB and a big buffer of bytes. How slow is that? I know you have to reverse the y axis when you display, so how bad is that to framework on older machines? I only want to go this route if I find out I HAVE to be prepared to work in 32-bit with DirectX.


How about using the DirectX3 interfaces to access the frame buffer? DirectX3 even works on Windows NT. (A fresh install of win95 doesn't come with DX3, but I bet it would be extremely hard to find one)

[EpicBoy]

Is that really necessary anymore? I highly doubt anyone who still has Windows 95 is going to be playing games (they're probably still using Netscape 4.0 wondering where the Internet disappeared to). I imagine Windows 95 is still only used on poorly funded library or data entry computers
You would be both surprised and horrified to know how many people are still using 95/98.

[RedKnight]

You would be both surprised and horrified to know how many people are still using 95/98.

I don't believe it. :D

Maybe win98.
Even here in a Third world country, most people used XP

[dan]

We've had several variants on this conversation before around here about which platform to target, and how much it helps to run on Windows 95 or whatever.

The short version is that it seems to help a lot for casual games. Solitaire, Mah-jong, Breakout, puzzle games, etc. seem to benefit if they can work on PC's that aren't even running DirectX7.

There's no real term for games that are a more complex than that, a little more targeted towards gamers, but still quick to pick up. I think of them as "SHAD" games in honor of EA's development mantra when EA burst on the scene -- "Simple, Hot, and Deep." GarageGames reflects this ethic.

I think SHAD games are okay even if they depend on DirectX8.1 (Windows XP and gamers who have upgraded their Direct X, probably by buying a CD game, in the past 3 years). If a SHAD game can support pre-2001 gear, even better, but it's not nearly as important as it is for casual games.

[Momor]

2) I'm considering doing all this without DirectX at all-- that is to say, using a DIB and a big buffer of bytes. How slow is that? I know you have to reverse the y axis when you display, so how bad is that to framework on older machines? I only want to go this route if I find out I HAVE to be prepared to work in 32-bit with DirectX.


I'm in your case : I had to make a software renderer for my games too. Just because my development PC is a notebook under Win98SE and very bad hardware support for 3D (OpenGL switch to software rendering).

I made my renderer using DIB and stuff. DIB was quite fast until Win98 appeared, now it seems that windows intentionnaly slows down all the DIB blits & stretchs just to force the developer to use DirectX.

As a clue, I realized that my DIB operations for my game were a LOT faster after having used any program which uses DirectX graphics functions.

If you want to test the DIB performances on your PC, just try one of the following games on my site : Mazemania, RunOut, Sentry or Volcano (just enable the Software rendering driver).

Good luck !

[Kai Backman]

<snip> .. My games attempt to use Dx5 and fall back on Dx3. But who knows, maybe I am missing some potential customers who don't have a working version of Dx3.

There is a huge market out there still using Dx1 alpha versions. You might make a whole sale each millenium just by supporting it! ;)

I didn't understand correctly if you were working on a 2D or 3D engine. If doing a 3D engine I would still consider buying a ready product, something like Fastgraph or Pixomatic. I have had a license for Fastgraph for ages and still haven't got around to supporting software in Space Station Manager, despite the occasional request. Will it be profitable for you to do it initially?