Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (577)
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  
  LWJGL vs Jogl  (Read 10220 times)
0 Members and 1 Guest are viewing this topic.
Offline oNyx

JGO Coder


Medals: 1


pixels! :x


« Reply #30 - Posted 2005-02-15 14:35:28 »

> You changed lots of things in LWJGL 0.95 [...]

I would like to point out that the leading 0 is there for a reason Wink

弾幕 ☆ @mahonnaiseblog
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #31 - Posted 2005-02-15 14:38:28 »

S'rite, we're still just in "alpha". I believe Elias is just about to break everything again.

Cas Smiley

Offline Matzon

JGO Knight


Medals: 19
Projects: 2


I'm gonna wring your pants!


« Reply #32 - Posted 2005-02-15 15:05:37 »

Quote
You changed lots of things in LWJGL 0.95, removing something, too, and leaving lots of unresolved issues to whom want to upgrade (like the ILU.DLL dependancies just to be able to run a LWJGL game).
Actually, very little changed - less than 5 methods I'd wager. As for requiring ILU - thats ONLY if you use Devil. If you don't use devil, you dont have to distribute it along.

Quote
This left me uncapable of using JME with LWJGL 0.95 since
I figured the fix, fix that when first appeared not even the development team wwas aware of (look at your forums).
Not being able to use jMe with 0.95 is really not an LWJGL issue!! but rather a jMe issue.

Quote
JOGL is a reference implementation, LWJGL is an hacky tool made to satisfy Puppygames needs, just like my Basilisk and the non OS Stirge engine were.

1 - JOGL is not a reference to anything. No JSR has been released (JSR 231 is still in progress). It might become it in the future, but it certainly isn't right now.
2 - LWJGL is NOT a hacky tool - what a ridiculous statement. There are a lot of people using LWJGL AND delivering commercially available games!

Quote
Don't get edgy when people spots the differences, the projects have different aims and intents, if decide to drop Java like many times you used to claim in the Indiegamer Forum, LWJGL will suddenly be without a huge part of its committment (but I'm pretty sure the project will continue).
Right, and don't claim some stupid stuff, when you're obviously not in tune with LWJGL development. Development of LWJGL will certainly not stall, at most it would be a minor bump on the road.  LWJGL isn't a one man job.

Quote
Rest assured that I've nothing against JME, LWJGL, JOGL or Xith3D, but if one has to *rely* on a mature technology for a real project he has two choices [snip]
Come on, using OpenGL in java with any current binding is:
A) not mature
B) well, don't need a B, coz the A was so f*cking great

Other than that, what they said - wait for a point release, then whine.

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 #33 - Posted 2005-02-15 15:36:15 »

Quote
- On display creation:
Jogl's system means you must 'guess' at what might or might not be avalible, which would be ok if failing actually triggered an exception. However what you really get is a core dump so you can't do jack about it. LWJGL's method of giving you a list of modes allows you to be much more confident of picking a working display.


There have certainly been bugs in JOGL's OpenGL pixel format selection in the past, but JOGL has always, since its first release, given the end user full control over the process from through the GLCapabilitiesChooser mechanism. Where JOGL's default selection mechanism has been found lacking, groups like Wurm Online have written their own choosers with good success from what I hear.

Quote
Equally, I'll bet no-one's fixed the no-alpha-bits-in-the-framebuffer-on-linux bug yet in Jogl? That makes a whole bunch of nice rendering methods unusable.


I haven't heard any complaints about this recently, but I think the bug you are talking about, where the visual selection on Linux occurred too late in the AWT's widget creation process, was fixed in 1.1 b01, released nearly a year ago.

Quote
Equally equally, take a glance at the Jogl forum and all the traffic seems to be on bugs, crashes, freezes, lockups and odd flag workarounds. Not what I'd call stable or mature.


The most recent build of JOGL has worked around a lot of stability issues on various vendors' hardware, ATI in particular but Intel and NVidia as well. There is one primary flag which enables "the" workaround to force all OpenGL rendering to occur on one thread, which seems to address almost all known issues. The JOGL library has been increasing in stability as we have learned more about the intricacies of interacting with the AWT and OpenGL in a multithreaded fashion, and from what I hear from users, things are working pretty well at this point.
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #34 - Posted 2005-02-15 15:39:45 »

Quote
When we get AWT rendering some eyebrows will be raised I should think.


I will personally be very interested to see how and whether LWJGL will interoperate with the AWT. I have found it challenging to handle situations where the underlying widget is being created and destroyed asynchronously. Perhaps you and the rest of the LWJGL team will find simpler solutions than those we have discovered in JOGL.
Offline Orangy Tang

JGO Kernel


Medals: 51
Projects: 11


Monkey for a head


« Reply #35 - Posted 2005-02-15 15:43:12 »

Quote

I haven't heard any complaints about this recently, but I think the bug you are talking about, where the visual selection on Linux occurred too late in the AWT's widget creation process, was fixed in 1.1 b01, released nearly a year ago.

Not when I tried it it wasn't.

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

JGO Coder




Java games rock!


« Reply #36 - Posted 2005-02-15 16:02:31 »

Quote

Not when I tried it it wasn't.


Do you have a test case? If so, could you please file a bug?
Offline z.e.r.o

Junior Member




Java games rock!


« Reply #37 - Posted 2005-02-15 17:07:08 »

Quote
> You changed lots of things in LWJGL 0.95 [...]

I would like to point out that the leading 0 is there for a reason Wink


Well, yes.
But the more you try to reach 1 the more your specifications should be consolidated.
Otherwise you're just hacking your way out of troubles.

But I'm just saying stupid things... like someone like to think, instead of trying to get something out from constructive criticism.

Matteo Anelli
.brain - http://www.dot-brain.com
Offline CaptainJester

JGO Knight


Medals: 12
Projects: 2


Make it work; make it better.


« Reply #38 - Posted 2005-02-15 17:58:51 »

Quote


Well, yes.
But the more you try to reach 1 the more your specifications should be consolidated.
Otherwise you're just hacking your way out of troubles.

But I'm just saying stupid things... like someone like to think, instead of trying to get something out from constructive criticism.


Just because someone makes a change to the API, does not mean it is a hack.  There are reasons for it and discussions are made behind the scenes between the developers.  That is also the reason for 0.95a.  It is not considered a production release, so ANYTHING can change until version 1.0 comes out.  That is always the risk you take when using a tool that is in alpah/beta/pre-1.0 release.  If you want to have a stable release, then stick with one version for your project until you are done.

Offline z.e.r.o

Junior Member




Java games rock!


« Reply #39 - Posted 2005-02-15 17:59:57 »

Matzon saying stupid to others and keeping things close & personal will not make you be smarter, just childish.

If JME is not able to run for a simple 0.01 update is your fault no matter how right you think you are.
If you're providing a library you shall provide the less possible hassle for the developers, expecially when closing to a major release.
Have you thought of just deprecate features to give developers time to adjust their libs (giving them time till 0.99)?
You've just broken support for one of the best 3D library out there.
And what about the countless professional games developed around the library? It's stupid "whining" (or it was suggesting, point of views) for an unfinished library but is intelligent (and pro) using an immature artifact to develop professional things? You've a quite confused opinion about how "pro" software is developed (I must assure than starting on the base of an alpha lib is not part of the equation, JOGL is not excluded from these considerations).

Before another flame will start I will leave Puppygames projects outside on purpose since Cas is involved in the development and knows where the lib will go (It's his own middleware after all).

Anyhow, let me remember you that most of the features removed where because you cannot stand the effort to support them cross platformly (like the input devices or EAX sound) at the moment.  Will we must assume "blinking" features? Better to leave them incomplete to than removing them to be added later.

BTW my first post was more broader than you undestood, there are a lot of potentially good (but unfinished) products out there. Xith3D and JME are just splendid examples of Scenegraph engines, JOGL and LWJGL are decent wrappers. My opinion about JOGL is a better RI candidate is because JOGL is just OpenGL for Java. No other stuff involved.

Nobody is saying that you all are doing bad jobs, just keep things on track and do not take unilateral decisions convinced that your choices are the choices of the community (or of the "pro").

Matteo Anelli
.brain - http://www.dot-brain.com
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline z.e.r.o

Junior Member




Java games rock!


« Reply #40 - Posted 2005-02-15 18:05:53 »

Quote


Just because someone makes a change to the API, does not mean it is a hack.  There are reasons for it and discussions are made behind the scenes between the developers.  That is also the reason for 0.95a.  It is not considered a production release, so ANYTHING can change until version 1.0 comes out.  That is always the risk you take when using a tool that is in alpah/beta/pre-1.0 release.  If you want to have a stable release, then stick with one version for your project until you are done.


Yes, as said before I'd rather fork an immature lib to handle my own project, since we can't start a serious project (an experimental worldwide GPS software in 3D using sat maps to handle logistics) using immature tools (JOGL, LWJGL or whatever). Better to develop it in-house so you can support what you need and ditch the other stuff you'll not need and have a stable release ASAP.
It's the centerpoint of software engineering, the vision must be consolidated before starting the development.

Matteo Anelli
.brain - http://www.dot-brain.com
Offline oNyx

JGO Coder


Medals: 1


pixels! :x


« Reply #41 - Posted 2005-02-15 18:08:39 »

>But the more you try to reach 1 the more your
>specifications should be consolidated.

Yes.

But if there are some things which doesn't make much sense, you have to change them. Remember the days where we had a display and window class? I always mixed em up and I'm really glad that they were merged. It just makes much more sense this way.

Many moons ago there where even pointers in lwjgl. Do you miss em? Smiley

Maturity is a good thing, but it takes it's time. It's evolutionary. If you don't want to do any changes every once in a while... you certainly don't need to. You can continue using an older version and - eventually - do all the changes at once at some point in the future (eg if you're entering the beta phase).

弾幕 ☆ @mahonnaiseblog
Offline z.e.r.o

Junior Member




Java games rock!


« Reply #42 - Posted 2005-02-15 18:17:08 »

Quote
>But the more you try to reach 1 the more your
>specifications should be consolidated.

Yes.

But if there are some things which doesn't make much sense, you have to change them. Remember the days where we had a display and window class? I always mixed em up and I'm really glad that they were merged. It just makes much more sense this way.

Many moons ago there where even pointers in lwjgl. Do you miss em? Smiley

Maturity is a good thing, but it takes it's time. It's evolutionary. If you don't want to do any changes every once in a while... you certainly don't need to. You can continue using an older version and - eventually - do all the changes at once at some point in the future (eg if you're entering the beta phase).


Agreed.

I only feel odd that supporters continue to stress the in-development of the library but, on the other hand, continue to support the idea that it is a "pro" tool.

Sticking on an alpha or beta (and outdated) build to avoid misalignment is not my way to develop things.


Matteo Anelli
.brain - http://www.dot-brain.com
Offline Matzon

JGO Knight


Medals: 19
Projects: 2


I'm gonna wring your pants!


« Reply #43 - Posted 2005-02-15 19:16:35 »

Quote
Matzon saying stupid to others and keeping things close & personal will not make you be smarter, just childish.
I never said you were stupid, but rather what you said was stupid. Your whole post was basically invalid, and based on no logic or truth - and IMO it sounded very uninformed (as if you used LWJGL 0.5, turned away and never looked back).

Quote
If JME is not able to run for a simple 0.01 update is your fault no matter how right you think you are.
You're kidding, right? LWJGL has been in alpha release since day one. It's not something we slapped on because we like the name Alpha, but rather because it is alpha. We reserve the right to change the library any way we see fit, and in any way we like. Thats not to say we enjoy breaking stuff. But we have a goal, and if we need to break stuff to get there - so be it. As for jMe, for each version they release they also break stuff. It's the nature of any evolutionary project. But for each release they typically specify which LWJGL to use with that version. Like any other program. Be it a 0.1 increment or not.

Quote
Anyhow, let me remember you that most of the features removed where because you cannot stand the effort to support them cross platformly (like the input devices or EAX sound) at the moment.  Will we must assume "blinking" features? Better to leave them incomplete to than removing them to be added later.
Once again (and not being personal) you come off rather uninformed.
1: EAX cannot be supported crossplatform since it's only available on Windows.
2: The controller stuff was removed, since it only worked on windows, as stated in the release thread on JGO. It was decided that it is better to support controllers completely than to have half an implementation blow up on users on non-win32 platforms.
We think it's a good decision to do so, those that disagree are more than welcome to build from a date prior to the cut.

LWJGL does not cater for all users, but rather for the common case. As such, some will be burned by some of our choices - but most will benefit. Should someone feel something is bad or wrong, they're more than welcome to raise their concern on the boards or on IRC. But the way I see it, those that do the actual coding gets to decide the direction... it's not like we're flooded with controller patches or software EAX implementations for non-win32 platforms each day. It's actually been some time since I've seen a patch from anyone ('cept some mispelling or very minor patch (line or two)).

Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #44 - Posted 2005-02-15 19:56:03 »

I would like to point out that all previous versions of LWJGL are still available. We break nothing. If you're happy with a particular release, stick with it.

If it's any consolation every time the API is broken I now have 3 entire games to keep up to date - and it's really a trivial matter to do so.

Cas Smiley

Offline Mojomonkey

Senior Member




ooh ooh eee eeee


« Reply #45 - Posted 2005-02-15 21:29:29 »

I'll pipe in on the jME part...

Current release 0.8 uses 0.94, as it was released prior to 0.95. We periodically have people on the boards mention problems, we tell them to use LWJGL 0.94 and the issue is resolved. We missed that release by about a week, which is too bad, but oh well.

CVS will have 0.95 support soon (getting some other core changes in first). And when we release 0.9 it will probably use LWJGL 0.95 when LWJGL 0.96 comes out. Smiley

It's the nature of the beast and we (jME team) grunt and groan now and then, questions some of LWJGL teams decisions every once in awhile. But overall, moving from one version to another has not been difficult.

Our getting started guide specifically mentions which version of LWJGL to get, so that keeps many of the issues from cropping up. We also put the LWJGL version into cvs lib directory to allow the CVS users to always be current and that seems to work well.


Don't send a man to do a monkey's work.
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #46 - Posted 2005-02-15 21:34:53 »

We never intended LWJGL to behave like an "extension" or a "dependency"... why not just bundle the binaries along with jME and solve the problem completely?

Cas Smiley

Offline CaptainJester

JGO Knight


Medals: 12
Projects: 2


Make it work; make it better.


« Reply #47 - Posted 2005-02-15 21:37:38 »

Quote
You've just broken support for one of the best 3D library out there.
And what about the countless professional games developed around the library? It's stupid "whining" (or it was suggesting, point of views) for an unfinished library but is intelligent (and pro) using an immature artifact to develop professional things? You've a quite confused opinion about how "pro" software is developed (I must assure than starting on the base of an alpha lib is not part of the equation, JOGL is not excluded from these considerations).


You are quite confused about how pro software is developed.  When you start developing, you pick a library version and stick with it to the end.  The only reason to move to a newer version mid-stream is for a required patch or if you need/want a new feature.  Everyone who makes professional production software knows the risks of changing a library version mid schedule.  It is always a risk.

And jME is not broken.  Each verison of jME specifically says which version of LWJGL it is made with.  If you move to a newer version, you broke it.

Quote

Yes, as said before I'd rather fork an immature lib to handle my own project, since we can't start a serious project (an experimental worldwide GPS software in 3D using sat maps to handle logistics) using immature tools (JOGL, LWJGL or whatever). Better to develop it in-house so you can support what you need and ditch the other stuff you'll not need and have a stable release ASAP.
It's the centerpoint of software engineering, the vision must be consolidated before starting the development.

If that is what you do, then what are you complaining about.  Pull version 0.94 out of CVS and have at it.

Offline elias

Senior Member





« Reply #48 - Posted 2005-02-16 06:39:47 »

Quote


Sure, Alien Flux drained some attention to the lib (but also spotlighted some issues in the deploy, like you admitted), but the aims are different.
JOGL is a reference implementation, LWJGL is an hacky tool made to satisfy Puppygames needs, just like my Basilisk and the non OS Stirge engine were.

Don't get edgy when people spots the differences, the projects have different aims and intents, if decide to drop Java like many times you used to claim in the Indiegamer Forum, LWJGL will suddenly be without a huge part of its committment (but I'm pretty sure the project will continue).


Erh, no, that is simply flat out wrong. I'm very active in the development of LWJGL, since we're using it for our Tribal Trouble game. And several others from the LWJGL development team is using it for their projects too, and they too provide fixes and features. So naming LWJGL a one-man-show by Cas might have been true in the beginning, but certainly not now.

And I'm not sure what you have against our Mac donation drive. We had been asking for help for ages, and then decided to ask for money instead. It worked out great (modulo problems with Paypal that we could do nothing about) and we have a stable and working port today.

- elias

Offline Orangy Tang

JGO Kernel


Medals: 51
Projects: 11


Monkey for a head


« Reply #49 - Posted 2005-02-16 07:09:07 »

Quote


Do you have a test case? If so, could you please file a bug?

Not handy, and I've not the time nor the inclination to mess around making one. The last official word I was told was that it was fundamentally incompatible with how the linux port did things, and wouldn't be fixed.

[ 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 #50 - Posted 2005-02-16 07:50:28 »

One other thing to throw into the mix, and it's not a fault of JOGL: LWJGL fullscreen works correctly on 1.4.0 and above. JOGL has unfortunately falley prey to a ton of bugs in AWT that to this day remain unfixed.

Regarding work on LWJGL, I do almost bugger all these days, as Elias is driving the implementation to get Tribal Trouble released. This is actually the best possible situation, as instead of writing an API for n00bs and wannabees and theoreticians and hobbyists, LWJGL has only ever been designed around the fundamental problem of getting a commercial game out there.

Cas Smiley

Offline javazoid

Junior Member




Where's Flender?


« Reply #51 - Posted 2005-02-16 14:26:21 »

.. and not only games..

Cheers ;-)

Mik

Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #52 - Posted 2005-02-16 14:39:48 »

Hehe, yes of course, LWJGL was first actually used in production for live TV graphics and still is to this day.

Cas Smiley

Offline javazoid

Junior Member




Where's Flender?


« Reply #53 - Posted 2005-02-16 15:07:47 »

I can run Castalia at 400fps (onscreen) vs 25-50 fps of Java2D. I can have NPOT images, video textures (AVI/Quicktime), etc. Learning a bit of OpenGL and playing with it through LWJGL has been really straightforward. I needed some JNI in order to overcome some LWJGL-NIO limitations but nothing transcendental.
Now I can easily mix Java2D and OpenGL'ed stuff with very little effort.

Cheers2 ;-)


Offline Ken Russell

JGO Coder




Java games rock!


« Reply #54 - Posted 2005-02-16 15:19:43 »

Quote

Not handy, and I've not the time nor the inclination to mess around making one. The last official word I was told was that it was fundamentally incompatible with how the linux port did things, and wouldn't be fixed.


I don't know where you heard that (if it was from me, I was wrong), but it is incorrect. We fixed JOGL's visual selection mechanism on X11 a long time ago.
Offline z.e.r.o

Junior Member




Java games rock!


« Reply #55 - Posted 2005-02-17 16:05:20 »

Quote
One other thing to throw into the mix, and it's not a fault of JOGL: LWJGL fullscreen works correctly on 1.4.0 and above. JOGL has unfortunately falley prey to a ton of bugs in AWT that to this day remain unfixed.

Regarding work on LWJGL, I do almost bugger all these days, as Elias is driving the implementation to get Tribal Trouble released. This is actually the best possible situation, as instead of writing an API for n00bs and wannabees and theoreticians and hobbyists, LWJGL has only ever been designed around the fundamental problem of getting a commercial game out there.

Cas Smiley


Testcase not propaganda.
I used JOGL (on a ATI, I must add) and LWJGL equally well in fullscreen without hassle. Just a coincidence? People have problems even with LWJGL, you're about to add Swing AWT support to LWJGL too, you're using a bug free AWT?

* AWT is buggy (that's true, but JOGL uses only a small subset of it).
* Swing is slow.
* JOGL is slow (in fact speed is not that different between LWJGL actually).
* Java is crap.
Common statements that most of the time are completely wrong or only superficial or driven by pride.

I can only shiver if people are trying to go in production with alpha versions (I've doubt how pro they can be to do such decisions) of their core tech.

I simply admire Elias with its tribal trouble project (the kind of game I strived to develop but wasn't able to find able people for, here in Italy), expecially since he is maintaining the lib at the same time... Being there done that, it is the only way to do the stuff, as said before.

You should get more easy on criticism, btw. I read almost all the board (Indiegamer too) and blatant FUD against everything is not LWJGL is rampant.

I must reckon you are not so fond to negative feedback about your work (after all people ship games from it, it must be good, wow!), but you must accept it.
After all other people are enduring your propaganda for months (if not years) without getting it close & personal like you did...

BTW I suggest to steer the 3d out of this sterile (if polite) flame war.

Matteo Anelli
.brain - http://www.dot-brain.com
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #56 - Posted 2005-02-17 16:38:14 »

To whom am I getting up close and personal, and where's this FUD of which you speak?

Cas Smiley

Offline elias

Senior Member





« Reply #57 - Posted 2005-02-17 17:53:16 »

Quote


JOGL supports concurrent rendering to multiple OpenGL contexts; LWJGL does not. If LWJGL used an object and per-context function table to represent OpenGL function pointers than it could more easily support multithreaded OpenGL rendering. As it stands the native code for LWJGL would have to change substantially and do a lookup in thread-local storage per OpenGL function call in order to support multiple contexts. See the GLEW library for more information on how to do this in straight C code.


As of today, this is no longer an issue. See

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

Sometimes, criticism leads to new features and fixes Smiley

- elias

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #58 - Posted 2005-02-17 19:58:47 »

Quote
Comparison of JOGL and LWJGL seems pretty pointless to me, as their design goals are different.


By definition, this means it is extremely important to compare them.

I think what you actually meant was "arguing which one is "always best"" is pointless...".

The considerable differences make it *essential* for us users to have a convenient comparison so we can make up our own minds based on up-to-date info.

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

Senior Member




while (true) System.out.println("WOO!!!!");


« Reply #59 - Posted 2005-02-17 20:00:47 »

I'll add my 2 cents..

JOGL apps crash my computer with a blue screen of death.

LWJGL apps are beautiful and not a one has ever given me problems.

EDIT: OK maybe I'm just a little peeved at how I can't even start Wurm Online...

Admin and Game Developer at
GameLizard.com
Play Rimscape!    |    Play Conquer!
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 (23 views)
2014-04-15 18:08:23

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

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

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

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

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

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

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

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

CJLetsGame (190 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!