We help IT Professionals succeed at work.

DirectX8

kamarey
kamarey asked
on
I have GeForce 2 MX 200,  thereis hardware T&L block
Here is the function that creates device:
          hr = pID3D->CreateDevice(D3DADAPTER_DEFAULT,
                              D3DDEVTYPE_HAL,
                              hWnd,
D3DCREATE_SOFTWARE_VERTEXPROCESSING,
                              &d3dpp,
                              &pID3DDevice);

Explain me please what difference between D3DDEVTYPE_HAL , D3DDEVTYPE_REF and D3DDEVTYPE_SW, and what difference between D3DCREATE_SOFTWARE_VERTEXPROCESSING, D3DCREATE_HARDWARE_VERTEXPROCESSING and D3DCREATE_MIXED_VERTEXPROCESSING. And what does this function:
     SetRenderState(D3DRS_SOFTWAREVERTEXPROCESSING, TRUE or FALSE);

And the last question why with my display adapter D3DCREATE_SOFTWARE_VERTEXPROCESSING works much faster then D3DCREATE_HARDWARE_VERTEXPROCESSING?
Comment
Watch Question

Welcome to the wonderfull world of DX8 where nothing is quite what it seems.

HAL = Hardware Abstraction Layer is the layer of code to which commands are issued. The commands are independent of the type of hardware used. The HAL is then linked to the driver software provided by the manufacturer. Then you have a thing called the REFERENCE RASTERISER which will in software emulate the functionality of the HARDWARE. It is a HARDWARE EMULATOR If your 3d Graphics are not behaving, switch to the REFERENCE RASTERISER. If you get a proper 3d image, then you must start looking at the drivers and paramater settings for the particular card.  On the lower end cards, not all of the functionality of the REFerence rasterizer is supported, so u would use MIXED ... typicaly the SOFTWARE would performe certain aspects of the 3D render, then custom FX, like specularity lighting etc would be done by the REFerence rasteriser in the MIXED mode.

HARDWARE ABSTARCION LAYER is an intermediary layer that translates the DX8 command into a format that will be understood by the 3D card.
SOFTWARE renders using the drivers supplied by the manuf.
REFERENCE RASTERIZER is the full dx8 functinalty provided in software without accessing the 3D card at all.


Thats it in a simplified nushell.

I hope this answers your question ?

Author

Commented:
1. Can you explain me what differens between definition of VERTEXPROCESSING in CreateDevice and SetRenderState functions?
2. Why SOFTWARE_VERTEXPROCESSING works much faster than HARDWARE_VERTEXPROCESSING with my graphic card ( there is some function that my graphic card doesn't have it as hardware? I don't do something like environment bump mapping which my card doesn't support. My program just draws a 3d object with big amount of faces ).
3. Is here a problem that I have with lightning with HARDWARE_VERTEXPROCESSING?

P.S. If DirectX is a wonderfull world, why I cann't find information that I need in the internet(there are only tutorials for beginers)?
The performance of vertex processing operations, including transformation and lighting, depends heavily on where the vertex buffer exists in memory and what type of rendering device is being used. Applications control the memory allocation for vertex buffers when they are created. In the create device command, the nature of the rendering device is specified. (Hardware, Reference etc)   In the set render state, the functionality of the rendering device is specified. (ie specifying lights, fogs, specularity, culling, filtering)

The vertex processing class supports vertex processing in both software and hardware. In general, the device capabilities for software and hardware vertex processing are not identical. Hardware capabilities are variable,
depending on the display adapter and driver, while software capabilities are fixed (and therefore faster).

D3DDEVTYPE_HAL
Hardware rasterization and shading with software,
hardware, or mixed transform and lighting.
D3DDEVTYPE_REF
Microsoft? Direct3D? features are implemented in software.
D3DDEVTYPE_SW
A pluggable software device that has been registered
with Direct3D using Direct3D8.RegisterSoftwareDevice

As I said above, the software device is the best one to use because it comes from the manufacturer and allows direct interaction with the 3D hardware. The Hardware (HAL) implies that one must pass through an extra layer of code, resulting in slower operation.

You must contact MS Help to find out which cards support bump mapping ... there are losta bugs in the DX8, Tests will report a capability which is in fact not supported. Do you get bump mapping using the REFerence rasterizer setting ?

As far as lighting is concerned ... that is a bitch all by itself.

In DirectX 8.0, the HAL can have three different vertex processing modes: software vertex processing, hardware vertex processing, and mixed vertex processing on the same device. The pure device mode is a variant of the HAL device. The pure device type supports hardware vertex processing only, and allows only a small subset of the device state to be queried by the application. Additionally, the pure device is available only on adapters that have a minimum level of capabilities.

In Microsoft? Direct3D? for Microsoft DirectX? 8.0, procedural models are used for specifying the behavior of the vertex transformation and lighting pipeline and the pixel texture blending pipeline. There are many advantages to a program model-based syntax for specifying the behavior of the hardware.

A procedural model allows a more general syntax for specifying common operations. Fixed-function, as opposed to programmable, APIs must define modes, flags, and so on for an increasing number of operations that need to be expressed. Further, with the increasing power of the hardware?more colors, more textures, more vertex streams, an so on?the token space for the operations multiplied by the data inputs becomes complex. A programmability model, on the other hand, enables even simple operations such as getting the right color and right texture into the right part of the lighting model in a more direct fashion and is therefore faster

The reasoning you use to determine the memory location?system or driver optimal?for vertex buffers is the same as that for textures. Vertex processing, including transformation and lighting, in hardware works best when the vertex buffers are allocated in driver-optimal memory, while software vertex processing works best with vertex buffers allocated in system memory. For textures, hardware rasterization works best when textures are allocated in driver-optimal memory, while software rasterization works best with system-memory textures.


If your application performs its own vertex processing and passes transformed, lit, and clipped vertices to rendering methods, then the application can directly write vertices to a vertex buffer allocated in driver-optimal memory. This technique prevents a redundant copy operation later. Note that this technique will not work well if your application reads data back from a vertex buffer, because read operations done by the host from driver-optimal memory can be very slow. Therefore, if your application needs to read during processing or writes data to the buffer erratically, a system-memory vertex buffer is a better choice.


Software vertex processing provides a guaranteed set of vertex processing capabilities, including an unbounded number of lights and full support for programmable vertex shaders. You can toggle between software and hardware vertex processing at any time when using the HAL Device, the only device type that supports both hardware and software vertex processing. The only requirement is that vertex buffers used for software vertex processing must be allocated in system memory.

Note  The performance of hardware vertex processing is comparable to that of software vertex processing. For this reason, it's a good idea to provide, within a single device type, both hardware- and software-emulation functionality for vertex processing. This is not the case for rasterization, for which host processors are much slower than specialized graphics hardware. Thus both hardware- and software-emulated rasterization is not provided within a single device type. Software vertex processing is the only instance of functionality duplicated between the run time and the hardware (driver) within a single device. Thus all other device capabilities represent potentially variable functionality provided by the driver.


Did you download the full DX8 SDK ? There is quite a lot in there. Personaly, I had to do about two weeks of reading bfore I could start using DX8.

regards

Author

Commented:
If I understood right, HARDWARE vertexprocessing must work faster, when I place an object(vertex or index buffer) in video memory. I did so using the D3DXMESH_MANAGED flag in D3DXCreateMesh and there is no difference.

Can you provide some links to sites with DirectX8 tutorias.
And I don't know what you want to read in DirectX8 SDK(I have it full, ~140MB) tutorials. And you will agree that it is imposible to learn DirectX by reading its tutorial, isn't it?

P.S. How did you find this question? In the 3D Game topic or by link in C++ tpoic?

Author

Commented:

Explore More ContentExplore courses, solutions, and other research materials related to this topic.