Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (756)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (842)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1]
1  Java Game APIs & Engines / JOGL Development / Re: GL4JAVA VS JOGL on: 2004-04-05 17:08:08
Last time I checked LWJGL is only supporting full screen modes and does not support the Swing Widget set, or any windowing operations for that matter.  Not everyone is trying to make games with these toolkits.  It looks like I'm still hungry.... Smiley
2  Java Game APIs & Engines / JOGL Development / Re: GL4JAVA VS JOGL on: 2004-04-03 15:29:28
Good luck with that....   Kiss

My last two cents:
If it can be made safe, FULLY functional and fast, then I'm all for it, however I haven't seen this possible yet.  Please someone, make me swallow my words.

3  Java Game APIs & Engines / JOGL Development / Re: GL4JAVA VS JOGL on: 2004-03-31 11:02:33
Safety is important, however if you claim to be a binding for OpenGL, then be a binding for OpenGL.  It just as easy to pass a NULL array to any of the OpenGL calls, thus causing major havoc, are there checks for everything?  We need to educate programmers.  If you're old enough to buy a hammer, you're old enough to hit your thumb....

4  Java Game APIs & Engines / JOGL Development / Re: GL4JAVA VS JOGL on: 2004-03-30 16:20:39
Well JoGL and Gl4Java are vastly different, and in my honest opinion GL4Java is a much better binding to OpenGL, it has all the hazards and capabilites of OpenGL.  the JoGL team is attempting to add layers of protection over OpenGL that make its use more limited.  For example, last time I reviewed the code, there was no way to perform manual buffer swapping, GLCanvas was final and you couldn't extend it, you had to use a factory to instantiate one, in addition, there was no way to make a context current directly.  You have to indirectly tell JoGL thorught the invokeGL command or run all of your openGL commands through the display(GLDrawable drawable) callback.  We are staying with GL4Java and have been invited to participate in JSR 231.  JoGL is not a bad implementation, it just prefers safety over capability.

5  Java Game APIs & Engines / JOGL Development / Re: Vote time: RFE - Developer controlled swap buf on: 2003-11-20 19:31:07
I will have to defend Ken and the JoGL team here a little.  It's definitely not a hand wavy attemp at an OpenGL binding, they are trying to mitigate the risks involved of the makeCurrent,free, and swapping conundrum that appears.  We all want it to be as robust as possible and as safe as possible.  I am on your side that this functionalty needs to exist and I have some ideas, but what the JoGL team needs is feedback of what you are trying to accomplish in each of the programs, whether it be manual buffer swapping or makeCurrent and free operations.  I have already submitted to Ken an implementation that supports custom swapBufferStrategies that will allow your desired behavior, but he had some problems with me making too many things public.  We'll get through this I'm sure, but it's going to take some thought.

6  Java Game APIs & Engines / JOGL Development / Re: Vote time: RFE - Developer controlled swap buf on: 2003-10-27 08:53:53
I have been in an email discussion with Ken on implementing this functionality and there is a disconnect between our philosophies, and seeing that there are other people trying to solve this problem, I thought maybe we can all just post our concept implementations, the actual code isn't important here, just the methodology and why:

Here it goes for me:
One of the onus' of OpenGL has not been safety, but always flexibility, if safety was the primary concern than there wouldn't be the inventive ways that people of bastardized some of the OpenGL calls, resulting in very nice effects or visualizations.  The makeCurrent and free are just another necessary part of OpenGL, no safer or less safer than any of the other state changing functions.  Granted it has much more far sweeping side effects, but so does going into the wrong matrix mode in the middle of your drawing routine.

My methodology behind doing the implementation in the way that I had sent is because it offered both safety, convenience and the ability to kick you in the butt if you did it wrong.  Safety and convenience through the classes that manage the buffer swap automatically, the different SwapBufferPolicy(s), but I also exposed the [make curent and free] calls.  Granted the swapBufferPolicy classes could have been written to use package only accessor's for buffer swapping, but then the user would have to add to this repository if they needed a different behavior.  Granted they can be very sneeky and insert a rouge class into the package, basically making a different jogl than everyone else is using, but when updates are available, they once again have to repackage.

-Jason (just my 3 and a half cents)
7  Java Game APIs & Engines / JOGL Development / Re: JSR 231 on: 2003-10-07 22:45:37
  I have a close relationship with people from SGI and am working on getting some of these pieces of information together.  Right now it is very hush hush all around.  I hope that the Java community can come together and figure this out.  I am trying to make contributions on a personal basis to JOGL, but will eventually move to whatever "standard" there is for Java/OpenGL bindings.

8  Java Game APIs & Engines / JOGL Development / Re: Vote time: RFE - Developer controlled swap buf on: 2003-09-18 23:30:54
I started coming up with a reference implementation but I am having to change many more things to really get it where I want it to go.  For this first "trial" version are we to alter the least amount possible, or really make the implementation that we think is right.  Once you allow OpenGL calls to be made outside of a current context, one needs to be able to query wether that context is current.  That would be a lower level change than maybe at this stage is necessary.  Any thoughts?

9  Java Game APIs & Engines / JOGL Development / Re: Extending GLCanvas on: 2003-09-16 22:17:58
I'm done with the implementation, how do you want me to post it?

I also made a jogl-demo...
10  Java Game APIs & Engines / JOGL Development / Re: Vote time: RFE - Developer controlled swap buf on: 2003-09-15 11:59:28
Yes we need it.  Especially for synchronizing the display of multiple buffers, for things like stereoscopic systems or cave environments.
11  Java Game APIs & Engines / JOGL Development / Manual Buffer Swapping on: 2003-09-12 00:57:59
I know that this has been brought up in other topics but I want to talk about a particular problem.  I am using GL4Java to perform passive stereoscopic visualization and the ability to synchronize the buffer swap on two independent views is critical.  This goes even further when I am using multiple computers to generate a single composite view.  Without being able to maually dictate when the buffer swap should occur, I'm sunk.  I have reviewed the code and I think I may be able to add the functionality into GLContext to support what I want to do, but want to hear from others on what other functionality is important.  I have this notion of a SwapBufferFence that needs to hear from all of the Context's that it's managing (remote or otherwise) and then call swap buffers on all of them "at once".
12  Java Game APIs & Engines / JOGL Development / Re: Extending GLCanvas on: 2003-09-06 17:30:14
I really hate to bring this up again, but I was hoping that as time passed there would be more banter on this subject.  While I know that jogl is open source and I can change the libraries to say whatever I want them too, I am going to once again suggest that GLCanvas becomes instantiable and non-final.  For safety reasons, I will not press the case in making any methods/fields un-finalized.  When events are propagating around the system, it would be nice to tell the users of my API that the mouse event came from my API and not expose any part of JOGL.

Maybe I'm the only one making an API with JOGL?  I kinda doubt that.....

As an aside, how does JOGL relate the the agreement that Sun and SGI signed that says they are going to write a Java binding to OpenGL?  It sounds like it may be YAJOGL (Yet another Java to Open GL).
13  Java Game APIs & Engines / JOGL Development / a concern Re: More API Feedback on: 2003-07-10 22:28:21
I've already started a thread on extending GLCanvas and will continue to support removing of all unnecessary final declerations, particulary for the sake of "safety".  I can respect the motivations and if that is a concern, make a SafeGLCanvas that extends GLCanvas that restricts people from mucking where they shouldn't, if they do not understand the problems that are inherent.

14  Java Game APIs & Engines / JOGL Development / Re: High resolution Timers on: 2003-07-10 22:24:40
If you ask me, that is a terrible way of setting frame rate.   You need to ask yourself whether you want a FPS construct at all.  Most of the time, games want to render as many frames per second as possible.  If that is the case then you want to record the time between the last time that you rendered and the next time and that would dictate the amount on animation that has taken place and update the locations of elements accordingly.


I am sure someone is going to argue with me on this, so look for some good discussion.
15  Java Game APIs & Engines / JOGL Development / Re: Extending GLCanvas on: 2003-06-29 22:12:46
Everyone knows how I feel about the final keyword, but if you don't, it's great in an application, but should be used VERY sparingly in an API.  As a comprimise I would accept the class to be public with some final methods.  That would allow me to accomplish the tasks that I need to, in an architectural fashion that is pleasing to the people using my tools, otherwise I need to do extra conversion and object creation or expose internals about what bindings I am using.  I cannot agree more that we cannot make things safe.  "while(true); " still has caused more problems than a well documented API that warns you of the inherent danger in extending and replacing it's functionality.  As an aside... I really dislike factories, the classes that they produce could be implented differently and hide the abstractness of the underlying structure (Win32, Mac, Linux...)

16  Java Game APIs & Engines / JOGL Development / Re: Extending GLCanvas on: 2003-06-27 20:32:48
Well, it was asked what I am doing when extending GLCanvas, to this class called Graph3D.  Graph3D contains not only the Canvas, but the camera that performs manipulation in the scene.  It also has Universe3D(s) that are drawn by this Graph3D.  It also deals with requests for re-rendering in a non-blocking fashion.  So when the user presses the mouse button in the Graph3D,  it notifies the listeners just like every other Java component and the user will often do something like move the view.  Since the Graph3D IS the view, they can call Graph3D.getCamera().dolly(), etc.  At the same time, when the Universe has changes to it, either through adding, deleting, or modifying some geometry, it notifies all the Graph3D's that they need to re-render the scene.  So that is the skinny on what I am doing by the current subclassing of GL4Java's GLCanvas.  Since what I write is ALSO an API, I can understand the problem with allowing users to extend a class and "screw" things up.  I am highly against making classes or methods final in the lowest level of an API.  The decision that we've taken is that we have at the lowest level a set of interfaces that can be implemented, then a number of InterfaceAdapters  that implement those interfaces in varying modes of complexity and safety.  These implementing adapters are then capable of having the diversity of extreme safety to extreme flexibility.  Would it be OK to have some methods final, yeah I guess, but it would have to be inconjunction with not having to use the factory as defined by the current implementation.  If it would be useful I can gin up some simple contrived examples of what I mean.

17  Java Game APIs & Engines / JOGL Development / Extending GLCanvas on: 2003-06-26 22:36:37
I read that there was a request to make GLCanvas non-final and instantiable.  I also read that it was denied, since managing open GL context's in conjunction with Java is difficult.  I can understand that a lot of issues can arise, but extending the class is a valid and useful thing to do.  Right now I am using GL4Java, I use to use Magician, and am currently extending GLCanvas, to a class called Graph3D, to fix some bugs in the underlying implementation and to add a slew of capabilities.  Think about registering mouse listeners to that Graph3D, it needs to be returned as the source of mouse/keyboard events.  In the case that I cannot subclass GLCanvas, I have to requests for registering mouse events to the Graph3D, just pipe them to the GLCanvas, and on the way back make the source the Graph3D again, or I have to expose to the users of my API that there is this thing called a GLCanvas, which I do not think is acceptable.  Especially when we are changing underlying OpenGL binding implementations like diapers on a baby.   Embarrassed

18  Java Game APIs & Engines / JOGL Development / Re: High resolution Timers on: 2003-06-24 22:45:57
I never expected my little request to cause such a fever of discussion.  Grin Timers are critical to accurate animation and for profiling.  While you may all be looking at uses for jogl that are for games.  I am not.  I am currently using GL4Java to write the realtime visual portion of simulations, for scientific analysis, and for non-realtime rendering to generate MPEG's.  I do not know if there is a concensus here, I am feeling that there is not, but it brings up a more important question on how the open source community is going to deal with Requests For Enhancements (RFE) for jogl?  The jogl site has an area for votes, are we to use that?

19  Java Game APIs & Engines / JOGL Development / Re: High resolution Timers on: 2003-06-23 22:55:00
I need a true cross platform API for the timers, Java3D isn't going to cut it.  I have not run across the GAGE timers before and unfortunately there is only a Windows implementation.

The fact that it's a hidden on JDK1.4.2 and may be exposed in a later version is a trend in the right direction, now all we need is unsigned primitives and we're all set...  Smiley

I will look at writing more of the ports for the GAGE timers, it appears to be not quite what I need, but thanks for the heads up.

20  Java Game APIs & Engines / JOGL Development / High resolution Timers on: 2003-06-22 10:10:00
There are significant flaws in the millisecond timer that ships with the normal JDK.  I am suggesting that we write a High Resolution Timer to give microseconds, just as Magician did, otherwise I've found java animation to be a little jumpy.  Take a look at :

I think this is the way to go.

Another question is that If I wanted to write this and submit it back, what is the process to do that.  I tried to register as a developer but the jogl admins said they weren't accepting that role yet.

Pages: [1]
DesertCoockie (54 views)
2018-05-13 18:23:11

nelsongames (86 views)
2018-04-24 18:15:36

nelsongames (76 views)
2018-04-24 18:14:32

ivj94 (761 views)
2018-03-24 14:47:39

ivj94 (93 views)
2018-03-24 14:46:31

ivj94 (645 views)
2018-03-24 14:43:53

Solater (106 views)
2018-03-17 05:04:08

nelsongames (187 views)
2018-03-05 17:56:34

Gornova (428 views)
2018-03-02 22:15:33

buddyBro (1088 views)
2018-02-28 16:59:18
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05 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‑
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!