LWJGL Forum

I'll be posting any updates on org.lwjgl.d3d here.

Right now I have it building into a separate dll and jar, lwjgl-d3d.dll and lwjgl-d3d.jar respectively.  It also only builds for Windows.

Since Direct3D is written in an object-oriented way, wrapping it in Java is quite straightforward.  But, little things like capitalized method names and having an 'I' in front of the object names makes it quite tricky.  I think a one-to-one mapping would be the best and most simple way to do it, but I would also really like to adhere to the Java standards.  All this means is that instead of using IDirect3DDevice9 dev; it's now Direct3DDevice9 dev;, and instead of dev.BeginScene(); it's now dev.beginScene();.

Another change is that for many of the 'create' functions, you have to pass in a pointer to the object you want to create.  That's not how things are done in Java Land.  For these methods, I am planing on returning the object created and throwing an exception if it doesn't work; you don't have to use try and catch specifically, unless you really want to.  This is much more Java friendly.  I plan on still returning the HRESULTs from the other method calls.  Throwing exceptions would be more Java-esk, but most of the time you don't need to check the result.

I welcome any questions or comments.

-gz

Quote from: gaarazero on March 13, 2008, 18:07:42
Right now I have it building into a separate dll and jar, lwjgl-d3d.dll and lwjgl-d3d.jar respectively.  It also only builds for Windows.

I'm sure that noone expects otherwise :) - tho I'd love to see it running under wine.

Quote from: gaarazero on March 13, 2008, 18:07:42
Since Direct3D is written in an object-oriented way, wrapping it in Java is quite straightforward.  But, little things like capitalized method names and having an 'I' in front of the object names makes it quite tricky.  I think a one-to-one mapping would be the best and most simple way to do it, but I would also really like to adhere to the Java standards.  All this means is that instead of using IDirect3DDevice9 dev; it's now Direct3DDevice9 dev;, and instead of dev.BeginScene(); it's now dev.beginScene();.

well, this is a bit of a "problem". from my point of view, it depends on how well it maps. one of the reasons that we chose the naming and static convention that we did for lwjgl, was that using import static would make a lot of the code "just" work from C/C++. By changing the names one has to refactor some code to make it work. Typically, however, this isn't a really big issue.

Quote from: gaarazero on March 13, 2008, 18:07:42
Another change is that for many of the 'create' functions, you have to pass in a pointer to the object you want to create.  That's not how things are done in Java Land.  For these methods, I am planing on returning the object created and throwing an exception if it doesn't work; you don't have to use try and catch specifically, unless you really want to.  This is much more Java friendly.  I plan on still returning the HRESULTs from the other method calls.  Throwing exceptions would be more Java-esk, but most of the time you don't need to check the result.

fair enough. The dx api, is really a bit ugly IMO.

Thanks for the update - do let us know if you have something ready for pre-pre-alpha :)

I'd map the names directly, capitals and all, so C++ code looks very similar, if I were you.

Cas :)

I too would keep the mapping as close to 1:1 as possible. This makes a transition easier and if people want Java style identifiers they can always just write their own wrappers on top of your work.

I prefer that slight changes be made to the names, as done above, since d3d is pretty ugly.
Although it will look slightly different from C/C++ d3d code, it will make the overall code look much cleaner and nicer.
Which will probably be a plus in attracting C/C++ d3d dev's since they will see how nice the code looks compared to what they are using.

I also prefer Java style naming. I would not want my eyes hurt when looking at Java code that doesnt look like Java code.

It's not a Java API though... so it shouldn't follow the Java naming conventions.

Cas :)

I think it would be better to keep the names as they are in DirectX (although I like the idea of returning an object and throwing an exception if something goes wrong).

Does seem like a good candidate for an exception but... the original API returns HRESULTS... so that what this one should do. Anyone wanting Exceptions should wrap the library.

Cas :)

Thanks for all the input!

Quote from: Matzon on March 13, 2008, 20:26:03
I'm sure that noone expects otherwise :) - tho I'd love to see it running under wine.

I'll look into that, because it would be crazy :P.  But much later.

Quote from: Matzon on March 13, 2008, 20:26:03
well, this is a bit of a "problem". from my point of view, it depends on how well it maps. one of the reasons that we chose the naming and static convention that we did for lwjgl, was that using import static would make a lot of the code "just" work from C/C++. By changing the names one has to refactor some code to make it work. Typically, however, this isn't a really big issue.

Users would still have to refactor their C/C++ D3D code any way since there are multiple ways to program.  You can use

IDirect3DDevice9* dev;
PDIRECT3DDEVICE9 pdev;
LPDIRECT3DDEVICE9 lpdev;

(all three mean the same thing).

Then call methods via the C++ way
dev->BeginScene(); or the C way IDirect3DDevice9_BeginScene( dev );

OpenGL is a C API anyway, so it's all functional programming, which Java can do.  Also, all the method names start with lowercase 'gl'.  You guys had it easy  ;).

Another thing is that if there is an 'I' in front of a class, it denotes an interface, even in C++.  Keeping it IDirect3DDevice9 in Java may confuse some newcomers.  But, after typing this and remembering that D3D is an interface for the graphics card, it makes sense to keep the 'I', kinda.

Quote from: Matzon on March 13, 2008, 20:26:03
fair enough. The dx api, is really a bit ugly IMO.

I agree.

Quote from: ndhb on March 14, 2008, 12:58:35
I too would keep the mapping as close to 1:1 as possible. This makes a transition easier and if people want Java style identifiers they can always just write their own wrappers on top of your work.

I'm pretty sure people wont get confused if their method names were lowercased.

I guess the best way to do it would be to have as little refactoring as possible.  But, refactoring will have to take place no matter what.

I'm really torn between keeping it 1:1 or making it more Java friendly.  There are positives and negatives to both.  I'm leaning more to make it Java friendly.  I think users of D3D would appreciate it.

A solution I came up with was to provide both capitalized and lowercase method names and both 'create' method types, returning an HRESULT or an object.  Hell, why not include the C wrapper as well :P.  I'm only kidding... unless it's a good idea.

-gz

To give an example of what I'm talking about when I say 'create' methods, here is the original C/C++ code:

IDirect3DDevice9* dev; //assume created successfully
D3DPRESENT_PARAMETERS params; //assume created
IDirect3DSwapChain9* swapchain = NULL;

HRESULT r = dev->CreateAdditionalSwapChain( &params, &swapchain );
if( r != D3D_OK) {
... //fail code
}


The Java equivalent would be:

IDirect3DDevice9 dev; //assume created successfully
D3DPersentParameters params; //assume created
IDirect3DSwapChain9 swapchain = new IDirect3DSwapChain9();

int r = dev.CreateAdditionalSwapChain( params, swapchain );
if( r != Constants.D3D_OK ) {
...//fail code
}


That looks almost counter productive.  You create a new swap chain, then call a method that says "create a new swap chain".  The refactor I propose would look like:

IDirect3DDevice9 dev; //assume created successfully
D3DPersentParameters params; //assume created

IDirect3DSwapChain9 swapchain = dev.CreateAdditionalSwapChain( params );
if( swapchain == null ) {
...//fail code
}


There is only one or two methods that I can think of were the HRESULT is actually useful; TestCooperativeLevel() is the first one that comes to mind.  Also, most of the time it doesn't really matter what is returned, as long as its D3D_OK.  Additionally, with the first Java example, there is still a SwapChain object that can be used, unless you set it to null in the fail code section, but then why did you need to create it in the first place.  Returning them is useful, but going out of the way to accommodate them for the sake of 1:1-ness is crazy.

-gz

Quote from: gaarazero on March 23, 2008, 02:43:14
I'm really torn between keeping it 1:1 or making it more Java friendly.  There are positives and negatives to both.  I'm leaning more to make it Java friendly.  I think users of D3D would appreciate it.

I've never really used d3d, so I can only make general comments from experience with the rest of lwjgl.

From the frontpage of lwjgl.org: "LWJGL is not meant to make writing games particularly easy; it is primarily an enabling technology which allows developers to get at resources that are simply otherwise unavailable or poorly implemented on the existing Java platform." LWJGL is about enabling otherwise hard or impossible to access functionality, which means that your job is to make it possible to access d3d from java and nothing else. If you're torn between two ways of exposing an otherwise native API to java, use the simplest possible (return the HRESULT instead of throwing exceptions) and let a org.lwjgl.util.d3d class handle mappings to exceptions. This has the additional advantage of keeping the performance die-hards off your back, since you're not doing any "excess" processing getting in their way to high FPS numbers.

Trust me, it's hard enough to get the JNI interface to the native code working correctly, let alone mapping to java-like designs :)

- elias

I'd also be sure to keep the "I" in interfaces, and preserve fully all the Microsoft/C capitalization, just as we have done for OpenGL. So it'd be HRESULT not HResult, and D3DPRESENT_PARAMETERS not D3DPersentParameters. This will make it all much more familiar to people coming from C++, and also much easier to understand and port all the millions of DX tutorials out there.

Cas :)

Going along those lines then, I had the idea of putting the enums that D3D uses into Java Enums.  I did it before and it makes the code look more like the original and is type safe.  The only down side is that if users don't have 1.5 or greater, it wont work.

-gz

That's probably not so much of an issue as it at first sounds because most people can ship a current VM with bigger projects and for smaller projects... meh who cares :) About time people upgraded!

Cas :)

Quote from: princec on March 23, 2008, 22:29:19
That's probably not so much of an issue as it at first sounds because most people can ship a current VM with bigger projects and for smaller projects... meh who cares :) About time people upgraded!

Cas :)

There's always the ever-present problem with Mac OS X 10.3 and not being able to upgrade to 1.5. Not supporting OS X 10.3 would be stupid, IMHO.

- elias

...Of course there's the possibility of splitting lwjgl in multiple jars, some 1.4 compatible, some 1.5 compatible:

1. lwjgl-core.jar with Display, Mouse, Keyboard and support classes for the other packages (1.4)
2. lwjgl-gl2.jar with GL*, ARB* (1.4)
3. lwjgl-d3d.jar with everything d3d related (1.5 since it will only be used on windows, where we can require 1.5)
4. lwjgl-gl3.jar with everything gl3 related (might as well be 1.5 since mac os x 10.3 will probably never support gl3)

5. lwjgl_util.jar, lwjgl_applet etc. (1.4)

the native dlls might be split up accordingly but it's not as important, compatibility wise.

- elias

so Mac 10.3 will be able to run DX ? ;)
we require 1.5 to compile anyway - so I dont see a problem.

We only require 1.5 in the pre-process compiling, the actual lwjgl.jar is compiled to java 1.4. And yes, you can allow the 1.5 requirement if all d3d code is split from the main lwjgl.jar.

- elias

Here's a thought - is there any useful generification could be done in the util / applet packages that might require 1.5? And could it then be Retroweaved to 1.4?

Oh and while I'm thinking about this - could we please change the build output so that LWJGL downloads as one single fat zip instead of lots of little zips that all unzip to slightly different root directories? Or at least, a single fat zip containing all the other zips, and all pointing at the same root?

Cas :)

Quote from: princec on March 24, 2008, 10:09:27
Here's a thought - is there any useful generification could be done in the util / applet packages that might require 1.5? And could it then be Retroweaved to 1.4?

I would think most 1.5 work could be layered upon a 1.4 core. I'm not quite sure how Enums is done, but I would suspect that the actual HRESULT (int) returning methods would exist in core regardless and that the translation to/from enums would be done by a separate layer anyway (along with the exception mapping?).

- elias

Yes, a wrapper layer to Javafy the API would be best.

Cas :)

do agree that there are too many LWJGL packages (lazy), one big bundle would be nice.

P.S. princec i think your signature is missing a "[" at the beginning :)

Now how the hell has that happened? I haven't changed that sig in years.

Cas :)

Quote from: princec on March 24, 2008, 18:33:56
Now how the hell has that happened? I haven't changed that sig in years.

Cas :)

when we upgraded to SMF - something broke  :-*

Getting back on track here...

To make this wrapper as much 1:1 as possible, enums should be used since the original API is type safe.  Instead of using the built in Enums 1.5 has, I could just use the 'Enum Pattern' to make it run in 1.4, but still have type safe values.  Either way, they both do the same thing.

I started implementing the Display class over the weekend.  Once that and the device interface are done, I'd like to release a pre-pre-alpha.  Here is the link for the D3D documentation (http://msdn2.microsoft.com/en-us/library/bb172964(VS.85).aspx), so those who are not familiar with it wont be flabbergasted, too much, when looking at the example code.

-gz

Quote from: gaarazero on March 24, 2008, 20:19:51
I started implementing the Display class over the weekend.

Eventually, the original Display (and AWTGLCanvas) of LWJGL should be able to handle d3d (and gl3) contexts, so don't waste too much time on this.

- elias

Another small niggle I came to think of: Should the package name be org.lwjgl.d3d9, anticipating a future org.lwjgl.d3d10? I'm under the impression that the two APIs are similar but still distinct enough that they can't be used at the same time (like for example GL11 and GL12).

- elias

AFAIK D3D9 and D3D10 are fairly dissimilar beasts so we should probably want to keep them separate.

Cas :)

Quote from: elias on March 24, 2008, 21:38:24
Eventually, the original Display (and AWTGLCanvas) of LWJGL should be able to handle d3d (and gl3) contexts, so don't waste too much time on this.

Thanks, that's good to know :).

And yes, D3D9 and D3D10 are quite dissimilar.  Separating them would be a good idea.

-gz

Quote from: gaarazero on March 25, 2008, 04:33:27
And yes, D3D9 and D3D10 are quite dissimilar.  Separating them would be a good idea.

After looking over the DirectX 10 API, there is a need to separate them.  All the DirectX 10 interfaces, enums, structures, functions, etc. start with either D3D10, D3DX10, or ID3D10.  From what I can tell, there is no overlap in code (except for ID3DXMatrixStack, which is most likely a typo on their part).  Therefore, keeping the package structure the same (org.lwjgl.d3d) is fine.  The only thing that I can see changing is the D3D class I created, renaming it to D3D9 so later on there can be a class called D3D10.

-gz

but having seperate packages (d3d9 and d3d10) will allow a user to cut out the unwanted APIs more easily. For example, I could imagine that most OpenGL games don't want either of the d3d apis, but more importantly, I don't think most d3d9 games want d3d10 and vice versa.

- elias

I don't even know if they can actually be mixed in the same application anyway. Or if they can I bet it's rather buggy.

Cas :)

Quote from: elias on March 28, 2008, 09:03:27
but having seperate packages (d3d9 and d3d10) will allow a user to cut out the unwanted APIs more easily.

True, but then why is GL11, GL12, etc. in the same org.lwjgl.opengl packaged?  What if I am using an on board graphics card that only supports up to GL12?  GL20 is still included in the package, even though I can't use it.

Quote from: elias on March 28, 2008, 09:03:27
For example, I could imagine that most OpenGL games don't want either of the d3d apis, but more importantly, I don't think most d3d9 games want d3d10 and vice versa.

That's why I split this off into it's own jar and dll.  There's no need to include the D3D code if you're just using OpenGL.  I'd like to also not include OpenGL if you're just using D3D.  But that might not be possible, unless some of the more general classes are split into a "core" jar.

Quote from: princec on March 28, 2008, 11:20:37
I don't even know if they can actually be mixed in the same application anyway. Or if they can I bet it's rather buggy.

I'd still want to try :P.

Quote from: gaarazero on March 29, 2008, 04:52:56

True, but then why is GL11, GL12, etc. in the same org.lwjgl.opengl packaged?  What if I am using an on board graphics card that only supports up to GL12?  GL20 is still included in the package, even though I can't use it.

GL11 and GL12 (and the rest of opengl) can easily be mixed in the same context, assuming driver support. As far as I understand it, d3d9 and d3d10 can't be used at the same time, but you have to conditionally decide which kind of d3d you want and create a context accordingly (and create two rendering paths). The same thing will happen with gl3, which can't be shared with gl2 (easily). And you're right, we probably want to split out gl2 in a seperate jar (and dll?) as soon as d3d is implemented.

Here are two screenshots I took.

The first describes what methods I used to render the four boxes.

The second is the same as the first, except I changed the PresentationInterval from D3DPRESENT_INTERVAL_ONE to D3DPRESENT_INTERVAL_IMMEDIATE, basically a speed test.

I think if I was using a native display, I could get a few more FPS out of it, but it works so I'm not complaining.  The only thing I will complain about is the way D3D locks it's vertex/index buffers.  The way I would have to do it would be to create a new direct buffer every time around the area that is returned.  That would be fine, except for the fact that when doing things like animation, you call Lock every frame.  I guess that's what garbage collectors are for, but still, that's a lot of buffers.  The way I did it for now is to just set the data to the buffer that's passed in (a memcpy to be precise).  I have an idea on how to fix this to give it more of a 1:1 feel, but I'm not sure if it will work.

-gz

I was about to post a pre alpha, but when I tested it on another computer, I was missing a dll.  I got the latest version of the DirectX SDK and doing so means that they updated the d3dx9 dll to the next version, d3dx9_36.dll.  If you have the d3dx9_36.dll, you're all set; if not, go here to download it (http://www.m3fe.com/760/skip/100) and place it in the windows native directory where all the lwjgl dlls are.  This is much safer than putting it in your system32 folder.  I've also attached the source code that made the screenshots I posted earlier.  Note: this is in no way finalized or anywhere near complete, it's just a taste of D3D.  One word of advice, don't use D3DPRESENT_INTERVAL_IMMEDIATE; it works, but locks your system for a bit.

I'd like any feedback you guys come up with.

To install, put lwjgl-d3d.dll in the windows native folder and lwjgl_d3d.jar in the jar folder of your lwjgl directory.  I'm going off the 1.1.4 code base.  It works under Java 1.4.  Sorry, Windows only... for now ;).

D3DTest.java

package org.lwjgl.test.d3d;

import java.awt.BorderLayout;
import java.nio.ByteBuffer;

import javax.swing.JFrame;

import org.lwjgl.BufferUtils;
import org.lwjgl.d3d.AWTD3DCanvas;
import org.lwjgl.d3d.D3D9;
import org.lwjgl.d3d.D3DCOLORVALUE;
import org.lwjgl.d3d.D3DDEVTYPE;
import org.lwjgl.d3d.D3DDISPLAYMODE;
import org.lwjgl.d3d.D3DFORMAT;
import org.lwjgl.d3d.D3DLIGHT9;
import org.lwjgl.d3d.D3DMATERIAL9;
import org.lwjgl.d3d.D3DPRESENT_PARAMETERS;
import org.lwjgl.d3d.D3DRENDERSTATETYPE;
import org.lwjgl.d3d.D3DVIEWPORT9;
import org.lwjgl.d3d.D3DX9;
import org.lwjgl.d3d.IDirect3D9;
import org.lwjgl.d3d.IDirect3DDevice9;
import org.lwjgl.d3d.IDirect3DTexture9;
import org.lwjgl.d3d.IDirect3DVertexBuffer9;

public class D3DTest {

public static void main(String[] args) {
// Create D3D
IDirect3D9 d3d = D3D9.Direct3DCreate9( D3D9.D3D_SDK_VERSION );

int width = 800, height = 600;

JFrame f = new JFrame();
f.setSize( width, height );
f.setTitle( "LWJGL D3D Example" );
// Create the canvas
AWTD3DCanvas can = new AWTD3DCanvas();

f.getContentPane().add( can, BorderLayout.CENTER );
f.setVisible( true );
f.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE );

// Get the display mode from the default adapter
D3DDISPLAYMODE dm = new D3DDISPLAYMODE();
d3d.GetAdapterDisplayMode( D3D9.D3DADAPTER_DEFAULT, dm );

// Setup the presentation parameters for the device
D3DPRESENT_PARAMETERS m_d3dpp = new D3DPRESENT_PARAMETERS();
m_d3dpp.BackBufferFormat = dm.Format;
m_d3dpp.BackBufferCount = 1;
m_d3dpp.MultiSampleType = D3D9.D3DMULTISAMPLE_NONE;
m_d3dpp.hDeviceWindow = can.getHWnd();
m_d3dpp.Windowed = true;
m_d3dpp.BackBufferWidth = width;
m_d3dpp.BackBufferHeight = height;
m_d3dpp.EnableAutoDepthStencil = true;
m_d3dpp.AutoDepthStencilFormat = D3DFORMAT.D3DFMT_D16;
m_d3dpp.Flags = 0;
m_d3dpp.FullScreen_RefreshRateInHz = 0;
m_d3dpp.SwapEffect = D3D9.D3DSWAPEFFECT_FLIP;
m_d3dpp.PresentationInterval = D3D9.D3DPRESENT_INTERVAL_ONE;

// Create the device interface
IDirect3DDevice9 dev = new IDirect3DDevice9();
int r = d3d.CreateDevice( D3D9.D3DADAPTER_DEFAULT,
D3DDEVTYPE.D3DDEVTYPE_HAL,
can,
D3D9.D3DCREATE_HARDWARE_VERTEXPROCESSING,
m_d3dpp,
dev );
if( D3D9.FAILED( r ) ) {
throw new RuntimeException( "Unable to create device" );
}


D3DCOLORVALUE color = new D3DCOLORVALUE( .2f, .1f, .6f, 1f ), cc = new D3DCOLORVALUE( 200, 100, 50, 255 );

// Create the view port
D3DVIEWPORT9 vp = new D3DVIEWPORT9();
vp.X = vp.Y = 0;
vp.Width = width;
vp.Height = height;
vp.MinZ = 0.0f;
vp.MaxZ = 1.0f;
dev.SetViewport( vp );

// Create a buffer to render
float w = 0f, h = .5f;
ByteBuffer bb = BufferUtils.createByteBuffer( 64 );
bb.rewind();
bb.putFloat( w ).putFloat( w ).putFloat( 0.0f ).putInt( cc.asInt() );
bb.putFloat( w ).putFloat( h ).putFloat( 0.0f ).putInt( -cc.asInt() );
bb.putFloat( h ).putFloat( w ).putFloat( 0.0f ).putInt( -cc.asInt() );
bb.putFloat( h ).putFloat( h ).putFloat( 0.0f ).putInt( cc.asInt() );
bb.rewind();

// Create a vertex buffer
IDirect3DVertexBuffer9 vb = new IDirect3DVertexBuffer9();
r = dev.CreateVertexBuffer( 64, 0, D3D9.D3DFVF_XYZ | D3D9.D3DFVF_DIFFUSE, D3D9.D3DPOOL_MANAGED, vb, 0L );
if( D3D9.FAILED( r ) ) {
throw new RuntimeException( "" + r );
}

// Set the vertex buffers data
ByteBuffer vbb = BufferUtils.createByteBuffer( 64 );
vbb.putFloat( -w ).putFloat( -w ).putFloat( 0.0f ).putInt( -cc.asInt() );
vbb.putFloat( -w ).putFloat( -h ).putFloat( 0.0f ).putInt( cc.asInt() );
vbb.putFloat( -h ).putFloat( -w ).putFloat( 0.0f ).putInt( cc.asInt() );
vbb.putFloat( -h ).putFloat( -h ).putFloat( 0.0f ).putInt( -cc.asInt() );
vbb.rewind();

// This is what it SHOULD look like
//if( D3D9.SUCCEEDED( vb.Lock( 0, 0, bb, 0 ) ) ) {
//bb.put( vbb );
//bb.rewind();
// vb.Unlock();
//}

// This is how it's done for now
vb.Lock( 0, 0, vbb, 0 );
vb.Unlock();

// Create a light and enable it
D3DLIGHT9 l1 = new D3DLIGHT9();
l1.Diffuse.fromColor( 1.0f, 1.0f, 0, 1 );
l1.Ambient.fromColor( l1.Diffuse );
l1.Specular.fromColor( 1, 1, 1, 1.0f );
l1.Range = 1000;
l1.Falloff = 100;
l1.Attenuation0 = 1;
l1.Direction.fromVector( -.5f, -1, 0 );
l1.Position.fromVector( 0, 5, 0 );
dev.SetLight( 0, l1 );
dev.LightEnable( 0, true );

// Create a material so the light has something it work from
D3DMATERIAL9 m1 = new D3DMATERIAL9();
m1.Diffuse.fromColor( 0.5f, 0.5f, 0.5f, 1 );
m1.Ambient.fromColor( m1.Diffuse );
m1.Emissive.fromColor( 0, .1f, 0, 1.0f );
m1.Specular.fromColor( 0.1f, 0, 0, 1 );
m1.Power = 1.0f;
dev.SetMaterial( m1 );

// Create the box with normals
ByteBuffer vblight = BufferUtils.createByteBuffer( 96 );
vblight.putFloat( -h ).putFloat( w ).putFloat( 0.0f ).putFloat( -.707f ).putFloat( -.707f ).putFloat( .707f );
vblight.putFloat( -h ).putFloat( h ).putFloat( 0.0f ).putFloat( -.707f ).putFloat( .707f ).putFloat( .707f );
vblight.putFloat( w ).putFloat( w ).putFloat( 0.0f ).putFloat( .707f ).putFloat( -.707f ).putFloat( .707f );
vblight.putFloat( w ).putFloat( h ).putFloat( 0.0f ).putFloat( .707f ).putFloat( .707f ).putFloat( .707f );
vblight.clear();

// Create a texture to render
IDirect3DTexture9 tex = new IDirect3DTexture9();
// Change this to put another texture in
// I used an absolute path because it was easier
r = D3DX9.D3DXCreateTextureFromFile( dev, "E:/My Documents/lwjgl-d3d/lwjgl1.1.4-d3d/LWJGL/res/appletlogo.png", tex );
if( D3D9.FAILED( r ) ) {
throw new RuntimeException( "Unable to create texture because: " + r );
}

// Create the box with texture coordinates
ByteBuffer vbtex = BufferUtils.createByteBuffer( 80 );
vbtex.putFloat( w ).putFloat( -h ).putFloat( 0.0f ).putFloat( 0f ).putFloat( 1f );
vbtex.putFloat( w ).putFloat( w ).putFloat( 0.0f ).putFloat( 0f ).putFloat( 0f );
vbtex.putFloat( h ).putFloat( -h ).putFloat( 0.0f ).putFloat( 1f ).putFloat( 1f );
vbtex.putFloat( h ).putFloat( w ).putFloat( 0.0f ).putFloat( 1f ).putFloat( 0f );
vbtex.clear();

// By default Lighting is enabled
dev.SetRenderState( D3DRENDERSTATETYPE.D3DRS_LIGHTING, false );

long start = System.currentTimeMillis();
int frames = 0;
while( dev.TestCooperativeLevel() == D3D9.D3D_OK ) { // While everything is OK
dev.BeginScene();
dev.Clear( 0, null, D3D9.D3DCLEAR_TARGET | D3D9.D3DCLEAR_ZBUFFER, color, 1f, 0 );

dev.SetRenderState( D3DRENDERSTATETYPE.D3DRS_LIGHTING, false );
dev.SetFVF( D3D9.D3DFVF_XYZ | D3D9.D3DFVF_DIFFUSE );

// Draw the first box
dev.DrawPrimitiveUP( D3D9.D3DPT_TRIANGLESTRIP, 2, bb, 16 );

// Draw the vertex buffer box
dev.SetStreamSource( 0, vb, 0, 16 );
dev.DrawPrimitive( D3D9.D3DPT_TRIANGLESTRIP, 0, 2 );

// Draw the light box
dev.SetRenderState( D3DRENDERSTATETYPE.D3DRS_LIGHTING, true );
dev.SetFVF( D3D9.D3DFVF_XYZ | D3D9.D3DFVF_NORMAL );
dev.DrawPrimitiveUP( D3D9.D3DPT_TRIANGLESTRIP, 2, vblight, 24 );

// Draw the texture box
dev.SetRenderState( D3DRENDERSTATETYPE.D3DRS_LIGHTING, false );
dev.SetFVF( D3D9.D3DFVF_XYZ | D3D9.D3DFVF_TEX1 );
dev.SetTexture( 0, tex );
dev.DrawPrimitiveUP( D3D9.D3DPT_TRIANGLESTRIP, 2, vbtex, 20 );
dev.SetTexture( 0, null );

dev.EndScene();
dev.Present( null, null, null, null ); // Display what was just rendered
frames++;
// Do some basic FPS calulations
if( System.currentTimeMillis() - start > 1000 ) {
start = System.currentTimeMillis();
f.setTitle( "FPS: " + Integer.toString( frames ) );
frames = 0;
}
}

// Clean up if there is a problem
vb.Release();
dev.Release();
}

}


-gz

oh, excellent - when running right now I get this:

Quotejava -cp bin;lwjgl_d3d_pre_alpha\lwjgl_d3d.jar; -Djava.library.path=libs\win32 org.lwjgl.test.d3d.D3DTest
Exception in thread "main" java.lang.UnsatisfiedLinkError: libs\win32\lwjgl-d3d.dll: Can't find dependent libraries
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(Unknown Source)
        at java.lang.ClassLoader.loadLibrary(Unknown Source)
        at java.lang.Runtime.loadLibrary0(Unknown Source)
        at java.lang.System.loadLibrary(Unknown Source)
        at org.lwjgl.d3d.D3D9.<clinit>(D3D9.java:10)
        at org.lwjgl.test.d3d.D3DTest.main(D3DTest.java:30)

I have lwjgl_d3d.jar in the classpath and the lwjgl-d3d.dll and d3dx10_36.dll in the native folder. Not entirely sure what I am missing (dx installed).

Quote from: Matzon on April 10, 2008, 06:43:40
I have lwjgl_d3d.jar in the classpath and the lwjgl-d3d.dll and d3dx10_36.dll in the native folder. Not entirely sure what I am missing (dx installed).

It's d3dx9_36.dll :P.

doh! - same error tho :(

When opening lwjgl-d3d in Dependency Walker, I get the following log:

QuoteError: At least one required implicit or forwarded dependency was not found.
Warning: At least one delay-load dependency module was not found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.
Files marked as red:
JAWT.DLL
DWMAPI.DLL

when I open the lwjgl on I get:

QuoteWarning: At least one delay-load dependency module was not found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.

Files marked as red:
JAWT.DLL
DWMAPI.DLL

Hmmm... I just ran it from another computer with the command java -cp lwjgl/jar/lwjgl_d3d.jar;bin -Djava.library.path=lwjgl/native test.TestD3D and got

QuoteThis application has failed to start because jawt.dll was not found. Re-installing the application may fix this problem.

and then the exception.

I was testing it in Eclipse.  I don't know if that makes a difference.

try compiling with /DELAYLOAD:jawt.dll - thats what we do with lwjgl.dll

Well then, I got it run in a command line.

"C:\Program Files\Java\j2re1.4.2_17\bin\java.exe" -cp bin;lwjgl/jar/lwjgl_d3d.jar;lwjgl/jar/lwjgl.jar -Djava.library.path=lwjgl/native test.TestD3D

Change the path to be the absolute path to your java.exe and it should work.  Yeah Windows...!

-gz

Right that works  ::)
I then changed that path to the texture to my local copy.

Frame opened up - but was grey.
I got the following error:

QuoteException in thread "main" java.lang.UnsatisfiedLinkError: org.lwjgl.d3d.IDirect3DVertexBuffer9.nRelease(J)V
        at org.lwjgl.d3d.IDirect3DVertexBuffer9.nRelease(Native Method)
        at org.lwjgl.d3d.IDirect3DVertexBuffer9.Release(IDirect3DVertexBuffer9.j
ava:48)
        at org.lwjgl.test.d3d.D3DTest.main(D3DTest.java:223)

but since this is in the exit code, that still means that the code doesn't run on my end. Indeed commenting the release part out just gave me the same blank screen.

hang on - I need to test this using 1.1.4 :)

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

files:

QuoteVolume 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

QuoteC:\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)

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

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

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

Quote from: Matzon on April 12, 2008, 07:06:52
* 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.

Quote from: Matzon on April 12, 2008, 07:06:52
* 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.

Quote from: Matzon on April 12, 2008, 07:06:52
* 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.

Quote from: Matzon on April 12, 2008, 07:06:52
* 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 :P.  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

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

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

Quote from: gaarazero on April 14, 2008, 16:02:09
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

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.

Quote from: elias on April 14, 2008, 18:19:21
Anyway, the actual selection of renderer is not as interesting as actually making Display etc. work correctly with both.

True.

-gz

Quote from: gaarazero on April 14, 2008, 19:14:05
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.

Quote from: elias on April 14, 2008, 18:19:21
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

Quote from: elias on April 14, 2008, 19:22:36
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

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?

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

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

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

Any new news so far?