Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (109)
games submitted by our members
Games in WIP (536)
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
  ignore  |  Print  
  Core stability  (Read 8906 times)
0 Members and 1 Guest are viewing this topic.
Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Posted 2006-10-20 16:50:50 »

Hi,

Can anybody of developers currently working on Xith3D core make a short summary of the changes, so I can coordinate my changes with the current version of Xith3D?

Is the current CVS version more or less stable?

Yuri

Yuri Vl. Gushchin
JProof Group
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #1 - Posted 2006-10-20 17:27:42 »

Can anybody of developers currently working on Xith3D core make a short summary of the changes, so I can coordinate my changes with the current version of Xith3D?

I'll sum them up the next days when I find some time for it.

Is the current CVS version more or less stable?

I guess it is a little less stable at the moment, since I made some really huge changes. But I'm debugging, so it will be stable in some days (I hope). But it's not too unstable. And If you'd use it, we could find bug faster.

Marvin
Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #2 - Posted 2006-10-20 18:03:41 »

Hi,

I anyway have ~200,000+ lines of source code based on previous version of Xith3D, so I plan a switch to the latest CVS now.

Yuri

Yuri Vl. Gushchin
JProof Group
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #3 - Posted 2006-10-20 18:22:19 »

I anyway have ~200,000+ lines of source code based on previous version of Xith3D, so I plan a switch to the latest CVS now.

Cool.
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #4 - Posted 2006-10-20 19:02:33 »

@Yuri : I'll try to summarize a bit :
Qudus made deep change to the rendering code so old known bugs may have disappeared while new one are being killed each day (even if not reported here).
About groups : BranchGroup is now used exclusively for Locales. For everything else you should simply use Group.
Some classes have been moved (e.g. Canvas3D from scenegraph to render IIRC) in fact they've been copied and set to deprecated in their previous location..
Now Shape3D have "Types" with the setType() method you can specify if your shape is entirely dynamic, entirely static or if only the appearance or only the geometry are static. This is used AFAIK to build display lists.
Low-level multipass rendering has been implemented. For more details, ask to Qudus.
RenderLoop/ExtRenderLoop and Xith3DEnvironment/ExtXith3DEnvironment are slowly becoming adopted by Xith3D users. They contain utility functions, e.g. for thread-safe operations (with ScheduledOperator), timing facilities, and tons of others things (just browse the code).
I've added a PrecomputedAnimatedModel class with 2 loaders : from OBJ animations as exported by blender and for Cal3D animation (the Cal3D loader has been ported by me from theKman's work for jME).

Other various notes about community/dev :
- We're (I for now) progressively writing the W3G book (Writing 3D Games with xith). Currently I have written a small example which shows several interesting aspects of optimizations which can be made. You can have a look at it, it's well-documented (@see org.xith3d.w3g.ColorCube).
- A blog space has been opened on Xith.org (http://www.xith.org/dev_blog/) I would be glad if you (and Qudus, by the way)  can post what you're doing on Xith here so all of we can follow it more easily. Register on xith.org if not done and I'll grant you write access.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #5 - Posted 2006-10-20 19:17:59 »

About groups : BranchGroup is not used exclusively for Locales. For everything else you should simply use Group.

A little typing error here, which messes up the sense. BranchGroups are exclusively for being added to Locales.

Some classes have been moved (e.g. Canvas3D from scenegraph to render IIRC) in fact they've been copied and set to deprecated in their previous location..

Canvas3D is not copied. It is moved to com.xith3d.render and a I've created a new class with the same name in the scenegraph package, that extends the one in render and which is deprecated. So the old code is compatible in this regard.

Now Shape3D have "Types" with the setType() method you can specify if your shape is entirely dynamic, entirely static or if only the appearance or only the geometry are static. This is used AFAIK to build display lists.

That's correct. Additionally you can set the type through the Shape3D constructor.

RenderLoop/ExtRenderLoop and Xith3DEnvironment/ExtXith3DEnvironment are slowly becoming adopted by Xith3D users.

I think XIN helped to publish the information about these class'es existance.

Marvin

EDIT: btw. Qudus = Me
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #6 - Posted 2006-10-20 19:23:56 »

Edited the previous message, I really meant "now Bgs are used for...", not "not" ^^

EDIT: btw. Qudus = Me
Huh always regarding about credits, hehe ? ^^ No just kidding so I should always call you Marvin from now on ?

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #7 - Posted 2006-10-20 19:35:47 »

Huh always regarding about credits, hehe ? ^^ No just kidding so I should always call you Marvin from now on ?

I do already. You're the only one, who still calls me Qudus Grin.

Marvin
Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #8 - Posted 2006-10-21 13:46:11 »

Hi,

Quote
About groups : BranchGroup is now used exclusively for Locales. For everything else you should simply use Group.

Oops... Breaks compatibility with my code a lot - I use BG for logical grouping and attaching meta information to the subgraphs...
Sure not so big change, but in this case compiler does not warn me "class not existing"...

Yuri

Yuri Vl. Gushchin
JProof Group
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #9 - Posted 2006-10-21 16:27:44 »

Hi,

Quote
About groups : BranchGroup is now used exclusively for Locales. For everything else you should simply use Group.

Oops... Breaks compatibility with my code a lot - I use BG for logical grouping and attaching meta information to the subgraphs...
Sure not so big change, but in this case compiler does not warn me "class not existing"...

Yuri
Well then you just have to create a GroupBranch class or somewhat, and replaces instances of "org.xith3d.scenegraph.BranchGroup" in your code with "this.is.your.package.GroupBranch" then replace all "BranchGroup" with "GroupBranch" (thus avoiding package problems)... With eclipse it's done in a few minutes.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #10 - Posted 2006-10-21 16:28:25 »

Just for the sake of curiosity, what are your ~200'000 code lines about ?  Smiley

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline hawkwind

Junior Member




Java games rock!


« Reply #11 - Posted 2006-10-21 17:07:05 »

First off I have become a big proponent of the recent changes made to some of Xith.  I am slowly converting from my swing-xith UI to the HUD and am very pleased with the ease of conversion and the quality of the HUD UI components.

Quote
RenderLoop/ExtRenderLoop and Xith3DEnvironment/ExtXith3DEnvironment are slowly becoming adopted by Xith3D users. They contain utility functions, e.g. for thread-safe operations (with ScheduledOperator), timing facilities, and tons of others things (just browse the code).

These are GREAT improvements...my code is becoming much clearer as I fail over to using these routines.

Run and examine org.xith3d.test.ui.HUD3DTest


The Texture loader stuff is different, see an example using the class Xith3DDemoFolder in the HUD3DTest.
Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #12 - Posted 2006-10-21 17:16:19 »

Amos, check your PM.

As of replacing, sure it is no problems, but I have to convert also other my developers involved... so this is more organizational question than technical.

Yuri

Yuri Vl. Gushchin
JProof Group
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #13 - Posted 2006-10-21 17:21:35 »

The Texture loader stuff is different, see an example using the class Xith3DDemoFolder in the HUD3DTest.
Ah yeah, so obvious to me now that I forgot to mention it.
Yuri if you have seen TextureLoader2, then it's now named TextureLoader and the Old texture loader has been completely removed. So now we don't depend anymore on com.sun packages at all.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #14 - Posted 2006-10-21 17:24:05 »

Amos, check your PM.

As of replacing, sure it is no problems, but I have to convert also other my developers involved... so this is more organizational question than technical.
Yeah, I see.

EDIT: That's where it'd been useful if you had creeped on these forums while you were working with Xith3D : surely design decisions are made taking into account users' opinion/work.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #15 - Posted 2006-10-21 17:41:13 »

Hi,

Quote
Yuri if you have seen TextureLoader2, then it's now named TextureLoader and the Old texture loader has been completely removed.

I am not dependent on TextureLoader at all - I use my own texture loading mechanism which loads images DIRECTLY into DirectBufferedImage instead of loading to BufferedImage and after converting to elementary array - this significantly reduces memory consumption during application startup, and sometimes speeds up application startup, too.

Yuri

Yuri Vl. Gushchin
JProof Group
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #16 - Posted 2006-10-21 17:47:06 »

Quote
Yuri if you have seen TextureLoader2, then it's now named TextureLoader and the Old texture loader has been completely removed.

I am not dependent on TextureLoader at all - I use my own texture loading mechanism which loads images DIRECTLY into DirectBufferedImage instead of loading to BufferedImage and after converting to elementary array - this significantly reduces memory consumption during application startup, and sometimes speeds up application startup, too.
OH man! Would you contribute that to xith-tk? This feature has been asked for a few days ago.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #17 - Posted 2006-10-21 18:05:10 »

Hi,

Something like this:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
45  
46  
47  
48  
49  
   public static final Texture2D setupRGBATexture(String resource, int sizeLimit, int boundaryWidth) 
   {
      BufferedImage bi = null;
      boolean noUpscaleNeeded = false;
      try
      {
         ImageInputStream stream = ImageIO.createImageInputStream(J3D2Utils.class.getResourceAsStream(resource));
         Iterator iter = ImageIO.getImageReaders(stream);
         if (iter.hasNext())
         {
            ImageReader reader = (ImageReader)iter.next();
            ImageReadParam param = reader.getDefaultReadParam();
            reader.setInput(stream, true, true);
            int iw = reader.getWidth(0);
            int ih = reader.getHeight(0);
            int piw = pow2(iw);
            int pih = pow2(ih);
            if ((iw == piw) && (ih == pih))
            {
               BufferedImage dst = DirectBufferedImage.getDirectImageRGBA(piw, pih);
               param.setDestination(dst);
            }
            bi = reader.read(0, param);
            stream.close();
            reader.dispose();
            if (sizeLimit > 0)
            {
               if ((piw <= sizeLimit) && (pih <= sizeLimit))
                  noUpscaleNeeded = true;
            }
            else
               noUpscaleNeeded = true;
         }
         else
            stream.close();
      }
      catch (Exception e)
      {
         System.err.println("Error loading " + resource);
         e.printStackTrace();
      }
      BufferedImage bimg1;
      if ((bi instanceof DirectBufferedImage) && noUpscaleNeeded)
         bimg1 = bi;
      else
         bimg1 = upScaleRGBA(bi, sizeLimit);
      ImageComponent2D imgc1 = new ImageComponent2D(ImageComponent.RGBA, bimg1.getWidth(), bimg1.getHeight(), bimg1);
      return setupRGBATexture(imgc1, boundaryWidth);
   }


upScale and setupRGBATexture methods are trivial, you nayway do not need them (OK, maybe upscale) in your architecture.

Important point is param.setDestination(dst), so you theoretically can modify your existing TextureLoader2 to use this trick, so everybody will immediately benefit from it.

I can not contribute to your loader because of my texture loading architecture is quite different and quite project specific.

Yuri

Yuri Vl. Gushchin
JProof Group
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #18 - Posted 2006-10-21 18:34:37 »

Huh okay, will see what I can do.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #19 - Posted 2006-10-21 19:41:52 »

Hi,

Shader processing seem to work somehow strange. I checked older examples (especially, TextureFiltersTest and StencilTest), and they do not work as expected.

Check JavaWebStart versions on xith.org - there they work as expected (Hit "Space" in StencilTest to see the difference with stencil test on/off).

Also the Q3FlightBenchmark shows in some cases odd behavior which is from my experience is typical when ther is a problem with shaders state changes.

Yuri

Yuri Vl. Gushchin
JProof Group
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #20 - Posted 2006-10-27 11:20:49 »

I'm thinking about the best way to integrate Yuri's texture loading way in TextureLoader2... I saw 3 potential places to put it in :
1. Create a "generic" TextureStreamLoader
2. Create a generic ImageComponentLoader
3. Replace this call by something better :
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
else {
                    try {
                        BufferedImage img = ImageIO.read(in);
                       
                        if (img != null) {
                            tex = createTexture(img, flipVertically, format, mipmap);
                        }
                    } catch (Throwable ex) {
                        ex.printStackTrace();
                    }


Other question : aren't TextureStreamLoader/ImageComponentLoader added automatically ?

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #21 - Posted 2006-10-27 12:19:18 »

I choosed solution 3..

Getting errors with some JPEGs...

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
Texture [src/Textures/gelo.JPG] has not been found in any locator
java.lang.IllegalArgumentException: ImageReadParam num source & dest bands differ!
   at javax.imageio.ImageReader.checkReadParamBandSettings(ImageReader.java:2746)
   at com.sun.imageio.plugins.jpeg.JPEGImageReader.readInternal(JPEGImageReader.java:907)
   at com.sun.imageio.plugins.jpeg.JPEGImageReader.read(JPEGImageReader.java:864)
   at com.xith3d.loaders.texture.TextureLoader.read(TextureLoader.java:397)
   at com.xith3d.loaders.texture.TextureLoader.loadFromStream(TextureLoader.java:349)
   at com.xith3d.loaders.texture.TextureLoader.getTexture(TextureLoader.java:788)
   at com.xith3d.loaders.texture.TextureLoader.getTexture(TextureLoader.java:458)
   at com.xith3d.loaders.texture.TextureLoader.getTexture(TextureLoader.java:443)
   at org.xith3d.ui.hud.widgets.Image$Description.<init>(Image.java:85)
   at org.xith3d.ui.hud.widgets.Image.<init>(Image.java:257)
   at org.xith3d.ui.hud.widgets.Label.setBackground(Label.java:312)
   at game.Game.createHUD(Game.java:561)
   at game.Game.<init>(Game.java:1314)
   at game.Game.main(Game.java:1349)


What does this mean ?

Yuri is the approach fast because a DirectBufferedImage is used ?

The current code is as follow :

1  
2  
3  
4  
5  
6  
                                BufferedImage dst = null;
            if(format == RGB) {
               dst = DirectBufferedImage.getDirectImageRGB(iw, ih);
            } else if(format == RGBA) {
               dst = DirectBufferedImage.getDirectImageRGBA(iw, ih);
            }


but with that code :

1  
dst = reader.getImageTypes(0).next().createBufferedImage(iw, ih);


I never get any errors

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #22 - Posted 2006-10-27 12:57:29 »

Okay, so I don't know how to make DirectBufferedImage for each image now so I stay with BufferedImage but Yuri if you have an idea of how to fix that take a look at the CVS.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #23 - Posted 2006-10-27 13:51:31 »

Hi,

After reviewing the code in texture shader, ImageComponent2D and DirectBufferedImage, I believe that we sould introduce some changes also there.

The general point on loading textures is that we copy them way too much - at least 3 times when DirectBufferedImage is used, and 4 times when using plain BufferedImage. Textures often are big, so this consumes memory and increases the startup time.

For regular BufferedImage, procedure is following:

A1. Read image and store it to data array allocated internally by ImageIO
A2. Allocate new byte[] in ImageComponent2D and pull data out of BufferedImage from step A1 using pixel processor
A3. Allocate DirectByteBuffer in ImageComponent2D and put data from byte[] from step A2 into it
A4. Pass a reference to DirectByteBuffer created at A3 to OpenGL context, which will allocate one more array to hold texture data in driver space

Step A4 we can not avoid anyway... (there are some ideas on that, but I am not so sure they will work).

Now what is happening with DirectBufferedImage.

B1. Create new DirectBufferedImage of appropriate type - it will create the byte[] (the Backing Store) similar to one created on A2 and hold reference to it
B2. Read image DIRECTLY into DirectBufferedImage - this will store pixel data into Backing Store byte[] and will avoid of extra byte[] allocation inside ImageIO
B3. Allocate DirectByteBuffer in ImageComponent2D and put data from byte[] from step B1 into it
B4. Pass a reference to DirectByteBuffer created at B3 to OpenGL context,

...and how it should be at the end:

C1. Create new DirectBufferedImage of appropriate type - it will create the DirectByteBuffer (the Backing Buffer) similar to one created on B3 and hold reference to it
C2. Read image DIRECTLY into DirectBufferedImage - this will store pixel data into Backing Buffer DirectByteBuffer. This is way more tricky, but I have few implementations of this which are fast enough (I did that for progress-trackable texture loading which shows the progress of ImageIO decoding the image.
C3. Create ImageComponent2D such a way that no new DirectByteBuffer is created but one from step C1 used
C4. Pass a reference to DirectByteBuffer created at C1 to OpenGL context

You can see that we can get rid of a lot of pixel processing this way, but this only fits Power-Of-Two-sized textures, and others have to be loaded conventional way.

Yuri

Yuri Vl. Gushchin
JProof Group
Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #24 - Posted 2006-10-27 13:57:36 »

Hi,

In general, you should support images of up to 4 bands:

1-band (grayscale) - for Alpha or Luminance textures
2-band - For Luminance+Alpha textures
3-band for RGB
4-band for RGBA.

There are methods for creating DirectBufferedImage for cases of 1, 3 and 4 bands. We probably should also support 2-band. Check com.xith3d.image.DirectBufferedImage for details.

Yuri

Yuri Vl. Gushchin
JProof Group
Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #25 - Posted 2006-10-27 14:27:18 »

Hi,

Quote
Step A4 we can not avoid anyway... (there are some ideas on that, but I am not so sure they will work).

I just checked the state-of-the-art OpenGL extensions, and there are ways how to avoid this and make texture download to the driver even faster.

Yuri

Yuri Vl. Gushchin
JProof Group
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #26 - Posted 2006-10-27 20:39:47 »

Okay, I guess this issue is assigned to you? (understand : I won't work on it anymore)

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #27 - Posted 2006-10-28 10:02:26 »

Hi,

Quote
Okay, I guess this issue is assigned to you? (understand : I won't work on it anymore)

Not really, I just explain how things work.

What I can (and probably will) do is to change DirectBufferedImage implementation so it is using DirectByteBuffers. Integration with TextureLoader is your part.

A4 step acceleration is tricky, but it after may make use of DMA transfers directly from user space to AGP/PCI/PCI-e memory or even decode image data directly there.

I am not so sure if we should use this because of side effect is neccesity to put all textures in single DirectByteBuffer (i.e. implement a kind of texture memory allocation ourself).

Yuri

Yuri Vl. Gushchin
JProof Group
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #28 - Posted 2006-10-28 11:26:46 »

Not really, I just explain how things work.
What I can (and probably will) do is to change DirectBufferedImage implementation so it is using DirectByteBuffers. Integration with TextureLoader is your part.
A4 step acceleration is tricky, but it after may make use of DMA transfers directly from user space to AGP/PCI/PCI-e memory or even decode image data directly there.
I am not so sure if we should use this because of side effect is neccesity to put all textures in single DirectByteBuffer (i.e. implement a kind of texture memory allocation ourself).
Hmm ok but then what about the not-same-number-of-bands error ? Some changes in DirectBufferedImage also? (maybe add a "bands" params in createDirectRGB(A)() methods?)

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #29 - Posted 2006-10-28 13:13:30 »

Hi,

I would like to get images that produce these errors for further investigation.

I had only a problem with bands when was trying to load RBG texture into RGBA destination, and Grayscale texture in RGB/RGBA destination.

Yuri

Yuri Vl. Gushchin
JProof Group
Pages: [1] 2
  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.

CogWheelz (18 views)
2014-07-30 21:08:39

Riven (26 views)
2014-07-29 18:09:19

Riven (15 views)
2014-07-29 18:08:52

Dwinin (13 views)
2014-07-29 10:59:34

E.R. Fleming (34 views)
2014-07-29 03:07:13

E.R. Fleming (12 views)
2014-07-29 03:06:25

pw (43 views)
2014-07-24 01:59:36

Riven (44 views)
2014-07-23 21:16:32

Riven (30 views)
2014-07-23 21:07:15

Riven (31 views)
2014-07-23 20:56:16
List of Learning Resources
by SilverTiger
2014-07-31 18:29:50

List of Learning Resources
by SilverTiger
2014-07-31 18:26:06

List of Learning Resources
by SilverTiger
2014-07-31 13:54:12

HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54
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!