Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (741)
Games in Android Showcase (225)
games submitted by our members
Games in WIP (823)
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] 4 5 ... 7
  ignore  |  Print  
  Catch 22 for jogl  (Read 66019 times)
0 Members and 1 Guest are viewing this topic.
Offline gouessej
« Reply #60 - Posted 2009-11-30 16:09:18 »

Sun already proved it doesn't give a damn about how many corporations are using it, as it's now in the hands of volunteers, so it can very well die, and relatively fast too. I'm not saying it will, I'm just saying that it is more likely to die than LWJGL.
It won't stay only in the hands of volunteers but rather in a community composed of both volunteers and paid engineers because it is in the interest of some corporations that have invested some time in building some frameworks on JOGL. It is too early to make any public announcement, I need some confirmations and some authorizations but I have excellent reasons to keep confident in JOGL. This library won't die; if the project of unification succeeds, the OpenGL-ES binding (and maybe some other features) of JOGL will be used; otherwise, a set of organizations will "take care of the baby" even though the exact kind of help is not yet clearly defined. Therefore, why going on speaking about its death? This is only a supposition. I don't make any supposition about the future of LWJGL.

We can still unify what is unifiable and keep 2 separate OpenGL bindings, it is an option. That's why I spoke about JOCL.

Julien Gouesse | Personal blog | Website | Jogamp
Offline kappa
« League of Dukes »

JGO Kernel


Medals: 119
Projects: 15


★★★★★


« Reply #61 - Posted 2009-11-30 17:27:37 »

We can still unify what is unifiable and keep 2 separate OpenGL bindings, it is an option. That's why I spoke about JOCL.

maybe gouessej has a point here, if the jogl dev's are willing for the merge to go ahead (just looks like LWJGL dev's atm), we can start by sharing parts that are missing from each binding.

e.g. theres no solid solution for sound when using JOGL atm, JOAL is just buggy as hell and development is dead, LWJGL on the other hand has a solid field tested sound solution with OpenALSoft which can be separated in a way it'd be usable by ppl using JOGL. Other examples include OpenGL ES which is missing in LWJGL but JOGL already has it. LWJGL's smooth AppletLoader or OpenCL with JOGL, NEWT is a similar concept to LWJGL's native Display again could share code bases, Native Input systems for Keyboard and Mouse, etc.

all are parts that can be started on pretty quickly and shared.

But again the main thing here is both parties (LWJGL and JOGL) must be willing to commit to a community effort.
Offline gouessej
« Reply #62 - Posted 2009-11-30 19:16:46 »

e.g. theres no solid solution for sound when using JOGL atm, JOAL is just buggy as hell and development is dead, LWJGL on the other hand has a solid field tested sound solution with OpenALSoft which can be separated in a way it'd be usable by ppl using JOGL.
Paul Lamb has made a great job, "3D Sound System" works fine even with Java Sound. JOAL is no more maintained but on my view, the absence of OpenAL is not blocking for a gaming project even though the simulation of some advanced features with Java Sound is not completely satisfying.

Other examples include OpenGL ES which is missing in LWJGL but JOGL already has it. LWJGL's smooth AppletLoader or OpenCL with JOGL, NEWT is a similar concept to LWJGL's native Display again could share code bases, Native Input systems for Keyboard and Mouse, etc.

all are parts that can be started on pretty quickly and shared.

But again the main thing here is both parties (LWJGL and JOGL) must be willing to commit to a community effort.
The community effort of JOGL does not depend on me as I have a pretty minor role, I will spare a bit of my time to fix some bugs in JOGL 2 if needed but I'm not a main contributor of JOGL, the decision concerning this library has to be made by Sven, Bienator and some legitimate people. We have to split the job into smaller tasks as you suggest. I don't know if it leads to a single unified API but it would be so fine to avoid creating 6 Java bindings of OpenCL and a bad clone of native systems in JOGL. However, where is your bug tracker? I would like to have a clear visibility on bugs of LWJGL and I will never use and promote any API that underestimates the support of Linux.

Another problem concerns the support of controllers under Linux. This problem has been solved in SFML (I don't know how) but not in JInput.

Finally, if we avoid duplicating efforts on some libraries, we will have more time to invest in some other projects. Spasi spoke about WebGL, I would like to have a wrapper of Android OpenGL-ES binding to use JOGL on Android, OpenGL-ES is available on PS3 too.

Edit.: OpenCL4Java and JOCL (of Apache, not JOGL of Bienator) are going to be merged.

Julien Gouesse | Personal blog | Website | Jogamp
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline kappa
« League of Dukes »

JGO Kernel


Medals: 119
Projects: 15


★★★★★


« Reply #63 - Posted 2009-11-30 19:59:14 »

However, where is your bug tracker?

legitimate bugs are usually crushed and killed pretty quickly usually within a few days of being report on the forums. The lwjgl forums serve as the main hub for bug reports or even are sometimes dealt with in real time via the lwjgl irc channel.

I would like to have a clear visibility on bugs of LWJGL and I will never use and promote any API that underestimates the support of Linux.

I'd also like to point out that I am also a Linux users and have been for using it as my main OS for a number of years, LWJGL support and compatibility has been nothing short of fantastic for this platform. Many of the core decisions regarding LWJGL's architecture have been taken to accommodate Linux. Also a number of core LWJGL developers develop on linux or have access to it. LWJGL was also the first binding to support 64 bit linux, so I'd rest assured that Linux is most definitely treated as a first class supported platform.

You always seem to imply that somehow LWJGL is lacking on linux which IMO is definitely not the case. As I remember the last time you had a tantrum about lwjgl not working on linux (which lasted a few months) you were using a botched example which was resulting in you getting a blank screen and had nothing to do with LWJGL and the other issues with regards to lines on your desktop has already been dealt with above by princec.

So really I wouldn't worry about lack of linux support.

Spasi spoke about WebGL

This IMO is a great idea, I'd love to see where this goes. Even if you we don't get direct access to WebGL via java, i reckon java plugin2's java -> javascript bridge is good enough to still create something nice and take advantage of java's raw horsepower. Direct Acess however would be an awesome development then to use the java -> javascript -> webgl bridge.
Offline gouessej
« Reply #64 - Posted 2009-11-30 21:22:28 »

Sorry I have just tested LWJGL 2.2.1 (FullScreenWindowedTest) and I have still the straight lines on my task bar as you can see in the screen capture (the enclosed file). This is a very old bug (at least 3 years?). Unlike princec, I think this bug comes from the way LWJGL modifies the display mode when exiting, I can verify my hypothesis when I have a few hours to spare, ok?

Julien Gouesse | Personal blog | Website | Jogamp
Offline gouessej
« Reply #65 - Posted 2009-11-30 22:24:46 »

I have a suggestion concerning the project of unification. Maybe we could satisfy everyone by following these "ideas":
- we keep OpenALSoft for the sound, we forget JOAL that is no more maintained
- we keep the whole native systems of LWJGL for the display (but I try to fix the bug I reported if possible), mouse, keyboard (but we improve the support of controllers under Linux by looking at SFML if possible) and we keep only the part of Newt that may be useful with OpenGL-ES, we throw the rest of Newt...
- we keep the both OpenGL bindings by using a kind of profile (GL.setBinding("LWJGL") or GL.setBinding("JOGL")) in order to please everyone and to allow OpenGL-ES access until people of the both teams find a solution to keep only one of them but we expose a common LWJGL-like public API
- maybe we keep the applet loader of LWJGL if it is really more reliable than its JOGL equivalent
- we package the project so that people who only needs an OpenGL binding or an OpenAL binding can use it separately even though removing some classes from a JAR is trivial
- we merge JOCL, OpenCL4Java and Java Bindings for OpenCL because having 3 bindings of OpenCL (instead a single reliable and cross-platform one) is a waste of energy
- the Android OpenGL-ES API is very close to the JSR 239 (Java bindings to the OpenGL ES native 3D graphics library) that is actually in JOGL 2, it is only a small "derivation", we should do something to allow the unified library to work with Android too
- we provide a new name for this unified API, we don't keep any previous names (maybe the name should not contain the word "game" in order to target not only gaming applications)

What do you think about it?

Julien Gouesse | Personal blog | Website | Jogamp
Offline spiraljetty

Senior Newbie





« Reply #66 - Posted 2009-11-30 22:54:02 »

This is an exciting discussion! There is a set of C# bindings called "The Open Toolkit Library", or "openTK" (http://www.opentk.com/) which wraps openGL, openAL, and openCL. Maybe a similar name like JOTK (for Java Open Toolkit), or JOB (for Java Open Bindings)?

-sj
Offline gouessej
« Reply #67 - Posted 2009-11-30 23:06:15 »

This is an exciting discussion! There is a set of C# bindings called "The Open Toolkit Library", or "openTK" (http://www.opentk.com/) which wraps openGL, openAL, and openCL. Maybe a similar name like JOTK (for Java Open Toolkit), or JOB (for Java Open Bindings)?
JOTK is a good catch, why not? Lol I remind you that the OpenGL binding of OpenTK is twice slower than JOGL  Grin Long life to Java  Tongue

Julien Gouesse | Personal blog | Website | Jogamp
Offline bienator

Senior Devvie




OutOfCoffeeException


« Reply #68 - Posted 2009-12-01 01:38:51 »

or JogAmp.org Java Graphics Audio Media Processing bindings

btw builds are now online (+junit and javadoc):
http://michael-bien.com/hudson/
(url will change)

I hope to join the discussion the next days... no time..

Offline pjt33

« JGO Spiffy Duke »


Medals: 40
Projects: 4
Exp: 7 years



« Reply #69 - Posted 2009-12-01 10:26:26 »

JOB (for Java Open Bindings)?
No no no! Cutesy acronyms like that make a project impossible to find with a search engine. If you Google for java opengl job you will get tonnes of recruitment sites. Unique is good.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

« JGO Spiffy Duke »


Medals: 973
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #70 - Posted 2009-12-01 11:06:59 »

Haha, something like ... LWJGL Wink Except maybe LWJML is more like it (M for Media or Multimedia).

Need to get something straight though: we can implement an instance based binding on top of a static binding, but not the other way around. Right now, today, we can probably provide a mostly compatible JOGL interface that called down to LWJGL.

Cas Smiley

Offline lhkbob

JGO Knight


Medals: 32



« Reply #71 - Posted 2009-12-01 22:46:37 »

As for acronyms, I'd like one that can be sounded out easily.  JOGL sounds like 'joggle', LWJGL makes a sound like 'lowjiggle' which I'm not a fan of (maybe there's an official pronunciation that's different?).  JOTK and JOGAMP are okay.

How about jAMP (java Audo Media Processing).  This is of course assuming that LWJGL won't just subsume the functionality of JOGL and keep its name.  Although I'm not in a position to truly argue against that, I think a project for a merge of this scope should have a new name to start anew and be fair to both sides (sort of give up the "bad blood" that may have developed between the projects).

Offline gouessej
« Reply #72 - Posted 2009-12-01 23:27:42 »

I think a project for a merge of this scope should have a new name to start anew and be fair to both sides (sort of give up the "bad blood" that may have developed between the projects).
I agree with you, that is why I suggested a change of name.

princec, kapta, what returns the method org.lwjgl.opengl.DisplayMode.getBitsPerPixel() when the X server pretends to support multiple depths at the same time (see java.awt.DisplayMode.BIT_DEPTH_MULTI)? What returns getFrequency() when the frequency is unknown (see java.awt.REFRESH_RATE_UNKNOWN)? When a Java application sets back the correct display mode and frequency on my machine, the straight lines disappear. I will give another look at the source code Saturday.

Julien Gouesse | Personal blog | Website | Jogamp
Offline xinaesthetic

Senior Devvie


Medals: 1



« Reply #73 - Posted 2009-12-02 12:24:44 »

How about jAMP (java Audo Media Processing).
"Audio Media Processing" to me sounds like something for processing media of the audio variety, especially given the 'AMP' acronym.

Maybe jMP (java Media Processing) would work.
Offline arielm

Junior Devvie




which way to the station?


« Reply #74 - Posted 2009-12-02 12:47:00 »

1) Direct-J
2) J-Extreme
Smiley

Ariel Malka | www.chronotext.org
Offline kevglass

« JGO Spiffy Duke »


Medals: 319
Projects: 25
Exp: 22 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #75 - Posted 2009-12-02 13:59:23 »

Java Unified Media Processing - JUMP!

Kev

Offline jezek2
« Reply #76 - Posted 2009-12-02 14:04:01 »

Yeah a new name would be better. Though both names have their long history and while I'm LWJGL user, I admire the JOGL name sounds better and more official. I'm very used to LWJGL name, but it bothers me a little that there is Game keyword in the name. LWJGL is great for non-gaming applications.

One thing is pretty limited though, the singleton behaviour of Display and other classes. This was not problem, usually you want just one screen, but with addition of setParent method it's pretty limiting, also what about multiple screens?
Offline Spasi
« Reply #77 - Posted 2009-12-02 14:17:45 »

Maybe we should wait to see what Bienator and other JOGL devs have to say before discussing potential features and library names (this thread isn't the best place to do it anyway). I purposely left out any suggestions from my replies on what *I think* should go into the merged library, I'd much rather see discussions start from a clean slate, assuming of course the JOGL party is interested (reminder: their first reply sounded negative Tongue). As I mentioned already the technical problems should pose no threat, but we really need this effort to be driven by what the users of both libraries want and need. The only assumption I'm making at this point is that it's in everyone's best interest for this merge to happen.

So, I'd like to hear more arguments in favor or against this assumption.
Offline gouessej
« Reply #78 - Posted 2009-12-02 14:33:37 »

As I mentioned already the technical problems should pose no threat, but we really need this effort to be driven by what the users of both libraries want and need. The only assumption I'm making at this point is that it's in everyone's best interest for this merge to happen.

So, I'd like to hear more arguments in favor or against this assumption.
I wonder how such a unified library could both give an access to OpenGL-ES through JOGL 2 and give an access to plain OpenGL through LWJGL if its users want to keep it. If we don't want to duplicate the efforts of maintenance on the OpenGL binding, we cannot keep 2 implementations of it, we will have to choose one of them.

Julien Gouesse | Personal blog | Website | Jogamp
Offline jezek2
« Reply #79 - Posted 2009-12-02 14:38:14 »

I wonder how such a unified library could both give an access to OpenGL-ES through JOGL 2 and give an access to plain OpenGL through LWJGL if its users want to keep it. If we don't want to duplicate the efforts of maintenance on the OpenGL binding, we cannot keep 2 implementations of it, we will have to choose one of them.

The generator can be extended to generate both APIs. Either by creating native methods for both APIs, or to create JOGL API as wrapper of lower level LWJGL API. The inline ability of HotSpot should completely eliminate any additional overhead when using this approach.
Offline ryanm

Senior Devvie


Projects: 1
Exp: 15 years


Used to be bleb


« Reply #80 - Posted 2009-12-02 20:03:39 »

Java Unified Media Processing - JUMP!

Kev
I mean this entirely literally: LOL

That is all.
[size=1pt]edit: unless of course it was a serious suggestion - in which case I'm 100% behind it.[/size]
Offline PeterB

Junior Devvie


Exp: 15 years



« Reply #81 - Posted 2009-12-02 22:14:20 »


I'd just like to say I'm eternally grateful for the work people have done maintaining GL4Java (Sven/Ken + others) years ago and in turn JOGL. It's helped me to learn loads about OpenGL using my main programming language (Java) without having to get back up to speed in C++ and I've been able to realise a lot of project ideas that were kicking around my head.

This is not a pro-JOGL / anti-LWJGL post (LWJGL is awesome too), I'm just showing my appreciation to contributors.

Thanks! Wink

On the anagram, I'm growing to like 'JUMP' ... it's catchy.


Offline Cork

Junior Devvie




vote 6uN for OSX


« Reply #82 - Posted 2009-12-03 06:22:00 »

Quote
I'd just like to say I'm eternally grateful for the work people have done maintaining GL4Java (Sven/Ken + others) years ago and in turn JOGL. It's helped me to learn loads about OpenGL using my main programming language (Java) without having to get back up to speed in C++ and I've been able to realise a lot of project ideas that were kicking around my head.

Indeed I can fully relate to that.  I have a similar background with GL4Java and I think these guys have done a great job o bring it this far.

I'm especially excited about the new features in JOGL2 like ES2, newt and CL support.  Breaking the AWT tie has to be a good thing too when you look at what's coming up with google os/android based netbooks/laptops/phones etc.  It would be great if JOGL can keep it's very light weight core with all the optional jars approach, and then if the best bits of other libs could live also as optional jars that sit on top, or along side, then that wold make a developers life easy.  As always I'm thinking about deployment issues and I think the focus should not just be on the name of any unified package, but also on how do we compete with flash and silverlight.  Whatever comes out of the process here has to be proffesional/serious enough to contend with these technologies, otherwise we may as well not try.  I don't think FX is the solution to Java on the desktop, I think what we build here could be though!!  The idea of accessig the browser context for direct rendering sounds like it would help alot, but otherwise we need to find a simple way to deploy 'JUMP' components to work on all desktops/OS's.  Then we can start thinking about our own store...!!

Peter

Offline arielm

Junior Devvie




which way to the station?


« Reply #83 - Posted 2009-12-03 08:58:37 »

As always I'm thinking about deployment issues and I think the focus should not just be on the name of any unified package, but also on how do we compete with flash and silverlight.  Whatever comes out of the process here has to be proffesional/serious enough to contend with these technologies, otherwise we may as well not try

I Agree...
Fixing JOGL is one thing, but when we look at the overall user-experience of accessing some JOGL/LWJGL content on the web, the situation is almost hopeless:

1) Java is far from being installed everywhere. Many reasons for that:
- poor content offer
- installation is not seamless (as Flash is...)
- lack of clear "Desktop Strategy" from Sun, etc.

2) The "Java Web Start Experience" sucks:
- It takes ages until the JVM is (first) loaded
- The jar downloading process is painful (we all know the "download stalled" issue, regardless of the quality of the connection)
- The need for certificate is a big annoyance both for users and developers (3d content should not require any certificate)

Well, nothing new. People have been discussing these issues for years.
I'm reading here and there that OpenJDK could solve (on the paper) many of these problems, but frankly, I don't believe in a massive world adoption...

Any hope doc?

Ariel Malka | www.chronotext.org
Offline pjt33

« JGO Spiffy Duke »


Medals: 40
Projects: 4
Exp: 7 years



« Reply #84 - Posted 2009-12-03 09:15:10 »

- installation is not seamless (as Flash is...)
I wish. One thing you can say in Java's favour is that it has proper Linux support.
Offline gouessej
« Reply #85 - Posted 2009-12-03 09:27:47 »

The generator can be extended to generate both APIs. Either by creating native methods for both APIs, or to create JOGL API as wrapper of lower level LWJGL API. The inline ability of HotSpot should completely eliminate any additional overhead when using this approach.
I would feel better if we did the opposite, we keep JOGL underneath and we create a wrapper to expose a LWJGL-like API for those who wish to use it because JOGL has an OpenGL-ES support, it is an excellent reason to keep it as the core OpenGL/OpenGL-ES binding. However, I understand that some LWJGL users may prefer your suggestion.

1) Java is far from being installed everywhere. Many reasons for that:
- poor content offer
- installation is not seamless (as Flash is...)
- lack of clear "Desktop Strategy" from Sun, etc.
Java is installed on 91% of the desktop computers whereas Flash is installed on 92% of the desktop computers as far as I know and I cannot install Flash on some computers under Windows Vista because the new installer works bad, it is not seamless, it seems to work bad with some firewalls, I have not found the exact root cause, the installation does not even start. There is a lack of strategy but the content is far from being poor on my view. When I see so many Flash games with a so limited gameplay, I don't call this a rich content, sorry for Flash programmers and artists, I see many Flash games using very similar artworks or concepts, it looks like several games made with the same cake pan, it becomes quickly boring... I prefer MineCraft, Tesseract, Bloodridge, Futuristic Arenas, Incredibuilder! ...

2) The "Java Web Start Experience" sucks:
- It takes ages until the JVM is (first) loaded
- The jar downloading process is painful (we all know the "download stalled" issue, regardless of the quality of the connection)
- The need for certificate is a big annoyance both for users and developers (3d content should not require any certificate)
Therefore, don't use Java Web Start, nobody forces you to do this. It is almost enough to deploy quickly a blue print but using an installer gives a more professional result (IzPack for example). 3D content should not require any certificate but the use of certificate for games accessing to the file system is a good thing on my view, it is safer, you don't allow anyone to do anything.

Julien Gouesse | Personal blog | Website | Jogamp
Offline Riven
Administrator

« JGO Overlord »


Medals: 1324
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #86 - Posted 2009-12-03 09:42:01 »

Java is installed on 91% of the desktop computers whereas Flash is installed on 92% of the desktop computers as far as I know

That would have been nice, but we shouldn't believe Sun propaganda.

It's more like 78-82% (depending on the country) and about 40% still using the old plugin (pre 6u10), which is unreliable. In my own gathered statistics, about 67% of non-technical users on a non-technical website, were able to launch an applet that was able to connect to its own host.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Offline jezek2
« Reply #87 - Posted 2009-12-03 10:09:59 »

I would feel better if we did the opposite, we keep JOGL underneath and we create a wrapper to expose a LWJGL-like API for those who wish to use it because JOGL has an OpenGL-ES support, it is an excellent reason to keep it as the core OpenGL/OpenGL-ES binding. However, I understand that some LWJGL users may prefer your suggestion.

I didn't mean to prefer LWJGL, but purely at technical level it seems that LWJGL static methods are exposing OpenGL directly as-is, whereas JOGL approach seems little more highlevel, so this approach make most sense technical-wise. I'll look to both LWJGL and JOGL sources to check if this is really true.

About OpenGL ES, I don't see any problem, in any way there would be just one generator, so the ES would be supported by both APIs.
Offline arielm

Junior Devvie




which way to the station?


« Reply #88 - Posted 2009-12-03 11:41:47 »

Java is installed on 91% of the desktop computers whereas Flash is installed on 92%

You're quite of an optimist monsieur.
But anyway, user-experience wise, you can't compare the overall "Java on the Desktop" experience with what Flash has to offer...

Java Web Start reflects the state-of-the-art of what Sun is capable / willing to propose on the Desktop.
It's been here for years, it sucks (user-experience wise) and it's broken.
Logical conclusion: it's never going to be better (confirmed by the recent drop of Jogl by Sun...)

Therefore, don't use Java Web Start, nobody forces you to do this

I don't believe in that direction either.
We live in Browser Land, and the future will be even more browser-based (think Chrome OS...)

In my humble opinion, the hope _ in term of Java + OpenGL _ resides in Android. Not exactly as it is today but in the not-so-far future (when Android enabled devices become bigger, with decent GPUs and JIT compiling...)
Let's try not to miss the train this time!

Ariel Malka | www.chronotext.org
Offline princec

« JGO Spiffy Duke »


Medals: 973
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #89 - Posted 2009-12-03 11:56:59 »

And the only guy who knew anything about fixing it (Ken, of plugin2 fame) got pushed out and went to work for Google. Leaving the rest to come up with the brilliant Java Store application.

Cas Smiley

Pages: 1 2 [3] 4 5 ... 7
  ignore  |  Print  
 
 

 
Ecumene (108 views)
2017-09-30 02:57:34

theagentd (135 views)
2017-09-26 18:23:31

cybrmynd (245 views)
2017-08-02 12:28:51

cybrmynd (240 views)
2017-08-02 12:19:43

cybrmynd (238 views)
2017-08-02 12:18:09

Sralse (252 views)
2017-07-25 17:13:48

Archive (864 views)
2017-04-27 17:45:51

buddyBro (1007 views)
2017-04-05 03:38:00

CopyableCougar4 (1566 views)
2017-03-24 15:39:42

theagentd (1373 views)
2017-03-24 15:32:08
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

SF/X Libraries
by SkyAphid
2017-03-02 06:38:56

SF/X Libraries
by SkyAphid
2017-03-02 06:38:32

SF/X Libraries
by SkyAphid
2017-03-02 06:38:05

SF/X Libraries
by SkyAphid
2017-03-02 06:37:51
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!