Slick Forums

Discuss the Slick 2D Library
It is currently Sun Dec 08, 2019 1:02 pm

All times are UTC




Post new topic Reply to topic  [ 63 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
Author Message
PostPosted: Fri Mar 23, 2012 7:50 pm 
Offline
Slick Zombie

Joined: Sat Jan 27, 2007 7:10 pm
Posts: 1482
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.


Top
 Profile  
 
PostPosted: Sat Mar 24, 2012 12:21 am 
@davedes Hey, its completely fine. I've realised now the benefits of your implementation.


Top
  
 
PostPosted: Sat Mar 24, 2012 12:48 am 
Offline
Slick Zombie

Joined: Sat Jan 27, 2007 7:10 pm
Posts: 1482
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:

Code:
Unfortunately, linking multiple shaders together into one program is not often done, and therefore not well-tested. When I tried to do this originally, I had serious issues on both NVidia/Linux and Mac OS X.

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

Code:
GLSL provides for multiple shader objects to be created, assigned GLSL source text, compiled, be attached to a program object, and then link the program object.

NVIDIA’s current driver doesn’t fully compile shader objects until the program object link. At this time all the source for a single target is concatenated and then compiled.

This means (currently) there is no efficiency from compiling shader objects once and linking them in multiple program objects.


Code:
Looks like this is still a bug on ATI. If I try to link together two vertex shader objects, one with main() and another just with a function, I get "ERROR: There was no main in the program." It doesn't matter the order in which I link them.

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.


Top
 Profile  
 
PostPosted: Sat Mar 24, 2012 3:10 pm 
Offline
Game Developer
User avatar

Joined: Thu Mar 03, 2011 6:22 pm
Posts: 534
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:
Image Mr. Hat I
Image Vegan Vs. Zombies
Projects:
RadicalFish Engine - Build on top of Slick2D, Ideas, Bugs? Open an Issue ticket!


Top
 Profile  
 
PostPosted: Sat Mar 24, 2012 6:21 pm 
Offline
Slick Zombie

Joined: Sat Jan 27, 2007 7:10 pm
Posts: 1482
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.


Top
 Profile  
 
PostPosted: Sat Mar 24, 2012 7:23 pm 
Offline
Game Developer
User avatar

Joined: Thu Mar 03, 2011 6:22 pm
Posts: 534
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:
Image Mr. Hat I
Image Vegan Vs. Zombies
Projects:
RadicalFish Engine - Build on top of Slick2D, Ideas, Bugs? Open an Issue ticket!


Top
 Profile  
 
PostPosted: Sun Mar 25, 2012 2:22 am 
Offline
Slick Zombie

Joined: Sat Jan 27, 2007 7:10 pm
Posts: 1482
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...


Top
 Profile  
 
PostPosted: Sun Mar 25, 2012 11:03 am 
Offline
Game Developer
User avatar

Joined: Thu Mar 03, 2011 6:22 pm
Posts: 534
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:
Image Mr. Hat I
Image Vegan Vs. Zombies
Projects:
RadicalFish Engine - Build on top of Slick2D, Ideas, Bugs? Open an Issue ticket!


Top
 Profile  
 
PostPosted: Sun Mar 25, 2012 9:02 pm 
Offline
Slick Zombie

Joined: Sat Jan 27, 2007 7:10 pm
Posts: 1482
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.


Top
 Profile  
 
PostPosted: Mon Mar 26, 2012 7:58 am 
Offline
Regular

Joined: Sun Oct 30, 2011 4:47 pm
Posts: 184
Location: Mittweida, Saxony, Germany
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


Top
 Profile  
 
PostPosted: Mon Mar 26, 2012 8:40 pm 
Offline
Slick Zombie

Joined: Sat Jan 27, 2007 7:10 pm
Posts: 1482
Quote:
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.

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).

Quote:
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?

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.


Top
 Profile  
 
PostPosted: Mon Mar 26, 2012 9:53 pm 
Offline
Regular

Joined: Sun Oct 30, 2011 4:47 pm
Posts: 184
Location: Mittweida, Saxony, Germany
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:
Code:
saveCompiled(OutputStream);
loadCompiled(InputStream);

:?:

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

Nitram

_________________
http://illarion.org


Top
 Profile  
 
PostPosted: Mon Mar 26, 2012 11:36 pm 
Offline
Slick Zombie

Joined: Sat Jan 27, 2007 7:10 pm
Posts: 1482
Fair point -- I tweaked my benchmark and got results that looked more like this:
Code:
Vertex read 1 ms
Frag read 12 ms
Vert shader compile 5 ms
Frag shader compile 10 ms
Shader link 8 ms


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.

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

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.


Top
 Profile  
 
PostPosted: Tue Mar 27, 2012 7:00 am 
Offline
Game Developer
User avatar

Joined: Thu Mar 03, 2011 6:22 pm
Posts: 534
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 :D

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:
Image Mr. Hat I
Image Vegan Vs. Zombies
Projects:
RadicalFish Engine - Build on top of Slick2D, Ideas, Bugs? Open an Issue ticket!


Top
 Profile  
 
PostPosted: Tue Mar 27, 2012 7:46 am 
Offline
Regular

Joined: Sun Oct 30, 2011 4:47 pm
Posts: 184
Location: Mittweida, Saxony, Germany
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:
Code:
String IOUtils.toString(InputStream input) throws IOException


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


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 63 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 7 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group