org.lwjgl.d3d Progress / Thoughts

[Matzon]

hmm, back to square 1 - the full java path stopped working with 1.1.4 

files:

Volume in drive C is Windows

Directory of C:\lwjgl-1.1.4

10-04-2008  19:49    <DIR>          .
10-04-2008  19:49    <DIR>          ..
21-01-2008  19:41    <DIR>          doc
10-04-2008  19:44    <DIR>          jar
10-04-2008  19:48    <DIR>          native
10-04-2008  19:44    <DIR>          org
21-01-2008  19:41    <DIR>          res


Directory of C:\lwjgl-1.1.4\jar

10-04-2008  19:44    <DIR>          .
10-04-2008  19:44    <DIR>          ..
21-01-2008  19:41           209.077 jinput.jar
21-01-2008  19:40           534.256 lwjgl.jar
29-03-2008  22:06            65.353 lwjgl_d3d.jar
21-01-2008  19:40           188.440 lwjgl_test.jar
21-01-2008  19:40            57.801 lwjgl_util.jar
21-01-2008  19:40            21.883 lwjgl_util_applet.jar
               6 File(s)      1.076.810 bytes

Directory of C:\lwjgl-1.1.4\native

10-04-2008  19:48    <DIR>          .
10-04-2008  19:48    <DIR>          ..
21-01-2008  19:41    <DIR>          linux
21-01-2008  19:41    <DIR>          macosx
10-04-2008  19:48    <DIR>          win32
               0 File(s)              0 bytes

Directory of C:\lwjgl-1.1.4\native\win32

10-04-2008  19:48    <DIR>          .
10-04-2008  19:48    <DIR>          ..
12-10-2007  15:14         3.734.536 d3dx9_36.dll
21-01-2008  19:41            31.232 jinput-dx8.dll
21-01-2008  19:41            29.184 jinput-raw.dll
29-03-2008  22:00            39.424 lwjgl-d3d.dll <-- upx compressed, doesnt make a difference
21-01-2008  19:41           131.072 lwjgl.dll
21-01-2008  19:41           163.328 OpenAL32.dll
               6 File(s)      4.128.776 bytes

Directory of C:\lwjgl-1.1.4\org

10-04-2008  19:44    <DIR>          .
10-04-2008  19:44    <DIR>          ..
10-04-2008  19:45    <DIR>          lwjgl
               0 File(s)              0 bytes

Directory of C:\lwjgl-1.1.4\org\lwjgl

10-04-2008  19:45    <DIR>          .
10-04-2008  19:45    <DIR>          ..
10-04-2008  19:45    <DIR>          test
               0 File(s)              0 bytes

Directory of C:\lwjgl-1.1.4\org\lwjgl\test

10-04-2008  19:45    <DIR>          .
10-04-2008  19:45    <DIR>          ..
10-04-2008  19:45    <DIR>          d3d
               0 File(s)              0 bytes

Directory of C:\lwjgl-1.1.4\org\lwjgl\test\d3d

10-04-2008  19:45    <DIR>          .
10-04-2008  19:45    <DIR>          ..
10-04-2008  19:46             7.503 D3DTest.class
               1 File(s)          7.503 bytes

Directory of C:\lwjgl-1.1.4\res

21-01-2008  19:41    <DIR>          .
21-01-2008  19:41    <DIR>          ..
21-01-2008  19:41             5.512 appletlogo.png
...
           10 File(s)        512.250 bytes

C:\lwjgl-1.1.4>"C:\Program Files\Java\jdk1.6.0_10\bin\java.exe" -cp .;jar\jinput.jar;jar\lwjgl.jar;jar\lwjgl_d3d.jar;jar\lwjgl_test.jar;jar\lwjgl_util.jar; -Djava.library.path=native\win32 org.lwjgl.test.d3d.D3DTest
Exception in thread "main" java.lang.UnsatisfiedLinkError: C:\lwjgl-1.1.4\native\win32\lwjgl-d3d.dll: Can't find depend
ent libraries
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1778)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1703)
        at java.lang.Runtime.loadLibrary0(Runtime.java:823)
        at java.lang.System.loadLibrary(System.java:1030)
        at org.lwjgl.d3d.D3D9.<clinit>(D3D9.java:10)
        at org.lwjgl.test.d3d.D3DTest.main(D3DTest.java:31)

[elias]

FWIW, LinuxSysImplementation includes this hack to ensure jawt can be found:

    static {
        java.awt.Toolkit.getDefaultToolkit(); // This will make sure libjawt.so is loaded
    }

- elias

[gaarazero]

Just some updates:
- I decided to move D3D to Java 1.5 because of the enums.  The enum pattern I was using was good, except when going from the native value to the Java value.  It would have been a pain to do, especially with the larger enum sets.  Now, I have one generic method that can convert any native enum to it's Java counterpart.
- I got vertex/index buffers to lock correctly by using some shady "JNI Magic".
- Most, if not all, the basic structures and enums are done, thanks to using 1.5 enums.
- IDirect3DDevice9 is done, baring any minor changes.
- The less commonly used interface functions have yet to be added.
- I also started adding some D3DX functions.  Just the methods needed so I can do a "look at".  There's a lot of useful stuff in D3DX that is pretty awesome; matrices, quaternions, fonts, meshes, sprites, shaders, etc.

I attached the latest sceenshot I took not too long ago.  It's pretty much the same as last time, except with a different background color and it's looking down on the boxes from an angle, and the vertex buffer is working how it was meant to work (I was really happy/surprised that it worked).

-gz

[Matzon]

I dont feel its any problems that it requires 1.5 - at the very least, this can be retroweaved ?
I have a couple of questions:
* How close are you to being in a state where it makes sense to develop from the lwjgl svn (so we can get more hands/eyes on the source)?
* Why are you using the canvas instead of native display
* Have you come any closer to fixing the weird jawt issue ?
* How much of the code is duplicate with regards to input and display? ( I know elias talked about abstracting some stuff so that everything works better with gl3 and dx (no reason to have display in the OpenGL package for instance).

[gaarazero]

* How close are you to being in a state where it makes sense to develop from the lwjgl svn (so we can get more hands/eyes on the source)?

I think I'm pretty close.  I'd like to get a little more done on the basic interfaces first, they are bare bones.  After that it should be ready for a commit.

* Why are you using the canvas instead of native display

I was going to make a native display that mirrored the one in OpenGl, but someone said that a new Display class was in the works (?), so I stopped and went on with the canvas, which I already knew worked.  Also, there's a AWTGLCanvas, why not have a AWTD3DCanvas.

* Have you come any closer to fixing the weird jawt issue ?

I just compiled with jawt.dll delay loaded and attached it.  Hopefully it fixes the problem.  If not, I have another computer I can start testing on.

* How much of the code is duplicate with regards to input and display? ( I know elias talked about abstracting some stuff so that everything works better with gl3 and dx (no reason to have display in the OpenGL package for instance).

Right now there is no code duplication, because I'm not handling input or a native display .  But I think they should be separated out.  If there is a generic enough Display class, input can be handled with it and both GL or DX could use it.  Separating out core functionality into it's own jar would be helpful, then having gl and dx in different jars with their own natives would lessen the foot print needed for a specific rendering option.

-gz

[elias]

The new Display _is_ the one merging d3d/gl(/gl3) . Generalizing Display, AWT(GL)Canvas, Mouse, Keyboard etc. to cover both d3d and gl is a must if we are to bundle it with lwjgl. If not, then you're merely doing a lwjd3d binding, seperate from lwjgl, where the code just happens to be very similar. This is possibly the most controversial part of d3d, since you'll have to fit in with the existing API and opengl functionality, so it's best to get this covered as soon as possible. In other words, I'd gladly commit a d3d binding if it can be seamlessly selected at Display.create time, even though the d3d interfaces themselves are still broken (or bare-boned as you state it).

If you like, try and see if you can somehow abstract the ContextImplementation to cover d3d too, since input should pretty much already be handled in a renderer agnostic way (there are a few exceptions, WindowsDisplay likes to call makeCurrent() as a workaround, but that can be ignored for now).

- elias

[gaarazero]

The way I see making Display.create work for both D3D and GL would be to add a JVM argument, such as '-Dorg.lwjgl.graphicsImplementation=OpenGL/DirectX', so the correct graphics implementation can be used when the program starts.  This would default to OpenGL if the argument was not set, so it would be really only be useful for the select few Windows programs that want to run D3D.

-gz

[elias]

The way I see making Display.create work for both D3D and GL would be to add a JVM argument, such as '-Dorg.lwjgl.graphicsImplementation=OpenGL/DirectX', so the correct graphics implementation can be used when the program starts.  This would default to OpenGL if the argument was not set, so it would be really only be useful for the select few Windows programs that want to run D3D.

-gz

Nah, that's too obscure and what about an advanced game that picks one renderer and falls back on the other? Instead, an enum argument (being either "Direct3D" or "OpenGL") might be added to Display.create or PixelFormat. Anyway, the actual selection of renderer is not as interesting as actually making Display etc. work correctly with both.

- elias

[gaarazero]

I suggested the VM argument because selecting a display mode/pixel format would be different for GL and DX.  Although, after looking over the code, the combination of DisplayMode and PixelFormat roughly equals the combination of D3DDISPLAYMODE and D3DPRESENT_PARAMS.  So under the hood, it can use the D3D objects, but still be seamless.

Also, I didn't know if changing the create method was okay or not.

Anyway, the actual selection of renderer is not as interesting as actually making Display etc. work correctly with both.

True.

-gz

[elias]

I suggested the VM argument because selecting a display mode/pixel format would be different for GL and DX.  Although, after looking over the code, the combination of DisplayMode and PixelFormat roughly equals the combination of D3DDISPLAYMODE and D3DPRESENT_PARAMS.  So under the hood, it can use the D3D objects, but still be seamless.

Also, I didn't know if changing the create method was okay or not.

Anyway, the actual selection of renderer is not as interesting as actually making Display etc. work correctly with both.

True.

-gz

Well, some method need to be changed to support d3d, and (an overloaded) .create() is just a valid suggestion as the PixeelFormat. The D3DDISPLAYMODE is puzzling, though. Can it be replaced by the existing display mode switching in Display (since display mode switching is not dependent on opengl at the moment)?

  - elias

[gaarazero]

The D3DDISPLAYMODE is puzzling, though. Can it be replaced by the existing display mode switching in Display (since display mode switching is not dependent on opengl at the moment)?

A mapping from one to another can be made.  But, when the display mode needs to be switched in D3D, D3DPRESENT_PARAMS is used, not D3DDISPLAYMODE.  The only major difference between D3DDISPLAYMODE and DisplayMode is that the later has a fullscreen flag, where in D3D that flag is in D3DPRESENT_PARAMS.  D3DDISPLAYMODE is only used to get the available modes the graphics adapter supports, then the info is used in D3DPRESENT_PARAMS were it actually defines the pixel format, height, width, buffer count, etc.

-gz

[Evil-Devil]

Even if this is a bit offtopic, but when the "new display" comes out, will there be a method for retrieving all available pixel formats? Or how to do this actually?

[elias]

OpenGL generally supplies a choosePixelFormat that takes the minimum requirements for a pixel format and returns a suitable one. I hope d3d will work the same way.

- elias

[gaarazero]

D3D has kind of the same thing.  You specify the pixel format, D3DFORMAT, you want to IDirect3D9.GetAdapterModeCount() and it returns the number of display modes that match; then call IDirect3D9.EnumAdapterModes() for each mode and select the one that matches your desired width, height, and refresh rate.  In essence, it's the same as how LWJGL does it with Display.getAvailableDisplayModes() and then loop through each mode checking if it's the one you want.

-gz

[elias]

display modes and pixel formats are two different, but overlapping concepts, though. Display.getAvailableDisplayModes() returns an array of display modes, each one describing a (width, height, bits per pixel (depth), frequency) tuple that is supported by the monitor/graphics adapter. Currently, a display mode has nothing to do with opengl. A pixel format is a description of the various buffers, be it the color buffer, depth buffer, stencil buffer and is tied to the rendering api (opengl). A pixel format is typically selected by specifying a set of minimum requirements (encapsulated in a org.lwjgl.opengl.PixelFormat object) that has to be fulfilled for Display.create() to suceed.

Pixel formats and display modes are overlapping, since it doesn't make much sense to select a pixel format where the color buffer is not compatible with the current display mode's depth (sometimes the resulting graphics will appear corrupted).

- elias