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   
  Show Posts
Pages: [1] 2
1  Java Game APIs & Engines / JOGL Development / Re: glDrawArrays on: 2004-04-24 11:52:33
Quote
           float[] color = new float[]{0,1,0,0,1,0,0,1,0,0,1,0};
           FloatBuffer fbuf = ByteBuffer.allocateDirect(0).asFloatBuffer();

           fbuf.wrap(color);


this is not going to work, first you allocate a direct-buffer with capacity 0, then you change it to a buffer that wraps an array, making it non-direct.

You have to do something like this:
1  
2  
FloatBuffer fBuf = ByteBuffer.allocateDirect(4).asFloatBuffer();
fBuf.put(color);

then render with the buffer.

Jan
2  Java Game APIs & Engines / JOGL Development / Re: Depth Mapped Shadows on ATI on: 2004-04-24 11:47:56
As far as I know, ATI supports ARB_shadow extension from Radeon 9500 on up.
It only supports doing GL_NEAREST filtering though, if you want more, you will have to use a fragment-program.
Another "problem" is, that currently render-to-depth-texture is not supported so you will have to resort to glCopySubTexImage.

Jan
3  Java Game APIs & Engines / JOGL Development / Re: JOGL 1.1 b02 released on: 2004-04-23 17:52:45
Hi,

the windows-natives.jar for the beta 2 seems to be missing fromt the download page. It's there for the beta 1.

Jan Eickmann
4  Java Game APIs & Engines / JOGL Development / Re: Hardware Performace Challenge on: 2004-04-16 12:51:20
Hi,

as always with performance questions, the first answer is: it depends.

Whether you'll be able to get several hundred thousand polys with 60-100 fps, is first off all a question of your graphics card.
when playing around with terrain-rendering, I was able to render a 512x512 heightfield (so about half a million triangles, no strips) using texture-splatting with two passes with about 80 fps on a Radeon 9800.
So basically, yes, it should be possible. Nevertheless, drawing about 100.000 textured fullscreen-quads will probably kill your framerate.

Concerning what technique to use, in my experience displaylists on newer (eg. Radeon 8500 and up) ATI hardware are quite slow. I guess, they are only implemented because the spec requires it, but nothing more.
In general, VBO's are the way to go especially if you have static geometry that can stay on the graphics-card, which appears to be the case with your problem, as you mentioned display lists.
And yes, they are supported by JoGL. It's actually pretty easy to use. There's a VBO whitepaper at developer.nvidia.com, which explains how to use them pretty well (of course, you have to use ByteBuffers instead of arrays, but a look at the jogl-demos with vbo should get you started).


Cheers,

Jan
5  Java Game APIs & Engines / JOGL Development / render to depth-texture on: 2004-04-05 16:20:47
Hello everybody,

is there any support for direct render-to-depth-texture in JoGL? As far as I see, the current pbuffer-stuff only support internal texture formats of RGB.

I also thought about requesting a floating-point pbuffer and then rendering with a fragment-program to alpha or a color channel, but no luck either.

Am I doing something wrong here or do I have to fall back to glCopyPixels and wait for the new generic render-to-texture extension?

Any help is most welcome.

Jan
6  Java Game APIs & Engines / JOGL Development / Re: Another pbuffer thread on: 2004-04-05 13:15:06
Hi,

thanks for all the replies so far. The code is quite deeply inside a much bigger chunk, so it's hard to get it out.
But somehow, after I put my Radeon 9800 back in (I was using the Geforce 3 for compatibility tests) it now runs like a charm.
Maybe the drivers where not installed properly, etc.
So for now, I'll just play around and hopefully new new render_target-extension gets out soon, that should make render-to-texture that much easier.

Jan
7  Java Game APIs & Engines / JOGL Development / Re: Another pbuffer thread on: 2004-03-30 12:13:08
Still stuck with this problem Huh

Nobody out there who could give me a hint?

Jan
8  Java Game APIs & Engines / JOGL Development / Re: Another pbuffer thread on: 2004-03-28 11:27:28
Hi,

Thanks for the help so far.
Calling the pbuffers display-method from the "creator's" display-method resulted in the pbuffer's init-method being called.

But on the second frame, I get the following exception:
1  
2  
3  
4  
5  
6  
7  
net.java.games.jogl.GLException: Surface already unlocked
      at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.unlockSurface(WindowsOnscreenGLContext.java:192)
      at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.free(WindowsOnscreenGLContext.java:134)
      at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:265)
      at om.uiServices.OmCanvas.display(OmCanvas.java:302)
      at om.sceneToolkit.MultiDrawableAnimator$1.run(MultiDrawableAnimator.java:96)
      at java.lang.Thread.run(Thread.java:534)


After playing around a bit, I noticed that when I start calling the pbuffer's display()-method, after a couple hundred frames have already been displayed for the main-drawable, I get the error immediatly, even before it gets to the pbuffer's init().

Any further ideas?

Jan
9  Java Game APIs & Engines / JOGL Development / Re: Per pixel lighting on: 2004-03-27 12:52:41
Vertex programs alone won't help you much. If you don't want to use fragment-shaders (which is advisable given the current hardware support is limited to GeforceFX/Radeon 9500+, etc), you can calculate the light-dir in a vertex shader as primary-color and then use tex_env_dot3-extension to calculate a dot3 against a bump-map.

This is only the basic idea but it should get you started. You might want to renormalize the light-dir in a normal-map since the linear interpolation between vertices will otherwise dim your light a little bit, etc.

Of course, this only gives you diffuse color (no speculars) but you should get the idea.
When I did something similar for a terrain-rendering-engine, what helped me a lot was to write down the lighting-math first and then try to figure out how you can map that to whatever hardware you have (register-combiners, ATI_fragment_shader, texEnv-dot3, etc).

Feel free to mail me if you have questions (jeNO@SPAMframesys.de)

Jan
10  Java Game APIs & Engines / JOGL Development / Another pbuffer thread on: 2004-03-27 09:42:56
Hi,

I just tried to create a simple pbuffer (for later use in shadow-mapping) and I just can't get it to work, this is how I set it up:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
supported = drawable.canCreateOffscreenDrawable();
            if(!supported) {
                  System.err.println("PBuffers not supported, shadow mapping not available");
                  return;
            }
           
            GLCapabilities caps = new GLCapabilities();
            caps.setDoubleBuffered(false);
            //caps.setDepthBits(24);
           //caps.setOffscreenRenderToTexture(true);
           
            GLPbuffer pbuffer = drawable.createOffscreenDrawable(caps, 512, 512);
            pbuffer.addGLEventListener(this);
            System.err.println("Pbuffer created");

that code runs perfectly and everything, except that the EventListener's init() method never gets called.

Did I miss something?
My current setup is a Geforce 3 with the most current drivers, so pbuffers should be supported.

Thanks for any help.

Jan
11  Java Game APIs & Engines / JOGL Development / Re: building with 1.5 support on: 2004-03-26 12:49:44
When I tried to get sgi's glext.h to run, I noticed that the Gluegen (or antlr?), just ignores some #defines in the header (as mentioned in the other thread for example APIENTRYP).
Take a look at the gluegen-output and look whether it tells you something about ignored stuff.

Jan
12  Java Game APIs & Engines / JOGL Development / Re: Per pixel lighting on: 2004-03-26 12:42:54
Try to specify what you want to accomplish. Tell people what you already figured out, whether you want some pointers to general tutorials (nehe.gamedev.com, developer.nvidia.com are usually good places to start) or have a specific problem.

What features of the GPU do you want to use: fixed-function texEnv extensions, register-combiners, ARB_fragment_program/shader, etc.

Unless you get more specific, you will probably not get that many useful answers.

Regards,

Jan
13  Java Game APIs & Engines / JOGL Development / Re: glDrawElements() unexplained ERROR! on: 2004-03-26 12:37:07
You can try to use the IntBuffer based version of glDrawElements. Create a direct int-buffer with jogl's BufferUtils-class and use that one instead of the int-array.
Direct Buffers are on the native side of JNI, maybe the gc shuffles your int-array around and the pointer is no longer valid, when the GL accesses it after your DrawElements-call has returned.
Maybe your curved-surfaces are bigger than the others and this results in the gc kicking in or something...

Jan
14  Java Game APIs & Engines / JOGL Development / Re: glDrawElements() unexplained ERROR! on: 2004-03-25 06:20:22
Can you post your vertex-arrays setup code?
Maybe the error is there.
15  Java Game APIs & Engines / JOGL Development / Re: glDrawElements() unexplained ERROR! on: 2004-03-24 16:27:21
1  
2  
3  
4  
int line = meshArray[0].length;
 
   for (int i = 0; i < total;  i++)
   gl.glDrawElements(gl.GL_TRIANGLE_STRIP, line, gl.GL_UNSIGNED_INT, meshArray[i]);


are you really sure, you want to say meshArray[0].length? Effectively using the same length for all your arrays?
I think you need to get the length for each array-entry in the for-loop.
Or do all of them have exactly the same length?
16  Java Game APIs & Engines / JOGL Development / Re: color on: 2004-03-13 15:24:28
duplicate the top-vertex. There's no other way except maybe using texture-mapping, but doesn't sound better.

Jan
17  Java Game APIs & Engines / JOGL Development / Re: Very low FPS on Linux on: 2004-03-13 15:21:41
I would guess that it still does vsync and somehow doesn't honor your export.
Try to reduce the vertical refresh rate and see if this also reduces the frame-rate.
I don't know any solution, but at least you can get your problem localized and maybe someone else can offer some insight.

Jan
18  Java Game APIs & Engines / JOGL Development / Re: From Jogl to OpenGL on: 2004-03-12 08:01:26
Hi,

OpenGL is just a graphics API that helps you draw triangles, etc to the screen. It doesn't do any input processing like mouse handling.
The funciton you are referring to belongs probably to some kind of additional library that you used under C++ (or whatever you used as programming language before Java/JoGL).
If you want some form of mouse handling you have to either do it yourself (maybe using opengl picking-mode) or look at one of the higher-level APIs layerd on top of JoGL like OpenMind (has picking suport) or Xith3d (haven't worked with it yet, but probably has something similar).

Maybe you can also specify what exactly you want to accomplish (rotate camera/select object/...), then maybe someone can give you additional pointers.

Regards,

Jan
19  Java Game APIs & Engines / JOGL Development / Re: jogl and  opengl 1.5  -  shader on: 2004-03-03 20:20:22
Hi,

I managed to get it to run (the interface is a little nasty, I just need it for testing purposes and the gluegen is not very well documented, but it works).
There's a thread called Jogl with OpenGL 1.5 capabilities a couple of weeks old where I explained how I got it to work.
If you just want the jar/dll for win32 write me a short mail to je@framesys.de and I'll send it to you.

Jan
20  Java Game APIs & Engines / JOGL Development / Re: Checking what functions are supported by jogl on: 2004-03-02 15:36:32
Quote
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
    String extensions = gl.glGetString(gl.GL_EXTENSIONS);  // Fetch Extension String

    if(extensions.indexOf("GL_EXT_stencil_wrap") !=-1)
      EXT_stencil_wrap_supported = true;

    if(extensions.indexOf("GL_ARB_vertex_program") !=-1)
      ARB_vertex_program_supported = true;

    if(extensions.indexOf("GL_EXT_stencil_two_side") !=-1)
      EXT_stencil_two_side_supported = true;

    if(EXT_stencil_two_side_supported && EXT_stencil_wrap_supported)
      twoSidedStencilSupported = true;

    if(ARB_vertex_program_supported)
      VPVolumesSupported = true;


this just checks the extension string, which doesn't help if my driver supports for example ARB_fragment_shader, but the jogl doesn't provide a wrapper for it because it has been compiled with the OpenGL 1.4 glext.h

I guess, it's either reflection or bundling the jogl like Markus_Persson suggested.

Thanks you anyway,

Jan
21  Java Game APIs & Engines / JOGL Development / Checking what functions are supported by jogl on: 2004-03-02 08:03:24
Hello,

I was wondering how to get information whether a certain function is supported in a particular jogl-implementation.
For example, I want to check, whether people have a jogl that also supports the OpenGL 1.5 functions or shader extension.
Just checking the version/extension string doesn't help as this reports the extension as being available, but jogl doesn't provide entrypoints to them.
Now I could use reflection but maybe there's a cleaner way?

Thanks for your answers,

Jan
22  Java Game APIs & Engines / JOGL Development / Re: JOGL and enum. on: 2004-02-24 12:36:32
In general, yes, that's how enums work. But there are two problems with using them with jogl:

1.) in order to use them you would call
gl.glBegin(BeginMode.GL_TRIANGLES);
while the C equivalent is
glBegin(GL_TRIANGLES);
so while this might be nice if you have an IDE that gives you a list of possible values, so you can just choose among the different BeginModes, the resulting code looks much different from the c code which makes JoGL code harder to read/write if you are used to using "normal" C-based OpenGL.

While this might sound purely cosmetic, it makes it for example harder to post snippets to C-centric GL-Forums, etc.

2.) Jogl creates the GL-class programmatically from the gl.h and glext.h header files. Since in these header files, there's no info about which values are being accepted by the different functions, you would have to somehow parse the extension and GL-spec in order to get this info. Since they are not easily parsed, this is a rather hard task and even then you might miss some values if a certain spec is formatted a little bit differently.
You could manually define these values, but this would kill the advantage of the automatic class-generation. That is that with a new exception coming out, you just have to recompile jogl in order to get access to the new functions and constant.
If you now define the enums manually, a new spec that introduces for example a new texture-format requires you to add that format by hand to the TextureMode-enum.

just my 2 cents

Jan
23  Java Game APIs & Engines / JOGL Development / Re: Problems building using Ant 1.60/Antlr 2.7.2 on: 2004-02-17 11:39:57
Quote
Great! Thanks. 1.53 compiles it mostly. Fails now after building the JAR, so I suspect that may have something to do with my MinGW setup.  Back to being productive again  Shocked

Hi,
I had the same problem. It's an issue with the new glext.h.
check the thread titled "Jogl with OpenGL 1.5 Capabilities". Pretty much at the end, I describe how you have to change it for it to work (at least it did for me under mingw)

Jan
24  Java Game APIs & Engines / JOGL Development / Re: Newbie problem with lighting on: 2004-02-14 12:43:32
Hi,

I think, the OpenGL Lighting uses material-colors instead of vertex-colors. So you might want to take a look at glMaterial(...) or, if you want to keep using glColor to specify vertex-colors, try glColorMaterial that sets the material to track the vertex-color for diffuse(probably what you want) or specular or ambient.

Jan

25  Java Game APIs & Engines / JOGL Development / Re: JOGL with OpenGL 1.5 capabilities? on: 2004-02-13 12:07:47
Alright, finally got it to work:

My solution is a little bit awkward to use (a lot of unecessary arrays, but I'm not that good at JNI and so, I'm happy that it works)

Of course, the stuff about changing from GLcharARB ** to GLcharARB * couldn't work.
So leave that out.

what you got to to is:
- add a line
ManuallyImplement glShaderSourceARB
to gl-common.cfg in make
this tells the gluegen, that we are going to do our own handling of that function.
next, add the following code to gl-impl-CustomCCode.c

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  
/*   Java->C glue code:
 *   Java package: net.java.games.jogl.impl.windows.WindowsGLImpl
 *    Java method: void dispatch_glShaderSourceARB(int shaderObj, int count, java.lang.String string, int[] length)
 *     C function: void glShaderSourceARB(GLhandleARB shaderObj, GLsizei count, const GLcharARB *  string, const

GLint *  length);
 */

JNIEXPORT void JNICALL
Java_net_java_games_jogl_impl_windows_WindowsGLImpl_dispatch_1glShaderSourceARB(JNIEnv *env, jobject _unused, jint

shaderObj, jint count, jstring string, jintArray length, jlong glProcAddress) {
  PFNGLSHADERSOURCEARBPROC ptr_glShaderSourceARB;
  const char* _UTF8string = NULL;
  GLint * _ptr3 = NULL;
  if (string != NULL) {
    _UTF8string = (*env)->GetStringUTFChars(env, string, (jboolean*)NULL);
    if (_UTF8string == NULL) {
      (*env)->ThrowNew(env, (*env)->FindClass(env, "java/lang/OutOfMemoryException"),
                       "Failed to get UTF-8 chars for argument \"string\" in native dispatcher for

\"
dispatch_glShaderSourceARB\"");
      return;
    }
  }
  if (length != NULL) {
    _ptr3 = (GLint *) (*env)->GetPrimitiveArrayCritical(env, length, NULL);
  }

char ** _strptr = &_UTF8string;

  ptr_glShaderSourceARB = (PFNGLSHADERSOURCEARBPROC) (intptr_t) glProcAddress;
  assert(ptr_glShaderSourceARB != NULL);
  (* ptr_glShaderSourceARB) ((GLhandleARB) shaderObj, (GLsizei) count, (GLcharARB **) _strptr, (GLint *) _ptr3);
  if (string != NULL) {
    (*env)->ReleaseStringUTFChars(env, string, _UTF8string);
  }
  if (length != NULL) {
    (*env)->ReleasePrimitiveArrayCritical(env, length, _ptr3, JNI_ABORT);
  }
}

this is mostly just copied from the generated gluegen-code generated with the GLcharARB * variant, but it adds another pointer level (_strport), so you get the **

now add the following to gl-impl-CustomJavaCode.java:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
  /** Entry point to C language function: <br> <code> void glShaderSourceARB(GLhandleARB shaderObj, GLsizei count, 

const GLcharARB *  string, const GLint *  length); </code>    */

  public void glShaderSourceARB(int shaderObj, int count, java.lang.String string[], int[] length)
  {
    final long __addr_ = _context.getGLProcAddressTable()._addressof_glShaderSourceARB;
    if (__addr_ == 0) {
      throw new GLException("Method \"glShaderSourceARB\" not available");
    }
    dispatch_glShaderSourceARB(shaderObj, count, string[0], length, __addr_);
  }

  /** Encapsulates function pointer for OpenGL function <br>: <code> void glShaderSourceARB(GLhandleARB shaderObj,

GLsizei count, const GLcharARB *  string, const GLint *  length); </code>    */

  private native void dispatch_glShaderSourceARB(int shaderObj, int count, java.lang.String string, int[] length,

long glProcAddress);


this is just plain passing to the JNI function except that we only pass the first entry of the string array.

Well, this should be it. As said, this is just a quick hack, so there are some limitations:
1.) You can only use the first entry of the string-array.
2.) resulting from this, you always have to pass in 1 as the number of array entries
3.) you have to supply the length of the string as the first element of the int array.

I know, this is not very clean, but at least, it works for me now and I didn't have too much time available. If anybody want to clean the code up and create a proper patch, I would love that.
If there's someone out there, that want to get the complete jar without going through the compile/change-hassle, just drop me short mail at jeDROP@MEframesys.de and I'll send it to you.

just remove the drop me from the mail adress (spam-trap)

Regards,

Jan
26  Java Game APIs & Engines / JOGL Development / Re: JOGL with OpenGL 1.5 capabilities? on: 2004-02-13 09:51:20
Another update:

Here's what I did to get the current glext.h to work with the jogl-compile:

- changed all accurences of
APIENTRYP
to
APIENTRY *
this just does what the typedef APIENTRYP APIENTRY * does anyway. But the gluegen doesn't like it, so you have to do it manually.

- remove the
#include <stddef.h>
its only needed for the immediatly following typedefs for GLintptr/GLintptrsize
just do them manually:
define int GLintptr
define int GLintptrsize
(I guess this only works on ia32, if you are on a 64-bit platform, you  will probably have to find another type)

- remove glGetBufferPointerv function
somehow, the extension version (with ARB in the end) does work. So I guess, there's a workaround for it somewhere in the code, but I couldn't find it. Anybody?

so far so good, but now the nasty surprise:
glShaderSourceARB
trips another bug, the gluegen doesn't like the GLcharARB ** parameter.
I changed them to be GLcharARB *, an it compiles, but I don't know if this works (e.g. if it takes it as an array of strings with just the first entry). I haven't yet tested it, but I'll keep you up to date.
What's weird: the jogl-todo says, that the ** should work for const char (which the const GLcharARB is, I also tried by putting it in directly) and only other types should produce errors, but this seems not the case. Any ideas?

Well, thats it so far,

Jan
27  Java Game APIs & Engines / JOGL Development / Re: JOGL with OpenGL 1.5 capabilities? on: 2004-02-12 21:21:59
Hi,

Ok, here's my current progress:

I got the current jogl CVS-checkout to compile using vc7. In order to get the shader extensions, etc. I downloaded the most current glext.h/wglext.h and places them in make\stub_includes\opengl\GL.
Now, when I do an ant win32.vc7, I just get a whole bunch (and I mean a whole bunch, the screen just keeps on scrolling forever) gluegen errors.

Do I have to make any adjustments in order for a vanilla glext.h to work?

Regards,

Jan
28  Java Game APIs & Engines / JOGL Development / Re: JOGL with OpenGL 1.5 capabilities? on: 2004-02-05 13:45:19
Hi,

just wanted to know if you got it to work with the GLSL extensions as I'm now trying to look into GLSL, but I don't really want to go into setting up a mingw-environment with a current glext.h, etc. if I don't even know if it works at all.
I hope, I don't sound too lazy :-)

Regards,

Jan
29  Java Game APIs & Engines / JOGL Development / Re: transforming quads without drawing them on: 2004-02-04 07:07:25
Cool, I didn't know this existed. I definitly have to keep that in mind.

Jan
30  Java Game APIs & Engines / JOGL Development / Re: transforming quads without drawing them on: 2004-02-03 21:28:16
Quote
i have a bunch of quads i need to fully transform and then sort them manually.
so, i would like to use the normal opengl matix stack pushes, glbegin(GL.GL_QUADS), etc. and then once i call glEnd(), read the transformed quad information (1 vertex at a time if i have to).
any idea how to do this?



I would say, it's impossible the way you are trying to do it.
A different solution might be to grab the OpenGL modelview matrix right where you would put the glBegin and do the matrix multiplication yourself (if you are using javax.vecmath, you have to change the row/column order in the array, I think).

Btw: what do you want with the homogenous vertex-coordinates (all scaled to be in [0,1], etc).
If you just want the world-coordinates, you somehow have to only get the world-matrix without the view-projection.
Which probably means, you have to track your transforms on the matrix stack for yourself.

Jan
Pages: [1] 2
 

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 (25 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 (33 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!