I found that strange. What version of GLSL the drivers report ?
"glxinfo| grep shading"
Found that list for better understanding the version. You will notice in the end they make somethings finally understandable
* OpenGL 2.0 - GLSL 1.1
* OpenGL 2.1 - GLSL 1.2
* OpenGL 3.0 - GLSL 1.3
* OpenGL 3.1 - GLSL 1.4
* OpenGL 3.2 - GLSL 1.5
* OpenGL 3.3 - GLSL 3.30
* OpenGL 4.0 - GLSL 4.00
I thinks It is better to at least declare the version 140. But deprecated stuff must be fix.
~ # glxinfo| grep shading
OpenGL shading language version string: 3.30 NVIDIA via Cg compiler
GL_ARB_shading_language_100, GL_ARB_shadow, GL_ARB_sync,
Which seems reasonably up to date.
And yeah, the depreciated variables should be taken care of. That was gl_FragData, gl_Color, gl_FragColor, and gl_TexCoord, IIRC.
First, version parameter was set in ZZoglShadersGLSL.cpp, change it (all 3 instance) for 130 -- sampler2DRect appear in 1.3 manual. Second, deprecated FragData and TexCoord is own OpenGL consortium trouble -- everybody use them. And although I really could use variable instead texCoord, I don't know how to change FragData (it's value are passed in binded buffers, so we could made alpha, depth testing and so on). FragColor should be removed by FragData[0] and I don't use it. gl_Color is not deprecated. At least in last manual I have (february 2010) gl_Color was not. And I hope it never be.
p.S. Working revision is r235 (it have one minor, but important change -- I forget to set initialised status to g_fPosXY variables, so only static picture -- load from quicksave -- was working). And check shader's file itself -- was a new copy made when ZZogl was built?
Well for the moment the goal is to have a fully working GLSL implementation. Deprecated stuff are not important, they could still be used with a compatible profile anyway. It could still be improved later. For information, do not know if it is related, but they create VBO things (stand for Vertex Buffer Object). Seem to replace some deprecated stuff. Maybe it can help you.
http://www.songho.ca/opengl/gl_vbo.html
http://www.opengl.org/wiki/Vertex_Buffer_Object
Ps: could you also add some copyright info into new files (ps2glsl.fx etc...) Thanks
No, FragData is from fragment shader, it's texture "layer".
What is the status of the RenderFormatType ? For the moment it is constant to RFT_byte8.
GetRenderFormat() is probably call a lots of time. RESOLVE_32_BIT have a loop that call Pitch which call GetRenderFormat(). Inline this small function will save some cpu cycle (in this case must be move into a .h). Moreover it can directly return RFT_byte8 so GCC can perform extra optimization (in particular it reduces the plugin by 12kBytes)
Code:
Index: pcsx2.snapshot-3767/plugins/zzogl-pg/opengl/zerogs.h
===================================================================
--- pcsx2.snapshot-3767.orig/plugins/zzogl-pg/opengl/zerogs.h
+++ pcsx2.snapshot-3767/plugins/zzogl-pg/opengl/zerogs.h
@@ -476,7 +476,12 @@
// call to load CLUT data (depending on CLD)
void texClutWrite(int ctx);
-RenderFormatType GetRenderFormat();
+// RenderFormatType GetRenderFormat();
+inline const RenderFormatType GetRenderFormat() {
+ // Zeydlitz: we don't support 128-bit targets yet. they are slow and weirdo
+ // return g_RenderFormatType;
+ return RFT_byte8;
+} //zz
GLenum GetRenderTargetFormat();
int Save(s8* pbydata);
Index: pcsx2.snapshot-3767/plugins/zzogl-pg/opengl/ZZoglFlush.cpp
===================================================================
--- pcsx2.snapshot-3767.orig/plugins/zzogl-pg/opengl/ZZoglFlush.cpp
+++ pcsx2.snapshot-3767/plugins/zzogl-pg/opengl/ZZoglFlush.cpp
@@ -207,7 +207,7 @@
extern CRangeManager s_RangeMngr; // manages overwritten memory // zz
void FlushTransferRanges(const tex0Info* ptex); //zz
-RenderFormatType GetRenderFormat() { return g_RenderFormatType; } //zz
+// RenderFormatType GetRenderFormat() { return g_RenderFormatType; } //zz
// use to update the state
void SetTexVariables(int context, FRAGMENTSHADER* pfragment); // zz
You right. I made byte8 (it's mean each colour are present by 8 byte number, so 32 byte per pixel) be default, because even modern drivers does not properly support 16F (each color is half-float, it's more precise, but why do Zerofrog use it? PS2 have not such colour support.
byte8 seems enough for me. Flat panel (affordable) can not render 16F anyway.
Moreover looking at the code. It must be more slower with 16F to resolve targets.