circlesoft

Members
  • Content count

    3565
  • Joined

  • Last visited

Community Reputation

1178 Excellent

About circlesoft

  • Rank
    Contributor
  1. Rendering to Offscreen-Surface is slooow

    Quote:Original post by MrSparkle27 Thank you for your quick reply. I'm using MDX so I use the SurfaceRenderer class to render offscreen surfaces and a swap chain to render to a backbuffer as suggested in an earlier posting. How are you guys rendering post effects? Are you rendering the scene to an offscreen surface or directly to the backbuffer and how do you pass the scene texture to the post effect? Thanks, Christian You have to create a texture with D3DUSAGE_RENDERTARGET (with only 1 mip level). Then get its surface using IDirect3DTexture9::GetSurfaceLevel(0). Render to this surface, and then pass the texture to your post-processing effect. It isn't 50% slower than normal.
  2. D3D9 multihead

    Quote:Original post by Drunken_Coder Unfortunately the settings are identical on both screens. The only solution I can see is to run two devices, but it seems from reading the docs that this would require separate resources, separate windows, and separate Present() calls. Is there any way to make two devices split two halves of the same window, and can I make them share resources (texture and vertex buffers)? The whole multi-monitor area has always been kind of blurry with D3D (I guess it was never a big issue, seeing as few, if no, commercial games use it), but I am guessing that with D3D9, no. All multimon apps I've seen have to create two or more devices and clone resources appropriately.
  3. skeleton animation problem

    If you said it works in debug, but not in release, try checking out these sites: Debugging Release Mode Problems Surviving the Release Version It is possible to interactively debug a release build, so you can try that at least.
  4. Locking Rendertarget...

    From the docs: Quote: The destination surface must be either an off-screen plain surface or a level of a texture (mipmap or cube texture) created with D3DPOOL_SYSTEMMEM. The source surface must be a regular render target or a level of a render-target texture (mipmap or cube texture) created with POOL_DEFAULT. This method will fail if: The render target is multisampled. The source render target is a different size than the destination surface. The source render target and destination surface formats do not match. Check the debug runtime output.
  5. Direct3D in the taskbar

    I noticed that you only rely on windows messages to inform you of when the device should be lost/reset. For robustness, use IDirect3DDevice9::TestCooperativeLevel() before calling BeginScene(). This will tell you if the device is ready, and if not, when you can reset it.
  6. Quote:Original post by xissburg Sorry if I misunderstood but, the drivers act like a Just-in-Time compiler? Then, they all follow a standard right? I wouldn't go that far (about both the JIT and the standard [wink]). But the drivers will modify shaders based on the strengths and weaknesses (and bugs) of each card. This also just doesn't apply to shaders. For example, I remember when the NV cards didn't perform hardware decompression correctly on certain DDS formats. Then the driver just did it manually first in software. They can be quite tricky sometimes. Microsoft likes to put out standards, but as we have already seen in the past, they are more like "guidelines" hehe
  7. Error while compiling the sample program

    Which file are the errors in? Are you possibly trying to compile a HLSL/FX file with the C/C++ compiler?
  8. No effect of ID3DXPMesh??

    There are a lot of factors at play here. First, make sure that your LOD call actually succeeded and isn't failing or something. How many verts/tri's did a mesh have to begin with? It is likely that you are simply not throwing enough at your card to make an even noticable dent in performance. The low framerate could be coming from a limit in batching or the shaders.
  9. Quote:Original post by jollyjeffers There's not much point upgrading to D3D10 if you've no interest in making use of the new features... Yea, this is another good point. Many people speak of upgrading/rewriting their renderers to use D3D10, while I'm not so sure that they actually assess if they even need the new features that 10 offers hehe Other than the book that Jack and I are a part of, I have no commercial involvement with it, although we are starting to look there for the future. Anyone in middleware rendering should surely consider it.
  10. Full screen on Dualmonitor

    It depends on the hardware - some dual-monitor cards can't actually have 2 fullscreen devices going at once. Plus, remember that clicking on one will probably minimize the other. Generally, it's more realistic to create two maximized windowed devices. Here is a tutorial on multiple devices. Below that one is a nifty tutorial on doing it with swap chains.
  11. RenderMonkey Install Problem

    This isn't really a DX related problem (directly at least), so you could always try mailing the people at ATI. There is also Nvidia's FX Composer, which I have always prefered anyways [wink]
  12. built-in animation in .x file

    Yep, although it is notoriously tricky to get right. Here is a short tutorial about it, right here on Gamedev. If you search the forums, you will find tons and tons of topics about it, as it is pretty common. You will also need a decent exporter, such as Pandasoft or kW Xport.
  13. shader debug

    I normally keep a VS2003 project space around and fall back to that when I need to debug a shader, since I find that debugger to be a bit nicer and more streamlined than the PIX one. The main thing is, if I am having a shader problem, it most likely has to do with setting up state, so it's nice to be able to step from the application, into the shader, and back out again. But then again, keeping around VS2003 is a pain in the but too (unless you need it for other reasons, like me).
  14. Reading stencil/depth-buffers

    Quote:Original post by amtri Once I write to the stencil/depth buffers, is there a way I can find out exactly what the values of each 32-bits for each pixel in this buffer? Unless you use the D3DFMT_D[16/32]_LOCKABLE format, you won't be able to lock the surface directly. You won't be able to use any APIs to copy it to a lockable surface, either (such as StretchRect()). If you need to get the values from a z-buffer, it is more practical to use multiple render targets and just write the depth out to a R32F surface.
  15. PIX state dump?

    Quote:Original post by rpsathe a coworker told me this may be useful.... ID3D10Device::OMGetBlendState Get the blend state of the output-merger stage. void OMGetBlendState( ID3D10BlendState **ppBlendState, FLOAT BlendFactor[4], UINT *pSampleMask ); Yea, this is what I was talking about. If you want to run in PIX and check this at the same time, you probably want to output this stuff to a log file, or something like that. The reference device isn't exactly interactive [wink]