Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 16 Apr 2009
Offline Last Active Dec 11 2014 02:57 PM

Topics I've Started

Multipass rendering with depth compare EQUAL

05 November 2014 - 03:58 PM

I'm doing deferred lighting, where I have a gbuffer pass, followed by a main pass.  For alpha tested objects, I would like to do the alpha test in the gbuffer pass, and then skip alpha test in the main pass by using a depth compare function of EQUAL.  This way the main pass should only render on top of pixels that passed the alpha test during the gbuffer pass.


The problem is that I can't get the depth values to match exactly between passes.  It works sometimes, on some machines, in some situations, but not all the time.  As far as I know, I am passing the exact same data for all verts and relevant shader parameters (matrices, etc).  Each pass has a different vertex shader, but they compute the output position in exactly the same way.  Is there any way to make this work reliably in D3D9?  Or will I just have to use LESSEQUAL in the main pass, with a possible depth bias?

Baking direct lighting into light probe

29 January 2014 - 03:50 PM

I have a typical system for rendering light probes, where I render a cube map at the probe position, and then project the cube map onto SH.  I render the lightmapped world geometry into the cube map, which captures indirect lighting from the lights in the lightmap.


I'd also like to capture direct lighting from the lightmap lights.  To do this, I was thinking I'd render a sphere with the light's color/radius/position in the cube map for each lightmap light.  Is this the right idea?  Am I missing anything?

Visual studio pixel shader debugger

24 November 2013 - 03:31 PM

I'm working with the shader debugger built into visual studio 2013.  As I step through the shader program, the values shown for local variables seem very inconsistent.  They seem correct when the program counter is directly after the statement in question.  As I step through, variables set on previous lines tend to show up as NAN.  The shader itself seems to be working, it's just a display problem in the debugger.  I'm compiling all my shaders with "D3DCOMPILE_DEBUG | D3DCOMPILE_PREFER_FLOW_CONTROL | D3DCOMPILE_SKIP_OPTIMIZATION".  Is this just a limitation of the shader debugger, or am I missing something?

Beginning D3D11, missing pixel shader

09 November 2013 - 03:24 PM

I'm just starting out with D3D11, trying to port an existing OpenGL game to D3D11.  Using the graphics debugger built into vs2013, I can see that I'm passing correct geometry into the input assembler, and it appears that I'm getting valid output from the vertex shader.  After that, it skips right to the output merger.  The pixel shader isn't being run, despite being set.


I'm not getting any errors or warning from the debug runtime.  I've disabled backface culling.  I have a valid viewport set.  I'm feeling pretty stumped at this point.  Anybody have any idea of what else I should look at?


This is my vertex shader:


cbuffer uniform_TransformState

    float4x4 param_Transform : packoffset ( c0 ) ;
    float4 param_Texture0Transform : packoffset ( c4 ) ;
    float4 param_CameraPosition : packoffset ( c5 ) ;
uniform SamplerState uniform_ColorTexture_State ;
uniform Texture2D uniform_ColorTexture ;
struct SagaAttributes
    float4 attr_Position : POSITION ;
    float2 attr_TexCoord0 : TEXCOORD0 ;
    float4 attr_Color : COLOR0 ;
struct SagaVarrying
    float2 var_TexCoord0 : TEXCOORD0 ;
    float4 var_Color : COLOR0 ;
float2 TextureTransform ( float2 attr , float4 transform )
    return attr . x * transform . xy + attr . y * transform . zw ;
void main_vert2 ( in SagaAttributes __attribute , out SagaVarrying __varrying , out float4 __position : SV_Position )
    __varrying . var_TexCoord0 = TextureTransform ( __attribute . attr_TexCoord0 , param_Texture0Transform ) ;
    __varrying . var_Color = __attribute . attr_Color ;
    __position = mul ( param_Transform , __attribute . attr_Position ) ;


This is my vertex shader output:


Thread synchronization, waiting for multiple jobs

10 May 2013 - 01:02 AM

I often find myself writing code where I want to kick off a bunch of jobs, and then wait for them all to complete.  I've come up with something like this:


int pendingJobCount = 0;
Event jobsComplete( true );

void AddJob()
	int newCount = InterlockedIncrement( pendingJobCount );
	if( newCount == 1 )

void FinishJob()
	int newCount = InterlockedDecrement( pendingJobCount );
	if( newCount == 0 )

Assert( pendingJobCount == 0 ); 

This seems to work, but I'm curious if this is a standard way of doing things, or if there's a better technique.  Is there a more traditional synchronization primitive that will accomplish this?