This new extension in its current form allows two new changes that relax this requirement to make re-use and organisation of shaders at runtime easier for developers, to paraphrase the spec it allows developers to “mix-and-match” stages to create more flexible shader pipelines.

Seperable Programs

The first change is that a SP doesn’t need to have both vertex & fragment shaders bound at link time for it to be considered valid, however this means that an SP that only has either a vertex shader or fragment shader bound (and not both) may not be consdered “complete” in a semantic sense; as-per the spec, using a SP that is missing a stage will produce results that are undefined for the missing stages.

Setting a SP to be “seperable” is done by setting it’s GL_PROGRAM_SEPARABLE_EXT parameter to GL_TRUE (just before linking):

glProgramParameteriEXT( shaderProgramId, GL_PROGRAM_SEPARABLE_EXT, GL_TRUE );

otherwise the SP object behaves as per the unextended spec, i.e. both the vertex and fragment stages must be specified before linking the SP.

SIDE NOTE: The glCreateShaderProgramvEXT API is provided to greatly reduce boilerplate and simplifies creation of a seperable shader, and should be your preferred way of creating seperable SP’s.

Program Pipeline Object

The second offering of this extension is the Program Pipeline Object (PPO). After linking a set of SP’s these are consolidated and named by a PPO to allow you to bind a permutation of SP’s using one named OpenGL object – the PPO. The PPO also allows uniforms to be set while bypassing the currently bound program object. The glProgramUniform* set  of functions take a PPO name as an argument, and the program to apply the uniform to.

GLSL level attribute binding

Supplemental improvements to the GLSL model included in this extension are the ability to set (and override application set) vertex attribute stream locations in GLSL source text. Without this extension, developers currently have to know the attribute identifier used in GLSL code to correctly bind it at runtime e.g.:

// GLSL code:
attribute vec4 myPostion;
attribute vec3 myNormal;
void main() { ... }

// Application Code:
const int POSITION_ATTRIB_INDEX = 0;
const int NORMAL_ATTRIB_INDEX = 1;
...
glBindAttribLocation( prog, POSITION_ATTRIB_INDEX, "myPosition" );
glBindAttribLocation( prog, NORMAL_ATTRIB_INDEX, "myNormal" );
...
glVertexAttribPointer( POSITION_ATTRIB_INDEX, ... )
glVertexAttribPointer( NORMAL_ATTRIB_INDEX, ... )
...

When the EXT_seperate_shader_objects extension is available, the location index can be specified in shader source text, and also takes precedence over any glBindAttribLocation calls in application code, the above code is simplified by not needing the glBindAttribLocation calls and few changes in the GLSL text e.g.:

// GLSL code:
#extension GL_EXT_separate_shader_objects : enable
layout(location = 0) attribute vec4 myPostion;
layout(location = 1) attribute vec3 myNormal;
void main() { ... }

// Application Code:
const int POSITION_ATTRIB_INDEX = 0;
const int NORMAL_ATTRIB_INDEX = 1;
...
glVertexAttribPointer( POSITION_ATTRIB_INDEX, ... )
glVertexAttribPointer( NORMAL_ATTRIB_INDEX, ... )
...

The main caveat to this is while is simplifies application code, developers will need to be consistent across several shader files for attribute location binding, though this isn’t hard and any conflicting layout(location) indexes will cause a GLSL-linker error.

Example Usage (C++)

const GLchar* VertexProgramCode =
{
  //tell the driver we need to enable particular GLSL extensions
  //note that the \n is important here
  "#extension GL_EXT_separate_shader_objects : enable\n" 

  //use the layout(location) syntax extension
  "layout(location = 0) attribute vec4 position;"
  "uniform mat4 mvp;"
  "uniform vec4 custom_color;"
  "varying lowp vec4 color;"

  "void main() {"
  "  color = custom_color;"
  "  gl_Position = mvp * position;"
  "}"
};

const GLchar* FragmentProgramCode =
{
  "varying lowp vec4 color;"
  "void main() {"
  "  gl_FragColor = color;"
  "}"
};

class Effect
{
protected:
  void log_status(GLuint prog)
  {
    int len(0);
    const bool is_ppo(glIsProgramPipelineEXT(prog) == GL_TRUE);
    //if this looks odd, it's just an ternary function pointer select
    (is_ppo ? glGetProgramPipelineivEXT : glGetProgramiv)(prog, GL_INFO_LOG_LENGTH, &len);
    if( len > 0 ) {
      GLchar log[len];//gcc extension: non-const array size
      (is_ppo ? glGetProgramPipelineInfoLogEXT : glGetProgramInfoLog)(prog, len, &len, log);
      std::cerr << log << "\n";
    }
  }

  GLuint m_vp;
  GLuint m_fp;
  GLuint m_ppo;

  //vertex program variable locations
  GLint m_mvp_location;
  GLint m_custom_color_location;

public:
  float m_mvp[16];
  float m_custom_color[4];

  Effect() : m_vp(0), m_fp(0), m_ppo(0)
  {
    //identity
    for(int i=0; i<16; ++i)
      m_mvp[i] = (i%5==0)?1.0f:0.0f;

    //default to red
    m_custom_color[0] = 1;
    m_custom_color[1] = 0;
    m_custom_color[2] = 0;
    m_custom_color[3] = 1;
  }

  ~Effect() {
    unload_all();
  } 

  bool load_shaders()
  {
    //in a well designed system you would pick these out of an e.g. vertex/fragment effect pool
    m_vp = glCreateShaderProgramvEXT(GL_VERTEX_SHADER, 1, &VertexProgramCode);
    log_status( m_vp );

    //bind the vertex program variables we need
    m_mvp_location = glGetUniformLocation( m_vp, "mvp");
    m_custom_color_location = glGetUniformLocation( m_vp, "custom_color");
    assert(m_mvp_location > -1);
    assert(m_custom_color_location > -1);

    m_fp = glCreateShaderProgramvEXT(GL_FRAGMENT_SHADER, 1, &FragmentProgramCode);
    log_status( m_fp );

    //generate and construct our PPO
    glGenProgramPipelinesEXT(1, &m_ppo);  

    //this is where you would "mix-and-match" using the bitmask
    //in the 2nd parameter
    glUseProgramStagesEXT(m_ppo, GL_VERTEX_SHADER_BIT_EXT, m_vp);
    glUseProgramStagesEXT(m_ppo, GL_FRAGMENT_SHADER_BIT_EXT, m_fp);

    glValidateProgramPipelineEXT(m_ppo);
    log_status( m_ppo );

    int status(0);
    glGetProgramPipelineivEXT(m_ppo, GL_VALIDATE_STATUS, &status);
    if( status == 0 )
      std::cerr << "unable to create program pipeline\n";
    return status != 0;
  }

  void unload_all()
  {
    glUseProgram(0);
    glBindProgramPipelineEXT(0);
    glDeleteProgramPipelinesEXT(1, &m_ppo);
    glDeleteProgram(m_vp);
    glDeleteProgram(m_fp);
  }

  void bind_pipeline()
  {
    assert(m_ppo);
    glBindProgramPipelineEXT(m_ppo);
    glProgramUniformMatrix4fvEXT(m_vp, m_mvp_location, 1, 0, &m_mvp[0]);
    glProgramUniform4fvEXT(m_vp, m_custom_color_location, 1, &m_custom_color[0]);
  }
};

• Correct SDK root
• “Header Search Paths” (Project Settings)
• “User Header Search Paths” (Project Settings)
• “Always search user headers” (Project Settings)

But there is one more element that will throw a spanner-of-confusing-impending-doom into the works: Header Maps.

This nifty and undocumented feature is basically a dictionary of all the filenames in your project (just the filename, not a fully qualified path), supposedly to speed up building, but it definitely gets in the way (in a big way) sometimes.

To keep a long story really short, if your build looks like the header search paths are very confused for example #include <math.h> actually includes a file in your project named Math.h regardless of folder depth that resides somewhere in your project (you can check this using  ”Build” > “Preprocess” and check which files its actually #included’ed)

Project > Edit Project Settings > (Cog Button Bottom Left) > Add User-Defined Setting

Name the setting USE_HEADERMAP and set its value to NO (EDIT 24/11/11: this was incorrectly USE_HEADERMAPS – should not be plural, thanks Simon for pointing this out)

Now all header includes MUST be relative to the file they are included from OR be explicitly relative from any of your specified header search paths.

More reading provided below:

http://web.archiveorange.com/archive/v/JT06F65y3o5h2vjWtjBo

http://www.openradar.me/7840694

http://www.omnigroup.com/mailman/archive/macosx-dev/2005-March/056049.html

http://stackoverflow.com/questions/2596695/controlling-which-project-header-file-xcode-will-include

Excuse the keyword dump here, it was hard to find this out so I hope this will help others looking:
cannot find correct system headers, header path order, include path order, search path order, Xcode include file quotes, header maps, hmap, import directive, include confused, incorrect include search path

dscl /Local/Default -list /Users UniqueID

I’m sure altering the last “UniqueID” value (as it’s referred to as a ‘key’) will yeild more interesting info, this is left as an excercise to the reader

The fix was the most paintfully simple addition to the Postfix main.cf, highlighted bold. This fix seems to only apply to Ubuntu based environments and means that the smtpd daemon will actually pay attention to the contents of /etc/postfix/sasl/smtpd.conf

smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_application_name = smtpd
broken_sasl_auth_clients = yes


more reading: http://ubuntuforums.org/showthread.php?t=297462

I thought about how I could get around this and have the Solution Explorer folders mirror the filesystem, first obvious option was write a shell script or macro to do it. So I fired up VS macro explorer and lo-and-behold theres a Sample macro which ships with VS called “AddDirAsSlnFolder”.

Looking very promising I checked out the source code, and sure enough it does exactly what I needed. The only thing I had to do to get it working exactly right was add “.svn” to the exclusions list (this is down the bottom of the source file and should be clearly visible next to all the other exclusions in the list)

Enjoy.

error C3163: '_vsnprintf': attributes inconsistent with previous declaration

the last post in this thread clarifies how this error arrises in common practice. To get it to compile I commented out these lines:

• FUtils\Platforms.h:145
• LibXML\config.h:92
• LibXML\include\win32config.h:90
• DLLEntry:40 (this one was just a missing symbol or something deprecated in new the PSDK shipping with VC9, the case statement is empty so commenting it out should have no effect)

I should clearly note that I haven’t tested it (running etc.), I simply got it to build to help save our tools guy a bit of time. I should also note that the Unit Tests (FColladaTest) project builds but returns about 60 linker errors. I just thought I’d post here to save someone a bit of hassle if they should run into this error.

FCollada version was 3.05B Win32

-Danu

Vec3 maxValue, minValue;

ofcourse the default constructor would initialize both vectors to [0,0,0]. This is useless when trying to determine a bounding box which lies entirely in the negative part of all axies (because no vertex in that area will ever excede maxValue, which has incorrectly been initalized to zero). The fix was simple, but it reminded me of another C/C++ quirk over numeric limits.

The fix, one would think, would be something like this:

const float FLOAT_HIGHEST = std::numeric_limits<float>::max();
const float FLOAT_LOWEST = std::numeric_limits<float>::min();
Vec3 maxValue(FLOAT_HIGHEST, FLOAT_HIGHEST, FLOAT_HIGHEST);
Vec3 maxValue(FLOAT_LOWEST, FLOAT_LOWEST, FLOAT_LOWEST);

But, you’de be wrong. If you were using numeric_limits<int> that would work fine, but numeric_limits<float>::min acutally returns the lowest representable positive float (this is to help calculate another issue with IEEE floats see: http://en.wikipedia.org/wiki/Denormal).

Boost provides a clean solution for this in their “bounds” package.

I’m tempted to just go “-numeric_limits<float>::max()” (that is pretty much what the boost code will compile down to) but I like consistency, and I don’t want to worry about any (if any exist?) unmatched upper and lower values like 32 bit signed ints have, I’m no float expert…

In C++, it turns out function-call arguments are not guaranteed by the standard to be evaluated in the traditional “left-to-right” order. Instead, it’s totaly implementation defined, and I’ve found that on VC++ (2k5) its as you would expect about 90% of the time, but there are certain situations where the compiler decides to mix things up.

the problem was noted in this piece of code:

Vec3 boundsMin( reader.readF32(), reader.readF32(), reader.readF32() )

the compiler translated it into something along these lines:

call readF32  /* stores the result in ecx */
push ecx
fstp dword ptr [esp]
call readF32
push ecx
fstp dword ptr [esp]
call readF32
push ecx
fstp dword ptr [esp]
lea [boundsMin]
call Vec3::Vec3

notice how the store instruction “fstp” always writes to the memory location specified by esp? now the assembly generated for Vec3 constructor’s uses the “rep stos” instruction to “block copy” the contents of the location esp refers to. Initially, all this code looks like it happens how you would expect: “left-to-right” but the reason it doesnt work as expected is because the “push” instruction is decrementing the value in esp by 4 and writing the value of the operand to the top of the stack every time its called.

What does this mean? in simple terms, yes, the reads happen in the order A,B,C but the resulting values are written into the stack-frame effectively backwards C,B,A (I say effectively because the “rep stos” instruction reads from lower memory to higher memory, but C was written to lower memory (because it was written last, hence esp would be at its lowest value), B in higher memory after C and A in even higher memory after B). This is where the non-guaratee by the standard comes into play, the only reason the compiler does this is because there is no requirement to do otherwise. hence all the values for this particular vector were having their x and z values swapped consistently in “Debug” generated code.

Fun times.

Oh and the lesson from all this: don’t inline function argument-expressions which have dependent reads. e.g. reading from streams.

For more reading: http://www.embedded.com/story/OEG20020429S0037
and: http://compilers.iecc.com/comparch/article/95-07-089

The last few years working with Java in the industry has given me a little bit of insight on producing quality software over software that just does what it’s supposed to, this is the “relearning” I refer to.

The new project has been written in a unit-test centric manner, that’s not to say its TDD nor has it 99% code coverage, but unit-test are part of the center stage. Additionally, we are making good (not over-the-top) use of the collection of powerful Boost libraries, and using these meta-programming/template heavy libraries has definitely learned me a thing or two about C++ – I guess that’s the thing about C++, no matter how long you’ve been using it effectively, there’s just so much to know and there are always those “ahhh-haa [forgot about that!!!]” moments and I guess for me this makes things a bit more challenging, but a little bit more fun (but probably not as productive as it could be).

I wrote the unit testing framework for our project, quite a simple suite/runner system. The system has been valuable for us as a  2-man-decentralised-after-hours-team (2MDAHT) – basically self documentation for code and use-cases and full regression testability, which when communication is not as often as we’d like it, is a great way to make sure we’re always taking two steps forward and none back.

The system is also written thread-safe from the ground up, the unit tests and our design-test-implement-test  philosophy allow us to see deadlock situations during the design-test phase and then during implementation allow us to more easily replicate and fix deadlocks by drastically narrowing the window of code which could be causing the problem.

If you had asked me 2-3 years ago whether unit-testing C++ code was worth it, I would’ve almost certainly would have said “no” or at best “it depends”, today I would go so far as to say it would be a “must” (however I do appreciate the feeling of impending doom when faced with retro-fitting legacy C++ for unit testing).

This reminded me that I had Weve 2.0 sitting around on my HDD gathering dust. So I’ve put the binaries up in a ZIP file, and I have applied to have a source forge page created to host/manage the project’s source code. At some stage I’ll update the MSI installer project and stick that version up too.

Hope people like the 2.0 improvements, alot of handy features that make WEVE 2.0 even easier and more intuitive to use than 1.5.

Get it from the WEVE page