Tiny bit off topic ;D
If you’re interested in this topic you should read Bruce Eckel’s article. Personally I tend a little bit more towards the type safe camp, but my experiments with objective c and cocoa so far are proving me wrong
[quote]Some people say it’s technically nearly impossible to do a type safe enum mapping with an OpenGL binding (like Jogl) because of the way OpenGL builds its constants?
If this is so, that’s bad…
[/quote]
Personally I don’t really care much for type safety in this case. The original C api does not use enums. It uses GLenum which is a typedef for unsigned int. Not much safety there :). Even if you wanted to make enum types for this, you would have to create a whole lot of enums if you want absolute type safety. Basically about one enum for each GLenum paramter of each function (I might be misunderstanding enums here, correct me if I’m wrong please). And even then this doesn’t prevent you from using the wrong value. Like Mithrandir said, you could for instance be using clamping instead of wrapping for some function and your compiler wouldn’t complain, but the result would still be wrong. As Eckel points out in his article no amount of compiler checking or good OO design can replace runtime tests. In the end it just seems like lots of work for very little gain in this case.
Deftly side stepping the “my 3d app is bigger than yours” debate, has anyone got a practical, workable, way of implementing said type safety?
Even besides the issue of translating enums into GL constants, you’d need massive (and tedious) amounts of checking in each function to check that the right ones were passed in. And even that’d be tricky to write as you’d have to do runtime checking of avalible extensions and the combination of enums.
Adding compile-time checking is only going to be half-accurate, as it can’t anticipate that kind of thing. The end result probably leading to more complacency and causing as many bugs as it stops.
[quote] Some people say it’s technically nearly impossible to do a type safe enum mapping with an OpenGL binding (like Jogl) because of the way OpenGL builds its constants?
[/quote]
Technically, it is possible to do it. Whether it’s practical or not is a different question, and one I that I think it is not.
The first problem is methods that take bitmasks of these enums - glClear() for example. Since an enum is a class, you can’t make bitmasks of classes. You need an alternative representation. Either you could take the class think to the extreme and set the parameter as a java.util.Set, which has a huge amount of overhead per-call (needing to create iterators etc, which then require JVM locking of the data structures while in native land), or you pass a non-type safe array of them in. The first costs you an unacceptable performance penalty, the second costs you the desired type-safeness.
The other penalty is one that Orangy Tang start to elucidate. You need to do this checking on the native code side. It also needs to be dynamic based on the user’s installed hardware and available extensions. Considering the thousands of constants available, that’s a hell of a setup time that needs to be taken care of. Not only that, but it’s per-graphics pipe specific too. Think of a PC with one AGP card and one PCI card - or even the new machine with two different brand PCI-X cards fitted. Now the native code needs to keep thread-specific information and know which context is doing the calling. That’s a lot of extra native code to have around and far from the goal of JOGL being a thin veneer.
Adding to this is the problem of the automated code generation. Once you start having to do type-specific constant convesions, and even just the basic setup of all those enum classes, that automated code generatoin goes right out the window. I wouldn’t say it’s impossible to do, but it’s darn close to it. A huge amount of semantics needs to be built into the automatic generator. Once you start heading down that path, you might as well just hand-roll the API bindings rather than auto-generate. That’s explicitly against one of the goals of JSR-231.
I had some code written out for this to copy in here, but considering that I fell asleep twice while writing this reply, I think it’s better I not post it because it will be junk… I’ll reply to the rest of the emails tomorrow once I’ve had a sleep. Darn builders waking me up at 4:30am… :-X
I’m all for compile time type safety and Java 5 has some great new features like generics, enums and foreach that will increase the number of errors found at compile time.
However, in a Java API like JOGL which is designed to be an almost 1:1 mapping of an existing C API, I think it would be bad to try to introduce new concepts not found in the C API, like type safe enums. You will lose some performance and the API will differ more from the one you’re trying to emulate. It is better to include all the benefits of OOP and Java in a higher level abstraction like Xith3D and other game engines. OpenGL is a badly designed C API that was never intended to be type safe. Let’s keep it that way.
[quote]The first problem is methods that take bitmasks of these enums - glClear() for example. Since an enum is a class, you can’t make bitmasks of classes. You need an alternative representation. Either you could take the class think to the extreme and set the parameter as a java.util.Set, which has a huge amount of overhead per-call (needing to create iterators etc, which then require JVM locking of the data structures while in native land), or you pass a non-type safe array of them in.
[/quote]
java.util.EnumSet was added to 1.5 for that very purpose.
[quote]I’m all for compile time type safety and Java 5 has some great new features like generics, enums and foreach that will increase the number of errors found at compile time.
However, in a Java API like JOGL which is designed to be an almost 1:1 mapping of an existing C API, I think it would be bad to try to introduce new concepts not found in the C API, like type safe enums. You will lose some performance and the API will differ more from the one you’re trying to emulate. It is better to include all the benefits of OOP and Java in a higher level abstraction like Xith3D and other game engines. OpenGL is a badly designed C API that was never intended to be type safe. Let’s keep it that way.
[/quote]
That’s a good summation of the various pros and cons.
[quote]java.util.EnumSet was added to 1.5 for that very purpose.
[/quote]
Is there any good tutorial on how to use EnumSet and EnumMap (and others) except that small one inside the Javadoc “What’s new” ?
I don’t think that the bitmask enums would be the biggest problem - it could be handled with the EnumSet, as suggested.
But why would the stuff need to be implemented on the native side of JOGL? I would rather see the possible usage of enums and other 1.5(5.0) specific features as an overlay to the existing (raw) binding.
Read Meyer OO design book instead. No wonder you you have such a wrong idea of it.
Again read Meyers and book and don’t relly on people you know very little about. Eckel probably doesn’t know when and how to take advantage of OO techniques. And just because he couldn’t do it he thinks no one else can.
OO is java philosophy. Using Java without using its full OO capabilities is wasting it as a programming tool. Of course you still need to use tests but high-level constructs let you program more cleanly and let the compiler use high-level optimizations. If you read my previous post thats what im saying there. Working with inteligence means working faster with less effort and more quality.
That could be a possible solution for people interested in JOGL for other areas than modern PC games. For this area however there are a lot of problems on using it.
Just some problems that come to my mind:
Your engine would be code dependent of OpenGL. You couldn’t switch to DirectX or a Software rendering engine or anything else easly.
If you wanted to port your game to a console you would need a jvm that would run on the console and at the same time a version of OpenGL ported to the console and the bindings for the two.
The amount of native calls for working with a binding that maps function to function to OpenGL.
OpenGL is very low-level so you would have to do a lot of patch code to make it less low-level and this isn’t Java’s strong point.
Doing binndings to a with a mini-engine on the other side as many interesting advantages:
You can tell your mini-engine what graphics lib to use at startup.
The Java side needs to do much less native calls.
The PC games market is very demanding on perfomance and is technology starving. A solid and fast OO solution is perfect for it.
Portability to consoles is much easier. The mini-engine take cares of whatever graphics lib the Console is using in a transparent way and still being able to switch to OpenGL/DirectX when running on a PC or any other gl for a different code. If you do your mini-engine in C++ this task would require compiling only some classes in the mini-engine.
A game engine is composed of many modules that do not require to be done in C++. For instance AI, scene-management, physics, animation, io, network, editing, etc… The mini-engine takes care only of the core essential features.
This one i have been thinking it for a long time. Some people say that OpebGL is old a problematic while DirectX is mor clean. Honestly i don’t know which one is more problematic.
With a mini-engine solution Sun could build its own graphics library in C++ and integrate with the mini-engine. This sounds like an herculean task but Sun has influnce on the major graphics card vendors and maybe Sun could convince them to make drivers for his own GL api.
With this Sun would have more control on the Console market and could deliver its own Console game solution in Java.
This thread started with enums ;D but i think that the problem is really if JOGL is a competitive solution for doing modern PC games or not. Having enums may not be a problem with relatively small and not so complex or speed demanding projects. But doing modern PC games is something completely different.
Well, I think this is getting a bit OT too. JOGL is an Java OpenGL binding, not a 3D-engine or an abstraction layer written in Java. What is then built on top of the binding is another topic.
Wow there, calm down. I think you should be a little bit more careful making such rash statements. Why are my ideas necessarily wrong? How do you know what my ideas are from one sentence? Anyway, I never meant to judge on what is right or wrong. Just wanted to point Bombadil to an interesting article.
How well do you know the author of any book. 99% of the time you can only judge based on reputation. And Bruce Eckel’s reputation isn’t that bad last time I checked. I assume you are talking about Bertrand Meyer BTW. If you think his ideas are the only right way forward maybe you should start programming in Eiffel instead of in Java (just kidding). I know Bertrand Meyer by reputation as well, and by reputation he’s an arrogant asshole (who happens to be correct most of the time when it comes to OO stuff)
Testing and OO design are two distinct things in my eyes. Good OO design will make your code more readable, maintainable, flexible, … Testing will make sure it actually does what it’s supposed to.
One aspect of OO design is layered design. Instead of trying to force OO design into an inherently non-OO api, I think you should build a nice OO layer on top of the “ugly” API.
Again I think it’s a matter of flexibility. As a java developer I would want to create an OpenGL based engine in java. Not have to write something in c first and then create a java binding for that.
Just out of curiosity I would like to know people’s background a little just to see where you guys are coming from (not to judge or anything). I’ll start myself: I studied computer sciences at the university of Leuven in Belgium and I’ve been programming on the previously mentioned GIS api and related projects for three years now. I know it’s not that much experience, but you’ve got to start somewhere
Sorry for making this thread go off topic btw. I’ll stop now ;D
JOGL is perfectly competitive for modern gaming. Just not as competitive as LWJGL 8)1
Here’s an anecdote: once I’d wrapped up texture creation in a GLTexture class, I haven’t looked at the code for over a year, and no longer care about the names of the constants or whether they’re right or wrong. The same goes for all sorts of other functions.
In fact, it is surprising just how little of your code actually calls the OpenGL API. Perhaps the enum thing is a red herring - a bit like building a concrete fortress to guard a peanut. Overkill and overhead.
[quote]JOGL is perfectly competitive for modern gaming. Just not as competitive as LWJGL
[/quote]
“Join me! Together we can rule the galaxy as father and son.”
Yes, you’re correct about the small fraction of actual OGL code in an application. Besides, the constants and enumerations are a small pain, compared to other fun anomalies possible to achieve with OpenGL code ;D …
[quote]Perhaps the enum thing is a red herring - a bit like building a concrete fortress to guard a peanut. Overkill and overhead.
[/quote]
My whole point condensed into two sentences. I couldn’t phrase it any better than that ;D
Im not saying your ideas are all wrong but they are not what OO advocates. Its just as simple as that. No personal offense intended.
Bertrand Meyer just has a better curriculum and worked in the OO field during more years and in more projects than anyone else. So he is in a better position to speak of OO. Besides his position is backup by Boch and many other figures that actualy did a considerable work the area.
Actualy I have Eiffel55 personal edition. Too bad that thing doesn’t work with a virtual machine like java.
Blah that is street chit-chat and not really worth of consideration.
Actualy thats where your view of OO doesn’t match with the advocated ones. OO is much more than just about type-checking but type-checking fundamentaly linked to every other feature in the language like code optimization, classes, generics, etc…
That is exactly the problem what we need: a layer on top of JOGL. I think everyone on this thread who is disagreeing with the weight of java enums on JOGL at least agrees on the layer thing. Not something like Xith3d or Aviatrix3d or any other candidate for a java game engine, but a collection of high-level interfaces that could be extended to provide the basis for things like Xith3d or Aviatrix3d to run on top.
I think this solution is very nice. It could work with JOGL or any other binding or even a native mini-engine in a transparent way and at the same time isolate programmers from chitty C programming style that JOGL will force people to mess with.
You realise however that by building a layer in java and on top of JOGL it will be using the garbage collection and the java language itself for sonething that Java is not good at: patching C style code into a more Java friendly one. Not to mention the huge anount of native calls that will be made all the time.
If you want to create modern PC games in Java or at least try to pursuit that objective for a time then you have to instruct yourself behind what they teach in Univ.
There are many sites on the internet that give a very good insight about this field like gamasutra and gamedev. Another good way is to buy games and try to mod them to how things work in detail from inside.
Just discussing figures rep and fancy ideas is not enough. We need to put them on the code and test them. Thats what i intend to do.
the management sections. Its very rare for someone actualy reusing an old engine.
[/quote]
Which is very very much their mistake. Just because something’s been done one way for years doesn’t mean that is the best way - or even a mildly correct way (often it’s the wrong way).
I was speaking to someone about this just last week and found common ground here, a great deal of frustration about games studios continued failings to get much out of re-using engines rather than wasting time and money re-inventing. He’s an industry veteran who’s just left EA, so on the other side of the fence, so to speak (i.e. only codes in C++, works for a giant games company).
And if you feel that they ought to be more biased towards java, you can help by volunteering something for JGF (link below). Persuading publishers (and developers) of the value to them, personally, of java games is part of JGF’s mission (so that we can all get jobs / funding / publisher contracts that little bit more easily ;)).
</shameless plug ;D>
And what does 5 have that is truly earth-shaking…um… still thinking …um… :P.
(and, 1.2 was too - it introduced Collections (!) for the first time (only 7-8 years ago), the whole of Swing, tolerably good reflection, etc).
Bascially, 5 is exciting in some ways (some good stuff for us networking people, some good stuff for multi-processor people, plus the first OpenGL java2D implementation, etc), but certainly nothing spectacular on the grand scale of things - the rest is just Sun’s incompetent marketing dept’s bullshit.
