Will JOGL use Java 1.5 features like typesafe Enum

They haven’t implemented a C++ namespace for OpenGL that uses strict typechecking of enum arguments to the GL API, for the reasons so far outlined. The GL API is designed to work thus:


glDoSomething(GL_WHOOPS); // Illegal argument so do nothing
error = glGetError(); // Check the error at runtime

Cas :slight_smile:

Cas you are simplifying the subject a LOT. Picture a big project like a game you want to sell containing hundreds of source files. A misplaced value on a opengl function call may give an error or it may just do something semanticaly legal but something that is wrong and the lack of type checking will force the tester to spend a lot of unnecessary time looking for something that should have been catched during compile time. And these kind of errors are very hard to come by.

Thats why im going for something similar like i have described above, if there isn’t a clever way to make enum work with JOGL. If i have to mess with low-level C style code in Java then i will have to deal with C style problems i don’t want to when working with real game projects. I must have an advantage when working with Java, otherwise whats the point ?

I don’t think JOGL aims to be another layer between the application and graphics hardware, but a binding that simply allows one to utilize the OpenGL API with Java language. What can be built on top of that, is a different story… I think that one could build such a delegating layer (working with enums only) on top of the current JOGL implementation - but it would require a lot of handcrafted work.

Cheers

[quote]I must have an advantage when working with Java, otherwise whats the point ?
[/quote]
Yes, that’s the point. This is the reason I can’t wait until all APIs which I’m currently using with Java (Xith and Jogl at the mo) switch to Java 1.5’s new things like generics and enums.
Sometimes I hardly can believe the Java world stayed away 10 years (!) from generics. To some Java critic dev folks I’d love to present Java 1.5 as the first Java version ever. :wink:

Ok, generics aren’t directly usuable with a C based API like OpenGL and hence JOGL. Xith and other highlevel APIs would benefit from generics however.
With enums it should be different however. They could be important to JOGL. Even if OpenGL isn’t at all typesafe when it comes to those thousands of “enum” constants: wouldn’t it be possible to offer them to Java devs?
I really wished my compiler would finally stop to compile a statement like this:
gl.glTexParameteri(GL.GL_TEXTURE_2D, GL.GL_TEXTURE_WRAP_R, GL_TEXTURE_MIN_FILTER);

You could implement a delegating wrapper which takes care of the type safety work. For instance:


public class TypeSafeGL implements GL
{
// delegate all methods to a wrapped GL instance
//   and handle enums where required
//
// Note: there are approx. 1500 methods which use
//  GLenum type and should be treated as enums
}

// Usage:
public void display(GLDrawable glDrawable)
{
TypeSafeGL gl = new TypeSafeGL(glDrawable.getGL());

// Not nice, as you cannot directly use enum member GL_TRIANGLES...
gl.glBegin(glBeginEnum.GL_TRIANGLES)
gl.glEnd();
}

Edit: Sorry, my bad. You can use the GL_TRIANGLES enum directly, if it is declared in a public enum (not inside another class…), in a separate file, that is:


public enum GLBeginEnum
{
GL_TRIANGLES, GL_QUADS, etc
}

//...and then the user class has to use static import:

import static jogl.foo.GLBeginEnum.*;

Cheers

[quote] To use LWJGL or JOGL without being able to use java enumerations, generics and all the rest of the magic in 1.5 is worst than working with C++.
[/quote]
combined with this gem of a quote

[quote]I must have an advantage when working with Java, otherwise whats the point ?
[/quote]
Riiiight. Please, go away to your fantasy land and return to doing stuff in C++ since that’s what you prefer doing anyway. If you are incompetent enough to be unable to develop professional applications in the existing pre-1.5 environment, you’ll still be incompetent developing them post 1.5. Those of us that have been developing and delivering large-scale applications in Java for the better part of a decade don’t need your help in evangalising Java. If you don’t already know what the development advantages of Java have been for the time pre 1.5, then you know nothing about Java at all. Come back in 5 years or so when you have some real world experience building large applications.

[quote] You end up building a layer on top of JOGL to hide the nasty and dangerous coding anyway so why not pushing this code into a mini-engine and get rid of the useless layer that is JOGL ?
[/quote]
Right, so now your argument boomerangs right back at you. You should go use Java3D if that is an issue for you. JOGL is the Java bindings to OpenGL. It’s a binding to a pre-existing API. All it does is provide an absolutely minimalistic interface for exposing the capabilities in Java.

As I stated before. If all you want to use is Java 1.5 features, then there’s nothing stopping you from using them right now (other than you making constant whiny excuses). Some, or most of the APIs you’ll be working with do not make use of them, but that doesn’t stop them from being useful and highly productive. Once you actually join the real world of large-scale application code, you’ll realise that it’s never the API that is the problem, it’s the documentation and implementation of it that you’ll spend far more time debugging. Trivial things like having the wrong int value will be insignificant to dealing with why XYZ video card manufacturer’s drivers seem to do weird stuff when you call glFoo after making 4 calls to glBar(), but not 5 calls.

[quote] Cas you are simplifying the subject a LOT. Picture a big project like a game you want to sell containing hundreds of source files. A misplaced value on a opengl function call may give an error or it may just do something semanticaly legal but something that is wrong and the lack of type checking will force the tester to spend a lot of unnecessary time looking for something that should have been catched during compile time. And these kind of errors are very hard to come by.
[/quote]
Or, you haven’t worked on a big project at all. That’s what unit testing does for you. That’s what making calls to glGetError() do for you. If you’re not using these very simple tools, then one can hardly expect to see good quality code as a result. If you can’t visually see these errors, then either they’re never a problem to begin with, or you need to go visit an opthamologist. Debugging OpenGL code is quite trivial compared to debugging the support functions around it such as culling, state sorting collision detection. In my time working on Aviatrix3D - about a year almost fulltime now, I’ve had exactly 2 bugs due to the wrong constant being used. Those took me a total of about 5 minutes to notice (unit testing) and correct. Using enums would have not saved me anything.

How do you unit test your opengl calls?

I try to cover my engine with tests, but the inner rendering code has a coverage near 0%. I have to test the rendering manualy. (Run a small app and inspect the results visualy)

To unit test GL calls you have to do two things:

  1. Inspect the result visually - no way around this.
  2. Check the GL error code and throw an exception if it’s nonzero.

Cas :slight_smile:

If you are creating a scene graph, you make unit tests for each scene graph object individually. The unit tests at this level assume you have passed unit tests for lower-level capabilities, such as culling and sorting (or have them turned off in your pipeline if your scene graph API has that capability). For example, take a geometry object, such as a TriangleStripArray and then have the unit test set all the values in different combinations, one frame at a time. Screen scraping etc allows you to grab each frame or only test one piece at a time and visually inspect the results.

I don’t think i like the tone you are using in this discussion. If you can’t have a discussion like a grwon up person its better you step away.

As for telling me to go to C++ forums let me remind you that this is an open forum to java games strangely called javagaming. Go figure. So why don’t YOU go find a forum about Visualization.

Just because i don’t have experience doesn’t mean i can’t analyse my possiblities and study the market. Instead trying to intimidate people with your great developer pose why don’t you actualy show some knowledge about PC games.

So why many successful PC games have you developed and sold ? What is the name of your studio ? What publishers have sold your great games ? Can we see a review of them on gamespy ?

Doing PC games is not the same thing as doing Visualization little applications. Your Aviatrix is nothing in complexity compared to a full-featured game engine. And im saying it nicely and with an educated tone.

So you’re saying that type-checking is not important. And by the way i saw your documentation. Not much of UML in there and javadocs with contract programming isn’t there.

And the crap continues. But i see statistics and the crap shows on statistics. Things like high-level language constructs and refactoring is what contributes for reducing the work of very complex projects like PC game engines. The ones you never made remenber ?

So you’re saying that junit replaces type-checking and high-order language features and i need an opthamologist ? Man im going to stop answer to you becase this is worst than the Texas massacre.

So says the great software developer of Visulaization projects. ::slight_smile:

Yes but not everyone has 2 years to make Aviatrix3D. If you want to be competitive you need to work in a team with projects having fully normalized dociumentation so that every understands the project; you need to do it well and FAST and thats why high-level constructs are and software tools that take advantage of these constructs are necessary.

Let me repeat it to you: quality, speed and organization.

I sugest you drop that arrogant great developer tone who thinks everyone is incompetent. Try to discuss arguments instead of attacking people and people may respect you more. Not only it makes you look like an asshole but people who come to these forums may feel intimidated and decide not to post in here. I think moderators should pay more attention to these situations where so called great developers come here telling people to shut up and go away.

The company I work for uses OpenGL in java (started with gl4java, now jogl) for GIS software. We decided not to use java3d a couple of years back because we were not happy with the feature set, performance, etc. So now we have a couple of years invested in software that’s based on jogl. The software we sell is a GIS API. If jogl were to become 1.5 dependent our API would become 1.5 dependent as well. This would mean that we have to force all our customers to migrate to 1.5 as well. In an ideal world this might be possible, but for our customers this is not the case.

I do not understand why it is absolutely necessary for jogl to use the latest and greatest jdk features before you would consider it useful to program in java instead of c++. Like some other people said, the java platform has more advantages then just having a nice opengl binding. For me the fact that the GL_* constants are integers has never been a problem. I agree that it might make it possible for some errors to occur at runtime, but a little bit of testing should bring those up pretty quickly. An other alternative the jogl offers is to use the DebugGL class which pinpoints your errors pretty accurately.

[quote]Its much better to have bindings for a native mini-engine that does the bare minimum but allows me to use 1.5 language features, instead of direct bindings to the opengl apis.
[/quote]
While that might be useful, it’s not an opengl binding, which is exactly what jogl is supposed to be. I don’t think a language binding should try to hide any details of the api it is trying to provide access to.

Grrr… reply toooooo long. This is the short version :frowning:

In return, I suggest you not take things personally and realise that I’m debating the concepts you personally have expressed as being desirable, which I am pointing out are non-desirable for anyone with more than a basic set of development experience, regardless of whether it is gaming related or not. If you don’t like having someone debate you by taking your arguments and using them against you, don’t express a public opinion. You asked for an opinion and so I’m giving you one. I bring up my own examples from 14 years of professional software development as these are something I can speak with authority on. In return, you debate with hand-waving and all the hallmarks of someone with no realworld experience.

[quote] Go figure. So why don’t YOU go find a forum about Visualization.
[/quote]
Because this is the one and only JOGL forum. Let me remind you again; JOGL is the Java bindings for OpenGL. OpenGL usage in gaming is a small niche of a far larger set of users. If there was a visualisation forum specifically targeted at JOGL, I would be there. There isn’t. Sun have stated that this is the one and only official discussion forum for JOGL, and so I’m here mixing it up with all the gaming people. If you don’t want non-gamers in here, do something about it - talk to Sun and get them to create another forum.

[quote] Just because i don’t have experience doesn’t mean i can’t analyse my possiblities and study the market. Instead trying to intimidate people with your great developer pose why don’t you actualy show some knowledge about PC games.
[/quote]
Sigh… pity you, Zingbat, can’t understand humour. Perhaps you’re not a native english speaker and so subtly of the english language is lost on you, If so, sorry about that. Re-read that portion you quoted. Features of a language do not make a competent programmer. Adding features to a language or API do not suddenly make a competent programmer. If a programmer is not competent beforehand, they’re certainly not going to be competent after either. In fact, in my experience, they become less competent as they discover the size of their sandpit is now bigger and try to still use all the sand without understanding the basics.

[quote] So why many successful PC games have you developed and sold ? What is the name of your studio ? What publishers have sold your great games ? Can we see a review of them on gamespy ?
[/quote]
Hmmm… depends on one’s definition of “game”. My gaming toys are typically far more expensive than your average college student could afford. ;D As far as professional game development is concerned, no you won’t see them on gamespy. We work with companies doing promotional games, particularly for use at tradeshows. For example, the one coming out at the end of this month will be used for promotional work at a medical conference here in Seattle for heamophiliacs. From what we know, it will be used exactly twice - this conference and another later in the year. Any other time, if you turn up to a conference like I/ITSEC, you’ll see our “games” in use all over the place.

[quote] So you’re saying that type-checking is not important.
[/quote]
Correct. Important meaning causing a lot of problems for application development. In fact, it’s close to a trivial in problem in large scale project development. As I pointed out before, the far greatest time consumer in terms of development and debugging is dealing with 3rd-party issues - driver bugs, external API bugs or features not implemented according to the documentation. One could go on about various theories here about good API design eliminating the need for type checking, but that’s one for the OO-zealots to play with. Here we as discussing an existing, well established and documented API and access to it in a given programming language.

[quote]And by the way i saw your documentation. Not much of UML in there and javadocs with contract programming isn’t there.
[/quote]
Which codebase? There’s at least 8 different public codebases that I’ve worked on. Several very large multi-million line private codebases too, one of them describable as safety-critical. What you happen to “require” for development is not necessarily a requirement for all development. Since you have not been privy to all of the projects I’ve worked on and seen what documentation is provided and where, I’m sure you have no clue about what you speak.

As for documentation of my projects, just what is your point here? Surely it’s not just to make an ad hominem personal attack is it? No, of course not., how silly of me to think so.

[quote] So you’re saying that junit replaces type-checking and high-order language features and i need an opthamologist
[/quote]
Once again, humour is lost on you, zingbat. Rather than assuming a defensive posture, sitback, relax, grab a coffee, and your reading glasses, and comprehend what I am actually saying, not just the words on the page.

Just so that you don’t get confused again, let me restate it a different way - type checking can be handy, but in terms of application development, it is not particularly useful for ensuring code quality. Unit testing is going to be far more useful in the long run. Type checking will not find regression bugs, or invalid data due to the external environment that the isolated piece of code is using having changed. In the couple of examples I gave, I showed how type checking may have saved me a total of about 2 minutes over the period of an entire year of development. That, in my book, means that it’s not useful at all as a development tool for ensuring code quality.

In the cases where there have been bugs related to OpenGL, the problem has been using the right types, but the wrong values. For example, in a volume rendering application I was developing, I had wrap on rather than clamp, which caused all sorts of “interesting” problems. These were immediately visible by what I could phyiscally see on screen. Problems with passing the wrong values to openGL are not going to be a one-pixel issue. You’re goinig to see entire objects look completely bogus - textures or complete objects missing, colour tints wrong. Type checking is not going to help you at all - the right types were passed, just the wrong values. That’s what unit testing and visual inspection are going to help with.

[quote] Doing PC games is not the same thing as doing Visualization little applications
[/quote]
And now who’s doing the belittling? So, since you have no clue about visualisation applications, don’t offer comment on something that you don’t know about. Some basic googling on something like a tank or naval ship bridge simulators will be enlightening. Hard realtime constraints, working with both physical and virtual models and interface to external equipment is far more complex than the very simplified models that PC game development uses.

In return, I ask if you, Zingbat, have actually developed a graphics engine, let alone a game engine? From everything that you have stated so far, it does not appear so (for reference, AV3D is my 3rd such endeavour). Writing off coding of optimised culling routines and so forth is not exactly a trivial task, as you so seem to want to imply.

[quote]Yes but not everyone has 2 years to make Aviatrix3D.
[/quote]
Well, I did state I’ve only been working on it for just under 1 year. But, you stated earlier:

[quote] Why ? Because thats how it is. Just check Doom3, Half-life 2, Morrowind or any other successful game. Game engines are complelety rebuilt every two years (sometimes more).
[/quote]
So which argument are you going to use then? Either game developers (professionals) have to spend every 2 years rewriting their game engine, or they aren’t. You can’t have it both ways here.

Now, going back to my specific example in terms of Aviatrix3D, it has almost all the features of a game engine available today. There’s skinned meshes, a physics engine (just finishing it off today integrating ODE), large-scale terrain rendering, particle systems. Shaders, layers and multipass rendering are all available. About the only thing currently missing is IK. They’re not part of the core AV3D because visualisation takes a different approach - componetised rather than an integrated monolith serving a very specific rendering style. That’s taken me a year to implement as a single developer. Gaming companies, assuming they’re not licensing someone else’s engine, will have 2-3 developers doing the same thing over a couple of years. The comparison in features/capabilities equality seems pretty good to me if you’re considering professional development. Amateur is a different kettle of fish of course, and not one that I’m considering (if you want to, go compare to the Xith3D group as they would be the closest equivalent).

(and the rest of the reply)

[quote]If you want to be competitive you need to work in a team with projects having fully normalized dociumentation so that every understands the project; you need to do it well and FAST and thats why high-level constructs are and software tools that take advantage of these constructs are necessary.
[/quote]
Are these the same game development companies that I know a lot about? I have a lot of friends in the industry. I could count easily 15 really good friends here in Seattle working for a few of the gaming companies here and what you describe is an ideal, but very far from reality. For a specific example, I know 3 former developers of the America’s Army game project. Game development for any A-list game either PC or console is still a 2-3 year cycle. The engine is not built in the first 6 months and then not touched for the next 2 years of content development for the engine. Everyting is constantly in flux dealing with the latest hardware, drivers, changes in the game plot as engine capabilities dictate what will and will not work.

Going back to the quip about UML and contract programming earlier, I’d actually like to see a game company do that! Having seen a lot on the inside of these companies, that’s really far from reality. In an idealised world, that would be great, but it’s not happening. You should have seen the documentation that came with the UT engine the AA guys were using. Makes my documentation look like a work of art! :wink:

Eeeh chaps, nuff with the mudslinging! Best agree to disagree.

Interesting point about JOGL, games, and scivis not being in the same boat. I wonder really what JOGL is doing in this forum myself :wink:

Cas :slight_smile:

No you were not debating anything you were becoming personal. As for the sense of humor exit thats the usual lame thing to say. Anyway if you really want to debate your points of view i wont become personal. That depends on you.

For instance, you didn’t debate the fact that making a PC game is completely different from anything else and that you didn’t show any experience or knowledge on the PC games subject on management or on dealing with publishers. There are douzens of reports from people who developed and managed successful PC games available on the internet that explain in detail the complexety of the task.

As for N friends you know from the industry and the worked M years on some field YOU consider related to PC games what does it mater ? If you have been working with old techniques and working that way all these years you can’t really say anything about OO and moderm programming language techniques. And even if you tried to use them there is a big chance that you like all the others who fall in the same line of thought when trying to move from an old tech to a new one didn’t do it correctly. If you read Meyers OO book there are many cases presented there similar to yours.

If OO and UML are just new fashions or not i prefer to believe in Meyer and Boch who have a very long curriculum testing OO in the field than a person i know on an internet forum.

If you don’t want gamers in here then talk to Sun and ask them to get a forum for your taste. Im not the one who come up with that atitude.

Neither he will recognize why using high-level languages features will improve and even be critical to his work.

I was talking of java PC games that can compete on the same field with HL2, Doom3 and Morrowind being examples. It looks pretty straight to me.

No problem. Your interests are different than mine. Completely different. My interests are called PC games.

You could do in assembler too. Why not ? There are so many good techniques for working in assembler. And after all if one knows how to program he doesn’t need all those sissy stuff right ? Right if you want to spend your life working on a single project and doing very simple stuff.

You miss the purpose of type-checking completely. And i think i mentioned not only type-checking but high-level features available in Java and the way the Java language itself is designed. Type-checking is not just for checking errors you know it also allows the optimizer to work better and is intimately linked to everything else.

I disregard that example completely since i don’t know the details of your little adventure and im talking about complex projects like modern PC games where an high-level aproach to the problem is much more productive and economical.

I am revising my aproach to the problem of building a modern PC game in Java. I think most of those problems happen because you are working with JOGL at a very low level that is not suited for the Java language.

Im not interesting on using JOGL at all. My aproach is working with a binding to a C++ mini-engine, that way preserving the advantages of java programming language and making the engine independent of opengl, directx or whatever.

Java3d would have been a good solution if it wasn’t so monolitic and in some parts a really bad feature creapled OO design. Having to install a different version of java3d just to be able to use DirectX instead of OpenGL doesn’t make any sense.

Excuse me ? Im not the one telling you to shut up becasue im a great software developer with X years of work.

Are we talking of an engine used for making modern PC games ?

Anyone who comes here with an interest on at least try building PC games (unless its only a sport) and sell them must aspire to making quality games comparable to the best PC games in the market and at the same time using the advantages of Java language:

  • high-level language, full enums, generics, etc…
  • much better portability
  • advanced garbage collection
  • better optimization because it is an high-level language and uses garbage collection
  • better tool integration and refactoring using tags
  • contract programming and automatic code validation
  • UML translation to java using CASE tools
  • junit only when none of the previous apply

This is what will allow people who use Java to make PC quality games faster and with less effort. Sure we can use junit for eveything and screw everything else but the important thing to notice is in small easy to read steps:
… FASTER PRODUCTION SAME QUALITY gets your money sooner … you gain MORE MONEY FOR YOUR TIME … you can DO THE GAMES YOU LIKE with more time on your hands.

As for Aviatrix3D being usable for a PC game engine, i think its better you make a demo of it running a Doom3 level with near quality and speed (notice im saying near 80% or so). And you are forgeting AI code integrated with the physics engine (less modular right ?), software to export/import data formats from common art aplications, advanced animation package that can combine animations and is affected by physics (modularity fails again).

Not to talk about that your engine must be at the same time very well documented and manageable to be used by others. And this means a good OO design and UML diagrams.

When you do this then i will give some credit to you, but not until you actualy show people proof of concept for all your inflated claims. Even so that doesn’t mean you can do it faster and without quality penality if you use Java properly.

Hi all, to try to soften a little the debate let me start we a little quotation, as Beaudelaire wrote : “Là, tout n’est qu’ordre et beauté,Luxe, calme et volupté.”
Which translate (very approximatively) as “Here everything is order and beauty, luxury, stillness and sensuousness.”

So, letting this apart, what about the topic of this thread…
First of all, I’m not sure that this using 1.5 features is the main issue for JOGL. A lot of big problems (ATI workaround, stability and so on ) have been pointed up by Ken, not to mention the JSR to define OpenGl place in Java. And keeping a backward compatibility with previous JDK is MANDATORY.

And I would like to re-insist on one point : JOGL is a binding to OpenGl which is a library used for many, many things …

Game industry, like other software industries, nowadays, make products as quick as they can. Sometimes it’s a good job, sometimes you have to wait patch 1.12.365.321.14234.2 to have all the vertex in the good direction and no bug. Result : Boss happy, shareholders happy on the one side and customers unhappy as well as developers who want to make a great job (not a quick and dirty one).

So to end it before I lose myself : Keep cool guys, if some new features of 1.5 land in JOGL we’ll use it (or not), if it don’t came i will wait because i think JOGL is a good library and I don’t want to use C++ and I don’t want to be a DirectX developer, light help me…

You’re right about version hopping in general, however… generics and in particular enums aren’t “the latest” but have been brought to Java very very late. So it’s not just an ordinary new Java release. Sun states Java 1.5 is the most important Java release since its debut 10 (?) years ago and … they’re right.

Just wanted to add that the whole point of having something like jogl is so that you can write your ‘mini-engine’, full fledged engine, or something else in java. If jogl didn’t exist and you wanted to write an engine from scratch in java, you would still need to write native code to access opengl. Provinding full and direct access to opengl gives developers the freedom to use opengl in whatever way they please without having to fallback on writing native code.

[quote]So you’re saying that type-checking is not important.
[/quote]
This sentence could lead us back to the origin of the thread… which has been… :
“Detect as many errors at compile time, not at run time.”
This is what I’ve learnt many many years ago.

Finally we Java fans got enums and generics (to name two new things) which will move a lot of errors from run time to compile time. I’m sure many people are keen to see this being used as many times as possible to make their apps (games are apps!) much more robust.

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…

Btw it’s good that in this nice forum game developers as well as application developers talk to each other and share their knowledge. (Many of us belonging to one of the two groups at day and to the other group at hobby time. :slight_smile: