Java-Gaming.org    
Featured games (78)
games approved by the League of Dukes
Games in Showcase (429)
Games in Android Showcase (89)
games submitted by our members
Games in WIP (468)
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  
  Objectloader  (Read 22553 times)
0 Members and 1 Guest are viewing this topic.
Offline apohlmann

Senior Newbie





« Posted 2006-11-13 13:27:11 »

Hi,

got another problem...
I tried to load a simple cube, exported from wings3D or Blender.
The loaded cube from the Blender-file is black or white depending on some settings; the wings3D-file is loadable with texture but (that's my problem) I want to change the texture or material of the cube but i can't reach the cube.
I load it that way: scene = objL.load("Test.obj");
Some posted codes load it like BranchGroup xy = null; -> null = new OBJLOader().load("xy");
I used to test it but if I try to load the object that way, I got a classCastException...  Huh
The only thing working is loading the file as scene, but no chance to set material or texture there.
Where is the mistake? Wrong export?

thx for help
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #1 - Posted 2006-11-13 13:47:54 »

I tried to load a simple cube, exported from wings3D or Blender.
The loaded cube from the Blender-file is black or white depending on some settings; the wings3D-file is loadable with texture but (that's my problem) I want to change the texture or material of the cube but i can't reach the cube.

Hmm... Sorry. I can't help you with this. But certainly Amos can. I guess he worked quite a lot with the loaders.

But I think, I can tell you, why the following is not working:
I load it that way: scene = objL.load("Test.obj");
Some posted codes load it like BranchGroup xy = null; -> null = new OBJLOader().load("xy");
I used to test it but if I try to load the object that way, I got a classCastException...  Huh
The only thing working is loading the file as scene, ...

The loader base currently used by ObjLoader returns an instance of "Scene", which is an interface and therefore doesn't extend BranchGroup ao another GroupNode extension. Even the concrete class used internally inside the loaders doesn't extend GroupNode. You'll have to use xy.getSceneGroup() as the Node to add to the scenegraph.
This is different in the new loader base, where any scene or model extends BranchGroup resp. Group. So they can directly be attached to the scenegraph. They're TransformNode as well and can therefore be directly transformed (like scaled), which was also not possible in the old system.

..., but no chance to set material or texture there.
Where is the mistake? Wrong export?

You can always traverse the model ( getSceneGroup() ) and find any Shape3D and apply a Materail to it. But I guess it is better to wait for the failure to be fixed inside the loader. Maybe you could yourself dig into the code and try to find the solution.

Marvin
Offline apohlmann

Senior Newbie





« Reply #2 - Posted 2006-11-13 14:39:24 »



But I think, I can tell you, why the following is not working:
I load it that way: scene = objL.load("Test.obj");
Some posted codes load it like BranchGroup xy = null; -> null = new OBJLOader().load("xy");
I used to test it but if I try to load the object that way, I got a classCastException...  Huh
The only thing working is loading the file as scene, ...

The loader base currently used by ObjLoader returns an instance of "Scene", which is an interface and therefore doesn't extend BranchGroup ao another GroupNode extension. Even the concrete class used internally inside the loaders doesn't extend GroupNode. You'll have to use xy.getSceneGroup() as the Node to add to the scenegraph.
This is different in the new loader base, where any scene or model extends BranchGroup resp. Group. So they can directly be attached to the scenegraph. They're TransformNode as well and can therefore be directly transformed (like scaled), which was also not possible in the old system.

Yes I know!
That's why I dont understand that someone works with loading as BranchGroup...
Was it possible in an older version?


..., but no chance to set material or texture there.
Where is the mistake? Wrong export?

You can always traverse the model ( getSceneGroup() ) and find any Shape3D and apply a Materail to it. But I guess it is better to wait for the failure to be fixed inside the loader. Maybe you could yourself dig into the code and try to find the solution.

Marvin

O.k. I try that...
Where is a documentation for traverse ?  Roll Eyes
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-11-13 14:53:19 »

Was it possible in an older version?

Don't know.

Where is a documentation for traverse ?  Roll Eyes

When I said "traverse" I wasn't talking about myNode.traverse(). I guess, you don't want to apply the same appearance or material to all Shape3Ds in the model. So you'll have to traverse "manually". This means, that you'll have to know the exact "path" in the model's graph and apply the specific materials to the shapes.
If you do want to apply the same material (or something like that) to all the shapes, then you should use model.getSceneGroup().traverse().

There're two overloaded versions of the traverse() method. One taking a TraversalCallback instance and one taking a DetailedTraversalCallback instance. The letter one is just for really complicated traversals, where you whould have to cast again and again.
In your case have a look at org.xith3d.scenegraph.traversal.impl.MaterialTraversal and take it as an example for your traversal implementation or just use one of the implementations from that package.

The only documentation existing for that is the JavaDoc. But I guess it is sufficient. Please tell me if it is not.

Marvin
Offline Amos Wenger

Senior Member




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


« Reply #4 - Posted 2006-11-13 19:31:01 »

Hi,

got another problem...
I tried to load a simple cube, exported from wings3D or Blender.
The loaded cube from the Blender-file is black or white depending on some settings; the wings3D-file is loadable with texture but (that's my problem) I want to change the texture or material of the cube but i can't reach the cube.
I load it that way: scene = objL.load("Test.obj");
Some posted codes load it like BranchGroup xy = null; -> null = new OBJLOader().load("xy");
I used to test it but if I try to load the object that way, I got a classCastException...  Huh
The only thing working is loading the file as scene, but no chance to set material or texture there.
Where is the mistake? Wrong export?

thx for help
I'll implement it soon. (Remind me).

"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 apohlmann

Senior Newbie





« Reply #5 - Posted 2006-11-14 14:01:26 »

I'll implement it soon. (Remind me).
What exactly ?  Wink

<remind> *knock knock* </remind>  Cool

Hmm... I exported a cube with a texture from wings3D:

 # Exported from Wings 3D 0.98.35
mtllib Xith3D-Cube.mtl
o cube1
#8 vertices, 6 faces
v -1.00000000 -1.00000000 1.00000000
v -1.00000000 1.00000000 1.00000000
v 1.00000000 1.00000000 1.00000000
v 1.00000000 -1.00000000 1.00000000
v -1.00000000 -1.00000000 -1.00000000
v -1.00000000 1.00000000 -1.00000000
v 1.00000000 1.00000000 -1.00000000
v 1.00000000 -1.00000000 -1.00000000
vt 0.0000000e+0 0.0000000e+0
vt 0.0000000e+0 1.6653345e-16
vt 0.0000000e+0 2.2204460e-16
vt 0.0000000e+0 1.00000000
vt 1.6653345e-16 1.00000000
vt 1.00000000 0.0000000e+0
vt 1.00000000 1.00000000
vt 1.00000000 0.0000000e+0
vt 1.00000000 2.2204460e-16
vt 1.00000000 0.0000000e+0
vt 1.00000000 1.00000000
vt 1.00000000 1.00000000
g cube1
usemtl default
f 1/1/ 4/10/ 3/12/ 2/4/
f 1/8/ 5/11/ 8/5/ 4/2/
f 2/12/ 6/4/ 5/1/ 1/10/
f 3/6/ 7/7/ 6/4/ 2/1/
f 4/1/ 8/10/ 7/12/ 3/4/
f 6/12/ 7/5/ 8/3/ 5/9/

mtl:

# Exported from Wings 3D 0.98.35
newmtl default
Ns 100.000
d 1.00000
illum 2
Kd 1.00000 1.00000 1.00000
Ka 1.00000 1.00000 1.00000
Ks 1.00000 1.00000 1.00000
Ke 0.00000e+0 0.00000e+0 0.00000e+0
map_Kd Xith3D.png

So there is nothing else but the cube. Scene.getSceneGroup().numChildren() returns a 1. Traversing the scene should be done with getChild(0) ... correct? But I can't cast it as shape3D or something else. And I am not able to set texture, material or something in that state.
What is the alternative? I need a good loader where I can change the appearance from the loaded object. And I need a free programm that allows me to export in this file. (e.g. Blender or wings3D...).

Thx for help ^^
Offline Amos Wenger

Senior Member




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


« Reply #6 - Posted 2006-11-14 19:49:43 »

Hi, very quick convenient method implementation, check the findFirst(String name) and findAll(String name) methods in all groups (all class extending GroupNode).

I haven't tested it so it maybe doesn't work i'll make an example of that.

Hope it's fine for you.

"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-11-14 22:16:14 »

Hi, very quick convenient method implementation, check the findFirst(String name) and findAll(String name) methods in all groups (all class extending GroupNode).

I haven't tested it so it maybe doesn't work i'll make an example of that.

Hope it's fine for you.

Cool idea to add these methods. But isn't the toolkit a better place for them? I think, adding them to the org.xith3d.scenegraph.traversal.impl package in the toolkit and org.xith3d.scenegraph.traversal.impl.SGUtils was a better way, since all other traversal implementations resist there. Do you agree?

Marvin
Offline Amos Wenger

Senior Member




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


« Reply #8 - Posted 2006-11-14 23:31:49 »

Cool idea to add these methods. But isn't the toolkit a better place for them? I think, adding them to the org.xith3d.scenegraph.traversal.impl package in the toolkit and org.xith3d.scenegraph.traversal.impl.SGUtils was a better way, since all other traversal implementations resist there. Do you agree?
I don't know if every cool thing must absolutely be excluded from the core. For me here are the place they're the more convenient.

Just to be able tp do
OBJLoader.load("yourscene.obj").getSceneGroup().get("xy").toShape().getAppearanceLazy().setTexture(TextureLoader.getInstance().getTexture("mytexture.jpg"));
is just cool.. (note : the toShape() and getAppearanceLazy() aren't implemented)

"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 #9 - Posted 2006-11-14 23:34:14 »

I don't know if every cool thing must absolutely be excluded from the core. For me here are the place they're the more convenient.

Fine for me Smiley. Just wanted to mention that.

Just to be able tp do
OBJLoader.load("yourscene.obj").getSceneGroup().get("xy").toShape().getAppearanceLazy().setTexture(TextureLoader.getInstance().getTexture("mytexture.jpg"));
is just cool.. (note : the toShape() and getAppearanceLazy() aren't implemented)

Wow. Long line Smiley. But easy...

Marvin
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-11-15 00:10:40 »

I tend to like long lines, I like block structures with function calls example,

1  
2  
3  
4  
5  
6  
7  
8  
9  
// Load the model in a rotatable group with some adjustments
RotatableGroup rot; (rot = new RotatableGroup(.1f, .5f, .03f)).addChild(
  new Transform(
    OBJLoader.load("yourscene.obj").getSceneGroup()
  ).addTranslationX(-.3f).addRotationZ(45f).add(new Sphere(10f 10, 3f))
);
rot.findFirst("xy").toShape().getAppearanceLazy().setTexture(
  TextureLoader.getInstance().newTexture(512, 512).drawText(10, 10, "Xith3D rocks", Color.RED).drawImg("alpha-layer.png")
)


and htat's even not that hard to do !
It's a lot of fun ^^

"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 #11 - Posted 2006-11-15 00:17:28 »

I've just finished the porting of the OBJLoader to the loader base. So please either use the new one or pick the legacy-loaders.jar from xith.org download section as described in the other thread.

Marvin
Offline Amos Wenger

Senior Member




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


« Reply #12 - Posted 2006-11-15 00:27:27 »

Oh, there isn't OBJLoader.load()-like methods 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 Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #13 - Posted 2006-11-15 00:33:29 »

Oh, there isn't OBJLoader.load()-like methods anymore ?

There are. They're called loadModel() and loadScene(). The only difference is that the returned type is OBJModel resp. OBJScene, which extend org.xith3d.loaders.models.base.Model resp. org.xith3d.loaders.models.base.Scene. org.xith3d.loaders.models.base.Model extends TransformGroup and org.xith3d.loaders.models.base.Scene extends BranchGroup.

But they're not static and have never been for OBJLoader. And I think creating an instance for the loader is no problem, since GC is only created at load time. And it is necessary for inheritance of org.xith3d.loaders.models.base.Loader. Maybe we could add a getInstance() method to all loaders to make them usable as singletons.

Marvin
Offline Amos Wenger

Senior Member




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


« Reply #14 - Posted 2006-11-15 00:45:06 »

I tend to find getInstance() method long but for the sake of design maybe naming them simply "get()" wouldn't be appropriate...

"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 #15 - Posted 2006-11-15 00:55:21 »

I tend to find getInstance() method long but for the sake of design maybe naming them simply "get()" wouldn't be appropriate...

I agree, that it is too long. I just wanted to match the naming, you (or Matthias Mann?) selected for TextureLoader. Quite often I've seen a method called instance() (without the get prefix) for singleton classes. Maybe this would fit better. But then we should change that for TextureLoader, too (and make the old one deprecated).

How do you like that?

Marvin
Offline Amos Wenger

Senior Member




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


« Reply #16 - Posted 2006-11-15 01:04:56 »

I tend to find getInstance() method long but for the sake of design maybe naming them simply "get()" wouldn't be appropriate...

I agree, that it is too long. I just wanted to match the naming, you (or Matthias Mann?) selected for TextureLoader. Quite often I've seen a method called instance() (without the get prefix) for singleton classes. Maybe this would fit better. But then we should change that for TextureLoader, too (and make the old one deprecated).

How do you like that?

Marvin
Well that's no problem for me but regular users may not be happy with such a not-so-important function renaming...

"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 #17 - Posted 2006-11-15 01:15:47 »

I tend to find getInstance() method long but for the sake of design maybe naming them simply "get()" wouldn't be appropriate...

I agree, that it is too long. I just wanted to match the naming, you (or Matthias Mann?) selected for TextureLoader. Quite often I've seen a method called instance() (without the get prefix) for singleton classes. Maybe this would fit better. But then we should change that for TextureLoader, too (and make the old one deprecated).

How do you like that?

Marvin
Well that's no problem for me but regular users may not be happy with such a not-so-important function renaming...

Hmm... They don't need to rename it on user side. It's just deprecated. And I think having a streamlined API at the end is worth a lot, isn't it.
Offline Amos Wenger

Senior Member




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


« Reply #18 - Posted 2006-11-15 01:17:25 »

Well so why not, why not add a developer guideline for that kind of things also ?

"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 #19 - Posted 2006-11-15 01:20:23 »

Well so why not, why not add a developer guideline for that kind of things also ?

Could you maybe stop that? I'm so happy, we finished the lazy discussion about code guidelines and found a quite fair consense. So we don't need to proceed it on other threads and stay friends. OK?

Marvin
Offline Amos Wenger

Senior Member




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


« Reply #20 - Posted 2006-11-15 01:30:05 »

Well so why not, why not add a developer guideline for that kind of things also ?
Could you maybe stop that? I'm so happy, we finished the lazy discussion about code guidelines and found a quite fair consense. So we don't need to proceed it on other threads and stay friends. OK?
Wait that wasn't meant to be sarcastic.

Not everyone knows getter methods for booleans are of isXXX() form. Not everyone is supposed to know we want to use instance() named methods instead of getInstance() for singleton classes.. I meant we could mention that in the "Developers Infos" (and I really think it's a good idea).

Woah calm down guy.  Smiley Wink

EDIT : I think, we're all getting a bit nervous these times.. sorry man if you felt offended

"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 #21 - Posted 2006-11-15 01:37:56 »

Wait that wasn't meant to be sarcastic.

Woah calm down guy.  Smiley Wink

Sorry, when I misunderstood you. Seems like I am a little shirty.

Not everyone knows getter methods for booleans are of isXXX() form.

Well, It is the way the JDK/JRE goes. And it is Bean-compatible.

Not everyone is supposed to know we want to use instance() named methods instead of getInstance() for singleton classes..

This instance() method is for example used in LWJGL. As far as I am concerned, we can stick to getInstace(). But it certainly is a good choice, if you find it too long.

I meant we could mention that in the "Developers Infos" (and I really think it's a good idea).

Yes, we could. And I agree, that it is a good idea to mention some basic things in that aticle like this one.

Marvin
Offline Matthias

Senior Member


Medals: 3
Projects: 1


TWL - Themable Widget Library


« Reply #22 - Posted 2006-11-15 02:21:34 »

I tend to find getInstance() method long but for the sake of design maybe naming them simply "get()" wouldn't be appropriate...

I agree, that it is too long. I just wanted to match the naming, you (or Matthias Mann?) selected for TextureLoader. Quite often I've seen a method called instance() (without the get prefix) for singleton classes. Maybe this would fit better. But then we should change that for TextureLoader, too (and make the old one deprecated).

How do you like that?

Marvin

Hi, I'm finally back at JGO (logon issues) Smiley

I choose the name getInstance() because sometimes I also have createXYZ methods - get signals a invariant behavior between calls. Also this getInstance() method is static and thus does not conflict with a bean property.

Long method names serve also as a documentation - I prefer them over too short and meaningless names.

But I don't want to start/continue any quideline issue - this post is just to explain the code (method names) that I had created.

Ciao Matthias
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #23 - Posted 2006-11-15 02:43:31 »

Hi, I'm finally back at JGO (logon issues) Smiley

Welcome back Smiley.

I choose the name getInstance() because sometimes I also have createXYZ methods - get signals a invariant behavior between calls. Also this getInstance() method is static and thus does not conflict with a bean property.

It wouldn't even break bean compatiblity, if it wasn't static Wink.

Long method names serve also as a documentation - I prefer them over too short and meaningless names.

I agree. So I'll use getInstance() for this method in the loaders.

But I don't want to start/continue any quideline issue - this post is just to explain the code (method names) that I had created.

Thanks Grin.

Marvin
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #24 - Posted 2006-11-15 03:07:50 »

I've now added static getInstance() methods to all Loader implementations to make them usable as singletons.

Marvin
Offline Amos Wenger

Senior Member




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


« Reply #25 - Posted 2006-11-15 18:52:26 »

I've now added static getInstance() methods to all Loader implementations to make them usable as singletons.

OK, cool, thanks.

"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 #26 - Posted 2006-11-15 18:59:36 »

But I think nevertheless that decisions like that should be written somewhere... if I know a bit as programmers work, if there's a doc maybe they'll read it (partly at least) if there's nothing, they'll do their work, no really matter how..

"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 #27 - Posted 2006-11-19 17:49:34 »

Just jumping in on this thread.     I am seeing the following after having upgraded to the SVN base as of today. 

Prior to this SVN pull, I was able to do the following, which worked but is no longer a valid call  SURPRISE!!! Shocked.

1  
2  
                org.xith3d.loaders.scene.Scene sc= new OBJLoader().load(name);
         bg=sc.getSceneGroup();


I am now trying something like the example code

     model = new OBJLoader().loadModel(demoFolder.getResource( myModel ));
     
      
java.io.FileNotFoundException: Untitled.mtl (The system cannot find the file specified)
   at java.io.FileInputStream.open(Native Method)
   at java.io.FileInputStream.<init>(Unknown Source)
   at java.io.FileReader.<init>(Unknown Source)
   at org.xith3d.loaders.models.impl.obj.MaterialLibLoader.<init>(MaterialLibLoader.java:87)
   at org.xith3d.loaders.models.impl.obj.OBJLoader.load(OBJLoader.java:148)
   at org.xith3d.loaders.models.impl.obj.OBJLoader.loadModel(OBJLoader.java:195)
   at org.xith3d.loaders.models.impl.obj.OBJLoader.loadModel(OBJLoader.java:202)
   at org.xith3d.loaders.models.impl.obj.OBJLoader.loadModel(OBJLoader.java:207)

 
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #28 - Posted 2006-11-19 18:25:16 »

Try something like this (please refer to the JavaDoc for more info, or ask):
1  
2  
    URL myModelFolderURL = new URL( folderToModel );
    model = new OBJLoader( myModelFolderURL ).loadModel( new URL( myModelFolderURL, myModel ) );


Where myModel is a resource name relative to myModelFolderURL.

I'm streamlining the model loaders and therefore porting all of them to the new loader base. This is why the previous usage isn't valid anymore. But you can grab the legacy-loaders.jar (mentioned above in this thread) to use the old loaders. But it is advisable to use the new loaders, if your project is work in progress. I guess / hope, it is not too hard to port, is it?

Marvin
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #29 - Posted 2006-11-19 18:33:26 »

I'll check, if the baseURL of the loader can always be safely retrieved from the given URL in loadModel( URL ). If it is, I'll modiy the loaders to do it. Then you won't need to set the baseURL of the loader and the call will work as you expected.

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

theagentd (6 views)
2014-04-24 23:00:44

xsi3rr4x (83 views)
2014-04-15 18:08:23

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

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

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

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

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

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

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

trollwarrior1 (217 views)
2014-04-04 12:06:45
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!