[bobef]

Just wondered... How long will it take to link all these libraries at run time? I mean all of them.

[JJR]

Good question. I've never tried loading up SDL, OpenGL, GLFW, etc all at once. But, in my experience, generally the dynamic linking is extremely fast. I would imagine that it's easily less than 1 second to load all libraries. I've done a similar process with DUI and GTK on linux and windows. There are many, many symbols to load in GTK, much more, I believe, than in Derelict. Even there I don't notice the delay on either platform.

I guess the only sure way to know, though, is to time it. Get the time before and after the Derelict***_Load() functions.

-JJR

[h3r3tic]

Loading OpenGL with all 1.5 extensions, SDL, DevIL and ODE takes virtually no time on my Athlon2000+

[404FileNotFound]

I have a totally unrelated question about performance. I have recently tried to reimplement one of my java thingies in D. It's a fairly simple proggie, it loads one texture and draws bits of it on the screen in 2d (a map for the online game continuum). in java it uses lwjgl for rendering the opengl and in D it uses derelictSDL for it but other than that the code is about the same. Somehow in java I get about 120 fps while in D it gets no higher than 43 at the same res. I also noticed that my processor usage is pretty low with the D prog (no higher than 8?), so is SDL to blame for the performance dent? Does anyone else have any performance problems with D/DerelictSDL/opengl as compared to other opengl bindings? Or maybe Im just doing something wrong?

[aldacron]

[404FileNotFound]

Yea it uses derelictGL. My source is a bit too big to post here completely Im afraid. All in all it's about 1000 lines already. I'll show some of the more interesting sections:

Here's the main part of the rendering code (incomplete, so some var defs could be missing)

[aldacron]

Nothing jumps out at me. But the problem might not even be in the rendering code. Compile the program with -profile, then run it. You should see a file called 'trace.log' or some such in the working directory. Paste that here and we'll go from there.

[404FileNotFound]

Here's the list on the lower part of that file (since that's the only part that looked readable to me).

[aldacron]

Is the code for SubspaceMap.draw the same as the tileset drawing code you posted earlier?

Next thing I can think of is to compile without -debug or -g, and with -release and -O. See if that makes any difference.

I haven't done any LWJGL/Derelict comparisons, but I just don't see how there can be any sort of difference at that level in LWJGLs favor. In D, bindings to C API calls are direct. In Java, they have to go through the JNI as a proxy. On top of that, many of the LWJGL calls do validation on the direct buffers (FloatBuffers and such) that you pass to the functions. So I just can't see the difference being at the binding level. And it surely wouldn't be SDL as that is only used to create the Window and OpenGL context.

Other things to check for - are you setting up the same pixel format? You can verify this through the following OpenGL calls:

int x = glGetInteger([constant]);

where constant is one of GL_RED_BITS, GL_GREEN_BITS, GL_BLUE_BITS, or GL_ALPHA_BITS. You can also check for depth, stencil, and accumulation buffer R, G & B bits. In LWJGL, use org.lwjgl.opengl.Util.glGetInteger.

Make sure you are passing SDL_HWSURFACE as a flag to SDL_SetVideoMode. I don't know if it's possible to get a software OpenGL implementation without that flag as I haven't dug around the SDL source to see the pixel format selection code, but I always use it to be safe.

Are you turning off vsync in LWJGL? And if not (and assuming you are running fullscreen), call org.lwjgl.opengl.Display.getDisplayMode after you have created the window to see what the refresh rate of the display mode is (or check the refresh rate of the DisplayMode object you pass to Display.create). I don't know of any way to check this through the SDL API, so if you are on Windows then you can get that info through the Win32 API. If you don't want to go that route, then when iterating the available DisplayModes in LWJGL select one with a refresh rate of 60. Pass that to Display.create and see what happens.

If none of this pans out, I don't know what to tell you. If you don't mind sharing your source, I would happily compile both versions on my system to see what comes up and try to help troubleshoot. I have the lastest LWJGL (0.9 and Eclipse 3.1, Netbeans 4.1, and Ant - so I will be able to build any project/build files for those environments (assuming you have no other dependencies). I'm hoping it's something simple like a vsync issue though.

[404FileNotFound]

I sent the info in a PM to you

[JJR]

Another thing to consider:

This may seem strange, but I experienced a severe degradation in performance while working with glfw on win32 awhile ago.

I was working on getting a dynamic glfw binding working with D (pre-derelict, I think). I had compiled several versions of the C glfw.dll with different compilers: openwatcom and dmc specifically. I also was testing the bindings with the pre-compiled glfw.dll file provided from the glfw project.

Strangely, I found the C version running full speed, but the D version ran approximately half the speed (fps; using opengl in both cases). I believe that this problem arose while using using the included glfw.dll and dmc compiled versions of the dll. I then tried compiling glfw.dll with openwatcom. After trying that version with d opengl project, I found that the demo now ran at the same speed as the C original. I don't know why this was so, but it seemed the performance degradation was due to which C compiler was being used for the dll. But the performance problem only showed up when I using it from d. I'm not sure if I tried compiling the dll with mingw gcc.

That said, perhaps the SDL dll in some way is an issue here? I know that doesn't make much sense since opengl uses it's own dll... but you never know. I couldn't make sense of my problem either.

-JJR

[aldacron]

It looks like a vsync issue. When I first ran the Java version, I was getting 500+ frames per second, and the D version was consistently giving me 59.xxxx. So I searched the Java files for vsync, and sure enough I found this on line 178 of Game.java:

// Display.setVSyncEnabled(true);

Uncommenting that line caused the framerate to drop to 75 fps. Although you were requesting 85hz refresh rate, the display mode that was being set was 75hz. And just to be sure, I changed the Display.setDisplatMode call to request 60hz and the framerate dropped to 60.

Next, I visited the D code. Either SDL is consistently setting a display mode with a 60hz refresh rate, or something is horribly wrong. So to verify this I added the following to the top of gfx.d:

[JJR]

Wow! Good catch, Mike!

Now that you mention it, I guess we should be suspicious about vsync whenever we see a frame rate consistantly hover around 59.xxx.

-JJR

[404FileNotFound]

Wow thanks for doing all that, however the weird thing is that I was testing with a refresh rate of 85 Hz, while getting somewhere around 40 fps. Now even if the refresh rate was somehow not 85 Hz, my monitor doesn't go lower than 60 for sure. I can't test on the same machine as previously anymore (Im no longer at my parents place) but I'll see what my laptop does with it.
My previous testing machine was a P3 800 MHz, with 768 MB ram and a Geforce 4 Ti4200 64 MB, so yea your machine should be a bit faster than mine
Anyway thanks a bunch I'll try your changes later and let you know what happend

[aldacron]