• Advertisement

freka586

Member
  • Content count

    108
  • Joined

  • Last visited

Community Reputation

152 Neutral

About freka586

  • Rank
    Member
  1. OK, and all results except Success are counted as failures? Can you imagine any scenario where underlying DirectX calls may return Success when something has gone wrong? Running out of process adress space (OutOfMemory) is for instance not uncommon, so if LockRectangle results in memory allocation (despite being in the Managed pool), perhaps that could be a case of failure? Sorry for being so vague, but troubleshooting based on a two separate occurances of "should never happen" is hard! Issues on a lower level is of course another possibility, as Nvidia Quadro is a common factor for both cases. But I still would like to explore aspects of my code before going down that road..
  2. I am currently investigating a scenario where content is drawn using incorrect/unexpected texture and/or texture content. The problem is intermittent, which makes troubleshooting much more difficult. Currently the most likely candidate seems to be that SetTexture for some reason seems to not have been executed, resulting in the previously used texture remaining set. The exact same operation succeeds a moment later, so actual textures and their content are fine. I have high-level try/catch blocks, so if SlimDX would have thrown an exception (via CheckHResult) I would have seen it. So, are there other cases where a SetTexture call can fail to succeed/complete, without it being serious enough for SlimDX to throw an exception? What about other result codes, such as WasStillDrawing, would they prevent completion and if so, would they result in an Exception being thrown? Thanks in advance, Fredrik [Edited by - freka586 on May 31, 2010 6:19:48 AM]
  3. Thanks for your reply! In my case, Effects would probably be the remaining problem. I use only a small portion of it, but I have no real feeling about how much lowlevel coding would be needed to work around it. To make sure I understand correctly, is no version of D3DX shipped with the OS? Or is it that particular/different versions are shipped depending on OS, and that SlimDX requires a single version of it?
  4. I'm working on a .NET application that requires the use of accelerated graphics, currently DirectX 9.0c. The software is quite graphics intensive and must, in addition, be launchable from a CD or by ClickOnce without the user requiring administrator's permissions. I currently use SlimDX, but the users are getting rather annoyed by having to install the DirectX redistributable. Especially since this does require elevated permissions. It is rather hard to explain to them why the version of DirectX already bundled with their OS is not sufficient. After all - DirectX 9.0c has been around since 2004, and I'm not using any new fancy features. The ability to deliver an application that "just works" in Vista or Windows 7 (or even XP SP3), without any particular additional prerequisites would be a huge advantage. Therefore: Is there any way I can adjust/compile SlimDX such that it relies only on the libraries provided in the standard Windows Vista/Win7 installation? That is - without requiring a particular DirectX redistributable to be installed? Thanks in advance!
  5. UpdateSurface on VolumeTexture?

    Come to think of it, this most likely has nothing to do with SlimDX. If I knew how to do this in basic DirectX, then the same approach would most likely work just fine in SlimDX as well. Updated title to reflect that! I can figure out the syntactic differences if someone has a clue how solve this problem in DirectX? [Edited by - freka586 on March 8, 2010 4:31:55 AM]
  6. First a small remark - I plan to explore this myself as soon as I get to a computer with proper development enviroment. But I thought it best to check this with the community as well, since that will be some time away for me. Is it possible to use the approach of UpdateSurface also on VolumeTextures? Or Volume, which would be the 3D equivalent of surface, right? Basically what I would like to do is as efficiently as possible fill the content of a Pool.Default VolumeTexture with the content of a Pool.System VolumeTexture. a) Is there an equivalent to UpdateSurface for this, or some other preferred approach? b) Any flags/options that might be of interest to reach maximum efficiency, as the amount of data for volume textures are typically fairly large? c) Are partial updates also OK, indicated by a Box region? What would the performance impact be, am I perhaps even better left at flushing the entire texture to reduce overhead? Thanks in advance, Fredrik [Edited by - freka586 on March 8, 2010 4:29:09 AM]
  7. SlimDX+PIX+64-bit?

    Yeah, I figured that this is some case of user error! It turns out that it works fine when running against x86-built versions of MiniTri but fails ("Failure creating process") when trying on explicit 64-bit build, and the previously mentioned error when using AnyCPU. I can probably manage with using 32-bit compiled version for now, but it would be very interesting to hear if anyone has successfully used "full 64-bit" (OS, PIX, code). And the steps/circumstances needed to get there... I noticed some previous posts on issues with PIX on 64-bit, but I am using the March 2009 which solved those problems.
  8. Hi, I just wanted to check if there are any known issues with running PIX on SlimDX programs using 64-bit Vista? My basic attempt consisted of launching the 64-bit PIX and pointing it to e.g. the MiniTri sample program I just built. This always seems to result in "Target Program Unexpected Exit". Now, I have never previously used PIX so I may be missing some vital parts here. Sorry if that is the case... If I do not want to perform any fancy kind of profiling, would I still need to do modifications to the MiniTri project? My initial idea has been that things should run out-of-the-box, but one can *hinder* PIX by adding compile flags? Thanks in advance, Fredrik
  9. When working under tight time pressure (as I am currently) it is always tempting to look for "the quick fix" instead of spending time to learn a new tool. Despite the fact that the latter *without a doubt* will save plenty of time in the long run. This time I will take the time needed to get familiar with PIX, thanks for the push!
  10. It turns out that I was a bit too quick in putting the blame on BeginScene/EndScene. I had made multiple changes, including some testing on the shader side. Things work well when using PS2.0 for my shader, but not when using PS3.0. And I must go for the latter due to the actual shader (not this test program) requiring many texture lookups. When playing around a bit it looks as if the texture coordinates are not correctly set. In some cases before I have seen that PS3 sometimes requires VS3 input, even if just a passthrough shader. But trying this also fails. Some comments on the code below (modified SlimDX MiniTri sample): a) Changing to PS2 and outputting texcoords shows nice colors as expected b) Doing the same with PS3 results in no colors at all c) The same when using PS3 and VS3. But there may of course be problems with how my vertex part is setup! d) I am extremely aware that resource handling is not very sane in this sample, but I wanted to contain as much of the sample in the same method as possible. // -------------- static void Application_Idle(object sender, EventArgs e) { while (AppStillIdle) { Device.Clear(ClearFlags.Target | ClearFlags.ZBuffer, Color.Black, 1.0f, 0); Device.BeginScene(); Surface previousRT = Device.GetRenderTarget(0); Texture renderTargetTexture = new Texture(Device, previousRT.Description.Width, previousRT.Description.Height, 1, Usage.RenderTarget, previousRT.Description.Format, Pool.Default); using (Surface renderTarget = renderTargetTexture.GetSurfaceLevel(0)) { Device.SetRenderTarget(0, renderTarget); // Stub for scene rendering, drawing a triangle with pretty colors. Device.SetStreamSource(0, Vertices, 0, 20); Device.VertexFormat = VertexFormat.PositionRhw | VertexFormat.Diffuse; Device.DrawPrimitives(PrimitiveType.TriangleList, 0, 1); } Device.SetRenderTarget(0, previousRT); string errors = null; string effectPath = @"C:\ImageShader.fx"; Effect effect = Effect.FromFile(Device, effectPath, null, null, null, ShaderFlags.None, null, out errors); effect.Technique = "BasicTechnique"; EffectHandle colorHandle = effect.GetParameter(null, "colorTexture"); effect.SetTexture(colorHandle, renderTargetTexture); Matrix wvp = Device.GetTransform(TransformState.World) * Device.GetTransform(TransformState.View) * Device.GetTransform(TransformState.Projection); effect.SetValue("worldViewProj", wvp); Viewport viewport = Device.Viewport; Device.SetTransform(TransformState.Projection, Matrix.OrthoOffCenterRH( viewport.X, viewport.X + viewport.Width - 1, viewport.Y, viewport.Y + viewport.Height - 1, 0, 1)); effect.Begin(FX.None); effect.BeginPass(0); VertexBuffer quadVertices = new VertexBuffer(Device, 4 * PositionTextured.SizeBytes, Usage.None, PositionTextured.Format, Pool.Managed); CreateVertices(quadVertices, viewport.Width, viewport.Height); Device.SetRenderState(RenderState.CullMode, Cull.None); Device.VertexFormat = PositionTextured.Format; Device.SetStreamSource(0, quadVertices, 0, PositionTextured.SizeBytes); Device.DrawPrimitives(PrimitiveType.TriangleStrip, 0, 2); effect.EndPass(); effect.End(); effect.Dispose(); effect = null; renderTargetTexture.Dispose(); renderTargetTexture = null; quadVertices.Dispose(); quadVertices = null; Device.EndScene(); Device.Present(); } } // ------- ImageShader.fx ---------- Texture colorTexture; uniform float4x4 worldViewProj : WORLDVIEWPROJ; sampler colorSampler = sampler_state { texture = <colorTexture>; AddressU = Clamp; AddressV = Clamp; AddressW = Clamp; MinFilter = Point; MagFilter = Point; }; // Dummy vertex shader to do the world/view/projection transformation. // This is normally not needed but sometimes a ps_3_0 shader // won't run unless there's a vs_3_0 shader. void DummyVS(in float4 inPos : POSITION0, out float4 outPos : POSITION0) { outPos = mul(inPos, worldViewProj); } void SimpleShader(in float3 textureCoords : TEXCOORD0, out float4 outColor : COLOR0) { float4 sample = tex2D(colorSampler, textureCoords); outColor = 1; //outColor.rgb = textureCoords.xyz; outColor.rgb = sample.xyz; } technique BasicTechnique { pass P0 { Texture[0] = <colorTexture>; //VertexShader = compile vs_3_0 DummyVS(); PixelShader = compile ps_3_0 SimpleShader(); } }
  11. When messing around a bit, it looks as if at least one source of error was illegal changes withing the same BeginScene-EndScene block. The following seems to work: Set RT to RT-texture BeginScene RenderMainScene EndScene Set RT to back buffer BeginScene RenderAndShade EndScene But not if all is done within a single BeginScene-EndScene block (omitting the inner ones). Does this make sense?
  12. Sorry, I didn't get that last advice? What I have already tried is just sampling the texture and setting that as output (without additional adjustments), and that did not work. Will try and look into PIX, as I have not had the pleasure of using that before!
  13. I am struggling a bit with getting a RenderTarget approach to work. Here's what I am doing: 1) Create a render target texture with the same size and format as the backbuffer. 2) Render the main scene into the rendertarget. 3) Render a textured quad covering the entire view, using the render target texture. A pixel shader is used that samples the texture and (optionally) performs some adjustments. However, as soon as I try and sample the texture in my shader for assigning output color, the result is full black. The following are my observations: a) If I remove the shader parts, the rendertarget texture is mapped correctly onto my quad. So both the main scene render and the quad seems valid. b) If I only set a fixed output color in my shader, without sampling the texture, this also gets applied as expected. So at least the shader gets executed as it should. So, given this vague description, any ideas on what could be going wrong? Are there any quick common mistakes I need to double check? I am will aware that code samples makes a world of difference. However getting some fairly clean code samples requires a fair bit of effort at this point, so I'd like to put that off at least for initial troubleshooting...
  14. Multisample questions

    Here's an example of a sort of worst case scenario. Different types of images show different artefacts, I guess depending on the frequency content of the source image. Here we get folding distorsion/aliasing in the form of vertical lines. For some images there are square patterns of varying scales. Please click "twice" to look at the image in full resolution, as downsampled representations would add problems of their own. The image shows, from left to right: a) Large scale differens (sourceWidth/destinationWidth close to 2, but slightly larger). No edge enhancement b) Exactly the same as [a] but with strong edge enhancement filter shader used. c) The same as [b] but zoom changed a small bit, such that a mipmap of half the size matches perfectly. As for anistropic settings, I tinkered with them a bit, but without luck. My knowledge in that area is slim, but I thought this would only help when the polygon edge suffers from "perspective" problems. Ie not being aligned with the view?
  15. Multisample questions

    Come to think of it, precomputing "mipmaps" on my own with tighter increments than full factors of 2 might actually be possible. The actual frequency problem would still be the same, but I might cut out the very worst cases by introducing more intermediate reconstructions. I'll probably look into this options as well!
  • Advertisement