c t o a n

Members
  • Content count

    306
  • Joined

  • Last visited

Community Reputation

163 Neutral

About c t o a n

  • Rank
    Member
  1. Many textures in D3D

    maybe you should try // this provides more control over the loaded texture. D3DXCreateTextureFromFileEx( D3DDevice, /*! device pointer */ "filename.jpg", /*! texture filename */ D3DX_DEFAULT, /*! reads the image dimensions, and rounds to the next power of 2 */ D3DX_DEFAULT, 1, /*! mip map levels */ 0, /*! texture usage flags */ D3DFMT_UNKNOWN, /*! the desired format for the texture (try for 16 or 32 bits) */ D3DPOOL_MANAGED, /*! the pool to place the texture into (this is probably whats slowing down your app. experiment with D3DPOOL_DEFAULT) */ D3DX_FILTER_POINT, /*! filter flags */ D3DX_FILTER_BOX, /*! the mip map filter flags */ 0, /*! desired transparent color key */ NULL, NULL, /*! some extra stuff */ &pTexture ); /*! your texture pointer */ what this is doing is automatically adjusting your texture to power-of-2 dimenions, making sure your texture is in a place the video card can quickly read it, and turning off the complicated render filters that directX will normally give you (D3DX_FILTER_POINT is the simplest filter, instead of D3DX_FILTER_TRIANGLE - the slowest - and D3DX_FILTER_BOX which directX normally assigns) you'll notice it also creates only 1 level LOD (mip maps). this can be changed, but if your doing a simple app it really won't matter, though for speed you might want to add another couple of layers depending on how big your textures are.
  2. Present failed

    by declaring the variable static, you're telling all the source files that there should only be one instance of that variable floating around. in order for the compiler to know WHICH instance to use, you need to declare it once in a source file. Its the same line of code to declare it, but without a 'static' modifier: header: class cGraphics { public: static bool bRunning; }; source: bool cGraphics::bRunning; // if you need an initial value, put it here
  3. Have you set your View and Projection matrices? using D3DXMatrixLookAtLH() and D3DXMatrixPerspectiveFovLH(), for example.
  4. Why does my cube look like this

    Quote:Original post by jollyjeffers It's a little bit more involved as you can set the type of mirroring (wrap/mirror etc..) and it is limited by the hardware - which specifies the number of times it can wrap/tile a texture (I forget the exact caps for determining this). check out MaxTextureRepeat, but it is also determined by if the hardware scales the floating point value to a texel position before or after interpolating the coordinates across the polygon. This is determined by the cap D3DCAPS9.TextureCaps & D3DPTEXTURECAPS_TEXREPEATNOTSCALEDBYSIZE Quote:I couldn't imagine any other USEFUL variable type for the UV-coordinates? vertex and pixel shaders can decompress or otherwise reconstruct a packed real value, for example. if bandwidth (or memory) is a problem, but you have lots of vertex/pixel processor power - turn your 8 byte U,V coords into 4 byte packed fixed point, or something similar. check out D3DDECLTYPE for a list of the many, many supported variable formats that you could use in your app.
  5. Rendering in a Separate Thread

    check out D3DPRESENT_DONOTWAIT Quote: If dwFlags = D3DPRESENT_DONOTWAIT, and the hardware is busy processing or waiting for a vertical sync interval, the method will return D3DERR_WASSTILLDRAWING so if Present()'ing the screen would block the CPU, just do something else in the meantime and check back later.
  6. Multitexturing

    well, if you're only using 3 stages, you shouldnt set all 8 blending stages. STSS( 3, D3DTSS_COLOROP, D3DTOP_DISABLE ); other than that it looks like the states are set correctly. are you sure your textures have alpha? what are your ALPHAOP, and ALPHAARG states?
  7. access buffer

    it depends on where you are placing your vertex buffers (which are encapsulated in your mesh class I assume?). if they are in D3DPOOL_SYSTEM then there should be no performance penalty for reading from them. If they are placed anywhere else, you really should not read back from the buffer. Data is intended to flow CPU -> GPU, not GPU -> CPU, and hence it would be quite slow.
  8. Multitexturing

    what are you trying to get it to do? T1 x T2 + T3 ? T1 + T2 + T3 ? etc are you trying to say, render T1, then render T2 blending T1 with alpha of T2, then render T3 blending (T2 + T1 x alpha of T2) with alpha of T3? let us know exactly what it is you want.
  9. VertexBuffer Question

    Well, I'm not very familiar with C#, but in C++ you Lock() the buffer, which returns a pointer to the locked memory (this is probably the difference) which you can fill with your vertex data. Then you call Unlock() to return access rights to the GPU (make sure and call unlock!) You can fit whatever vertex data you want in your buffer. Different FVF's, different size vertices, several meshes, it can all fit in a single buffer. In C++, when you call SetStreamSource you can tell the runtime where in the buffer to begin referencing (OffsetInBytes). I profiled SetStreamSource with OffsetInBytes=0 and OffsetInBytes=X a while back, and both incurred a similar performance penalty (very small), though when you render many hundreds of triangles, its actually more efficient to stuff as much data as you can (reasonably) fit into a single buffer. I forget the exact numbers, but if you search for SetStreamSource I made a thread about it a long time ago.
  10. SetTextureStateStates explanation

    word of warning though, the texture blend states still matter when using vertex and pixel shaders. I don't know the order of operations between the blend states and the shaders (I dont have the slides in front of me) but I remember a few times when the pixel shaders just didn't work because I had not set D3DTA_TEXTURE as the color source in the blending state.
  11. SetTextureStateStates explanation

    Well, it really takes some experience to fully understand all the blend states, such as how to blend two or three textures together to get the effect you want, just yesterday I read in an obscure DXSDK doc that if you use D3DTA_TEXTURE in the second argument, it is slower then using it in the first argument. I had no idea! I'm wondering if this would satisfy your first situation (I've not tried it myself): STSS( 0, D3DTSS_RESULTARG, D3DTA_TEMP ); // TEMP register would have to be checked for support STSS( 0, D3DTSS_COLOROP, D3DTOP_SELECTARG1 ); STSS( 0, D3DTSS_COLORARG1, D3DTA_TEXTURE | D3DTA_ALPHAREPLICATE ); STSS( 1, D3DTSS_RESULTARG, D3DTA_CURRENT ); STSS( 1, D3DTSS_COLOROP, D3DTOP_MODULATE ); STSS( 1, D3DTSS_COLORARG1, D3DTA_TEXTURE ); STSS( 1, D3DTSS_COLORARG2, D3DTA_TEMP ); STSS( 2, D3DTSS_RESULTARG, D3DTA_TEMP ); STSS( 2, D3DTSS_COLOROP, D3DTOP_MODULATE ); STSS( 2, D3DTSS_COLORARG1, D3DTA_TEXTURE ); STSS( 2, D3DTSS_COLORARG2, D3DTA_TEMP | D3DTA_COMPLEMENT ); STSS( 3, D3DTSS_RESULTARG, D3DTA_CURRENT ); STSS( 3, D3DTSS_COLOROP, D3DTOP_ADD ); STSS( 3, D3DTSS_COLORARG1, D3DTA_CURRENT ); STSS( 3, D3DTSS_COLORARG2, D3DTA_TEMP ); STSS( 4, D3DTSS_COLOROP, D3DTOP_DISABLE ); SetTexture( 0, Texture1 ); SetTexture( 1, Texture1 ); SetTexture( 2, Texture2 ); SetTexture( 3, NULL ); *whew* that's complicated! There has to be a better way using texture states... Probably resort to the obscure and often not supported 3-Argument commands, such as D3DTOP_BLENDCURRENTALPHA. Of course, all this does is take the place of doing two passes with the AlphaBlendEnable renderstate, and setting the appropriate D3DRS_SRCBLEND and D3DRS_DESTBLEND states (which I think is alot easier, I'm sure efficiency would depend on your textures, polys, and video card) And what I wrote only works on the color components (r,g,b) and leaves the alpha completed unchanged (I believe the default operation is MODULATE for the first stage, and DISABLE for the rest?) so you have to set those up as well. Someone else can help you out with the second case, I've said enough.
  12. Private/Protected members and methods are only helpful when you deal with code that directly and intentionally accesses your class. You can still easily 'overwrite' the data either accidentally or intentionally (clear the entire object to zero, for example) So its really a mechanism to 'keep honest code honest'. Its really helpful when all you need to call is CreateObject( Width, Height, BPP ) instead of setting m_Width, m_Height, and m_BPP, which might have to change later, or extra variables might have to be set, etc.
  13. render queue

    I calculate a bounding 'influence' sphere for my lights (maximum effective range) and if the light isn't directly inside the view frustum, I test for intersection between each lights bounding sphere and the frustum planes. Of course, theres some spatial sorting in there, so I'm not testing all the lights in the entire map, though if a light spans a spatial boundary (such as two octree nodes) its referenced in both. I also store a timestamp for the last known time the light influenced anything inside the view frustum. If the light was an influence last frame, its very likely to be an influence this frame too. (and vice versa)
  14. Camera Positioning

    As long as you're not clearing your depth buffer, it shouldn't matter if you have multiple Begin/End calls because all the pixels in the depth buffer are unaffected unless you Clear() them. are you sure ZTest is enabled? (its a SetRenderState value). and unless you're using pre-transformed and lit vertices (XYZRHW), you can set the maximum/minimum zvalues by changing your perspective transformation matrix (D3DXMatrixPerspectiveFovLH, for example). while sorting back to front is necessary with alpha blending (unless you get into 'depth slicing' which is a technique to avoid sorting, but its a bit complex), sorting front to back for all your other polys doesn't really provide that much of a speed boost as cards nowadays are very efficient at testing/rendering very quickly, as opposed to using CPU time to sort through all your polygons before sending them off to the graphics card.
  15. How fast is DrawPrimitiveUP?

    Quote:Original post by barakus I started a similar thread a few weeks back. After some testing between using dynamic vertex buffers and DrawPrimitiveUp, I found DrawPrimitiveUp to be a tad faster. This difference, however was negligible as the vertex buffer drawing quad gave me around 890 frames per second and DrawPrimitiveUp around 910. This was however with sprites consisting of two triangles, for my map I have always used index buffers with dynamic vertex buffers, as the batching of thousands of triangles is essential for speed. If you are just going to be rendering two triangles each call, I recommend you use whatever you find easier, as the differences between speeds will be almost non existant. I've found DrawPrimitiveUP to be ALOT slower then locking a dynamic vertex buffer yourself. How many triangles did you test it with? (getting 910 frames per second sounds like 'not very many')