Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories

Using Front/Back Buffers With DirectX 3

Mike7409Mike7409 Member Posts: 15
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?

Comments

  • gautamgautam Member Posts: 642
    Hi,

    I don't really know much about DirectX3 but is it mandatory that you have to use DirectX. If you are just starting out then I suggest you move your app to use OpenGL as during the time DirectX 3 existed OpenGL was far better supported. Also OpenGL is backward compatible as long as you use 1.0 or 1.1 version. In addition it also has Mesa which is a software implementation of OpenGL so you are safe on the account of having many hardware supported.

    Sorry I can't answer your question about DirectX 3 but regarding polygon texturing its quite simple. Assume I have a rectangle (4 sided polygon) and I want to texture it. I would set my texture coordinates as (0, 0), (1, 0), (1,1), (0, 1)

    (1, 0) (1, 1)
    ......................
    . .
    . .
    ......................
    (0, 0) (1, 0)

    Where 0, 0 represents the bottom left of the texture, (1, 0 ) the bottom right, 1, 1 the top right and 1, 0 top right of the texture. This is the UV coordinates and then some kind of mapping happens in the hardware which renders the texture on the polyong.

    Hope this helps.

    Regarding animation keys - I will answer that another day or let someone else answer it :)


    : 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?

  • Mike7409Mike7409 Member Posts: 15
    Thank you for taking the time to reply to my post. In answer to your reply, I will certainly consider using OpenGL if all else fails. I'm not as familiar with OpenGL as I am with the C language and DIrectX. (Of course, if I was more familiar with DirectX3, I probrably would know how to use front/back buffers, right? -- and I'd be able to continue on with my projects.)

    As you may know, OpenGL's coordinate system along the z-axis is the reverse of DirectX -- it's positive z-coordinates are away from the user wheras OpenGL's positive z-coordinates are toward the user. Because I also do flight simulation scenery programming, I prefer to work with the DirectX coordinate system rather than the OpenGL one.

    Thank you again for taking the time to reply to my post.

    Sincerely,

    Mike7409

    : Hi,
    :
    : I don't really know much about DirectX3 but is it mandatory that you
    : have to use DirectX. If you are just starting out then I suggest you
    : move your app to use OpenGL as during the time DirectX 3 existed
    : OpenGL was far better supported. Also OpenGL is backward compatible
    : as long as you use 1.0 or 1.1 version. In addition it also has Mesa
    : which is a software implementation of OpenGL so you are safe on the
    : account of having many hardware supported.
    :
    : Sorry I can't answer your question about DirectX 3 but regarding
    : polygon texturing its quite simple. Assume I have a rectangle (4
    : sided polygon) and I want to texture it. I would set my texture
    : coordinates as (0, 0), (1, 0), (1,1), (0, 1)
    :
    : (1, 0) (1, 1)
    : ......................
    : . .
    : . .
    : ......................
    : (0, 0) (1, 0)
    :
    : Where 0, 0 represents the bottom left of the texture, (1, 0 ) the
    : bottom right, 1, 1 the top right and 1, 0 top right of the texture.
    : This is the UV coordinates and then some kind of mapping happens in
    : the hardware which renders the texture on the polyong.
    :
    : Hope this helps.
    :
    : Regarding animation keys - I will answer that another day or let
    : someone else answer it :)
    :
    :
    : : 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?
    :
    :
Sign In or Register to comment.