Jump to content
  • Advertisement
Sign in to follow this  

Conceptual Question On Separate Ps/vs Files

This topic is 864 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi all,
During my journey to go away from effects11 to own shader management, there's something I don't understand.

Effect files/FX:
- contains vertex and pixel shader (functions)
- contains constant buffers which can be used by the VS, PS (and GS etc)
- contains techniques which pick variants of combinations between the shaders

Now from what I understood, I will create separate files for my vertex and pixel shaders. So far so good.

But what do I do with constant buffers that are used by both the PS and VS (for example a CB per frame)?

- do I include the exact same CB definition in both the VS file and PS file?
- is 1 enough? And will the HLSL compiler accept that the CB is not defined in the shader file?
- do I need to create separate CB's for the PS and VS? I hope not, because the counter that goes to 14 will raise quickest that way.
- .... Other/ better option?

Any input is appreciated.
Note; I'm using VS 2013 community as IDE, which can compile all shaders for me using FXC under the hood.

Share this post

Link to post
Share on other sites

Hodgman pretty much covered everything I just have one more thing to add:


You don't have to use separate files for PS/VS if you don't want to -- you can specify which function is the entry-point of the shader, and compile the same file twice using two different targets (ps/vs) and two different entry points (ps_main, vs_main, etc). Personally I like to keep them in the same file.
You can also use #include to pull code from other files into the one that's being compiled.

I'd like to keep them too in the same file, but keep in mind if you're aiming at cross platform some day (i.e. OpenGL + GLSL); in GLSL you must declare the vertex and pixel shaders in separate files. Although you can also use macros to workaround, i.e.

void main()
vec4 main()
    return vec4( 1.0, 1.0, 1.0, 1.0 );

Share this post

Link to post
Share on other sites

Thanks guys, this clears things up and makes me feel prepared for the next step :cool:


Some thoughts

- for practice I'll first go for a basic VS and PS in one file

- with an include for the CBuffer(s)

- like hodgman said, I'll go for assuming 14 CB's in total, not per stage

(this also suits my 1st attempt of my CBuffer class, keeping track of a register/ slot number per CBuffer object, which wouldn't work if they differ per stage)


I'll also dig into HLSL debugging in Visual Studio (2013, community), which should be possible, although I didn't manage to get it working yet.


A last question;

When I create new items/files in VS, it gives me the following options (and some more on DS, HS, GS, CS etc.):

- HLSL Header file (.hlsli)

- Pixel shader file (.hlsl)

- Vertex shader file (.hlsl)


For the individual VS and PS files it's clear :)

I assume that for a combined VS/PS file I can/ should also use the .hlsl file exension.

What would be the best way to go for, for the CBuffer header and other files I will #include? (like light and material structs etc.)

(just .hlsl or .hlsli or different?)


Probably any extension will work technically, but I'd like to do things right at once, so what's best practice?

Share this post

Link to post
Share on other sites

You can use whatever extension you'd like, the compiler doesn't care. Personally I like to use .hlsl for all files containing shader code, but that's just preference. Putting shared structure and constant buffer definitions in a shared header file is definitely a good idea, since it will ensure that if you change a structure all of the shaders will see that change.

Share this post

Link to post
Share on other sites

To illustrate that you can use any extension you like, I actually use .cgfx for HLSL files that will be compiled, and .h for included HLSL files :o

(for legacy reasons :P)

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!