This is a patch that uses GLSL for vertex shaders instead of CG in the OpenGL plugin. It doesn't work yet, it's just a bunch of black screen. I am probably going to need help fixing it. I included debugging code that prints to stderr. There are some errors sometimes, I haven't narrowed down exactly where they are coming from.
I have my graphics settings set to disable Dest Alpha Pass, lighting, and fog. These settings still show a nice picture with the OpenGL/CG plugin, and this way I don't have to convert as much code and will minimize the possible sources for errors.
I'm not sure that I mapped all of the varying variables correctly, and I'm not sure that the fragment shader is getting them all. That's next on my list to test.
After this patch is applied, you can still build the OpenGL/CG shader by commenting out #define GLSL 1 in GLUtil.h.
Recently gDEBugger became free to use, I just checked it out yesterday and I was pretty impressed. It can probably help you a lot with debugging.
FWIW, won't it slow down stuff quite a bit if you call glGetUniformLocation everytime in SetVSConstant4fvByName & co?
Also, it's a bad idea to keep two shader generators for HLSL and GLSL... you should try to keep both in one file, maybe using macros or sth. Shouldn't really be THAT hard.
Apart from that nice work, hope this will reach a working state some time
(01-26-2011, 08:17 AM)NeoBrain Wrote: [ -> ]FWIW, won't it slow down stuff quite a bit if you call glGetUniformLocation everytime in SetVSConstant4fvByName & co?
It might. I want to get a picture before I worry too much about performance, though.
(01-26-2011, 08:17 AM)NeoBrain Wrote: [ -> ]Also, it's a bad idea to keep two shader generators for HLSL and GLSL... you should try to keep both in one file, maybe using macros or sth. Shouldn't really be THAT hard.
We discussed that on IRC, and I thought it was a great idea to put them both in the same function until I actually tried it. Some things would be easy, like setting a FLOAT4 constant that would be "float4" in CG and "vec4" in GLSL. But for the most part the languages are very different. At least half of the function would be if glsl, write a bunch of lines, and if else, write a bunch of completely different lines.
Another problem is that I can't test the DirectX plugins. For example, the current shader generator uses this line to declare a struct: "typedef struct { float4 t; } FLT4;" In GLSL, typedef is a keyword reserved for future use, and it is an error to use it. So the struct has to be declared like so: "struct FLT4 { float4 t; };". I think this would work fine in HLSL and CG, but I can't test it for HLSL. This is only an example.
Also, putting both shader generators in the same function would be more intrusive, and I would have to be very careful not to disrupt the working shaders. This would be an extra challenge without being able to actually test the HLSL half of the shader generator function. And I like being able to open both files and look at the two functions side by side.
(01-26-2011, 08:17 AM)NeoBrain Wrote: [ -> ]Apart from that nice work, hope this will reach a working state some time
Thanks.
Seriously, we definitely don't want two different shader generators, that'd be mantainance hell. I for sure won't give my okay to anything like that...
Just explain what kept you from doing it in one function, I'm sure there's a way to solve it. Anyway I guess it would be better not to implement a GLSL generator in one patch since as you said it might break the hlsl stuff => better split that work in multiple patches.
OK. Here's a new patch, with both vertex generators in one function. It wasn't as tough as I made it out to be. I can't test it with DirectX, but I have tested it with OGL/CG and it works fine.
Thanks, shuffle2, for the advice on the debugger. It seems that it doesn't do much for GLSL, which is unfortunate because that it mostly what I'm working on, but it has helped me to get rid of the compiler errors and warnings, and I think it will continue to help me out a bit in the future.
I separated GLSL from CG/HLSL in GenerateVertexShaderCode by using ifdefs. For example, #ifdef USE_GLSL #define FLOAT4 "vec4" #else #define FLOAT4 "float4" This allows us to write lines like so:
WRITE(p, FLOAT4" myvec = dot(...;\n");
rather than using variables adjustable at run-time, which would require writing like so:
WRITE(p, "%s myvec = dot(...;\n", float4_str);
Putting the type specifiers at the end would be tougher to read, especially considering that many of these lines go past the edge of the screen. Fortunately, VertexShaderGen.cpp is included in each plugin, rather than being included in the exexutable, so we can define USE_GLSL for the OGL plugin and not define it for the D3D plugins. I haven't done this yet, instead opting for a hack that requires that anybody who installs this patch can only disable glsl and compile D3D plugins by commenting out the #define USE_GLSL line in VertexShaderGen.cpp, and to disable GLSL in a OGL plugin you would have to comment out #define USE_GLSL in both VertexShadergen.cpp and GLUtil.h. Finding a better solution is on my todo list before committing and I think I know how I am going to do it.
I believe that the GLSL vertex shader is now properly cached, using the mechanisms in VertexShaderCache.cpp.
There is still no picture.
imo, CGSL is the more versatile shader language (GLSL is crap ATI fed to ARB after Microsoft ditched them, and ARB rejected the more capable CGSL in spite)
I'm here to help, not argue with trolls.
He has a point though.. What's the advantage of using glsl over cg anyway?
The advantages of open source over closed source is not an appropriate topic for this thread. I started this thread in the Code Patches forum for the purpose of sharing my progress on a GLSL video plugin for Dolphin, and for soliciting help. Since open source vs closed source and GLSL vs CG isn't even really specific to dolphin, I believe a more appropriate forum would be Delphino Plaza.