csdn_文档中心_directx 8 开发者常见问题集.htm

csdn10年中间经典帖子

            shadow faces as back faces will have been rendered and the stencil 
            will be zero, having been incremented as many times as decremented. 
            </P>
            <P>The final possibility is that the point lies inside the shadow 
            volume. In this case the back face of the shadow volume will be 
            z-buffered out, but not the front face, so the stencil buffer will 
            be a non-zero value. The result is portions of the frame buffer 
            lying in shadow have non-zero stencil value. Finally, to actually 
            render the shadow, the whole scene is washed over with an 
            alpha-blended polygon set to only affect pixels with non-zero 
            stencil value. An example of this technique can been seen in the 
            "Shadow Volume" sample that comes with the DirectX SDK.</P>
            <H4>What are the texel alignment rules? How do I get a one-to-one 
            mapping?</H4>
            <P>This is explained fully in the DirectX 8 documentation (under the 
            article titled <A 
            href="http://msdn.microsoft.com/library/psdk/directx/DX8_C/hh/directx8_c/_dx_directly_mapping_texels_to_pixels_graphics.htm">Directly 
            Mapping Texels to Pixels</A>). However, the executive summary is 
            that you should bias your screen coordinates by –0.5 of a pixel in 
            order to align properly with texels. Most cards now conform properly 
            to the texel alignment rules, however there are some older cards or 
            drivers that do not. To handle these cases, the best advice is to 
            contact the hardware vendor in question and request updated drivers 
            or their suggested workaround.</P>
            <H4>What is the purpose of the D3DCREATE_PUREDEVICE flag?</H4>
            <P>If the D3DCREATE_PUREDEVICE flag is specified during device 
            creation, Direct3D will create a "pure" device. This disables the 
            use of the Get* family of methods, and forces vertex processing to 
            be hardware only. This allows the Direct3D runtime to make certain 
            optimizations that afford the best possible path to the driver 
            without having to track so much internal state. In other words, you 
            can see a performance advantage using PUREDEVICE, at the cost of 
            some convenience.</P>
            <H4>How do I use color keying?</H4>
            <P>DirectX 8 does not support color keying. You should use alpha 
            blending/testing instead, which is in general a more flexible 
            technique that does not suffer from some of the problems associated 
            with color keying.</P>
            <H4>How do I enumerate the display devices in a multi-monitor 
            system?</H4>
            <P>In common with other enumeration functionality, this has moved 
            from being callback based to a simple iteration by the application 
            using methods of the <B>IDirect3D8</B> interface. Call 
            <B>GetAdapterCount</B> to determine the number of display adapters 
            in the system. Call <B>GetAdapterMonitor</B> to determine which 
            physical monitor an adapter is connected to (this method returns an 
            HMONITOR, which you can then use in the Win32 API 
            <B>GetMonitorInfo</B> to determine information about the physical 
            monitor). Determining the characteristics of a particular display 
            adapter or creating a Direct3D device on that adapter is as simple 
            as passing the appropriate adapter number in place of 
            D3DADAPTER_DEFAULT when calling <B>GetDeviceCaps</B>, 
            <B>CreateDevice</B>, or other methods.</P>
            <H3><A name=directx8faq_topic4></A>Geometry (Vertex) Processing</H3>
            <H4>What happened to the old vertex types like D3DVERTEX?</H4>
            <P>The "pre-canned" vertex types are no longer explicitly supported. 
            The multiple vertex stream system allows for more flexible assembly 
            of vertex data. If you want to use one of the "classic" vertex 
            formats, you can build an appropriate FVF code.</P>
            <H4>Vertex streams confuse me, how do they work?</H4>
            <P>Direct3D assembles each vertex that is fed into the processing 
            portion of the pipeline from one or more vertex streams. Having only 
            one vertex stream corresponds to the old pre-DirectX 8 model, in 
            which vertices come from a single source. With DirectX 8, different 
            vertex components can come from different sources; for example, one 
            vertex buffer could hold positions and normals, while a second held 
            color values and texture coordinates.</P>
            <H4>What is a vertex shader?</H4>
            <P>A vertex shader is a procedure for processing a single vertex. It 
            is defined using a simple assembly-like language that is assembled 
            by the D3DX utility library into a token stream that Direct3D 
            accepts. The vertex shader takes as input a single vertex, and a set 
            of constant values, and outputs a vertex position (in clip-space) 
            and optionally a set of colors and texture coordinates which are 
            used in rasterization. Notice that when you have a custom vertex 
            shader, the vertex components no longer have any semantics applied 
            to them by Direct3D and vertices are simply arbitrary data that is 
            interpreted by the vertex shader you create.</P>
            <H4>Does a vertex shader perform perspective division or 
            clipping?</H4>
            <P>No. The vertex shader outputs a homogenous coordinate in 
            clip-space for the transformed vertex position. Perspective division 
            and clipping is performed automatically post-shader.</P>
            <H4>Can I generate geometry with a vertex shader?</H4>
            <P>A vertex shader cannot create or destroy vertices; it operates on 
            a single vertex at a time, taking one unprocessed vertex as input 
            and outputting a single processed vertex. It can therefore be used 
            to manipulate existing geometry (applying deformations, or 
            performing skinning operations) but cannot actually generate new 
            geometry <I>per se</I>.</P>
            <H4>Can I apply a custom vertex shader to the results of the 
            fixed-function geometry pipeline (or vice-versa)?</H4>
            <P>No. You have to choose one or the other. If you are using a 
            custom vertex shader, then you are responsible for performing the 
            entire vertex transformation.</P>
            <H4>Can I use a custom vertex shader if my hardware does not support 
            it?</H4>
            <P>Yes. The Direct3D software vertex-processing engine fully 
            supports custom vertex shaders with a surprisingly high level of 
            performance.</P>
            <H4>How do I determine if the hardware supports my custom vertex 
            shader?</H4>
            <P>Devices capable of supporting vertex shaders in hardware are 
            required to fill out the <B>D3DCAPS8::VertexShaderVersion</B> field 
            to indicate the version level of vertex shader they support. Any 
            device claiming to support a particular level of vertex shader must 
            support all legal vertex shaders that meet the specification for 
            that level or below.</P>
            <H4>How many constant registers are available for vertex 
            shaders?</H4>
            <P>Devices supporting DX8 vertex shaders are required to support a 
            minimum of 96 constant registers. Devices may support more than this 
            minimum number, and can report this through the 
            <B>D3DCAPS8::MaxVertexShaderConst</B> field.</P>
            <H4>Can I share position data between vertices with different 
            texture coordinates?</H4>
            <P>The usual example of this situation is a cube in which you want 
            to use a different texture for each face. Unfortunately the answer 
            is no, it's not currently possible to index the vertex components 
            independently. Even with multiple vertex streams, all streams are 
            indexed together.</P>
            <H4>When I submit an indexed list of primitives, does Direct3D 
            process all of the vertices in the buffer, or just the ones I 
            indexed?</H4>
            <P>When using the software geometry pipeline, Direct3D first 
            transforms all of the vertices in the range you submitted, rather 
            than transforming them "on demand" as they are indexed. For densely 
            packed data (that is, where most of the vertices are used) this is 
            more efficient, particularly when SIMD instructions are available. 
            If your data is sparsely packed (that is, many vertices are not 
            used) then you may want to consider rearranging your data to avoid 
            too many redundant transformations. When using the hardware geometry 
            acceleration, vertices are typically transformed on demand as they 
            are required.</P>
            <H4>What is an index buffer?</H4>
            <P>An index buffer is exactly analogous to a vertex buffer, but 
            instead it contains indices for use in DrawIndexedPrimitive calls. 
            It is highly recommended that you use index buffers rather than raw 
            application-allocated memory when possible, for the same reasons as 
            vertex buffers.</P>
            <H4>I notice that 32-bit indices are now a supported type; can I use 
            them on all devices?</H4>
            <P>No. You must check the <B>D3DCAPS8::MaxVertexIndex</B> field to 
            determine the maximum index value that is supported by the device. 
            This value must be greater than 2<SUP>16</SUP>-1 (0xffff) in order 
            for index buffers of type <B>D3DFMT_INDEX32</B> to be supported. In 
            addition, note that some devices may support 32-bit indices but 
            support a maximum index value less than 2<SUP>32</SUP>-1 
            (0xffffffff); in this case the application must respect the limit 
            reported by the device.</P>
            <H4>What restrictions are there on using multiple vertex streams 
            with the fixed-function pipeline?</H4>
            <P>The fixed-function pipeline requires that each vertex stream be a 
            strict FVF subset, ordered as per a full FVF declaration. Also, note 
            that you must respect any restriction on the number of streams as 
            reported by the <B>D3DCAPS8::MaxStreams</B> field (many current 
            devices and/or drivers only support a single stream).</P>
            <H3><A name=directx8faq_topic5></A>Performance Tuning</H3>
            <H4>How can I improve the performance of my Direct3D 
            application?</H4>
            <P>The following are key areas to look at when optimizing 
            performance: 
            <UL type=disc>
              <LI><B>Batch size</B>. Direct3D is optimized for large batches of 
              primitives. The more polygons that can be sent in a single call, 
              the better. A good rule of thumb is to aim to average over 100 
              polygons per call. Below that level you're probably not getting 
              optimal performance, above that and you're into diminishing 
              returns and potential conflicts with concurrency considerations 
              (see below).<BR><BR>
              <LI><B>State changes</B>. Changing render state can be an 
              expensive operation, particularly when changing texture. For this 
              reason, it is important to minimize as much as possible the number 
              of state changes made per frame. Also, try to minimize changes of 
              vertex or index buffer. 
              <P class=atl><B>Note&nbsp;&nbsp;&nbsp;</B>Changing vertex buffer 
              is no longer as expensive in DirectX 8 as it was with previous 
              versions, but it is still good practice to avoid vertex buffer 
              changes where possible.</P>
              <LI><B>Concurrency</B>. If you can arrange to perform rendering 
              concurrently with other processing, then you will be taking full 
              advantage of system performance. This goal can conflict with the 
              goal of reducing renderstate changes. You need to strike a balance 
              between batching to reduce state changes and pushing data out to 
              the driver early to help achieve concurrency. Using multiple 
              vertex buffers in round-robin fashion can help with 
              concurrency.<BR><BR>
              <LI><B>Texture uploads</B>. Uploading textures to the device 
              consumes bandwidth and causes a bandwidth competition with vertex 
              data. Therefore, it is important to not to over commit texture 
              memory, which would force your caching scheme to upload excessive 
              quantities of textures each frame.<BR><BR>
              <LI><B>Vertex and index buffers.</B> You should always use vertex 
              and index buffers, rather than plain blocks of application 
              allocated memory. At a minimum, the locking semantics for vertex 
              and index buffers can avoid a redundant copy operation. With some 
              drivers, the vertex or index buffer may be places in more optimal 
              memory (perhaps in video or AGP memory) for access by the 
              hardware.<BR><BR>
              <LI><B>State macro blocks</B>. These were introduced in DX 7.0,