Slick Forums

Yes -- org.newdawn.slick.shader is obsolete and incomplete.

Sorry liam -- not trying to "take over" your work. If you want to see specific changes/features to my design I'm open to suggestions. Also if you have any criticisms about it then let me know.

@davedes Hey, its completely fine. I've realised now the benefits of your implementation.

I've been reading about "stitching" GLSL shaders together as we're trying to allow with our utility class (i.e. attaching multiple shaders of the same type).

Here are a couple of posts I found about it:


Source: http://www.idevgames.com/forums/thread- ... l#pid37881




Source: http://www.opengl.org/discussion_boards ... Post252512

All of that, and the fact that it doesn't work at all in OpenGL ES, leads me to wonder why we are going to all this trouble in the first place. It might be better to just allow for one-to-one (one vertex, one fragment) to ensure good practice and OpenGL ES compatibility.

Thoughts? I'm all for minimizing clutter. Besides; how many users will actually need to use this? And if they are that advanced, they will probably be better off pre-processing the source to allow for custom "import/include" statements (which I'm gathering is the way many big game companies do it).

We can still allow the design to separate shader compiling / linking process -- for advanced users who want to catch the errors separately.

I guess one vertex shader plus one fragment shader is okay. But we NEED a TestCase for something like horizontal Blur and vertical Blur. I still have issues on how to make it possible to add more then one effect for a postprocessing effect... But as I can see there is no way but to make one source file which implements all the functions :/

I will use them for sure btw. For wave animations and stuff like that

_________________
Current Projects:
Mr. Hat I
Vegan Vs. Zombies
Projects:
RadicalFish Engine - Build on top of Slick2D, Ideas, Bugs? Open an Issue ticket!

Pushed ShaderTestAdvanced which shows a simple way to achieve horizontal/vertical blur. Used this tutorial:
http://www.gamerendering.com/2008/10/11 ... er-shader/

The code is a bit messy -- I'll have to clean it up a little.

I guess we can't hide away the messy code for shaders. For blur I once had another shader which was for backgrounds and works with one pass (without the downside of the texture samplings.

_________________
Current Projects:
Mr. Hat I
Vegan Vs. Zombies
Projects:
RadicalFish Engine - Build on top of Slick2D, Ideas, Bugs? Open an Issue ticket!

i'd be interested to see that. generally speaking blurring in a single pass requires more texture lookups (via texture2D) than blurring in two passes, but i'm sure there are a variety of blur techniques that I'm overlooking...

Here you go:
http://pastebin.com/EMB1n2ay

I'M not exaclty sure who it works but it blur pretty well (Could not find out ho to change the the strengh of the blur). I don't even know where I have this code from xD

_________________
Current Projects:
Mr. Hat I
Vegan Vs. Zombies
Projects:
RadicalFish Engine - Build on top of Slick2D, Ideas, Bugs? Open an Issue ticket!

From what I gather online and in IRC channels it's not worth the trouble to have "reusable" shaders, or having multiple shaders attach to the same program. Especially because there is no performance/memory benefits of separating shader and program creation: all of the compiling is done when you link the programs. Also this is likely to introduce problems on certain drivers that don't fully support it. I will include a static validate method for users who want to validate a shader without having to create a new program.

Unless anybody strongly feels that they need "reusable" shaders, I will revert to my first draft (no Shader class, just a ShaderProgram which attaches and links everything on construction).

EDIT: Deleted Shader, made ShaderProgram all you need. Advanced users who want to handle compile/link/attach separately can override the empty constructor and use the protected methods.

The only advantage I can see, if I understand everything correctly is that you could implement the Shader as DeferredResource. So the sources of the shaders can be load by any thread during the loading process but the linking is done is the thread that controls OpenGL.

I have no clue how long it takes to compile the shaders. Is it possible to read compiled shaders back and store them as a sort of cache for the local maschine?

Other then that... I "like" the current implementation. My subjective impression of it. Its a nice clear and exspecially selfexplaining structure. In case there are no major disadvantages I would keep it as it is.

Nitram

_________________
http://illarion.org

Couple issues:

• Shaders need to be compiled in the OpenGL thread (same with creating textures) EDIT: nevermind, this is not true
• It appears to be driver-specific whether anything is actually compiled on glCompileShader. On various NVidia cards, glCompileShader only does a brief syntax check; the actual compilation of the shader is not done until glLinkProgram (i.e. there is no significant benefit in deferring glCompileShader, or re-using shader objects).

A very rough benchmark: my machine takes ~35 ms to compile the rather complex 'apple shader':
http://www.geeks3d.com/20111123/procedu ... e-in-glsl/ (compare to ~350 ms to load a 512x512 image)

In terms of caching -- the GL_ARB_get_program_binary extension lets you access the compiled binary code, though IMO we should let that be up to the developer.

In any case, allowing ShaderProgram to be deferrable is a good idea.

Did you benchmark only the compiling operation or loading the source from the filesystem and compiling? I ask because looking over your code I notices that you used a VERY slow method of loading text files.

Regarding the storage of compiled shaders:
You have a better look into the whole shader handling so is it a option to add functions like:



That could handle loading and saving the compiled shaders in a simple and easy way?

Nitram

_________________
http://illarion.org

Fair point -- I tweaked my benchmark and got results that looked more like this:


The file reading uses the same technique as the rest of Slick -- which admittedly could be made much more performant. Feel free to post some alternatives.


Unfortunately I can't test it here since it requires the GL_ARB_get_program_binary extension which is not present on my machine. i.e. It won't even work for me... iMac 10.6.6 + NVIDIA GeForce 9400.

I'm looking into the multiple thread context thing a little more -- it seems possible, so I shouldn't rule it out yet. I'll look into it a bit more tomorrow.

Loading is not import imho. If you look on games you often see that shaders are compiled and linked at game start. Benchmarking loading time is imho not as important as FPS, meaning how fast works the shader.
Anyway, I'm okay with all. Seems like having a Shader class is really useless xD I thought it might be a good idea but well

If the extension does not work for you it's possible that it does not work on other pc too So I say drop that since I really think if a dev wants something like this he can make it himself just like most of us create their own Ressoure class for ref images/sounds etc.

_________________
Current Projects:
Mr. Hat I
Vegan Vs. Zombies
Projects:
RadicalFish Engine - Build on top of Slick2D, Ideas, Bugs? Open an Issue ticket!

Loading time is not important if it is about loading in 1 second or loading in 0,5 seconds.

But for larger projects with a real load of resources where the loading time hits 30 seconds when unoptimized, improving the loading time has significant advantages for the user experience.

As for things like loading files... I do not know how often this is done in Slick, but it might be a option to use something like Apaches Apache common IO 2. The apache license should be compatible with the Slick2D license and this library is widely used, stable and actively maintained. And it makes loading stuff REALLY easy.

For this case it would be:


I benchmarked this loading a file from filesystem using the Slicks current method and the apache common IO library with a 1,2 MB lorem ipsum file.

• Slick: 10 237ms
• common IO: 17ms

We can surely implement those functions we need ourselves... but at some point its the question if we really want to reinvent everything. And this library is one of those that is unlikely to disappear in the years to come.

Nitram

_________________
http://illarion.org