What if we could have in one binding the choice to use either OpenGL or DirectX? I have idea this idea a long time ago but now it seams clear to me java gaming won't go anywhere without a quality DirectX binding.

My idea was to create a small rendering engine written in C (not C++ classes for compatibily) that would either use OpenGL or DirectX. The interface would dynamically link the necessary .dll to either use OpenGL or DirectX.

On the Java side there would be only one binding, to this small rendering engine.

The advantages i see with this solution is a much more clean binding than JOGL or LWJGL and a much more useful one since we aren't restricted to just one native api and a new api (perhaps a software rendering engine) could be added at the C language level without having to mess with the Java binding. Doing two separate bindings would be less efficient and more important much more trouble to maintain IMO.

Having a DirectX binding is very important if not critical for java gaming and i see this now with consoles like XBox gaining more importance.

I posted on that thread but I changed my mind on this matter. I neglected how the confidence factor affects the acceptance of technology. If people have the choice, when running a Java to choose between using OpenGL or DirectX as the native cg api, just having this choice, would give them more confidence about using Java to make PC games.

I don't see JOGL being accepted as much as it could have been after all this time. One thing is the real quality of technology, another is people who make decisions accepting it and knowing that in the future Microsoft can't make our game unplayable because it only works with with OpenGL.

Another thing would be stability... DirectX "just works" whereas OpenGL has all sorts of compatibility issues and ATi with their flakey drivers... they got a lot better, but does everybody and their mother have those recent drivers? Nope.

The only problem is that you'd get the lowest subset of shared capabilities/functionality of DirectX and OpenGL in your "little C engine". everybody wants other features, so it'd never be useful for anything complex, probably only aimed for the casualgame market? With that features in mind you could as well just run it with OpenGL 1.4.

So what would we gain?

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

I posted on that thread but I changed my mind on this matter. I neglected how the confidence factor affects the acceptance of technology. If people have the choice, when running a Java to choose between using OpenGL or DirectX as the native cg api, just having this choice, would give them more confidence about using Java to make PC games.

Given the choice, I think lots of people would prefer an industry-standard API (ie. OpenGL) rather than Joe Blogg's 3D Engine Spectacular, even if it does have multiple backends. You'd have much more success IMHO by building a D3D binding library, and then writing a separate 3d engine capable of using it or an OpenGL binding behind the scenes (or better, extending JME or Xith to use use the D3D backend).

Isn't Java3D open source now? It might be worth using that as a starting point.

The only problem is that you'd get the lowest subset of shared capabilities/functionality of DirectX and OpenGL in your "little C engine".

Why would it have to be that way? Some PC games have an option to use either DirectX or OpenGL and they don't have to sacrifice anything. If you switch to a renderer that has less features the game will simply query the features available and use only those. In these cases we have to restart our game for changes to apply.

Most games use DirectX, for the most part. It's becoming harder to find a game that uses OpenGL exclusively.

I don't think it makes much of a difference between having a mini-engine in C or having a Java engine on top of two separate bindings (for OpenGL and DirectX). The mini-engine would be easier to maintain if it's api was simple enough and we wouldn't have to make so much native calls. The disadvantage would be to have to maintain more code on the C side.

You'd have much more success IMHO by building a D3D binding library, and then writing a separate 3d engine capable of using it or an OpenGL binding behind the scenes (or better, extending JME or Xith to use use the D3D backend).

I don't have the skills to do a DirectX binding myself. I have to divide my free time for games between learning modeling, texturing and programming games so i wouldn't have the time either.

How hard would it be to make a DirectX binding for Java? DirectX also supports sound, image/movie loading, input and a lot of other things so it would be worth it.

I don't think it makes much of a difference between having a mini-engine in C or having a Java engine on top of two separate bindings (for OpenGL and DirectX). The mini-engine would be easier to maintain if it's api was simple enough and we wouldn't have to make so much native calls. The disadvantage would be to have to maintain more code on the C side.

I don't have the skills to do a DirectX binding myself. I have to divide my free time for games between learning modeling, texturing and programming games so i wouldn't have the time either.

1. As a programmer, I'm more inclined to use a 3d engine which is separated out from the low level binding. One written as a separate layer above is likely to be of higher quality than having them all mixed into one big API.

2. I'd much rather deal with an engine written in Java instead of C. Not only is it likely to be more robust, but when it goes wrong it'll be much easier to debug. Your API will likely suffer due to having to worry about memory management on the C side.

3. Good 3D engines are hard. If you don't have the skills to write a D3D binding, why should I risk using your engine?

"One written as a separate layer above is likely to be of higher quality than having them all mixed into one big API."

"I'm more inclined to use a 3d engine which is separated out from the low level binding."

The mini-render would be a simple layer without a scenegraph or anything fancy that would just render batches of polygons using a common binding api. Such low-level code would be perfect for C and would simplify the binding process.

"I'd much rather deal with an engine written in Java instead of C."

Ok. Personal preference.

"Not only is it likely to be more robust, but when it goes wrong it'll be much easier to debug."

Robustness is important for certain types of applications but for games robust enough usually do. It would probably be much harder to say to a guy that is going to sell your game that it only works with Open GL. The key here is confidence.

"Your API will likely suffer due to having to worry about memory management on the C side."

Again whats the problem? Most PC games are made in C++ and don't even have GC and do they sell less because of this?

Besides we are talking about a mini-renderer that would be very small with a simple job to setup batches of polygons to render and that's it. Something that would not require a full GC and could even use a customized memory management solution as it's usually the case with C programs when they want to reduce allocation time.

This is a software component we see in most C++ games that separates the engine from the low level cg api. It doesn't have to support every exotic feature that OpenGL or DirectX supports and isn't something so complicated that would require the high-level features of the Java language or GC.

This said i think he way they are doing this with Java3D interests me more than JOGL.

frankly this is not a new idea and one that I have had before numerous times. My solution revolved around the C library being a consumer of data that is given by the Java layer. The Java layer would contain Materials and the Vertices etc, the C library would have 1 point of entry where it would render the geometry.

Unfortunetly, like Riven said, you end up supporting the lowest common denominator and I'll give you a solid example of that:

Say you have an enum that holds the format of textures available: DXTn, RGBA, then comes RGBA_16F. Now the problem with the last one is you need new hardware to support floating point textures, but you can't declare RGBA_16F in the enum because not all HW can support it....

With this particular example, you can query the C layer for a list of supported texture formats, but this is a simplistic example of why its a bad idea and I suppose this is one of the main reasons why Java3D is having a hard time keeping up with the latest and greatest in graphics...

So what would your "mini renderer" do? Untextured polys? Textured polys? Multitexturing? Blend states? Render to texture? Shaders? Compressed textures? Visibility culling? Geometry caching? Clipping? Stenciling? A simple renderer that only did basic textured polys might be easy to write, but you're going to have a hard time convincing people to switch from something full-featured and standard like OpenGL just based on some mythical, hand-wavy "confidance" factor.

I dont think thats a fair statement to make Orangy Tang. Its a startup engine so it will take time to get all the features of the other engines. With time and active developers, any engine gets features, its whether you like the API is the question...

Lot's of talking. If you think it's a good idea, start it, get something running - if it works then it'll be easier to assess if it's a good idea, and hopefully encourage assistance and users. If you think it's too much effort to start without a team - then possibly the idea isn't that good in the first place.

I dont think thats a fair statement to make Orangy Tang. Its a startup engine so it will take time to get all the features of the other engines. With time and active developers, any engine gets features, its whether you like the API is the question...

DP

I guess I just don't understand the logic behind claiming that "java gaming won't go anywhere without a quality DirectX binding.", and from that leaping to the idea that an entirely new C-based engine is the way forward.

DirectX binding? Fine, go right ahead. New 3d engine? Cool, knock yourself out. But you can't realistically claim that jamming them both into one big lump is a better alternative.

FWIW, I think the best way to support D3D is to write a D3D binding instead of some new engine.As soon we have that, we could try to use it in a platform independent way, for example, writing an OpenGL->D3D wrapper, for example as an LWJGL plug-in. That way, we have best of both worlds, and we're still able to use existing engines.

I mean, it would be such a waste to write a D3D binding specifically for some new engine which didn't prove itself yet so which might never be used. Besides, we already have J3D which does exactly that.

If you'd go this route, you should start with making a "little C engine" on top of LWJGL. Then you'd run into all kinds of problems (what to support, why, how) and you'll see how restricted you are (or how you are going to restrict the user), even with only 1 backing API. Pumping geometry around would be hard enough. What (interleaved) formats to support? All?

DX has no immediate-mode, you don't have push/pop of any matrices, no translate/rotate/scale for the current matrix... you'd have to either manually emulate that, or simply not support it. How are you going to deal with MODELVIEW+PROJ (2 matrices) in OGL and MODEL+CAMERA+PROJ (3 matrices) in DX?

What you are basicly are asking of a user (dev) is to forget all about OpenGL and DirectX and instead learn "ÿour little C engine". In which case you should market it just like that, not as a "OGL/DX hybrid". It would be something like "Slick" (kevglass) for 3D: the user shouldn't even care much about the backing, and the end-user even less.

Therefore I think the "confidence factor" in DX is completely not relevant. End-users don't care, at all, and they mostly don't even want to know. If they see a dropdown box to chose the backing-implementation (containing OpenGL and DirectX) they are forced to think about techy stuff... they want to play a game for ** sake. Everything that gets in the way (every click of a button) will only annoy them. So if you were to hide that from the start-screen, almost everybody will play with the default setting. There goes "confidence factor" out of the window. If you have to mention DirectX in the marketing of your fullblown game, to pump the confidence factor, all the confidence would be destroyed by having "Java" mentioned on the same page.

Your valuable time is spent better by making a simple layer on top of OpenGL, for ease of use for developers, and work from there. Such an API is not available yet, because everybody that reached that point, went further and built a scenegraph (and whatnot) around it.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

The most valuable thing missing from Java right now is a full DirectX binding.

This thread is full of FUD and general misinformation and general "haven't actually done it myself" sorts of posting, and so I hope you'll bear with me with my thoughts on this as someone who is desperately trying to make a living from writing games in Java:

1. WRT driver quality: D3D drivers are more or less exactly as buggy as OpenGL drivers, on all platforms, from all vendors. If someone actually has OpenGL drivers, it's likely that the drivers they have are good enough quality. If you rely on cutting edge features in any API expect trouble. And don't forget the Mac market folks, it's big. Much bigger than you think.

2. WRT consoles: who cares, there's no JVM. Give up on the idea until there is one.

3. Never mind users' confidence. What you should be concerned about is developers' confidence. I for one will feel much safer knowing there is a DX binding available for Java should I need to unlock that 35% of Windows machines (actual statistic I have measured myself over 3 years) that don't have OpenGL. Also there is a large installed programmer base of C++/DX programmers that simply won't switch to Java because they know D3D and don't want to try and learn everything in one go. There is a comfort factor in knowing that your preferred APIs are available.

4. If you're going to write an OpenGL / D3D abstraction layer then do it in Java, and code to Java bindings. Keep the C code to an absolute minimum, because it's a total arse to maintain. Performance will be identical, maintenance will be much easier, and on top of it all, you don't have to use it because if you want you can use the DX binding directly if you want.

5. Still waiting for a volunteer to propose a LWJGL D3D binding...

6. No-one really cares whether a binding is cross-platform or not. They exist to fill gaps that Java doesn't cover. So please don't anyone argue against a DX binding on that basis; you will be simply ignored by those that want the binding.

7. Someone has stated that Java won't go anywhere without a D3D binding. This is probably correct. It's the main API used by real games programmers industry wide. So someone had better step up to the challenge Then we might get some converts. Even Carmack might get interested.

Like i said before i'm just discussing some ideas not saying i'm going to do anything.

"DX has no immediate-mode, you don't have push/pop of any matrices, no translate/rotate/scale for the current matrix... you'd have to either manually emulate that, or simply not support it. How are you going to deal with MODELVIEW+PROJ (2 matrices) in OGL and MODEL+CAMERA+PROJ (3 matrices) in DX?"

Much more games use DirectX than OpenGL, so what's the problem?

Have you ever looked at DirectX documentation and support material? You have .x exporters for most 3d modelers. DirectX supports apis to play movies, load textures, get input from controllers, play sound and music in many devices. If we were to make a java game for the xbox we would only require a good javavm and a directx binding.

"Therefore I think the "confidence factor" in DX is completely not relevant. End-users don't care, at all, and they mostly don't even want to know. If they see a dropdown box to chose the backing-implementation (containing OpenGL and DirectX) they are forced to think about techy stuff..."

What about the guys that will buy your game? Do they also think this issue is irrelevant? You are going to spend 2-4 years making a game. In the meantime a lot of things can happen but Microsoft will always be there supporting DirectX and making sure it works for it's clients. That's confidence factor. That's the reason why most games use DirectX and not OpenGL.

"Your valuable time is spent better by making a simple layer on top of OpenGL, for ease of use for developers, and work from there. Such an API is not available yet, because everybody that reached that point, went further and built a scenegraph (and whatnot) around it."

Most engines have a renderer as a fundamental engine component. It abstracts the renderer code from the native graphics api and lets programmers link different rendering apis. Besides it's good coding pratice to make the scenegraph loosely tied to the renderer so that you can still render stuff and control the order and details of your render without the need of a scenegraph.

The C renderer would simply be a C version of the renderer component binded to an abstract renderer Java class. Alternatively we could have the renderer made in java and direct bindings to directx and opengl but how would this be a better solution? Without someone testing this solution it's not obvious to say what would work best. So i don't think there would be much problem with it's usefulness since this is a fundamental component.

2. WRT consoles: who cares, there's no JVM. Give up on the idea until there is one.

I have to disagree with that argument. The market for consoles is huge. With a DirectX binding it wouldn't be so hard to port a Java game to the XBox since DirectX provides almost everything except for storage and the bare OS services.

The Playstation 3 is another case but that would not be a problem if the PS3 would support linux and then we would also have an easy support for the Macs. PCs + XBox + Playstation3 + Macs i wouldn't throw this away.

Like i said before i'm just discussing some ideas not saying i'm going to do anything.

Quote

DX has no immediate-mode, you don't have push/pop of any matrices, no translate/rotate/scale for the current matrix... you'd have to either manually emulate that, or simply not support it. How are you going to deal with MODELVIEW+PROJ (2 matrices) in OGL and MODEL+CAMERA+PROJ (3 matrices) in DX?

Much more games use DirectX than OpenGL, so what's the problem?

Have you ever looked at DirectX documentation and support material? You have .x exporters for most 3d modelers. DirectX supports apis to play movies, load textures, get input from controllers, play sound and music in many devices.

All not useful, because you get the lowest-common-denominator of OpenGL and DirectX.

Quote

If we were to make a java game for the xbox we would only require a good javavm and a directx binding.

dream on about consoles. not going to happen (basicly what Cas just said)

Quote

Quote

Therefore I think the "confidence factor" in DX is completely not relevant. End-users don't care, at all, and they mostly don't even want to know. If they see a dropdown box to chose the backing-implementation (containing OpenGL and DirectX) they are forced to think about techy stuff...

What about the guys that will buy your game? Do they also think this issue is irrelevant? You are going to spend 2-4 years making a game. In the meantime a lot of things can happen but Microsoft will always be there supporting DirectX and making sure it works for it's clients. That's confidence factor. That's the reason why most games use DirectX and not OpenGL.

I don't see how that's relevant. OpenGL isn't going to move anywhere too. And if so, what would you rather have? A (sucky, unsupported) hybrid API (like you said: a lot can happen in 2-4 years) or a decent DirectX binding?

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

We are not talking about what you or me or what the end-user think. You have to convince someone who thinks that apples are oranges or maybe it's you who thinks that aplles are oranges and you have to please that guy. Otherwise you won't sell your game. That guy is not changing his opinion with free Java lessons but only when you give him something he can trust. Even if it implies making a product that is technically inferior (but not in a noticeable way) but gives (to this guy) a greater insurance of success. There's nothing to rationalize here. This is about marketing and what your investers believe it works.

Consoles really aren't going to happen... until they do. But before then there really is no point considering them in your game designs or business plans. Concentrate on using what technology there is to get games out there on actual computers that currently exist.

Right now we're seriously missing a DirectX binding, and that's the missing technology link that'll open up the doors to everything else.. XBox, portals, PCs of all flavours, abstracted rendering layers, etc.

Right now we're seriously missing a DirectX binding, and that's the missing technology link that'll open up the doors to everything else.. XBox, portals, PCs of all flavours, abstracted rendering layers, etc.

In the 2D world, Java 2D is really promising if you consider Java 6 and the fact that this release will be omnipresent in the future (within 5 years maybe?)

In the 3D world, we still have Java 3D. Why not seriously considering supporting its dev and maintenance to make it up to date with the latest DX features (because that's an actual problem)? Its architecture might cause performance issues compared to Xith3D for example but why not focusing on those weaknesses?

DirectX programmers that do 2D really don't want to learn Java2D, it's a different beast, and you have a lot less freedom.

DirectX programmers that do 3D really don't want to learn Java3D, because they either have their own engine, or don't want to have to wait before bugs gets fixed (the fact that's opensource doesn't mean you can just fix something the way you like best), or simply because it's way too highlevel.

If we want to attract DirectX programmers, we need a DirectX binding, not another API they don't (want to) know about and makes them feel restricted.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

How hard would it be for someone to do this binding? I browsed the DirectX documentation and it is very well written with lots of examples and tutorials. Microsoft Visual Studio is even free now and all the libs are freely accessible from the internet. For someone that has already made something similar it should be relatively easy i suppose.

On Java3D i like this api a lot since it was the frst high-level graphics api i used and it could be improved a lot by making it more flexible. That is we can choose whatever graphics device, input device, sound device or whatever we want to use. The problem with improving Java3D directly is that this effort would only benefit Java3D and could not be used by other engines like Xith or jME.

The binding itself is really not that hard to do. LWJGL could be relatively easily modified to cope and add it as an "optional module" like we do for DevIL and FMOD. Somebody just needs the time and inclination to do it. Maybe we should post an advert?

The binding itself is really not that hard to do. LWJGL could be relatively easily modified to cope and add it as an "optional module" like we do for DevIL and FMOD. Somebody just needs the time and inclination to do it. Maybe we should post an advert?

Cas

Wouldn't a lot of the current display code require changing to cope with creating either an OpenGL display or a D3D display?

I thought D3D made heavy use of reference counted objects too, which doesn't sound nearly as easy as binding to some static C functions.

The binding itself is really not that hard to do. LWJGL could be relatively easily modified to cope and add it as an "optional module" like we do for DevIL and FMOD. Somebody just needs the time and inclination to do it. Maybe we should post an advert?Cas

I hope someone has the time and inclination because this is something that would help the entire community. All those guys that are working on Java game engines consider the benefits of a DirectX binding that could be used by everyone. Unfortunately the only thing i can do is make threads like this here and in other java related sites and hope someone who can do this binding will see my point of view. Posting for help on a non-java related site would be useless i think.

I'm kind of too busy with my day job and another project on the side, so at the moment I don't have the time to both learn D3D and to get the binding started.When I'll have some more free time on my hands (hopefully somewhere this summer or fall), I might give it a go.

The way I see is that for any game maker out there, there already exists a 3D binding that "does the job" (LWJGL or JOGL), so there is no incentive for anyone to make a D3D/DX binding.

In anycase, the next OGL release would be Object based rather than ID based like we have now. So both wrappers are going to have to change to accompany this. This is a good thing for a DX binding because it bridges DX and OGL ever closer in terms of API and then someone perhaps might be inclined to make a DX binding

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org