It doesn't find the shaders file

[elect]

Hi,

I did a small program in order to benchmark the relative cost between different opengl state changes.

I wrote it initially in jogl and now I would like to give a try with lwjgl.

The first real problem I met is that I can't read the shader file.

I'm trying to read my vertex and fragment shaders here.

The relative path comes from here.

The complete path for my vertex shader is "common/shaders/VS.glsl", I removed the leading backslash on the ra4king suggestion, since it should indicate root which is something I don't want to.

But still it doesn't find them, complete stacktrace

Parenthesis says (the system cannot find the given path)

GlCallsOverheads 3.0.0a!
java.io.FileNotFoundException: common\shaders\VS.glsl (Das System kann den angegebenen Pfad nicht finden)
   at java.io.FileInputStream.open0(Native Method)
   at java.io.FileInputStream.open(FileInputStream.java:195)
   at java.io.FileInputStream.<init>(FileInputStream.java:138)
   at java.io.FileInputStream.<init>(FileInputStream.java:93)
   at java.io.FileReader.<init>(FileReader.java:58)
   at lwjgl.glsl.ProgramBase.loadShader(ProgramBase.java:43)
   at lwjgl.glsl.ProgramBase.<init>(ProgramBase.java:26)
   at lwjgl.GlCallsOverhead.initPrograms(GlCallsOverhead.java:137)
   at lwjgl.GlCallsOverhead.init(GlCallsOverhead.java:109)
   at lwjgl.GlCallsOverhead.run(GlCallsOverhead.java:49)
   at lwjgl.GlCallsOverhead.main(GlCallsOverhead.java:320)
Could not read file.
Java Result: -1

What's wrong, guys?

[emris]

Try "src/common/shaders/VS.glsl".

[Kai]

If you ask the filesystem to resolve a "relative" file path (that's a path without a "C:\" or "D:\" or a "\" in front, then it will do so relative to the current working directory of the Java process.
This working directory is likely your project folder, which, as @emris pointed out, is likely to contain the "common/shaders" package inside the "src" folder or "res" folder.
A somewhat better solution to load resources generally is via the classpath. Why is that better? Because you can then load resources which are packaged inside your application's deployments (JAR files), instead of having to explode your application into the user's filesystem.
You would then use ClassLoader.getResourceAsStream() (with the ClassLoader being the ClassLoader.getSystemClassLoader() or some Class.getClassLoader() of a named class).

[elect]

Thanks both, really useful


Ps: @Kai, are you the same KaiHH on JGO?