Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 18 May 2001
Offline Last Active Sep 14 2014 07:59 PM

Posts I've Made

In Topic: XNA Stencil Buffer problem, with code

03 September 2014 - 06:31 PM



Very helpful, thank you very much.  Simply put, when I set a new rendertarget I lose the stencil buffers on previous rendertargets.  Is this correct?  So stenciling needs to be done in a multipass inside of a single SetRenderTarget, yes?  What a PITA....

In Topic: XNA Stencil Buffer problem, with code

02 September 2014 - 11:44 AM



You answered with "So you can't set a new render target and use the stencil buffer from a previous one.", and then asked exactly what I was trying to do.  I was unable to come back to this for several days so I started a new thread, including code explaining exactly what I'm trying to do.


Maybe I misunderstand you answer, but I'm not setting a new render target and using the stencil buffer from a previous one.  Are you saying that I need to set the rendertarget, write to the stencilbuffer, and then immediately send the rendertarget to the pixel shader for the comparison operation?  This makes no sense.....you can't send an active rendertarget to the pixel shader, it will error out.  Or do you mean that I can only perform a stencil test on the active rendertarget?  In this case if I lose my stencil buffer as soon as I set the rendertarget, how can stencil buffering be in any way useful at all?  Would I have to create the stencil and perform the comparison test all inside one draw call?  


SO if what I'm trying to do isn't possible maybe I could trouble you to explain exactly how I can do this?  Really all I'm trying to do is mask  certain pixels out of a rendertarget with an early stencil test.....seems pretty simple.  This is driving me nuts, and I've found several other examples of people with pretty much the same problem who haven't found a resolution, or people who made it work in XNA 3 but couldn't make it work in XNA 4.  I found one guy who says you need to use preservecontents on a rendertarget in order to write to the stencil buffer, but still no dice, although my tests do indicate that the stencil buffer is never being written to.    


I can't even find a decent explanation of how stencil buffering works.  I might be conceptually completely out of the ballpark.  For example, I *think* what I'm doing is comparing the stencil buffer of a rendertarget to a simple reference value.  Is this correct?  Am I comparing the contents of the rendertarget stencil buffer to the stencil buffer of the back buffer?, noting that I'm not drawing to the back buffer?  Is drawing to the backbuffer the only circumstance where stencil buffering will work?  


Or maybe you could help me with simple code describing how simple a stencil mask works, that actually does work?  


Much Confusion.  I really appreciate your help.  

In Topic: Recalculating terrain normals

01 June 2014 - 11:09 AM

I'm by no means an expert.  I don't think you need to calculate normals in the shader unless you're terrain is moving every frame, as opposed to the camera moving every frame.  Below is the code I use to get the terrain normals when I initialize new terrain, in C#, which seems to work.  It's not my code, You could probably find a better algorithm for generating the normals, since it doesn't run every frame speed is not a huge factor.    


  private static Vector3 SimpleCrossFilter(int x, int y, ref float[] heightfield,
    float normalStrength, int width, int length)
            // Create four positions around the specified position
            Point[] pos = new Point[]
                    new Point(x - 1, y), // left
                    new Point(x + 1, y), // right
                    new Point(x, y - 1), // higher
                    new Point(x, y + 1), // lower

            // Get the heightvalues at the four positions we just created
            float[] heights = new float[4];
            for (byte i = 0; i < 4; i++)
                // Check if we can access the array with the current coordinates
                if (pos[i].X >= 0 && pos[i].X < width &&
                    pos[i].Y >= 0 && pos[i].Y < length)
                    int j = pos[i].X + pos[i].Y * width;
                    heights[i] = heightfield[j];
                    // If not, then set value to zero.
                    heights[i] = 0;

            // Perform simple cross filter.
            float dx = heights[0] - heights[1];
            float dz = heights[2] - heights[3];
            float hy = 1.0f / normalStrength;

            // Create and normalize the final normal
            Vector3 normal = new Vector3(dx, hy, dz);

            return normal;

In Topic: Vertex Shader unexpected results, bizarre

01 June 2014 - 10:59 AM

This topic is old because I've been involved with other things.  I've seen conflicting info re: use of int's, seems I saw a MS recommendation to use int's to avoid rounding errors.  Regardless, I get better results when replacing ints with floats.   Thanks!

In Topic: Bizarre D3D9 hResult error: "The drive cannot find the sector requested....

20 May 2014 - 06:36 PM

Hi.  Did you run scandisk with both checkboxes checked, or with both the ./F and /R switches (chkdsk /f /r)?  The /R switch, or the bottom checkbox, repairs bad sectors by copying the data to another location and marking the sector so it won't be accessed anymore.  Check your logs after running, if it found any bad sectors run it again and see if it finds anymore.....or if it finds a lot of bad sectors.....replace the drive.  The /R switch may run for a long time depending on how many bad sectors it finds....maybe hours.  BACK UP YOUR HARD DRIVE BEFORE SCANNING WITH /R.....if your boot sector is bad the /R switch can cook your operating system and cause much sorrow.    


Also scandisk isn't 100% reliable, for example it won't find problems with the drive motor, which would still cause errors if it's failing.  If you can't get past your error message you should clone the drive and replace it.  IMO you should replace the drive now.....I'm not a DX expert but I don't think hardware errors are a result of bad code because code never directly accesses hardware, so you can't write any code that would access the hard drive in the wrong way, etc...all of this is negotiated by DX and the bios.  Also if you suddenly have bad sectors then more will probably follow, and keep in mind that you're only seeing bad sectors that your program is trying to access.....there may be many more.  .    


If you're dealing with a drive failure you'll never find the source of the problem until you repair or replace the drive.  If the drive crashes before you replace it recovering will be a lot more difficult, or impossible, or very expensive, so make sure you're backed up.