Java-Gaming.org Hi !
Featured games (81)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (119)
games submitted by our members
Games in WIP (576)
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  
  JSR-231 beta 1 and nightly builds available  (Read 5785 times)
0 Members and 1 Guest are viewing this topic.
Offline Ken Russell

JGO Coder




Java games rock!


« Posted 2005-10-28 05:30:54 »

The first "beta" build of the JSR-231 Reference Implementation has been posted to java.net on October 27, 2005. See the Documents and Files section of the JOGL home page, under "Release Builds 2005".

There are many changes from the previous (1.1.1) release of JOGL. The most obvious is that the namespaces have changed from net.java.games.* to javax.media.opengl.*. The position of Buffers passed down to OpenGL is now significant; the pointer passed to C code is a combination of the base of the Buffer plus the scaled position, effectively "slicing" the buffer without creating a new object. This is an idea borrowed from the LWJGL library. All C void* arguments are now exposed at the Java level as java.nio.Buffer. All APIs which used to accept Java arrays as arguments now accept either direct or non-direct Buffers; all APIs which previously accepted only direct Buffers continue to do so and this restriction is documented in the Javadoc.

Internally, the JOGL library has been almost completely rewritten. The high-level GLEventListener paradigm is now optional instead of required. Users can manipulate GLContexts and GLDrawables directly to create new contexts, make them current and swap buffers manually. The GLDrawable and GLContext concepts have been implemented on all platforms and the default widgets, GLCanvas and GLJPanel, have been reimplemented in terms of them. It is now possible to write your own heavyweight OpenGL widget (a Canvas subclass) using the public JSR-231 APIs if the GLCanvas does not suit your needs. GLCanvas and GLJPanel can also both be usefully subclassed in the new library. The GLEventListener callback paradigm is now optional. GLAutoDrawables support it, while lower-level GLDrawables do not. The default OpenGL rendering targets (GLCanvas, GLJPanel and GLPbuffer) support it, but users can again build their own widgets which do not use it.

There is some exciting new functionality available in the form of the new Java2D/JOGL interoperability bridge. This is built on the new GLDrawable and GLContext APIs in JSR-231 and offers huge speed increases for the GLJPanel. It is possible to use this bridge in other interesting ways. The XTrans (Accelerated Transition) demo on the JOGL demos page shows off a completely different use of this bridge to provide a compositing JDesktopPane for arbitrary Swing widgets. While the APIs of the bridge are not being standardized at this point, they are still available for experimentation and we encourage you to look at what has been built and see what you can do with it.

There are more changes in the new APIs that need to be documented; this documentation is forthcoming. Please look at the new code and port your existing JOGL applications to the new APIs. While the new APIs are not yet set in stone and there will be some flux during the public review period, they have been fairly thoroughly tested over the past several months and the general structure will probably not change much.

Last but not least, nightly builds are finally available again largely thanks to Travis Bryson from Sun. There is no archiving of the nightly builds; the current one is simply linked from the JOGL home page. Javadoc is automatically generated each night, so you can always see the up-to-date specification. Currently the zip archive of javadoc is not available due to legal requirements of the JSR (we need to add a click-through license for it), and we will need to add copyrights and legal notices to the posted javadoc, but you can now see the API as it evolves.

An extension JNLP file for the current JSR-231 beta is available for developers wishing to test their applications against the new APIs. The link is documented in the JOGL Users' Guide. Please again keep in mind that this link will change when the JSR is complete and that the APIs are still evolving somewhat.

Please post your feedback about the new APIs and the implementation. The spec is currently in Early Draft Review, which will be followed by the official Public Review period. This is your opportunity to influence the structure of the specification, and we look forward to your input.
Offline TagadaX

Senior Newbie





« Reply #1 - Posted 2005-10-28 09:03:43 »

Hello,

I changed all my code in order to use this new version of Jogl, and first of all, it was really easy to do it.

Then, before this version, I had lots of problems with the GLJPanel component, but now, it seems that everything is ok. My problems consisted in adding / removing several times gljpanel and glcanvas component from a JInternalFrame. Therefore, the GLJPanel component really seems to be more robust. Really a good point.

Then, in term of performance, I don't really know if the gljPanel is more performant, but in my case, the GLCanvas component is still faster than the GLJPanel.

And finally, everything is running very well with this new version, except one point. I had skyboxes in my app before passing to this version, that worked very well. However, now, I have an error when calling to glu.gluBuild2DMipmaps(...).

#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x038d6576, pid=652, tid=2820
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0_02-b09 mixed mode, sharing)
# Problematic frame:
# C  0x038d6576
#
# An error report file with more information is saved as hs_err_pid652.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

and the file hs-err_pid652.log contains :

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  
50  
51  
52  
53  
54  
55  
56  
57  
58  
59  
60  
61  
62  
63  
64  
65  
66  
67  
68  
69  
70  
71  
72  
73  
74  
75  
76  
77  
78  
79  
80  
81  
82  
83  
84  
85  
86  
87  
88  
89  
90  
91  
92  
93  
94  
95  
96  
97  
98  
99  
100  
101  
102  
103  
104  
105  
106  
107  
108  
109  
110  
111  
112  
113  
114  
115  
116  
117  
118  
119  
120  
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x038d6576, pid=652, tid=2820
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0_02-b09 mixed mode, sharing)
# Problematic frame:
# C  0x038d6576
#

---------------  T H R E A D  ---------------

Current thread (0x030a8120):  JavaThread "AWT-EventQueue-0" [_thread_in_native, id=2820]

siginfo: ExceptionCode=0xc0000005, reading address 0x031cf001

Registers:
EAX=0x031cec00, EBX=0x00000000, ECX=0x00000003, EDX=0x00000000
ESP=0x035eef3c, EBP=0x000000ab, ESI=0x031cefff, EDI=0x062015d4
EIP=0x038d6576, EFLAGS=0x00010202

Top of Stack: (sp=0x035eef3c)
0x035eef3c:   69670fa0 035eeff0 05ad00c0 000001be
0x035eef4c:   69670fc5 031cec00 06201080 00000200
0x035eef5c:   69669094 05ad00c0 035eeff0 031cec00
0x035eef6c:   06201080 038d68c0 05ad00c0 035eeff0
0x035eef7c:   69669050 00000200 00000001 696695aa
0x035eef8c:   05ad00c0 035eeff0 05ad00c0 05bf0080
0x035eef9c:   031b6000 038d68c0 031b6000 00000002
0x035eefac:   00000002 00000005 00000004 3f800000

Instructions: (pc=0x038d6576)
0x038d6566:   00 b9 03 00 00 00 0f 8f 04 00 00 00 f7 d9 f7 dd
0x038d6576:   0f b6 5e 02 c1 e3 10 0f b7 16 0b da 03 f1 83 c7


Stack: [0x035b0000,0x035f0000),  sp=0x035eef3c,  free space=251k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  0x038d6576

[error occurred during error reporting, step 120, id 0xc0000005]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  com.sun.opengl.impl.GLImpl.glTexImage2D0(IIIIIIIILjava/lang/Object;I)V+0
j  com.sun.opengl.impl.GLImpl.glTexImage2D(IIIIIIIILjava/nio/Buffer;)V+37
j  javax.media.opengl.DebugGL.glTexImage2D(IIIIIIIILjava/nio/Buffer;)V+19
j  com.sun.opengl.impl.mipmap.BuildMipmap.gluBuild2DMipmapLevelsCore(Ljavax/media/opengl/GL;IIIIIIIIIIILjava/nio/ByteBuffer;)I+341
j  com.sun.opengl.impl.mipmap.Mipmap.gluBuild2DMipmaps(Ljavax/media/opengl/GL;IIIIIILjava/lang/Object;)I+305
j  javax.media.opengl.glu.GLU.gluBuild2DMipmapsJava(IIIIIILjava/nio/Buffer;)I+22
j  javax.media.opengl.glu.GLU.gluBuild2DMipmaps(IIIIIILjava/nio/Buffer;)I+18
j  net.active3d.viewer3d.engine3d.objects.skybox.SkyBox.makeRGBTexture(Ljavax/media/opengl/GL;Ljavax/media/opengl/glu/GLU;Ljava/awt/image/BufferedImage;IZ)V+195
j  net.active3d.viewer3d.engine3d.objects.skybox.SkyBox.loadImages(Ljavax/media/opengl/GL;Ljavax/media/opengl/glu/GLU;)V+154
j  net.active3d.viewer3d.engine3d.objects.skybox.SkyBox.<init>(Ljava/lang/String;FFFIILjavax/media/opengl/GL;Ljavax/media/opengl/glu/GLU;)V+29
j  net.active3d.viewer3d.engine3d.objects.skybox.SkyBoxManager.init(Ljavax/media/opengl/GL;Ljavax/media/opengl/glu/GLU;)V+68
j  net.active3d.viewer3d.engine3d.Canvas3D.init(Ljavax/media/opengl/GLAutoDrawable;)V+534
j  com.sun.opengl.impl.GLDrawableHelper.init(Ljavax/media/opengl/GLAutoDrawable;)V+29
j  javax.media.opengl.GLCanvas$InitAction.run()V+11
j  com.sun.opengl.impl.GLDrawableHelper.invokeGL(Ljavax/media/opengl/GLDrawable;Ljavax/media/opengl/GLContext;Ljava/lang/Runnable;Ljava/lang/Runnable;)V+84
j  javax.media.opengl.GLCanvas.maybeDoSingleThreadedWorkaround(Ljava/lang/Runnable;Ljava/lang/Runnable;)V+36
j  javax.media.opengl.GLCanvas.display()V+9
j  javax.media.opengl.GLCanvas.paint(Ljava/awt/Graphics;)V+1
j  sun.awt.RepaintArea.paintComponent(Ljava/awt/Component;Ljava/awt/Graphics;)V+6
j  sun.awt.RepaintArea.paint(Ljava/lang/Object;Z)V+326
j  sun.awt.windows.WComponentPeer.handleEvent(Ljava/awt/AWTEvent;)V+63
j  java.awt.Component.dispatchEventImpl(Ljava/awt/AWTEvent;)V+765
j  java.awt.Component.dispatchEvent(Ljava/awt/AWTEvent;)V+2
j  java.awt.EventQueue.dispatchEvent(Ljava/awt/AWTEvent;)V+46
j  java.awt.EventDispatchThread.pumpOneEventForHierarchy(ILjava/awt/Component;)Z+200
j  java.awt.EventDispatchThread.pumpEventsForHierarchy(ILjava/awt/Conditional;Ljava/awt/Component;)V+26
j  java.awt.EventDispatchThread.pumpEvents(ILjava/awt/Conditional;)V+4
j  java.awt.EventDispatchThread.pumpEvents(Ljava/awt/Conditional;)V+3
j  java.awt.EventDispatchThread.run()V+9
v  ~StubRoutines::call_stub

---------------  P R O C E S S  ---------------

Java Threads: ( => current thread )
  0x03177ba0 JavaThread "IfcViewerFrame" [_thread_blocked, id=2404]
  0x00356a78 JavaThread "DestroyJavaVM" [_thread_blocked, id=568]
  0x0314cff8 JavaThread "TimerQueue" daemon [_thread_blocked, id=2808]
=>0x030a8120 JavaThread "AWT-EventQueue-0" [_thread_in_native, id=2820]
  0x030a38d0 JavaThread "AWT-Windows" daemon [_thread_in_native, id=544]
  0x030a34b8 JavaThread "AWT-Shutdown" [_thread_blocked, id=2028]
  0x03061528 JavaThread "Java2D Disposer" daemon [_thread_blocked, id=2204]
  0x00a0cf98 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=2968]
  0x00a0bb70 JavaThread "CompilerThread0" daemon [_thread_blocked, id=340]
  0x00a0ae60 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2676]
  0x00a081e0 JavaThread "Finalizer" daemon [_thread_blocked, id=2972]
  0x00a06d00 JavaThread "Reference Handler" daemon [_thread_blocked, id=220]

Other Threads:
  0x00a04458 VMThread [id=2004]
  0x00a0e1e0 WatcherThread [id=3216]

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: None

Here is heap information and libraries information......

VM Arguments:
jvm_args: -Xmx512m
java_command: IfcViewerFrame

Environment Variables:
PATH=E:\oracle\ora90\bin;C:\Program Files\Oracle\jre\1.1.8\bin;E:\Applications\openCascade\3rdparty\win32\tcltk\bin;E:\Applications\openCascade\ros\win32\bin;"C:\Program Files\Java\jdk1.5.0_02\bin";C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\Fichiers communs\Autodesk Shared\;E:\Applications\cvsnt;C:\Ant\apache-ant-1.6.5-bin\bin
USERNAME=JR
OS=Windows_NT
PROCESSOR_IDENTIFIER=x86 Family 15 Model 2 Stepping 7, GenuineIntel


---------------  S Y S T E M  ---------------

OS: Windows XP Build 2600 Service Pack 2

CPU:total 1 family 15, cmov, cx8, fxsr, mmx, sse, sse2, ht

Memory: 4k page, physical 523268k(55040k free), swap 1278200k(740584k free)

vm_info: Java HotSpot(TM) Client VM (1.5.0_02-b09) for windows-x86, built on Mar  4 2005 01:53:53 by "java_re" with MS VC++ 6.0


I don't know how to solve this...

My textures are initialised from the "public void init(GLAutoDrawable gld)" method and the call to glu.gluBuild2DMipmaps(...) crashes my JVM. I tried to call GLU glu = new GLU(); just before calling the glu.gluBuild2DMipmaps(...) method (as the way to use GLU has changed), but it doesn't run...

If someone has an idea...

Thank you.
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #2 - Posted 2005-10-28 13:42:38 »

And finally, everything is running very well with this new version, except one point. I had skyboxes in my app before passing to this version, that worked very well. However, now, I have an error when calling to glu.gluBuild2DMipmaps(...).

#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x038d6576, pid=652, tid=2820
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0_02-b09 mixed mode, sharing)
# Problematic frame:
# C  0x038d6576
#
# An error report file with more information is saved as hs_err_pid652.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#


Have you checked to make sure you have called Buffer.rewind() on the Buffer you're passing in to gluBuild2DMipmaps? If you already have, and it's still crashing, could you please file a bug with the JOGL Issue Tracker and attach a small test case (you'll need to ba an Observer of the project to do so)?

We need to implement bounds checking on the low-level GL routines like glTexImage2D. This is still on the to-do list.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline TagadaX

Senior Newbie





« Reply #3 - Posted 2005-10-31 09:32:07 »

I didn't use Buffer.rewind(), that's why it didn't work. Thank you very much.
Offline Rob Nugent

Junior Duke




May contain nuts


« Reply #4 - Posted 2005-10-31 16:21:36 »

Ken,

Could you clarify please if the 'size' parameter in the new:

1  
   glBufferData(int target, int size, Buffer data, int usage) 


Is 'number of bytes' or 'number of elements' please ?

(I'm not in a position to test this right now).

Thanks,
Rob
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #5 - Posted 2005-10-31 19:28:45 »

Number of bytes. This is actually unchanged from the previous API.
Offline Mithrandir

Senior Duke




Cut from being on the bleeding edge too long


« Reply #6 - Posted 2005-10-31 23:10:49 »

The GLPbuffer.isInitialised() method has gone. Does that now mean that we can assume that, if we have an instance of GLPbuffer, that it will always be initialised? We had timing related issues with the old code where we had to check for this, but now no such check is available.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Offline Mithrandir

Senior Duke




Cut from being on the bleeding edge too long


« Reply #7 - Posted 2005-10-31 23:20:01 »

Oh, and another bug it seems with the void* handling. Look to the method of glDrawElements().
There are two signatures defined:

void glDrawElements(int mode, int count, int type, Buffer indices)
void glDrawElements(int mode, int count, int type, long indices_buffer_offset)

The second one is broken as it's effectively useless. There is no way of passing an array of something through to it. I haven't looked through the other methods that also use void*, but I suspect they'll all have the same thing. Ii would recommend that the auto generation change void* to an Object and int offset. Since all the primitive array types can be passed through as Object instances, this shouldn't cause a problem (and the javadoc says that it should only pass through numeric primitive arrays).


The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Offline tom
« Reply #8 - Posted 2005-11-01 00:08:29 »

Looks like the second glDrawElements is used with VBOs where you need to pass an offset into the currently bound index buffer.

Offline Mithrandir

Senior Duke




Cut from being on the bleeding edge too long


« Reply #9 - Posted 2005-11-01 01:23:38 »

Could be, but it wasn't like that under the old API. The old code took an int[] for the second form. Since all the other APIs have just an extra int m_offset parameter added, this looks far more like the broken generation than anything VBO-related. The old code supported VBOs too, but didn't have that sort of method signature.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
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 2005-11-01 01:51:41 »

The GLPbuffer.isInitialised() method has gone. Does that now mean that we can assume that, if we have an instance of GLPbuffer, that it will always be initialised? We had timing related issues with the old code where we had to check for this, but now no such check is available.

Yes. Pbuffers are initialized upon creation in the new implementation.
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #11 - Posted 2005-11-01 01:54:45 »

Could be, but it wasn't like that under the old API. The old code took an int[] for the second form. Since all the other APIs have just an extra int m_offset parameter added, this looks far more like the broken generation than anything VBO-related. The old code supported VBOs too, but didn't have that sort of method signature.

The API change was caused by a change in handling of JOGL's VBO support. In order to tighten up security around the VBO- and PBO-related routines it was necessary to identify them to the glue code generator and have VBO/PBO and non-VBO/PBO variants generated. The new implementation also checks whether the appropriate extension is enabled at the time the particular variant is called. This is similar to how LWJGL has been handling these extensions.
Offline Mithrandir

Senior Duke




Cut from being on the bleeding edge too long


« Reply #12 - Posted 2005-11-01 03:46:40 »

Ok. so just to make sure I understand correctly: glDrawElements() now requires that I use a NIO Buffer class to interact with it, with no chance of using the normal primitive arrays?

If that is the case, what is the state of an NIOBuffer after a call? Is the position updated to the end of where it it would be after reading the values, or is it rewound? The wording above is not very clear and there's nothing in the javadoc about what the behaviours of buffers will be. Here's the example I'm trying to update:

We have an indexed triangle strip set. In the old code I had a single 2D array of the indices for each strip and then iterated over the sets of strips with a for loop and multiple glDrawElements() calls. Under the new system, I was expecting I could go back to using a single array and use the offset parameters like in the other API calls so that I could stick with just using a single index array and step through it with the glDrawElements() call. Basically what it looks like I need to do is convert that 2D int[][] into IntBuffer[] and work from there. (I have an alternative codepath when glMultiDrawElements is available, I just need to be able to deal with earlier versions of OpenGL too).

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #13 - Posted 2005-11-01 04:23:33 »

Ok. so just to make sure I understand correctly: glDrawElements() now requires that I use a NIO Buffer class to interact with it, with no chance of using the normal primitive arrays?

You can use a primitive array with it by calling IntBuffer.wrap() at the point of use. You can also wrap your primitive array in an IntBuffer ahead of time and interact with it that way.

Quote
If that is the case, what is the state of an NIOBuffer after a call? Is the position updated to the end of where it it would be after reading the values, or is it rewound? The wording above is not very clear and there's nothing in the javadoc about what the behaviours of buffers will be. Here's the example I'm trying to update:

We have an indexed triangle strip set. In the old code I had a single 2D array of the indices for each strip and then iterated over the sets of strips with a for loop and multiple glDrawElements() calls. Under the new system, I was expecting I could go back to using a single array and use the offset parameters like in the other API calls so that I could stick with just using a single index array and step through it with the glDrawElements() call. Basically what it looks like I need to do is convert that 2D int[][] into IntBuffer[] and work from there. (I have an alternative codepath when glMultiDrawElements is available, I just need to be able to deal with earlier versions of OpenGL too).

The state of the Buffer is unchanged after the call. You can either stride through a 1D Buffer by setting its position before each call, simply wrap up your existing primitive arrays with each call down (inefficient), or any combination of other solutions.
Offline Rob Nugent

Junior Duke




May contain nuts


« Reply #14 - Posted 2005-11-01 08:08:19 »

Ken,

Thanks for the reply.

I've started moving my code to JSR231, and apart from a bit of work moving from a number of old JOGL APIs that took arrays to the JSR231 Buffer variants it's all going very smoothly and easily.

Re glBufferData()

We discussed the issue of "number of bytes" versus "number of elements" some months ago and in some detail. I will not reinterate here, other than to say that all other Java APIs that deal with Buffers deal in numbers of elements. My code now looks like:

1  
2  
3  
4  
5  
6  
               
 FloatBuffer fb = tsa.getInterleavedFloatBuffer();
 gl.glBufferData( GL.GL_ARRAY_BUFFER_ARB,
   fb.limit() * BufferUtils.SIZEOF_FLOAT,
   fb,
   GL.GL_STATIC_DRAW_ARB);


Is there any chance of having a version of glBufferData that explicitly takes a FloatBuffer and where the 'size' is in "number of elements" please ?

1) This would eliminate the possibity of supplying an invalid size when using a FloatBuffer (e.g. currently 7 can NEVER be a valid size when supplying a FloatBuffer)
2) It would eliminate my having to use SIZEOF_FLOAT which is an anathema to any Java programmer
3) In the above I'm pretty much force to use BufferUtils (a non-core com.sun API) any time I want to use the above (core, javax.media API)

If I understood you correctly, the start of the data is now taken from the Buffer position which is specified as the ordinal of the first element, so a length in bytes is really odd.

Thanks,
Rob
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.

Longarmx (38 views)
2014-10-17 03:59:02

Norakomi (28 views)
2014-10-16 15:22:06

Norakomi (24 views)
2014-10-16 15:20:20

lcass (28 views)
2014-10-15 16:18:58

TehJavaDev (53 views)
2014-10-14 00:39:48

TehJavaDev (54 views)
2014-10-14 00:35:47

TehJavaDev (43 views)
2014-10-14 00:32:37

BurntPizza (64 views)
2014-10-11 23:24:42

BurntPizza (36 views)
2014-10-11 23:10:45

BurntPizza (78 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

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
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!