Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (603)
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 11538 times)
0 Members and 1 Guest are viewing this topic.
Offline ug02070

Senior Newbie




Java games rock!


« Posted 2005-02-03 17:35:19 »

Is there any links to a thread that has comparisons between these two api's? i wish to produce a table that shows differences, advantages, disadvantages of each language, as i am using lwjgl i am hoping that it has more advantages. oh yes and the context of this question is in relation to making games but all advantages and disadvantages are welcome, thanks guys
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #1 - Posted 2005-02-03 19:57:29 »

Take a look at http://jogl.dev.java.net/JOGLGlueGen.pdf , slide 4. It has a table which compares significant attributes of LWJGL, GL4Java, Magician, and JOGL. This was presented a while back (May 2004) to the JSR-231 and 239 expert groups.
Offline kevglass

« JGO Spiffy Duke »


Medals: 212
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #2 - Posted 2005-02-04 09:26:13 »

Isn't it just slightly out of date? I though LWJGL now had the idea of contexts so you could happily rendering into AWT/Swing..

Meaning that they are apparantly the same from the slide Smiley

Except of course they're not.

Kev

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

« JGO Spiffy Duke »


Medals: 434
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #3 - Posted 2005-02-04 13:00:42 »

Although LWJGL can be used with JOGL, there is no direct LWJGL method for creating LWJGL contexts in AWT components. Soon to be rectified I think.

Cas Smiley

Offline whome

Junior Devvie




Carte Noir Java


« Reply #4 - Posted 2005-02-04 14:04:10 »

Why would anyone have to use LWGJL with JOGL. They both do same level of opengl java wrapping, so feels kind of weird.

"Soon to be rectified..." meaning JWLGL team is working on to make it a first class citizen in Java Swing/SWT world?

Offline princec

« JGO Spiffy Duke »


Medals: 434
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #5 - Posted 2005-02-04 14:34:20 »

Gregory Pierce has come up with a LWJGL-in-a-JPanel thingy, and I'm thinking about how to do a first-class LWJGLAWTCanvas component descended directly from java.awt.Component.

Cas Smiley

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #6 - Posted 2005-02-07 09:13:05 »

I've been trying to get a serious, complete, lengthy, accurate comparison of the two for over a year now Sad.

With the new JGF, I've had comments from quite a few people that suggest an automated comparison table between technologies would be useful.

What do you think about a page where you could do something like:

1. Click "add new feautre"
2. Type in description + details
3. Select the feature-type from a drop-down (so that it gets compared like-with-like with other techs)

?

How much detail would be needed? Any extra fields? Obviously, the more detailed the features could be, the less description, the better (lets viewers just choose the particular features they're interested in).

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

Senior Devvie


Medals: 1


Who, me?


« Reply #7 - Posted 2005-02-08 08:14:33 »

Quote
3. Select the feature-type from a drop-down (so that it gets compared like-with-like with other techs)


There's no way you'll be able to come up with a feature list that's detailed enough but still usuable! Roll Eyes

I've never found two pieces of software (or hardware) that can be easily compared using bullet-point lists.  One-line descriptions are rarely enough to enable people to understand the ramifications of an API difference.  And trying to get rival developers to agree on common feature-types or the wording of each API's entry... *shudder*

Might be better to just have a specific area where user-described API comparisons can be posted - a couple of paragraphs from three different people should be enough for most people to understand the differences.

Hellomynameis Charlie Dobbie.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #8 - Posted 2005-02-08 09:05:27 »

Quote

There's no way you'll be able to come up with a feature list that's detailed enough but still usuable! Roll Eyes


....is my default expectation too. But, since the other thing doesn't seem to work (c.f. below), and JGF is heavily moderated, I'm holding out hope that some compromise could be done that is useful even if it has obvious imperfections.

Perhaps...if users could propose features, and a moderator ACCEPT'd those that they thgought applied, and the JOGL, LWJGL, etc authors could fill in their own 200 words on each "feature" proposed this way?

Quote

a couple of paragraphs from three different people should be enough


So far it's proved impossible to find people of even approximately equivalent knowledge about the different API's who are also willing and also able and also *actually do it* to do this.

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

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #9 - Posted 2005-02-08 10:11:45 »

Quote

So far it's proved impossible to find people of even approximately equivalent knowledge about the different API's who are also willing and also able and also *actually do it* to do this.

I have a fairly good working knowledge of both APIs if you need any help from that angle.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline cfmdobbie

Senior Devvie


Medals: 1


Who, me?


« Reply #10 - Posted 2005-02-08 10:25:18 »

Quote
....is my default expectation too. But, since the other thing doesn't seem to work (c.f. below), and JGF is heavily moderated, I'm holding out hope that some compromise could be done that is useful even if it has obvious imperfections.


Well, if you think it'll work - go for it!

Perhaps I'm being a little too negative here.  It's not necessary to get everything absolutely 100% concise - any central source of information on relative API merits will be a good thing, even if it doesn't quite apply in some circumstances.

Hellomynameis Charlie Dobbie.
Offline boessu

Junior Newbie




Java games rock!


« Reply #11 - Posted 2005-02-12 12:02:35 »

Hello blahblahblahh

Actually the only feature you'll find in JOGL which is not present in LWJGL is the embedding with AWT. If you don't need that feature, I suppose you won't find the killer feature in one or the other library that you search for.

All other things are more or less a matter of opinion. JOGL is more modular. You need to download more libraries for sound and control (e.g. joal and jinput).
Also JOGL is more instance oriented. That means you get more the feeling of OO in JOGL. Even the fact that JOGL talks about games, it's also useful for other things e.g. in Swing.

LWJGL puts everything in one distribution. It seems to me more like a "best of breed" library for games (graphics, sound, control in one place). It's developed for games and nothing else in mind. You'll get everything you need from one place. LWJGL uses heavily static methods (as far as I see that). This looks more like C and that means also the layer in LWJGL is slightly thinner than in JOGL. Thats cool for all those who need that transparent approach.

Fact's are: Both libraries are well developed, both have reached mature stability and both have enthusiastic support from their developers.

I suppose you search the library for a game. ;-) Games usually don't have the requirement for a long term maintenance track.
So I think you can't go wrong. Just use the library that looks useful for you and that supports your programming style.
Sometimes it's better just to begin... ;-)

Cheers

Bössu
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #12 - Posted 2005-02-13 17:15:21 »

Quote
Hello blahblahblahh


FYI, I know and use both. This isn't for *me*, but for other people Wink.

Quote

Actually the only feature you'll find in JOGL which is not present in LWJGL is the embedding with AWT.


I can think of a couple differences that *to me* are much much bigger than that. See? This is why a feature guide would be nice Grin.

Quote

If you don't need that feature, I suppose you won't find the killer feature in one or the other library that you search for.


...apart from all the other differences you don't seem to be aware of.

Quote

All other things are more or less a matter of opinion.


Which is why a side-by-side compare, from the horse's mouth of each camp, would be handy.

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

Junior Devvie




Carte Noir Java


« Reply #13 - Posted 2005-02-13 17:59:08 »

+1 difference: JOGL windowed does not steal a mouse cursor. LWJGL windowed steals all your mouse cursors.

EDIT: after two following posts, I stand corrected. Some readymade copypaste code did it, so dont blame me  Grin
Offline weston

Junior Devvie





« Reply #14 - Posted 2005-02-13 19:10:40 »

That doesn't happen on my machine... if it 'steals the mouse' you have probably done this: Mouse.setGrabbed(true);

edit: typo.

for(int i = 1; i > 0; i++)
{
System.out.println(i+" cups of java downed");
}
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #15 - Posted 2005-02-13 20:17:49 »

correctomundo - LWJGL doesn't "steal" a cursor - only if a developer has requested to do so by calling Mouse.setGrabbed(true);

Offline boessu

Junior Newbie




Java games rock!


« Reply #16 - Posted 2005-02-14 09:56:08 »

Hello blahblahblahh (and others ;-) )

I see, the discussion is beside of "only" OpenGL, OpenAL, Input-Binding. ;-)

Well, feature-lists... It would be really cool if there would be a list which helps to find the right solution for a problem, hands down.

Cheers

Bössu
Offline princec

« JGO Spiffy Duke »


Medals: 434
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #17 - Posted 2005-02-14 10:24:05 »

Briefly:

In functionality terms, LWJGL = Hires Timer + JOGL + JOAL + JInput - AWT; LWJGL is not directly integrated with AWT but JOGL is, which means LWJGL is less of a candidate for CAD/CAM applications right now

In API terms, LWJGL exclusively uses direct ByteBuffers to pass data to native code and we have removed methods that are just C shortcuts for efficiency; JOGL also uses heap arrays, for convenience at the expense of efficiency and high performance programming techniques.

In dependency terms, LWJGL is totally self-contained; JOGL depends on AWT

In size terms, LWJGL is considerably smaller.

In simplicity terms, LWJGL is much simpler than the JOGL/JOAL/JInput combination - we have one focus, which is games, and that's allowed us to axe tons of complex setup code.

Cas Smiley

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #18 - Posted 2005-02-14 11:57:52 »

Also:

- LWJGL is miles ahead in terms of reliability and compatibility. I couldn't seriously expect any professional game to be satisfied with the current reliability of Jogl.

- Jogl's display creation is clumsy, awkward and not nearly as flexible as LWJGL's. Also, when it goes wrong it tends to core dump instead of throwing anything you could recover from.

- Jogl has the object access to GL, LWJGL uses the static interface. In theory that means Jogl has the handy-dandy composable pipeline. In reality both end up doing error checking (LWJGL substancially more on buffer args) but Jogl makes you pass round an annoying GL object constantly.

- Jogl allows for GL contexts that can be resized.

- Jogl has a clumsy Animator interface for actually displaying anything that forces you to do things how it wants. Although I believe that there's now a proper swapBuffers interface now?

- Both are going to have heavyweight vs. lightweight issues when embedded in a Swing app. Theoretically Jogl has a lightweight display that doesn't suffer from these problems. Realistically it performs so slow its just not practical for anything useful.

- Both have almost useful documentation. But the LWJGL examples/tests do provide a working base. By contrast the Jogl demos seem to be constantly out of sync everytime I look at them (and consequently broken).

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

JGO Coder




Java games rock!


« Reply #19 - Posted 2005-02-14 19:38:44 »

Quote
Also:

- LWJGL is miles ahead in terms of reliability and compatibility. I couldn't seriously expect any professional game to be satisfied with the current reliability of Jogl.


I don't think this is a fair assessment of the JOGL project. 1.1 b08 (and in particular the revised single-threaded workaround) has addressed basically all open stability issues, most of which were ultimately caused by OpenGL driver bugs exposed by multithreading. If you are still seeing stability issues on a given vendor's card with JOGL, I would appreciate it if you would file a bug.

Quote
- Jogl's display creation is clumsy, awkward and not nearly as flexible as LWJGL's. Also, when it goes wrong it tends to core dump instead of throwing anything you could recover from.


Could you provide an example of how LWJGL's display creation is "more flexible" than JOGL's? The current JOGL source base does enforce a factory method for the construction of OpenGL widgets, but this restriction will be removed in the forthcoming JSR-231 API implementation.

Quote
- Jogl has the object access to GL, LWJGL uses the static interface. In theory that means Jogl has the handy-dandy composable pipeline. In reality both end up doing error checking (LWJGL substancially more on buffer args) but Jogl makes you pass round an annoying GL object constantly.


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.

Quote
- Jogl has a clumsy Animator interface for actually displaying anything that forces you to do things how it wants. Although I believe that there's now a proper swapBuffers interface now?


JOGL has exposed a swapBuffers API for nearly a year.

Quote
- Both are going to have heavyweight vs. lightweight issues when embedded in a Swing app. Theoretically Jogl has a lightweight display that doesn't suffer from these problems. Realistically it performs so slow its just not practical for anything useful.


JOGL 1.1 b08 adds hardware acceleration for its GLJPanel widget, and there are fixes in the CVS repository which will be present in 1.1 b09 which address performance issues on ATI cards. The GLJPanel is now fast enough and featureful enough for application use.

Quote
- Both have almost useful documentation. But the LWJGL examples/tests do provide a working base. By contrast the Jogl demos seem to be constantly out of sync everytime I look at them (and consequently broken).


This has not been my experience. The JOGL demos are tested on all platforms before each major release of the library and consistently show off the most advanced features of OpenGL like vertex and fragment programs.
Offline Vorax

Senior Devvie


Projects: 1


System shutting down in 5..4..3...


« Reply #20 - Posted 2005-02-15 00:03:11 »

First, I am not on one side or the other.  I just use what works.  I started my project with the one I saw the most demos for, JOGL, but will probably add LWJGL support later on.

Quote
Also:

- LWJGL is miles ahead in terms of reliability and compatibility. I couldn't seriously expect any professional game to be satisfied with the current reliability of Jogl.


I have found JOGL to be very stable and have had no issues in this regard.  The only problems I have ever really seen in running open gl java were actually LWJGL, but probably because it is more prevelant out there (an even more likely it was due to bugs in the program using the API).  From what I have seen both are stable enough for real use.

Quote

- Jogl's display creation is clumsy, awkward and not nearly as flexible as LWJGL's. Also, when it goes wrong it tends to core dump instead of throwing anything you could recover from.


I have found the API pretty easy to use.  In terms of core dumps, I am doing some pretty advanced stuff with it and have not seen any core dump that wasn't my fault.... though I would like to blame the API, it hasn't been an option so far Wink

Quote

- Jogl has the object access to GL, LWJGL uses the static interface. In theory that means Jogl has the handy-dandy composable pipeline. In reality both end up doing error checking (LWJGL substancially more on buffer args) but Jogl makes you pass round an annoying GL object constantly.


At first I didn't like this, but I found it made me do better code.  My project is a multi-threaded engine and not having access to the GL reference has made me avoid temptation in the engine thread... Of course if I really did want it, I could make it available any time.   However, I can see why that might be annoying to some.  It's a necessary evil for multiple GL contexts.  Unless you had some kind of set active context method added that had to be called before executing any GL commands...and it would make threading between contexts a bloody nightmare.

Quote

- Jogl has a clumsy Animator interface for actually displaying anything that forces you to do things how it wants. Although I believe that there's now a proper swapBuffers interface now?


What's this Animator you speak of?  Kidding. Smiley  
It's very easy to write your own buffer swap in JOGL.  There is no trick, just shut off the autoswap and then swap at the end of a render loop.

Quote

- Both are going to have heavyweight vs. lightweight issues when embedded in a Swing app. Theoretically Jogl has a lightweight display that doesn't suffer from these problems. Realistically it performs so slow its just not practical for anything useful.


Not sure, haven't used it like that yet.

Quote

- Both have almost useful documentation. But the LWJGL examples/tests do provide a working base. By contrast the Jogl demos seem to be constantly out of sync everytime I look at them (and consequently broken).


I found the Jogl demos to work perfectly, maybe it wasn't always so?  Dunno.  They're great now though.



Offline cyberyoyo

Junior Devvie




Java games funk


« Reply #21 - Posted 2005-02-15 00:23:22 »

It's very personal but I don't like external game libraries because IMO they make things more difficult ,except for the creators of said libraries.
That's why I chose JOGL, I prefer to create my own library from scratch with a clean base that lets me access OpenGL as I need to, it actually lets me save time.
With a game library or "framework" you have to spend a lot of time learning the library and how to use it.
Offline tom
« Reply #22 - Posted 2005-02-15 00:41:29 »

Quote
It's very personal but I don't like external game libraries because IMO they make things more difficult ,except for the creators of said libraries.
That's why I chose JOGL, I prefer to create my own library from scratch with a clean base that lets me access OpenGL as I need to, it actually lets me save time.
With a game library or "framework" you have to spend a lot of time learning the library and how to use it.

Do you think LWJGL is a "external game library" in contrast to JOGL? Or are your comment just off topic?

Offline weston

Junior Devvie





« Reply #23 - Posted 2005-02-15 02:37:39 »

lwjgl is a lot easier to just pick up and use, there really is no learning; if you know opengl you know lwjgl.  In contrast, jogl forces you to learn a bit more api specific stuff: should you use a glcanvas or a gljpanel? whats the best way to design your system so that everything that needs to have access to ogl can use the GL object? what should I put ean each of the 5 or so methods you have to implement when using the GLEventListener interface. Of course all that stuff is trivial, I'm just trying to point out that its sort of silly to say that you have to learn more to use lwjgl than jogl.

p.s. I don't actually think your silly Tongue I'm sure it was just a misconception about what lwjgl is, which is why it would be good to have all the facts in a single location.

edit: one of these days I'll learn to type.

for(int i = 1; i > 0; i++)
{
System.out.println(i+" cups of java downed");
}
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #24 - Posted 2005-02-15 03:36:40 »

Quote
It's very personal but I don't like external game libraries because IMO they make things more difficult ,except for the creators of said libraries.
That's why I chose JOGL, I prefer to create my own library from scratch with a clean base that lets me access OpenGL as I need to, it actually lets me save time.
With a game library or "framework" you have to spend a lot of time learning the library and how to use it.

Wow, you really don't know what LWJGL is?
There is no "learning" curve or framework you have to adhere to, to use LWJGL - you just plonk it in, and use OpenGL.

At most, you could argue that LWJGL forces you to use it's display system - but it's hardly difficult:
1  
2  
3  
Display.create();

// and we're set to go in fullscreen 640*480

Offline Deadcow

Senior Newbie




Back from beyond ... Moo!


« Reply #25 - Posted 2005-02-15 05:42:00 »

Comparison of JOGL and LWJGL seems pretty pointless to me, as their design goals are different. JOGL is supposed to be a generic and object oriented binding of opengl for java, that is, be able to handle every kind of opengl usage : games, CAD/CAO, etc. Thus, opengl context management makes sens in JOGL. On the other hand, LWJGL purpose is to provide a direct, lightweight and game oriented binding of opengl for java. Context management is of no use in games, as for AWT/Swing widget, so, what's the point adding it ?
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #26 - Posted 2005-02-15 06:09:12 »

Damnit, point-by-point argument makes reading messy Shocked So I'll try and keep this direct:

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

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.

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.

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

« JGO Spiffy Duke »


Medals: 434
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #27 - Posted 2005-02-15 08:07:26 »

A very surprising number of people jumped straight at JOGL to write games with, probably because it got that golden halo from Sun. But it's not a gaming oriented API, it's a completely integrated AWT solution for general purpose OpenGL. Similarly JInput is a hugely complex Swiss-army knife of an API. We just cut out everything that 99% of us don't need and left it at that.

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

Cas Smiley

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #28 - Posted 2005-02-15 08:21:57 »

There seems to be this image that because something is a semi-official Sun API it must magically be better, more reliable and more likely to be maintained over any 3rd party library.

The grim reality is that Sun don't care about gaming, and so don't care about its related technologies. Being an official Sun API didn't help Java3D any. And the GTG seem to have vanished without even the customary wisp of smoke.

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

Junior Devvie




Java games rock!


« Reply #29 - Posted 2005-02-15 13:10:39 »

Quote
A very surprising number of people jumped straight at JOGL to write games with, probably because it got that golden halo from Sun. But it's not a gaming oriented API, it's a completely integrated AWT solution for general purpose OpenGL. Similarly JInput is a hugely complex Swiss-army knife of an API. We just cut out everything that 99% of us don't need and left it at that.

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

Cas Smiley


Well, the problem is not the halo, but the focus.

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

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

This is not way a finger pointed in your direction but it's an hint to fly low with the ego... Cross platform support was clumsy from time to time (like in the donation drive for mac support), if also the architecture (well, it's not the exact term since LWJGL/JOGL  are substantially wrappers) fails to remain stable and consistent there's no way to define it professional. Hacky may be a more appropriate term.

JOGL has focus on a subset of what LWJGL does but does it trying to remain compliant with old code. It has a slower development process, but it is also more harmonic.

You'll not see many: "I at the moment don't need it, so I will put it on the backburner", from the JOGL team.

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

These are the factors that are relevant when you are  developing real software (that spans years, not a couple of months) and have to make choices.

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: fork an existing project, or adopt a support license. For professional needs I'd like to use AgentFX, more than rely on unsure & unstable specifications, for example. If I've the money I'd like to try to get my in-house one. And for that I thank you all to release the libs in the OS-friendly BSD instead of the zealotish GPL.

Matteo Anelli
.brain - http://www.dot-brain.com
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.

rwatson462 (30 views)
2014-12-15 09:26:44

Mr.CodeIt (23 views)
2014-12-14 19:50:38

BurntPizza (44 views)
2014-12-09 22:41:13

BurntPizza (78 views)
2014-12-08 04:46:31

JscottyBieshaar (39 views)
2014-12-05 12:39:02

SHC (53 views)
2014-12-03 16:27:13

CopyableCougar4 (51 views)
2014-11-29 21:32:03

toopeicgaming1999 (117 views)
2014-11-26 15:22:04

toopeicgaming1999 (107 views)
2014-11-26 15:20:36

toopeicgaming1999 (32 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50
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!