Messages

211

Graphics / Debugging is slow at first. then speeds up

« on: February 02, 2012, 12:14:15 pm »

Try it by removing those oss lines and setting constant strings.
If your framerate goes up to 100 again, you got your answer.

212

Java / How to build JSFML

« on: February 01, 2012, 04:57:27 pm »

Found this:
http://stackoverflow.com/questions/3976342/running-swt-based-cross-platform-jar-properly-on-a-mac

In short, try adding this command line argument:

Code: [Select]

-XstartOnFirstThread

Apparently, this can cause trouble on other systems, so we'll have to think of something here. But let's see if this does the trick first. I'm not too sure about that, since I could not get any information on this flag outside a SWT context. JSFML is not a SWT application.

213

Java / How to build JSFML

« on: February 01, 2012, 04:01:00 pm »

Still it's much more convenient if that's out of the way!
I will try and do some research on the window thing myself in a bunch, see what I can find out.

214

Java / How to build JSFML

« on: February 01, 2012, 01:53:22 pm »

It appears to me that the depdendency's full path is written into the jnilib when it is linked. Do you have any influence on that?

215

Java / How to build JSFML

« on: February 01, 2012, 07:49:49 am »

I have never run into these kinds of problems, but I will read about it.
Normal Java Swing GUIs do work, right? They (the Java developers) must have found a way to create windows, so I believe it must be possible somehow.

If not, there is a plan B. That plan would be to not feature dedicated RenderWindows under JSFML on Mac OS X. Instead, one could create a simple Swing frame and put a RenderCanvas on it (planned for JSFML 1.x). I suppose that on Mac OS X, the RenderWindow(HANDLE) constructor works even in a worker thread?

It appears that the jnilib will try to load libsfml-system.dylib even if it was loaded by Java manually. This means that the users must install SFML in the default location.

Can you try running Java with the following command line argument?

Code: [Select]

-Djava.library.path=/Users/marcoantognini/.jsfml/

The java.library.path System property is used for locating dynamic libraries if they are not loaded manually using an absolute path. I tried to avoid that, because I kept running into issues with it, but it would still be a very nice solution.

216

Graphics / Forcing a certain GLSL specification

« on: February 01, 2012, 07:41:10 am »

That is, a comment in the first line of the shader itself? I believe I had read about such a feature once, thanks for reminding.

EDIT: Yes, that's it! Thanks!

217

Graphics / Forcing a certain GLSL specification

« on: January 31, 2012, 09:08:09 pm »

Is it possible to somehow tell the GPU to compile GLSL programs following a certain specification? Let's say my GPU supports the latest GLSL, but I want to make sure my shader program is compatible to GLSL 1.10 (OpenGL 2.0) to avoid problems like this one: http://www.sfml-dev.org/forum/viewtopic.php?t=6930 .

If so, I believe the sf::Shader class (or, depending on how it'd work, the sf::ContextSettings class) should support that feature. I can tell for sure that setting the OpenGL major and minor versions in the context settings does not influence the GLSL specification used for compiling.

218

Java / Test Release

« on: January 31, 2012, 08:53:18 pm »

Argh, I officially need a GLSL course.
http://stuff.pdinklag.de/jsfml-examples-shader-fix-2.zip
Now this should do the trick. At least for that line...

Note to self: the "f" suffix for floats has been introduced in GLSL 1.2 (OpenGL 2.1).

219

Java / Test Release

« on: January 31, 2012, 05:54:01 pm »

Can you try replacing your jsfml-examples.jar with the one in this zip file?
http://stuff.pdinklag.de/jsfml-examples-shader-fix.zip

Apparently, implicit conversions from int to float are not supported before GLSL 1.5 (OpenGL 3.2), so if your graphics card only supports an older version, this would explain the error. I should keep this in mind from now when writing shaders.

220

Java / Test Release

« on: January 31, 2012, 05:43:45 pm »

Hey there! Thanks for trying out that example. It was only so I could test it at work but good you tried it, apparently.

JSFML itself works fine for you, if dlls or anything were missing it would not get that far (jsfml.jar takes care of all those things). The problem is definitely with the example's fragment shader. In fact, that looks pretty interesting. Your graphics card seems to support shaders, but apparently it does not support the GLSL code I wrote.

Probably I am using a "too new" GLSL version, I am honestly not sure which, but I will sort this out.

221

Java / How to build JSFML

« on: January 31, 2012, 03:40:09 pm »

Good to see it working! (well, kindof)

Be careful with audio. SFML does not allow a manual shutdown of the AudioDevice and the JVM termination does not seem to invoke static destructors, so the AudioDevice never gets destroyed and the OpenAL thread keeps running until you kill the Java process. I'm just mentioning this in case you start wondering why the process won't end.

Good luck with that window issue. Mac support would be sweet!

222

General / SetFramerateLimit does not seem to work correctly

« on: January 31, 2012, 03:24:11 pm »

Oh, no, it's the opposite, I get better results in JSFML. Sorry.

Well, I don't have any explanation for this if this doesn't happen for you. That's why I said we should wait for other peoples' results. Maybe there's still something wrong but only under certain circumstances, but I wouldn't know which.

223

General / SetFramerateLimit does not seem to work correctly

« on: January 31, 2012, 02:58:02 pm »

Those results I posted here were strictly from that C++ program in my first post, run using MSVC++ 2010 Express. They do indeed not have anything to do  with Java.

224

General / SetFramerateLimit does not seem to work correctly

« on: January 31, 2012, 01:20:58 pm »

Weirdly enough, it's a lot better when I use it out of Java. Maybe let's wait for other people's results.

225

General / SetFramerateLimit does not seem to work correctly

« on: January 31, 2012, 12:32:36 pm »

It definitely changed something,  but I got a feeling dealing with microseconds on Windows is extremely inaccurate and should not be done for timing.

Using the above code,
for a limit of 60, my average FPS is 67
for a limit of 80, the average is 67,
for a limit of 30, the average is 23,
for a limit of 200, the average is not saying anything because the FPS jumps wildly between 67, 150 and 250 every second,
for a limit of 0 (none), the FPS is a roughly constant 1000 proving that the jumps at 200 are not a performance problem. Also, the fact that it's almost a constant 1000 looks very suspicious to me.