Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (578)
games submitted by our members
Games in WIP (498)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2] 3
  ignore  |  Print  
  Will JOGL use Java 1.5 features like typesafe Enum  (Read 7431 times)
0 Members and 1 Guest are viewing this topic.
Offline pepijnve

Junior Member




Java games rock!


« Reply #30 - Posted 2004-10-05 20:21:16 »

Quote

Ignore them. They can use Java3d for other type of applications besides games. JOGL is for making games and game programming requires constant updates to use the latest features.

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.

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.
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #31 - Posted 2004-10-05 21:46:23 »

Grrr... reply toooooo long. This is the short version Sad

Quote
 
I sugest you drop that arrogant great developer tone who thinks everyone is incompetent.


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.


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.


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 ?


Hmmm... depends on one's definition of "game". My gaming toys are typically far more expensive than your average college student could afford. Grin 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.


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.


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


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


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.


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


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

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #32 - Posted 2004-10-05 21:46:58 »

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


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

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #33 - Posted 2004-10-05 23:28:33 »

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 Smiley

Offline zingbat

Senior Member




Java games rock!


« Reply #34 - Posted 2004-10-06 17:44:46 »

Quote

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.


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.

Quote

If you don't want non-gamers in here, do something about it - talk to Sun and get them to create another 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.

Quote

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.  


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

Quote

Hmmm... depends on one's definition of "game".


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.

Quote

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.


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

Quote

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.


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.

Quote

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.


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.

Quote

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.


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.

Quote

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.


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.

Quote

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.


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

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.


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

Senior Member




Java games rock!


« Reply #35 - Posted 2004-10-06 17:51:46 »

Quote

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


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.
Offline turquoise3232

Junior Member




Java (games) rock!


« Reply #36 - Posted 2004-10-06 18:31:04 »

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.....
Offline Bombadil

Senior Member





« Reply #37 - Posted 2004-10-06 18:49:46 »

Quote

I do not understand why it is absolutely necessary for jogl to use the latest and greatest jdk features

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.
Offline pepijnve

Junior Member




Java games rock!


« Reply #38 - Posted 2004-10-06 18:52:10 »

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 ?

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.
Offline Bombadil

Senior Member





« Reply #39 - Posted 2004-10-06 18:58:56 »

Quote
So you're saying that type-checking is not important.

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. :-)
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline pepijnve

Junior Member




Java games rock!


« Reply #40 - Posted 2004-10-06 19:40:55 »

Quote

"Detect as many errors at compile time, not at run time."
This is what I've learnt many many years ago.

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

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.
Offline Orangy Tang

JGO Kernel


Medals: 51
Projects: 11


Monkey for a head


« Reply #41 - Posted 2004-10-06 19:57:38 »

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.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #42 - Posted 2004-10-06 22:33:21 »

Not to mention a vast bloat of the JOGL library.

Cas Smiley

Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #43 - Posted 2004-10-07 03:44:21 »

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?


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.....  Lips Sealed

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Offline phazer

Junior Member




Come get some


« Reply #44 - Posted 2004-10-07 08:41:46 »

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

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.


java.util.EnumSet was added to 1.5 for that very purpose.

Offline Bombadil

Senior Member





« Reply #45 - Posted 2004-10-07 09:01:28 »

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

That's a good summation of the various pros and cons.

Quote
java.util.EnumSet was added to 1.5 for that very purpose.

Is there any good tutorial on how to use EnumSet and EnumMap (and others) except that small one inside the Javadoc "What's new" ?
Offline phazer

Junior Member




Come get some


« Reply #46 - Posted 2004-10-07 09:49:08 »

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" ?


Don't know. EnumSet seems to be very easy to use though. For example:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
public class EnumTest {
  enum Direction {UP, DOWN, LEFT, RIGHT};

  public static void giveMe(EnumSet<Direction> directions) {
    if (directions.contains(Direction.UP)) {
      System.out.println("Up");
    }
  }

  public static void main(String[] args) {
    giveMe(EnumSet.of(Direction.UP, Direction.LEFT));
    giveMe(EnumSet.allOf(Direction.class));
  }
}


EnumMap is used just like a normal Map.

Offline nnevatie

Junior Member




It is slightly better to be simple than correct.


« Reply #47 - Posted 2004-10-07 13:00:07 »

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.

Awards:
- Nobel Prize in Physics for inventing his Doomsday Machine
- Nobel Peace Prize for not using it

http://www.g0dmode.com -- a collection of things not real
Offline zingbat

Senior Member




Java games rock!


« Reply #48 - Posted 2004-10-07 13:59:41 »

Quote

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


Read Meyer OO design book instead. No wonder you you have such a wrong idea of it.

Quote

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.


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.
Offline zingbat

Senior Member




Java games rock!


« Reply #49 - Posted 2004-10-07 14:35:49 »

Quote

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.


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  Grin 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.
Offline nnevatie

Junior Member




It is slightly better to be simple than correct.


« Reply #50 - Posted 2004-10-07 14:56:15 »

Quote

This thread started with enums  Grin 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.


Awards:
- Nobel Prize in Physics for inventing his Doomsday Machine
- Nobel Peace Prize for not using it

http://www.g0dmode.com -- a collection of things not real
Offline pepijnve

Junior Member




Java games rock!


« Reply #51 - Posted 2004-10-07 15:30:13 »

Quote

Read Meyer OO design book instead. No wonder you you have such a wrong idea of it.

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.

Quote

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.

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

Quote

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.

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 Smiley

Sorry for making this thread go off topic btw. I'll stop now Grin
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #52 - Posted 2004-10-07 15:33:13 »

JOGL is perfectly competitive for modern gaming. Just not as competitive as LWJGL Cool1

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.

Cas Smiley

1 hahhaaa, j/k, don't flame my pants

Offline nnevatie

Junior Member




It is slightly better to be simple than correct.


« Reply #53 - Posted 2004-10-07 15:40:20 »

Quote
JOGL is perfectly competitive for modern gaming. Just not as competitive as LWJGL


"Join me! Together we can rule the galaxy as father and son." Smiley

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

Awards:
- Nobel Prize in Physics for inventing his Doomsday Machine
- Nobel Peace Prize for not using it

http://www.g0dmode.com -- a collection of things not real
Offline pepijnve

Junior Member




Java games rock!


« Reply #54 - Posted 2004-10-07 15:46:57 »

Quote
Perhaps the enum thing is a red herring - a bit like building a concrete fortress to guard a peanut. Overkill and overhead.

My whole point condensed into two sentences. I couldn't phrase it any better than that Grin
Offline zingbat

Senior Member




Java games rock!


« Reply #55 - Posted 2004-10-08 08:57:55 »

Quote

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.


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.

Quote

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.


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.

Quote

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


Actualy I have Eiffel55 personal edition. Too bad that thing doesn't work with a virtual machine like java. Wink

Quote

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


Blah that is street chit-chat and not really worth of consideration. Wink

Quote

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.


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

Quote

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.


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.

Quote

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.


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. Wink
Offline zingbat

Senior Member




Java games rock!


« Reply #56 - Posted 2004-10-08 09:00:14 »

Quote
JOGL is perfectly competitive for modern gaming. Just not as competitive as LWJGL Cool1


Now you will have to explain yourself.
Cool

Im also inclined to think that LWJGL can do a better job than JOGL.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #57 - Posted 2004-10-10 15:28:00 »

Quote
I sugest you guys read more:

http://www.gamasutra.com

or

http://www.gamedev.net  

the management sections. Its very rare for someone actualy reusing an old engine.


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

Quote

a publisher won't be convinced by telling him the game is made in java or not


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 Wink).
</shameless plug Grin>

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #58 - Posted 2004-10-10 15:50:25 »

Quote

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.


/me clears throat...

1.4 was a **** of a lot more important than 5.

NIO buffers? Fullscreen?

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. :P

/me ducks and runs for cover!

malloc will be first against the wall when the revolution comes...
Offline nnevatie

Junior Member




It is slightly better to be simple than correct.


« Reply #59 - Posted 2004-10-10 16:00:25 »

Quote

And what does 5 have that is truly earth-shaking...um... still thinking ...um... :P.


Well, we have this really cool new feature called Genecasts (oops, Generics):

http://mindview.net/WebLog/log-0050

;D

Awards:
- Nobel Prize in Physics for inventing his Doomsday Machine
- Nobel Peace Prize for not using it

http://www.g0dmode.com -- a collection of things not real
Pages: 1 [2] 3
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

xsi3rr4x (27 views)
2014-04-15 18:08:23

BurntPizza (22 views)
2014-04-15 03:46:01

UprightPath (38 views)
2014-04-14 17:39:50

UprightPath (20 views)
2014-04-14 17:35:47

Porlus (36 views)
2014-04-14 15:48:38

tom_mai78101 (61 views)
2014-04-10 04:04:31

BurntPizza (119 views)
2014-04-08 23:06:04

tom_mai78101 (219 views)
2014-04-05 13:34:39

trollwarrior1 (186 views)
2014-04-04 12:06:45

CJLetsGame (193 views)
2014-04-01 02:16:10
List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:05:20
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!