Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (499)
Games in Android Showcase (118)
games submitted by our members
Games in WIP (567)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  No vertex buffers, glBindBufferARB wants int?  (Read 5949 times)
0 Members and 1 Guest are viewing this topic.
Offline shawnkendall

Senior Member





« Posted 2003-07-26 01:10:08 »

Hi guys,

I was attempting to set up vertex buffers a la C

GLuint buffer = 0;
glGenBuffersARB(1, &buffer);
glBindBufferARB(GL_ARRAY_BUFFER_ARB, buffer);
glBufferDataARB(GL_ARRAY_BUFFER_ARB, sizeof(data), data, GL_STATIC_DRAW_ARB);

and it appears the JOGL version is a bit off?  The JOGL version takes an int, instead of say a ByteBuffer or the int[] you CAN pass into GenBuffers.

It seems the "Display list vs. vertex buffer" thread post indicates this is known problem but not directly, only that vertex buffers don't work which is one thing it's needed for OR perhaps I am missing it?

Thanks!

Shawn Kendall
Cosmic Interactive, LLC
http://www.facebook.com/BermudaDash
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #1 - Posted 2003-07-26 02:54:45 »

ARB_vertex_buffer hasn't been exposed yet in JOGL. As you can see there are some bugs in the glue code that is generated for any routines that are present and some are just absent. Nobody's working on this yet though I'll try to bump it up on my to-do list. If you or anyone else has some time to devote to it please let me know.
Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #2 - Posted 2003-07-26 14:06:21 »

There are quite a few functions that fall into this category - pretty much anything that didn't take void * doesn't have the right binding emitted. My plate is full at the moment so I can't take a look at it and I'm hoping someone else could hope into the GlueGen code and fix it.

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline shawnkendall

Senior Member





« Reply #3 - Posted 2003-07-26 19:59:58 »

Thanks for the quick response!

In terms of JOGL usage there is only one type of geometry we are working with, vertex buffers.  So right now the dynamic stuff is fine since DrawElements works, but the buffers are what we would use for static geometry, which I would say is fairly typically usage since their addition to OpenGL.  
I can understand why GlueGen won't generate the "correct" bindings since in the C functions expect dereferenced int in one call (for writing to) and the int in the other!

In any case, this is half of the use we will get out of JOGL until we move on to vertex and fragment programs.
Unfortunately, I doubt I will get to look at the GlueGen code, so where can I send donations to to bump the priority! ;-)

Shawn Kendall
Cosmic Interactive, LLC
http://www.facebook.com/BermudaDash
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #4 - Posted 2003-07-27 06:06:22 »

Actually I checked and the glue code for glGenBuffersARB is correct. The usage is similar to glGenTextures. See some of the jogl-demos source code for examples of glGenTextures.

However a couple of key routines like glMapBufferARB aren't exposed, and glBufferDataARB and glBufferSubDataARB are unnecessarily restricted to using NIO-only variants.

I'll try to fix this soon.
Offline abies

Senior Member





« Reply #5 - Posted 2003-07-27 11:05:40 »

For temporary glMapBuffer workaround (win32 only unfortunately), please edit gl-common.cfg and replace
1  
Ignore glMapBufferARB

with

1  
2  
3  
4  
5  
TemporaryCVariableDeclaration glMapBufferARB    int size[1];
TemporaryCVariableDeclaration glMapBufferARB    static PFNGLGETBUFFERPARAMETERIVARBPROC __getParam = 0;
TemporaryCVariableAssignment  glMapBufferARB  if ( !__getParam) __getParam =  (PFNGLGETBUFFERPARAMETERIVARBPROC) wglGetProcAddress("glGetBufferParameterivARB");
TemporaryCVariableAssignment  glMapBufferARB  __getParam(target,GL_BUFFER_SIZE_ARB,size);
ReturnValueCapacity glMapBufferARB size[0]


It is a long time since I have played a lot with C, so I'm not sure if __getParam will be reinitialized every time - if yes, then this field will have to be moved outside function body (but I'm afraid it is not possible with current emitter). This trick also depends on first parameter name (target in this case) - it would be more elegant to do it in way similar to ReturnValueCapacity, with MessageFormat being fed parameter names.

Anyway, it is enough to play with MapBuffer under windows - doing the same for linux should be trivial. IMHO it is an acceptable solution until the 'official' fix will appear.


Artur Biesiadowski
Offline abies

Senior Member





« Reply #6 - Posted 2003-07-27 13:07:57 »

To make it useful, we also need gl*Pointer taking offsets instead of Buffer references. Here is a patch

http://nwn-j3d.sourceforge.net/jogl/vertexbuffer.diff

It outputs raw int versions of glColorPointer, glEdgeFlagPointer, glIndexPointer, glNormalPointer, glTexCoordPointer, glVertexPointer. I hope that all casts inside code are valid and offset will not get multiplied by 4 anywhere.

I must say that adding this was painless - congrats to gluegen author, it is really powerful tool.

Artur Biesiadowski
Offline shawnkendall

Senior Member





« Reply #7 - Posted 2003-07-27 21:15:13 »

Ok new fun...
I made all of abies suggested changes and sure enough, I got vertex buffers to work!

My sample looks like this. Thing is a FloatBuffer and Faces is a ByteBuffer that worked with straight vetex arrays.

Init section:
1  
2  
3  
4  
5  
6  
7  
gl.glGenBuffersARB(1, buffer);
gl.glBindBufferARB(GL.GL_ARRAY_BUFFER_ARB, buffer[0]);
gl.glBufferDataARB(GL.GL_ARRAY_BUFFER_ARB, 15*4*4, thing, GL.GL_STATIC_DRAW_ARB);

gl.glGenBuffersARB(1, buffer2);
gl.glBindBufferARB(GL.GL_ELEMENT_ARRAY_BUFFER_ARB, buffer2[0]);
gl.glBufferDataARB(GL.GL_ELEMENT_ARRAY_BUFFER_ARB, 9*4, faces, GL.GL_STATIC_DRAW_ARB);


Draw section
1  
2  
3  
4  
gl.glBindBufferARB(GL.GL_ARRAY_BUFFER_ARB, buffer[0]);
gl.glVertexPointer(3, GL.GL_FLOAT, 0, 0);
gl.glEnableClientState(GL.GL_VERTEX_ARRAY);
gl.glDrawArrays(GL.GL_TRIANGLES, 0, 3);


However, my goal is INDEXED geometry...
Unfortuately, the normal way would be something like this:
Draw section
1  
2  
3  
4  
5  
6  
7  
8  
9  
gl.glBindBufferARB(GL.GL_ARRAY_BUFFER_ARB, buffer[0]);
gl.glVertexPointer(3, GL.GL_FLOAT, 0, 0);

gl.glBindBufferARB(GL.GL_ELEMENT_ARRAY_BUFFER_ARB, buffer2[0]);

gl.glEnableClientState(GL.GL_VERTEX_ARRAY);

//use indexing
gl.glDrawElements(GL.GL_TRIANGLES, 9, GL.GL_UNSIGNED_BYTE, 0); //last 0 is offset in element-array


Except that glDrawElements wants a buffer as the last arg.  As I understand it there is only one glDrawElements in C, it's just the meaning changes on the render context (it treats the arg as a pointer or an offset depending on the earlier binding...)

I did try null and an empty int[1] array, first no compile, second vm crash, as expected.

Making two methods in JOGL, one taking the buffer and the other accepting an int offset, map back to the one GL function I think is outside my current GlueGen hack ability, I looked around but thought I might post in the meantime. Any ideas?;-)

Shawn Kendall
Cosmic Interactive, LLC
http://www.facebook.com/BermudaDash
Offline shawnkendall

Senior Member





« Reply #8 - Posted 2003-07-27 22:29:07 »

Ok, I hacked in the method:
public void glDrawElements(int mode, int count, int type, int offset);
into GL.java and WindowsGLImpl.java

as well as the C function in WindowsGLImpl_JNI.c

1  
2  
3  
4  
5  
JNIEXPORT void JNICALL 
Java_net_java_games_jogl_impl_windows_WindowsGLImpl_glDrawElements__IIII(JNIEnv *env, jobject _unused, jint mode, jint count, jint type, jint offset) {

  glDrawElements((GLenum) mode, (GLsizei) count, (GLenum) type, (GLvoid *) offset);
}


Set to frappe, and bingo!
Indexed vertex buffers in JOGL.
Whew... Nothing quite like hacking an autogenerated JNI file...
I know WAY more about JOGL guts than I ever wished to.
;-)
"I seen enough to know I've seen too much..."

Shawn Kendall
Cosmic Interactive, LLC
http://www.facebook.com/BermudaDash
Offline kaffiene
« Reply #9 - Posted 2003-07-28 00:58:29 »

Is this fix going to be applied to the CVS version of the code at any point?
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #10 - Posted 2003-07-28 02:11:47 »

(First: thanks to abies and shawnkendall for the patches.)

I don't think all of these patches in their current form will be applied to the main source base. I plan to add a ByteBuffer BufferUtilities.bufferOffset(int offset) routine for fabricating the "offset" buffers that glVertexPointer, etc. need. The reason for this is the same as described in the ARB_vertex_buffer_object spec, which is that adding overloaded variants of the base OpenGL routines will cause a geometric increase in the number of methods.

Aside from that abies's patch to get the return value size inside of getMapBuffer looks great; thanks for thinking it through and contributing it. I think it would be better to do this in Java instead of C, though GlueGen might need to be extended in order to do this.
Offline abies

Senior Member





« Reply #11 - Posted 2003-07-28 05:28:44 »

Quote

I plan to add a ByteBuffer BufferUtilities.bufferOffset(int offset) routine for fabricating the "offset" buffers that glVertexPointer, etc. need. The reason for this is the same as described in the ARB_vertex_buffer_object spec, which is that adding overloaded variants of the base OpenGL routines will cause a geometric increase in the number of methods.


We already have some extremly overloaded methods (ones that accept void * in C and are converted to 8-9 versions in java). I think that having few extra methods for buffer objects are acceptable - especially given the fact, that they ARE overloaded as far as idea is concerned, with BUFFER_OFFSET being an ugly hack to reduce number of functions in .h file.

As far as I understand, for spec, reason to stay with existing functions was not only to reduce entry points, but also to reduce state variables, by reusing existing array states (which are exclusive with buffer usage). Unless there is some kind of problem here I do not see, we are talking only about adding second version of vertex arrat void* routines - maybe 10 in total, including vertex parameters for shaders.

Quote

Aside from that abies's patch to get the return value size inside of getMapBuffer looks great; thanks for thinking it through and contributing it. I think it would be better to do this in Java instead of C, though GlueGen might need to be extended in order to do this.


It might be quite hard to do it in java. You need to return something from C. I think that a bit of hackery in C is better than returning raw pointer from it and they wrapping it in buffer at java side - it will start to look a bit like lwjgl in previous incarnation. Of course, this C code needs to be portable - probably some kind of C-level system independent function query could be useful.

Artur Biesiadowski
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #12 - Posted 2003-07-29 03:12:46 »

Quote


We already have some extremly overloaded methods (ones that accept void * in C and are converted to 8-9 versions in java). I think that having few extra methods for buffer objects are acceptable - especially given the fact, that they ARE overloaded as far as idea is concerned, with BUFFER_OFFSET being an ugly hack to reduce number of functions in .h file.

As far as I understand, for spec, reason to stay with existing functions was not only to reduce entry points, but also to reduce state variables, by reusing existing array states (which are exclusive with buffer usage). Unless there is some kind of problem here I do not see, we are talking only about adding second version of vertex arrat void* routines - maybe 10 in total, including vertex parameters for shaders.


It's my understanding that the vertex buffer objects are intended to be applied to many states in the pipeline so that perhaps in the future it will be more than just glVertexPointer, glNormalPointer, etc. that need to be cloned. For this reason I think we should match the C APIs by providing a bufferOffset routine which returns a zero-capacity ByteBuffer which has as its pointer value the desired offset.

Quote

It might be quite hard to do it in java. You need to return something from C. I think that a bit of hackery in C is better than returning raw pointer from it and they wrapping it in buffer at java side - it will start to look a bit like lwjgl in previous incarnation. Of course, this C code needs to be portable - probably some kind of C-level system independent function query could be useful.


What I meant was to do the call to glGetBufferParameterivARB from Java and pass down the size as another parameter to the (hand-coded in this case) dispatch_glMapBufferARB.
Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #13 - Posted 2003-07-29 14:24:24 »

Too much verbage - can someone post a code sample on how its intended to be used? Smiley

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline abies

Senior Member





« Reply #14 - Posted 2003-07-29 17:12:05 »

I have just noticed the obvious - map routine allocated new Buffer each time. This means that for every data update we will create few objects of garbage (probably one buffer for coordinates, another for normals or colors). Two garbage objects may not seem a lot, but it can quickly add up to hundred or more objects per frame. I don't know how others have worked, but for my java3d applications, I had kept garbage creation down to 2-3 objects per frame max (mouse/key events and some java3d internal thing).

Probably the cost of mapping/unmapping the buffer is many times greater than cost of collecting stale java wrapper, but I'm always afraid it can add up to noticeable pause once per few hundred frames... After all, these buffers are in addition to what application allocated by itself.

I do not really see a solution here - I doubt we can pass Buffer to fill address field. We can do it by reflection, but is it acceptable for 'official' binding ?

Artur Biesiadowski
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #15 - Posted 2003-08-01 02:38:58 »

No, I think we'll have to allocate a new Buffer each frame. Note however that these are extremely short-lived objects and will be scavenged by a generational collector like HotSpot's. Scavenges are very fast and can't be perceived as pauses.
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #16 - Posted 2003-08-01 07:13:24 »

Quote
No, I think we'll have to allocate a new Buffer each frame. Note however that these are extremely short-lived objects and will be scavenged by a generational collector like HotSpot's. Scavenges are very fast and can't be perceived as pauses.


Er, say again? I've heard mention of small, short lived objects being light on the GC, but i never seemed to find any concrete information on it. Is there any ways to ensure that objects like this can be quickly picked up by the GC?

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

Junior Member





« Reply #17 - Posted 2003-08-01 10:12:29 »

Quote
Er, say again? I've heard mention of small, short lived objects being light on the GC, but i never seemed to find any concrete information on it.


Try to search for "eden space" and/or new/young generation and you'll probably get some interesting documents.

Basically (IIANM), it boils down to that the small objects in the eden space are not actually collected. Think of the eden space as a big irregular spaced array where each object occupies one "slot", when the runtime decides to gc - instead of actually doing the usual collection algorithms on the eden space it does nothing. Allocation of small objects placed in the eden space is done by just incrementing a pointer (i.e. eventually wrapping around and writing over old objects). The runtime is rumoured Wink to become quite good at deciding which objects should be placed in the eden space (short lived rectangle objects used for painting is probably a good example).

Quote
Is there any ways to ensure that objects like this can be quickly picked up by the GC?


Ensure that your eden space is spaced correctly:
-XX:NewSize=Xm and -XX:MaxNewSize=Ym should do the trick (this should of course only be done after investigating profiling information on a final product to get that little extra performance - "premature optimization is ...")  
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #18 - Posted 2003-08-02 09:22:41 »

Ah, thanks. A few minutes searching and i found this ( http://java.sun.com/docs/hotspot/gc1.4.2/#3.2.%20The%20Young%20Generation|outline ) which seems to cover the whole thing in plenty of detail. Not exactly light reading but interesting none the less. I still don't see how the VM decides what is likely to be short lived or not though (perhaps i can be finally cured of my phobia for iterators.)

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

Senior Member





« Reply #19 - Posted 2003-08-03 15:59:50 »

Is the object still placed in eden space when it has a finalizer? IIRC, all *Buffer objects have a finializer to take care of the native memory destruction. In the current lwjgl version (CVS), we give the previous mapped buffer (or null) as argument to MapBuffer. That way, MapBuffer can decide to either return the same buffer if the map address is constant.

Of course, this only works if the underlying driver doesn't move the buffer around much. I think that's a safe assumption.

- elias

Offline abies

Senior Member





« Reply #20 - Posted 2003-08-03 21:16:52 »

As far as I understand, you need to add finalizer to buffer object explicitly if you want to get native memory cleared (through PhantomRef probably). I have not found finalize method anywhere in Buffer source and I hope it is not there - finalization would KILL any hopes for performance. While normal garbage is only bad, objects with finalizers are major offense - for me, acceptable only for critical, long-lived resources (like open files, graphic context etc).

Artur Biesiadowski
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #21 - Posted 2003-08-04 00:57:25 »

Quote
I have not found finalize method anywhere in Buffer source and I hope it is not there - finalization would KILL any hopes for performance.


Unfortunately the hidden class DirectByteBuffer (which is what is created from the JNI call NewDirectByteBuffer) does in fact have a finalizer.

We'll have to fully implement the new map primitives and work around this problem if it in fact arises. One possibility would be to keep around a HashMap from the Long address to the ByteBuffer which points to it, since the buffers are unlikely to move in memory.
Offline abies

Senior Member





« Reply #22 - Posted 2003-08-07 07:51:14 »

I have done some measurements for finalizer overhead. Allocating object in tight loop (so they are clearly in eden space only and available for gc umpteen creations after their own), shows following data (jdk141 server after dry run, I'll retest with 1.4.2 at home)

Allocating and collecting 1.000.000 objects without finalizer (with static x++ in constructor) - 50ms. Doing the same for object with x++ instruction moved to finalizer - 8400ms (this is after substracting overhead for loops and x++, which is around 16ms).

While 50ms is too small number to tell anything, it can give a feeling about order of magnitude of difference between objects with and without finalizer. We are talking here about 1 obj with finalizer = 150 objects without one. This also means that you can allocate and trash only around 100 finalizable objects per ms. Given 5ms per frame as estimate, with 500 direct buffers of garbage you will have no time left for any rendering/ai/anything.

IF we want to go Buffer route, caching is a must - only question is if it should be done at library side or application side. Most apps can easily put a wrapper object around vertex buffer and cache offset buffer there. Certainly, caching 'zero pointer' at library would be helpful, for the rest - maybe it is better to leave it to app.

I would just like to ask you to reconsider going plain int route - I know, that this way we are adding amount of manual intervention to api, but on the other hand, int as offset is a lot easier to grasp, manage and a gives no problems with performance.

Artur Biesiadowski
Offline shawnkendall

Senior Member





« Reply #23 - Posted 2003-08-07 09:05:23 »

Although I normally dislike the "me too"s....

Me too! ;-)

Shawn Kendall
Cosmic Interactive, LLC
http://www.facebook.com/BermudaDash
Offline elias

Senior Member





« Reply #24 - Posted 2003-08-07 18:29:51 »

We recently went the int route, including the hard parts - manually tracking the VBO state in the library and only allowing Buffer arguments when VBO is disabled and only allowing int offset arguments otherwise. It is ugly to track VBO, but at least it can be done behind the application's back, and it actually gives extra security over the buffer-only implementation.

- elias

Offline Ken Russell

JGO Coder




Java games rock!


« Reply #25 - Posted 2003-08-07 18:55:03 »

Vertex_buffer_object support has just been checked in to the JOGL source tree. It deals exclusively with Buffers (no ints/longs exposed) and performs caching of the mapped Buffer objects based on their base address and capacity. The VertexArrayRange demo has been ported to VertexBufferObject and works, though the relative speedup from the system memory version to the vertex buffer object version is currently less than with the original VAR demo. I think the geometry needs to be retesselated to have longer quad strips in order to be more effective; additionally the element arrays could be moved into fast RAM. I'll try to rebuild on all platforms and post a new set of binaries tonight.
Offline Markus_Persson

JGO Wizard


Medals: 15
Projects: 19


Mojang Specifications


« Reply #26 - Posted 2003-08-07 18:57:30 »

Great, thanks!  Grin


So basically, to send the offset, I can just use ANY buffer that has it's .position() set to the offset I want?
Or am I reading you wrong?

Play Minecraft!
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #27 - Posted 2003-08-07 19:43:21 »

Quote
So basically, to send the offset, I can just use ANY buffer that has it's .position() set to the offset I want?


You need to use the new net.java.games.jogl.util.BufferUtils.bufferOffset() API, which returns a ByteBuffer representing the desired offset. Please see the source code for the new VertexBufferObject demo (in the jogl-demos source tree) for an example. This demo hasn't been tuned yet but does show one way of using the APIs.
Offline abies

Senior Member





« Reply #28 - Posted 2003-08-07 19:59:37 »

Shouldn't ARBVBOKey class have hashCode and equals method implemented ? I do not understand how they work as a key in HashMap at the moment.

Second question - is 'if (!BufferFactory.isDirect(pointer))'
check really needed ? I think it would fit in DebugGL more than in default implementation.

And finally - BufferUtil does not cache buffers, does it ? For the offsets, we still need to do caching at app level ?

Artur Biesiadowski
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #29 - Posted 2003-08-07 21:05:51 »

Quote
Shouldn't ARBVBOKey class have hashCode and equals method implemented ? I do not understand how they work as a key in HashMap at the moment.


Good point, I hadn't thought clearly through the fact that hashCode() would be broken. Both hashCode() and equals() are now overridden.

Quote
Second question - is 'if (!BufferFactory.isDirect(pointer))'
check really needed ? I think it would fit in DebugGL more than in default implementation.


The old check used to be in the C code and was present in the default implementation. Range checks are also done by default for passed arrays where the expected size of the array is known. I'm open to moving them into DebugGL but doing so would need to be done by giving GlueGen a .cfg file option to elide the checks and then have them produced by BuildComposablePipeline. If you want to change GlueGen and BuildComposablePipeline to be able to move the checks into DebugGL (while leaving them in by default in GlueGen's generated code) then please send in a patch. I think however that there isn't enough information available to BuildComposablePipeline to reconstitute these checks.

Quote
And finally - BufferUtil does not cache buffers, does it ? For the offsets, we still need to do caching at app level ?


Thanks for the suggestion, I've added this caching to BufferUtils.
Pages: [1]
  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.

Pippogeek (37 views)
2014-09-24 16:13:29

Pippogeek (29 views)
2014-09-24 16:12:22

Pippogeek (18 views)
2014-09-24 16:12:06

Grunnt (42 views)
2014-09-23 14:38:19

radar3301 (24 views)
2014-09-21 23:33:17

BurntPizza (60 views)
2014-09-21 02:42:18

BurntPizza (30 views)
2014-09-21 01:30:30

moogie (36 views)
2014-09-21 00:26:15

UprightPath (49 views)
2014-09-20 20:14:06

BurntPizza (52 views)
2014-09-19 03:14:18
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

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

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

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

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

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

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

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!