Thread: Using Front/Back Buffers With DirectX 3

Hello.

I'm working on a Win 32 Direct3D Retained Mode application framework that I'm hoping to use to draw 3-dimensional animations of buildings, buses, etc. that I can use. I'm using Microsoft Visuall C++ 5.0 Visual Studio (yes, I have the original MSDN CD's) with DirectX 3. Why am I working with this proverbial "dinosaur" when everyone else is working with DX9+? It's because I'm low-income, have to function on what I call "trickle-down computernomics", must use what I have, and need to be sure that whatever I develop will be fully compatible with any computer system. Besides, even though I purchased a book that has a CD that's supposed to have DX9 on it, "garbage" appears in the dialog box that appears when I try to execute the DX9 install program. I'm also not sure that a DX9-based application would be fully back-compatible or if someone else's computer does not happen to have a DLL or other library on it that's needed or has a newer version of DX that no longer supports the functions my application will call for. So far, the application (which I'm developing on a Windows-98 machine) runs OK on my Windows XP-based Internat computer, but I need to be sure that it will run when I take it to our local transit agency or to another entity to try to run it on their systems. No, I can't develop it on my Internet machine because that machine has an issue involving a repeated IDE HDD cable motherboard connect issue and I can never tell if or when that machine's going to go down on me at any time.

Specifically, I'm working on animations of buses and transit facilities that I need to share with other people and organizations, including transit agencies. So far, as I am legally blind and have been on disability, this has been on a volunteer, non-commericial basis. I find it easier to work with the code (as I can do this in a high-contrast, large-font environment) than trying to use one of the already-existing applications such as Anim8or, etc. (due to difficulty in being able to see the mouse pointer clearly enough) and I cannot by any means afford any of the fancy ones.

Now to the problem at hand: I understand that the usual approach to preventing 3-d objects from flickering while being moved is to draw to a back buffer so that the actual update is hidden from the screen until after it's complete and then "flip" or "blit" that image to the visible screen area.

The sample Direct3DRM application as originally designed to draw an object during its initialization. That object remains in one position. So long as I do not attempt to move any object, this works fine. I can draw a bus and then I can move the camera around and look at it from inside and from various angles. So far so good. I can draw buildings, etc. and this will work fine.

However, because I've had to develop a separate "update loop" which locks the camera temporarily in place and must currently destroy all objects before drawing a new frame while moving objects (moving a seat on a bus to open up a wheelchair securement area, for example) -- by re-creating the scene frame and then calling the drawing function after modifying the global variables for the moving object's position and rotation -- the moving object flickers while moving.

I've tried several different strategies as far as re-writing the initialization routines. The original app enumerates the drivers and sets up Direct3D in immediate mode and a DirectDrawClipper object with the "DirectDrawCreateClipper" function. Then it uses the "Direct3DRM::CreateDeviceFromClipper" function to create the Direct3DRM device and goes from there.

What I have tried to do is to:

1. Use the "Direct3DRM::SetBuffer" to 2 for double-buffering. I do not yet know how to take advantage of this fully, though.

2. Create a DirectDrawSurface front buffer (lpDDSFront) and back buffer (lpDDSBack) and then trying to use the "Direct3DRM::CreateDeviceFromSurface" function to create the Direct3DRM device and associate it with the back buffer. My intent here was to later try to use the "DirectDrawSurface::Flip" function later to flip the surfaces. That has so far failed because the call to the "CreateDeviceFromSurface" function is failing. I have verified that the surface creation function call is succeeding for lpDDSFront as a DD_OK is being returned after this and after the "GetAttactedSurface" function call to retrieve the lpDDSBack pointer. I have also verified that the lpDDSBack pointer is not NULL and therefore the lpDDSBack surface does indeed exist.

3. After creating the surfaces mentioned above, I've tried to attach a standard "DirectDrawClipper" object to the surfaces mentioned above with the intent of using the "CreateDeviceFromClipper" function to create the Direct3DRM device from this clipper. That, too, failed. The call to the "DirectDraw::SetClipper" function is failing.

Part of my problem, too, is that I'm not sure whether z-buffers are needed for the DirectDraw surfaces -- I would imagine they are -- but I'm not sure how to go about that.

I've tried researching the online documentation extensively, including examining other sample programs supplied with the Visual C++ 5. For the most part, though, these only deal with 2-d apps that use bitmaps rather than true 3-d objects.

I apologize for being so long-winded. Can anyone "fill in the gaps" or offer suggestions on things that I'm overlooking.

Thank you.

Mike7409

P. S. Can anyone tell me about using animation keys or about applying textures to polygonal faces?

and need to be sure that whatever I develop will be fully compatible with any computer system.

You failed that test by using DirectX 3. As of DX10 everything from DX7 and back is unsupported. As of DX8, DirectDraw is officially unsupported and deprecated and has been merged with D3D to form DirectGraphics.

You will never get DX3 to run on any modern system running a DX7 to DX10 era video card.

I want to thank all of you who have taken the time to respond to my "Using Front/Back Buffers With DirectX 3" message.

The application as it is now written is being developed and is running on a Windows 98 computer with DirectX 7. I have also been able to run the app on my Internet computer which is equipped with Windows XP and DirectX (DX 8.1 according to the Help documentation in the Windows Help system). I'm assuming that this is because I have "#included" the neccessary include files and have also incorporated some "lib" files in Visual C++ 5's "lib" files with #pragma comment commands. Can anyone tell me where I can find information to "fill in the gaps" -- some older books on DirectX and 3-D graphics maybe? -- so that I can figure out how to get the "double-buffering" to work so as to get rid of the flickering on the moving objects?

I will certainly consider upgrading to DX9 or 10 if all else fails. Can I install DX9 SDK on the Windows 98 computer such that it installs only to the needed "include" and/or "lib" directories without affecting the DirectX 7 already on the machine? This proved true with the installation of the Visual C++ 5 and its SDK's (including the DIrectX 3) -- these did not affect the DX7 on the machine. Will this hold true if I install DX9 -- if I can find a good copy, that is.

If nothing else, can someone tell me how to use front/back buffers with DirectX 7 or 8? Granted, I may have to rewrite the app somewhat to be compatible with these or with 9 or 10 but it's something I'm willing to consider doing to make the thing work.

Thanks again to all of you.

Sincerely,

Mike7409

I want to again thank everyone who has taken the time to reply to my message. As it now stands, I think I've found some solutions.

I went ahead and downloaded both DirectX9 SDK and Microsoft Visual Studio 2008 Express Edition. However, I can't register the product because it wants me to get a Windows Live ID and the site won't let me get one -- it won't accept my email address. So, my efforts to use the more recent stuff are on hold for now.

As far as being able to use the older stuff (DX3), I found a book entitled "Win32 Game Developer's Guide With DirectX 3" by Jason Kolb. After looking at a copy obtained via an inter-library loan, I was able to purchase my own copy of the book and return the library's book to them.

In a nutshell, the solution consists of using the Direct3DRMFrame GetChildren and GetElement() functions to work your way through the frame heirarchy until you get to the particular frame you want. Once you've "grabbed" the particular frame -- and thereby the particular object -- that you want, you can then move it or rotate it as you want. No more "flickering" and no "messing around" with front and back buffers.

It looks like the book has the potential of answering many of my other questions as well -- regardings textures, etc.

Thanks again to everyone!

Mike Swanson

RM mode is no longer in DirectX.