Archive > DirectX
org.lwjgl.d3d Progress / Thoughts
gaarazero:
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
Matzon:
--- 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.
--- End quote ---
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();.
--- End quote ---
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.
--- End quote ---
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 :)
princec:
I'd map the names directly, capitals and all, so C++ code looks very similar, if I were you.
Cas :)
ndhb:
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.
kappa:
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.
Navigation
[0] Message Index
[#] Next page
Go to full version