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?