Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (582)
games submitted by our members
Games in WIP (503)
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  
  jogl API feedback requested for JSR 231  (Read 12885 times)
0 Members and 1 Guest are viewing this topic.
Offline djp

Junior Member





« Posted 2004-04-09 20:00:19 »

As most of you are probably aware, jogl will be used as the starting point for the Reference Implementation for JSR 231 Java bindings to OpenGL (see http://jcp.org/en/jsr/detail?id=231).  The people who read this forum have some of the most experience with this API.  I would like to solicit your feedback regarding the jogl API.

I don't want "jogl crashes when I do x" type of issues.  While legitimate problems, they are not tied to the creation of an API specification.  Assuming everything worked 100% as advertised, what parts of the API would you want to see changed and why.  The better the explanation, the better the JSR 231 Expert Group will be able to determine the importance of the issue.

Please note there are no guarantees that any issue posted will be addressed, the Expert Group will decide how best to deal with all issues.

As a starting point, here are the issue I thought were relevant from the open issues in the jogl.dev.java.net project:
     52  Current GLU semantics need to be properly encapsulated
     63  NoAutoRedraw paint behavior
     27  convenient usage of jogl from a jdk perspective

d
Offline kevglass

JGO Kernel


Medals: 85
Projects: 25


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #1 - Posted 2004-04-09 20:40:01 »

I think theres a fair bit of interest in this concept of abstracting away the window/canvas management, i.e. removing the dependancy on AWT, or does this break JCP in some way?

Kev

Offline abies

Senior Member





« Reply #2 - Posted 2004-04-09 21:05:06 »

I think there is one very big problem which can be even a showstopper - safety. Currently, it is possible to do almost everything (crash machine, probably even take over root) using JOGL, as it allows to overflow native buffers by driver. I think it would be first JSR api which would allow such thing. To avoid it, a large number of checks would have to be made for many calls - slowing things down and probably not catching all cases anyway, given number of drivers/environments.

With java3d, it was possible to crash jvm using some bugs - but this was just crashing virtual machine and it could be fixed. Here, more serious danger is present by very design of exposing direct driver calls. This means that opengl binding would have to be out-of-reach for anything what does not have 'all-permission'. Even for such code, exposing api which make it trivial to crash jvm (at least) is a bit strange for JCP...

Reassuming - I don't think it is possible to provide safe opengl binding, especially safe for non 'all-permission' code usage - it can be a major point for design discussion.


On the other subject, it would be nice if gl prefixes could be removed from methods - they are really redundant and make IDE job very hard (at is often starts to autocomplete after first or second letter, resulting in HUGE hint list).

Please also think about removing suffixes - java overloading should help in many cases here. Not really sure about it, because sometimes it could be ambiguous...

And my pet sleeve - VBO should use int for offsets, not 'offset buffers' - IMHO it is a hack, which does not protect from crashes/misuse anyway.

Artur Biesiadowski
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #3 - Posted 2004-04-09 21:24:28 »

Quote
I think theres a fair bit of interest in this concept of abstracting away the window/canvas management, i.e. removing the dependancy on AWT, or does this break JCP in some way?

Kev


Do you have a concrete suggestion on how to do this? The GLDrawable interface is designed to abstract away the differences between GLCanvas and GLJPanel. I don't see any technical reason why we couldn't have a GLFullscreenDrawable interface with a couple of extra methods and a new GLDrawableFactory.createFullscreenDrawable() API. However, the built-in full-screen functionality of the AWT seems to work in at least most cases.
Offline overnhet

Junior Member




Java games rock!


« Reply #4 - Posted 2004-04-09 21:49:10 »

1) No additional safety checks please, it could kill performance and make it really difficult to compete with native apps. Wouldn't a big "WARNING : Don't mess too much with buffers" be sufficient ? Grin

2) Restricted permission could prevent the use of OpenGL in applets,  so this decision shouldn't be taken lightly (IMHO OpenGL applet could be a great way to draw people into java game development).

3) I second the removing suffixes proposal, "duplicated" functions clutter the API.

For example, glActiveTextureARB and glActiveTexture are exactly the same thing so it would make sense to merge them into a single glActiveTexture call which would fall back to glActiveTextureARB if necessary.

If I understood the whole ARB process correctly, we could suppress every ARB suffixes. As of EXT suffixes I don't know : is there the any guarantee that they would keep the same meaning if they were promoted to ARB or core ?

4) VBO offset : I haven't used them yet but any nice, non native way to handle them would be welcomed  Smiley
Offline pdjensen

Senior Newbie





« Reply #5 - Posted 2004-04-10 01:39:17 »

The support for controlling buffer swapping. See the thread:

     Vote time: RFE - Developer controlled swap buffer
Offline elias

Senior Member





« Reply #6 - Posted 2004-04-10 07:24:15 »

I like to think that the VBO issue is fixed nicely within LWJGL, by tracking the current VBO buffer and then allowing for int offsets only when the buffer is != 0. It's a bit tedious to track it because of glPush/PopClientState and the overloaded methods, but it's worth it imho.

Furthermore, we'll very soon begin working on abstracting out the rendering context from the rest of LWJGL. Please let's not duplicate the efforts again by being blind to the alternatives....

- elias

Offline kevglass

JGO Kernel


Medals: 85
Projects: 25


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #7 - Posted 2004-04-10 08:12:29 »

Quote

Do you have a concrete suggestion on how to do this? The GLDrawable interface is designed to abstract away the differences between GLCanvas and GLJPanel. I don't see any technical reason why we couldn't have a GLFullscreenDrawable interface with a couple of extra methods and a new GLDrawableFactory.createFullscreenDrawable() API. However, the built-in full-screen functionality of the AWT seems to work in at least most cases.


Cas seemed to have to pretty well thought out ideas here:

http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=jogl;action=display;num=1077270484

The objective was to support API clients of JOGL (e.g. Xith3D) being able to abstract away which rendering layer they were using cleanly. The dependancy of JOGL on AWT makes it pretty messy to support LWJGL or any other native implementation (DirectX one day?) as an provider of a rendering layer.

Kev

Offline cjbeyer

Senior Newbie




Java games rock!


« Reply #8 - Posted 2004-04-10 22:18:12 »

I would really like the API ro remove all the redundant gl and GL instances.
Isn't:

 gl.texParameteri (GL.TEXTURE_2D, GL.TEXTURE_WRAP_S, GL.CLAMP);

so much cleaner than:

gl.glTexParameteri (GL.GL_TEXTURE_2D, GL.GL_TEXTURE_WRAP_S, GL.GL_CLAMP);
Offline GKW

Senior Member




Revenge is mine!


« Reply #9 - Posted 2004-04-11 06:24:44 »

Are you getting carpal tunnel from typing GL_?  Seriously though the spec says GL_ so I think we should do GL_.  I am an ee so I may be overly anal.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #10 - Posted 2004-04-11 17:54:29 »

Better multihead support definitely needed. Sometimes it is needed to run JOGL programs on multiple different heads from different and the same Java VMs. Currently I use modified version of JOGL with a patch from Issue #45 "JOGL multihead fix for linux" to run JOGL application (actually, Xith3D app) on 8- and 12-headed systems, but it would be really better to define screen during context creation via GLDrawableFactory and leave GLCapabilities to define requesting context capabilities.

Yuri

Yuri Vl. Gushchin
JProof Group
Offline shawnkendall

Senior Member





« Reply #11 - Posted 2004-04-11 18:07:36 »

Quote
I would really like the API ro remove all the redundant gl and GL instances.
Isn't:

 gl.texParameteri (GL.TEXTURE_2D, GL.TEXTURE_WRAP_S, GL.CLAMP);

so much cleaner than:

gl.glTexParameteri (GL.GL_TEXTURE_2D, GL.GL_TEXTURE_WRAP_S, GL.GL_CLAMP);


The GL. in GL.GL_CLAMP goes away automatically in Java1.5 when using static imports.

The gl.glFunctionName should stay and will have to stay to be OpenGL standard compliant.

Shawn Kendall
Cosmic Interactive, LLC
http://www.facebook.com/BermudaDash
Offline abies

Senior Member





« Reply #12 - Posted 2004-04-11 20:49:07 »

Quote

The gl.glFunctionName should stay and will have to stay to be OpenGL standard compliant.


Sorry to be picky about this issue, but I don't think it is true. I have just opened OpenGL 1.5 spec and functions does NOT have any prefix. If anything, then C library is not standard compilant, because it added gl prefix trying to work around lack of namespaces. [1]

AFAIK, only reason for leaving glVertex3f as it is was to make copy/paste porting from C easier. Search/replace gl -> gl.gl is easier than Search/replace gl -> gl.[and next letter to lowercase]. My solution was to leave method names with big letters (thus conforming exactly to opengl spec), but different choice was made by JOGL maintainers.

[1] - additionally, it is explicitly allowed to omit 3f from Vertex3f if language allows for that. GLSpec 1.5, page 7:
"The declarations shown in this document apply to ANSI C. Languages such as C++ and Ada that allow passing of argument type information admit simpler declarations and fewer entry points."


Artur Biesiadowski
Offline shawnkendall

Senior Member





« Reply #13 - Posted 2004-04-11 23:38:40 »

Are you saying the 1.5 REMOVED from the C functions the gl?
i.e. any sample existing OpenGL code would break horribly?
Typical OpenGL C code...
void display(void)
{
  glClear(GL_COLOR_BUFFER_BIT);
  glIndexi(RAMP1START);
  glPushMatrix();
  glRotatef(-rotAngle, 0.0, 0.0, 0.1);
  glBegin (GL_LINES);
     glVertex2f (-0.5, 0.5);
     glVertex2f (0.5, -0.5);
  glEnd ();
  glPopMatrix();
  glFlush();
}
I am searching the spec right now, but I think you are misunderstanding it ( I hope!).
Can anyone else confirm this?
"gl" is dropped from OpenGL function calls?

Shawn Kendall
Cosmic Interactive, LLC
http://www.facebook.com/BermudaDash
Offline shawnkendall

Senior Member





« Reply #14 - Posted 2004-04-11 23:45:19 »

Well, the spec document may not declare the use of the prefix "gl" in OpenGL functions...
But I am not aware of a single C API implementation that doesn't have.
Interesting though...probably can yank it without violating the "standard"
But then code all over the world would fail to recompile...

Shawn Kendall
Cosmic Interactive, LLC
http://www.facebook.com/BermudaDash
Offline abies

Senior Member





« Reply #15 - Posted 2004-04-12 10:22:21 »

Quote
Well, the spec document may not declare the use of the prefix "gl" in OpenGL functions...
But I am not aware of a single C API implementation that doesn't have.
Interesting though...probably can yank it without violating the "standard"
But then code all over the world would fail to recompile...


Of course, ALL C implementations out there use gl prefix. Question is, if java binding should be a java-wrapper-around-C or java-wrapper-around-OpenGL. In both cases C library will be used under the hood (unless somebody will do some kind of special, java-only driver for X for example ?), point is what are we looking at when binding is made - opengl.h header, or OpenGL spec.

In no way I'm advocating creating C library without prefixes - with lack of namespaces, it would be a mess with generic names like Enable/Disable. But these gl prefixes are just a hack that need to be added in C, I see no point in copying them to java, just because they are in C. If big letters at start of method name can stay, then converting C code to java will be trivial  - just add . after every "gl".

I think same should be done for static values, but this is of secondary importance to me, given availability of static imports in 1.5. Choices are:
a) gl.glBegin(GL.GL_TRIANGLE_STRIP);
b) gl.glBegin(GL_TRIANGLE_STRIP);
c) gl.Begin(GL.TRIANGLE_STRIP);
d) gl.Begin(TRIANGLE_STRIP);

With b and d using static import and c and d using version without prefixes. For me personally, d look like native java binding, while a/b clearly are just ports to java. Isn't it giving a  message like "You should be using C if you want to use OpenGL, what are you doing here !?"  ? Please also read all 4 versions aloud - d one sounds like what are you really doing Smiley

Artur Biesiadowski
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #16 - Posted 2004-04-12 20:05:51 »

I think that removing the "gl" prefix from the OpenGL method names will cause a lot of confusion. If it is removed and nothing is done to the following letter (i.e., make it lowercase), the method names no longer conform to the Java guidelines. If it is removed and some rule is applied to the following letter, there will be some cases where special treatment will be needed where the "gl" prefix is followed by two or more capital letters. Either way, it's going to be non-obvious how to read OpenGL documentation written for C/C++ and transliterate it to Java.

Given the reality that the OpenGL API is implemented at the bottommost level in C, I don't think we should try to hide this fact by changing constant or method names. It's been tried before in APIs like Magician. It resulted in a lot of overloaded methods, and the original methods were kept anyway to avoid confusing end users.
Offline liminal

Senior Newbie




Java games rock!


« Reply #17 - Posted 2004-04-12 21:59:11 »

Two issues that seem to keep coming up:

1)  Use of the gl contexts outside of the display() method. I'm not proposing any course of action, but this seems to keep surfacing as an issue in code in the forum

2)  Integrating with the AWT event queue. Different methods of bridging the awt thread to the gl thread (queues?) should be investigated and possibly included as a standard part of the library.
Offline pdjensen

Senior Newbie





« Reply #18 - Posted 2004-04-12 23:32:01 »

Since Ken Russell requested problems also be discussed on this thread, the big show stopper for me is the reshape problem which causes system hangs. It's been discussed quite often, most recently on the java-seed@lists.apple.com list under the topic:

Re: OT: JOGL Re: Still getting link issues with JNLP

   pdj
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #19 - Posted 2004-04-13 02:29:32 »

Actually let's keep the bug discussions to other threads as Dan requested. The reshape hanging issue is one I consider serious and plan to investigate soon, or if others have time to do so please post any progress made.
Offline shaddam_IV

Junior Member




Java makes me happy the way C# doesn't!


« Reply #20 - Posted 2004-04-13 04:44:42 »

It is my opinion that the "objectification" of the state machine in the GLDrawable is a great way to leverage the best of both OpenGL and Java.  It would be a major mistake to drop the gl.glFoo() and revert to glFoo() (where gl is a GLDrawable).

The beauty of having a GLDrawable is that each state machine/context is associated with a single GLDrawable.  This means you don't have to worry about keeping track of which RC you are currently using.  The one associated with your GLDrawable is it.

BTW/OT, when the spec drops the GL_ from a function, that is merely for convenience.  The actual enumeration always has the GL_.  Don't even think of dropping the GL_ prefix.

There are 10 kinds of people in the world.  Those that understand binary and those that don't.
Offline shaddam_IV

Junior Member




Java makes me happy the way C# doesn't!


« Reply #21 - Posted 2004-04-13 04:50:57 »

Quote
[issue] that seem to keep coming up:

1)  Use of the gl contexts outside of the display() method. I'm not proposing any course of action, but this seems to keep surfacing as an issue in code in the forum


It is my personal opinion that rendering should only occur in rendering functions.  This goes along with the idea of modular design.  This means that there is no reason to have access to the GLDrawable in, say, a simulation function.  In any event, you can certainly hack the class and get access to the GLDrawable in other locations than in display.

There are 10 kinds of people in the world.  Those that understand binary and those that don't.
Offline shaddam_IV

Junior Member




Java makes me happy the way C# doesn't!


« Reply #22 - Posted 2004-04-13 05:07:44 »

My inputs:

  • Definitely keep the whole GLDrawable setup.  This is a great way to leverage the OOP design of Java with OpenGL.

  • Get rid of GLJPanel.  I am developing a cross platform PC & Mac Swing app that uses GLCanvas.  These technologies play together just fine.  There are a few caveats with popups, but they are no big deal.  The existence of GLJPanel perpetrates the myth that you should never use GLCanvas with Swing, which is bogus.

  • I think that the ability to create pbuffers should be available without the requirement to derive them from a viewable GLDrawable.  They should also not be lazily created.  AFAIK, I can create an offscreen RC in a C/C++ program without having to create an onscreen one.  Why not the ability to do the same in JOGL?

  • There should definitely be a user controlled swapbuffer command in the form of gl.glSwapBuffers() or something like that.

  • I would eliminate the Animator class and instead provide a nice tutorial on thread safety and OpenGL.  I don't think it should be that hard to manage things so that all of your rendering goes on in one thread.  After reading the *simple* Animator source, I understood things a lot better.  it would be a good thing if the Java GL developers understood what was going on under the hood.

  • Make the bindings a standard part of Java 1.x (x>.5).  Java2D is part of the core, so why aren't the gl bindings?

  • Rename the package to javax.media.opengl, as the JSR suggests.  Not everyone is using this library for games.

  • Make resources shareable across contexts.  You can do this on most other platforms via calls such as wglShareLists.  Of course, this would have to be abstracted away to something like joglShareLists.

There are 10 kinds of people in the world.  Those that understand binary and those that don't.
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #23 - Posted 2004-04-13 05:11:34 »

Just to chip in on the gl prefix. I think it should stay there. Makes comparing C/C++ to the Java version very easy and consistent.  For example, you're scanning a heap of code and you come across "vertex3f()" Now what does that mean based on a 20ms instant recognition thing? Are we working with the vecmath package, OGL calls or something else?

Also, one issue to factor in will be static imports in JDK 1.5. A lot of those GL.GL_foo things will disappear and you can go to using GL_foo saving plenty of typing.

As for the rest, I'll add more comments tomorrow after I've played with it to see what has changed. In general, I want a real specification. One that actually specifies behaviour, not an API declaration like Java3D has.  Try doing anything in realtime with dynamically created pBuffers and you'll see  what I mean.

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 GKW

Senior Member




Revenge is mine!


« Reply #24 - Posted 2004-04-13 14:53:27 »

Quote
Get rid of GLJPanel.  I am developing a cross platform PC & Mac Swing app that uses GLCanvas.  These technologies play together just fine.  There are a few caveats with popups, but they are no big deal.  The existence of GLJPanel perpetrates the myth that you should never use GLCanvas with Swing, which is bogus.

Considering GLJPanels performance right now I don't htink many people are going to use it anyway.  But in the future I think it will be a good thing to have around.

Quote

I think that the ability to create pbuffers should be available without the requirement to derive them from a viewable GLDrawable.  They should also not be lazily created.  AFAIK, I can create an offscreen RC in a C/C++ program without having to create an onscreen one.  Why not the ability to do the same in JOGL?

I looked into this and you need to create a onscreen window, you don't have to show it though, to create a pbuffer with Windows.  I wouldn't mind removing the lazy instantiation but you would only be able to create a new pbuffer in one of the GLDrawabel methods.
Offline abies

Senior Member





« Reply #25 - Posted 2004-04-13 16:03:32 »

Quote
 For example, you're scanning a heap of code and you come across "vertex3f()" Now what does that mean based on a 20ms instant recognition thing?


No, you won't see vertex3f(). You will see gl.Vertex3f() as opposed to gl.glVertex3f(). But I understand that having to keep method starting with lower case is top priority, and gl.vertex3f is indeed too different from current standard.

Artur Biesiadowski
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #26 - Posted 2004-04-13 16:42:07 »

Quote


No, you won't see vertex3f(). You will see gl.Vertex3f() as opposed to gl.glVertex3f(). But I understand that having to keep method starting with lower case is top priority, and gl.vertex3f is indeed too different from current standard.


You cannot really answer this issue without defining the audience.

Audience: OpenGL newbies relying on word-for-word source-code compatibility between NeHe and java, who are too thick or lazy to read documentation and apply a simple transformation

-- Keep as is

Audience: OpenGL C programmers who want to not have to open their brain for a little while to use a cleaner, simpler, interface definition.

--Keep as is

Audience: OpenGL C programmers who want to translate / port source

--Don't care either way, so long as a simple regex will convert from one to the other. In fact, if the regex's were provided by someone else, they'd be deliriously happy

Audience: Java programmers coming to OpenGL

--Remove as much of the cruft as possible, since it gets in the way of "thinking in java" and it marginally reduces productivity. It is also stressful and painful, largely because the programmer is aware it's unnecessary [sad, but true: if you know you're doing something you don't like AND THERE'S NO REASON YOU HAVE TO, it makes it extra undesirable] (seriously: these are primary reasons why I'd never accept a C contract ever ever again: it's just too painful to keep making up for shortcomings in the tools by inserting additional programmer effort)

Audience: Java programmers making extensive use of fancy IDE's with autocomplete

--Remove as much identical prefix as possible, within the bounds of whatever the audience wants otherwise, since "GL.GL_something" MORE THAN DOUBLES the amount of typing for most vars, ditto "gl.glSomething" - they turn "2-3 keystrokes for tolerably small match-set" into "7-8 keystrokes for tolerably small match-set".

Personally, as someone who is glad to have escaped "thinking in C", and has had (on occasion) to go back to C programming for short periods, I wouldn't be happy with anything more than:

  gl.vertex( ... );

Anything else insults my intelligence and makes all the OpenGL source code psychologically incompatible with the rest of the game - I hate the additional effort of having to "context-switch" your brain into this crappy "ultra-hardcore-polish-notation" which was only invented to work around a crappy 2-bit programming language design.

With about half of devlopers appearing to dislike/hate 2-character or more polish notation, why is it that people here want to force at least 2 and often much more on every programmer?

Note: I'm only describing how *I* feel, and I'm not claiming it should be done to satisfy *me*; as I said, I think you should make the decision based on an evaluation of your intended audience first and foremost.

malloc will be first against the wall when the revolution comes...
Offline kaffiene
« Reply #27 - Posted 2004-04-14 03:03:38 »

I striongly oppose the idea of changing the prefixes.  The biggest issues doing OpenGL in Java are purely OpenGL issues and being able to communicate with the OpenGL world is a really handy feature of the current naming scheme.  I have posted my jogl java code to openGL news groups and C programmers have had no problem understanding the code.

That is a good thing.

If we want to encourage programmers in the C/C++ world to use Java, it is doubly a good thing to leave things the way they are.

Also, it would break everyone's code to change it now.

I really like the fact that there is very little diffrence between my Java OpenGL code and my C++ OpenGL code.    I think this benifits newbies as well as old OGL hands since the vast body of OGL code out there can work fairly much directly.
Offline pepijnve

Junior Member




Java games rock!


« Reply #28 - Posted 2004-04-14 07:54:10 »

I second blahblahblahh's opinion on the prefix issue. It really depends on what you're going for: a direct port of the C implementation of the OpenGL spec or a Java implementation of the OpenGL spec. Personally I don't see any benefit in having
1  
gl.glVertex

over
1  
gl.vertex

besides the capitalization issue of the first character.
I'm also fairly sure that any decent c/c++ programmer can understand both versions...
Offline abies

Senior Member





« Reply #29 - Posted 2004-04-14 08:19:15 »

Quote
I striongly oppose the idea of changing the prefixes.  The biggest issues doing OpenGL in Java are purely OpenGL issues and being able to communicate with the OpenGL world is a really handy feature of the current naming scheme.  I have posted my jogl java code to openGL news groups and C programmers have had no problem understanding the code.


So you claim that they are able to understand
gl.glEnable(GL.GL_TRIANGLE)
and would not be able to understand
gl.Enable(GL.TRIANGLE) ?

Artur Biesiadowski
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 (72 views)
2014-04-15 18:08:23

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

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

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

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

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

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

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

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

CJLetsGame (220 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

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