Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (538)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (600)
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  
  LWJGL Threading problem  (Read 6650 times)
0 Members and 1 Guest are viewing this topic.
Offline Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Posted 2007-01-01 22:50:36 »

hi

When I change the rendering thread for LWJGL I run into problems. Inside the rendering thread the following code is executed:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
        if (renderingThread != Thread.currentThread())
        {
            /*
             * Sometimes it is necessary to remeber LWJGL, which Thread is is using ;-)
             */

            try
            {
                if (renderingThread != null)
                    Display.releaseContext();
               
                Display.makeCurrent();
            }
            catch (Throwable e)
            {
                e.printStackTrace();
            }
           
            renderingThread = Thread.currentThread();
        }


and this is the exception that crashes the game:
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  
java.lang.IllegalStateException: From thread Thread[Thread-4,5,main]: Thread[main,5,] already has the context current
   at org.lwjgl.opengl.Context.checkAccess(Context.java:169)
   at org.lwjgl.opengl.Context.makeCurrent(Context.java:176)
   at org.lwjgl.opengl.Display.makeCurrent(Display.java:625)
   at org.xith3d.render.lwjgl.CanvasPeerImpl.renderStart(CanvasPeerImpl.java:652)
   at org.xith3d.render.lwjgl.CanvasPeerImpl.display(CanvasPeerImpl.java:1003)
   at org.xith3d.render.lwjgl.CanvasPeerImpl.render(CanvasPeerImpl.java:1104)
   at org.xith3d.render.Renderer.renderOnceInternal(Renderer.java:552)
   at org.xith3d.render.Renderer.renderOnce(Renderer.java:578)
   at org.xith3d.scenegraph.VirtualUniverse.renderOnce(VirtualUniverse.java:133)
   at org.xith3d.render.base.ExtXith3DEnvironment.render(ExtXith3DEnvironment.java:286)
   at org.xith3d.render.loop.RenderLoop.invokeRendering(RenderLoop.java:736)
   at org.xith3d.render.loop.RenderLoop.loopIteration(RenderLoop.java:757)
   at org.xith3d.render.loop.ExtRenderLoop.loopIteration(ExtRenderLoop.java:349)
   at org.stratagem.apps.Stratagem.loopIteration(Stratagem.java:176)
   at org.xith3d.render.loop.RenderLoop.nextIteration(RenderLoop.java:924)
   at org.xith3d.render.loop.RenderLoop.run(RenderLoop.java:960)
   at java.lang.Thread.run(Thread.java:595)
java.lang.NullPointerException
   at org.lwjgl.opengl.GL11.glRenderMode(GL11.java:2021)
   at org.xith3d.render.lwjgl.CanvasPeerImpl.renderStart(CanvasPeerImpl.java:725)
   at org.xith3d.render.lwjgl.CanvasPeerImpl.display(CanvasPeerImpl.java:1003)
   at org.xith3d.render.lwjgl.CanvasPeerImpl.render(CanvasPeerImpl.java:1104)
   at org.xith3d.render.Renderer.renderOnceInternal(Renderer.java:552)
   at org.xith3d.render.Renderer.renderOnce(Renderer.java:578)
   at org.xith3d.scenegraph.VirtualUniverse.renderOnce(VirtualUniverse.java:133)
   at org.xith3d.render.base.ExtXith3DEnvironment.render(ExtXith3DEnvironment.java:286)
   at org.xith3d.render.loop.RenderLoop.invokeRendering(RenderLoop.java:736)
   at org.xith3d.render.loop.RenderLoop.loopIteration(RenderLoop.java:757)
   at org.xith3d.render.loop.ExtRenderLoop.loopIteration(ExtRenderLoop.java:349)
   at org.stratagem.apps.Stratagem.loopIteration(Stratagem.java:176)
   at org.xith3d.render.loop.RenderLoop.nextIteration(RenderLoop.java:924)
   at org.xith3d.render.loop.RenderLoop.run(RenderLoop.java:960)
   at java.lang.Thread.run(Thread.java:595)
Exception in thread "Thread-4" java.lang.Error: java.lang.NullPointerException
   at org.xith3d.render.lwjgl.CanvasPeerImpl.display(CanvasPeerImpl.java:1068)
   at org.xith3d.render.lwjgl.CanvasPeerImpl.render(CanvasPeerImpl.java:1104)
   at org.xith3d.render.Renderer.renderOnceInternal(Renderer.java:552)
   at org.xith3d.render.Renderer.renderOnce(Renderer.java:578)
   at org.xith3d.scenegraph.VirtualUniverse.renderOnce(VirtualUniverse.java:133)
   at org.xith3d.render.base.ExtXith3DEnvironment.render(ExtXith3DEnvironment.java:286)
   at org.xith3d.render.loop.RenderLoop.invokeRendering(RenderLoop.java:736)
   at org.xith3d.render.loop.RenderLoop.loopIteration(RenderLoop.java:757)
   at org.xith3d.render.loop.ExtRenderLoop.loopIteration(ExtRenderLoop.java:349)
   at org.stratagem.apps.Stratagem.loopIteration(Stratagem.java:176)
   at org.xith3d.render.loop.RenderLoop.nextIteration(RenderLoop.java:924)
   at org.xith3d.render.loop.RenderLoop.run(RenderLoop.java:960)
   at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.NullPointerException
   at org.lwjgl.opengl.GL11.glRenderMode(GL11.java:2021)
   at org.xith3d.render.lwjgl.CanvasPeerImpl.renderStart(CanvasPeerImpl.java:725)
   at org.xith3d.render.lwjgl.CanvasPeerImpl.display(CanvasPeerImpl.java:1003)
   ... 12 more


Any help would be appreciated. Thanks in advance.

Marvin
Offline darkprophet

Senior Devvie




Go Go Gadget Arms


« Reply #1 - Posted 2007-01-02 13:12:12 »

The realseContext() call has to be made from the other thread that is no longer the rendering thread. The makeCurrent() call needs to be made in the new thread that wants the context.

Also, the thread that created the Display has the initial context, you would need to release the context after Display.create(...); if your rendering thread is not the same thread that created the Display.

DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Reply #2 - Posted 2007-01-02 17:47:33 »

The realseContext() call has to be made from the other thread that is no longer the rendering thread. The makeCurrent() call needs to be made in the new thread that wants the context.

Also, the thread that created the Display has the initial context, you would need to release the context after Display.create(...); if your rendering thread is not the same thread that created the Display.

Thanks for the reply.

Why is all this necessary? Especially this releaseContext() thing. Why can't an arbitrary thread pull the "render thread ownership" without the other thread release the context itself? This makes it really hard to abstract LWJGL.

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

Senior Devvie




May the 4th, be with you...


« Reply #3 - Posted 2007-01-02 18:29:06 »

Got it. Thanks for the help Smiley.

Well, for my (ignorant) feeling this is way more complicated than it has to be. JOGL does it without these threading issues and its even faster.

Marvin
Offline darkprophet

Senior Devvie




Go Go Gadget Arms


« Reply #4 - Posted 2007-01-02 18:35:56 »

Those are all subjective feelings and are your opinion. Please keep these to yourself, no one needs to hear these sort of remarks. And for your information, JOGL does deal with them, but in a less transperant manner which makes it subjectively easier.

As for the "faster", look at Jake2 benchmark results which reflect what a real life situation looks like, not just some random GL code written by amatures.

DP


Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Reply #5 - Posted 2007-01-02 18:58:59 »

Those are all subjective feelings and are your opinion. Please keep these to yourself, no one needs to hear these sort of remarks. And for your information, JOGL does deal with them, but in a less transperant manner which makes it subjectively easier.

Well, even if it is a subjective feeling, it should of high interest for any API designer. And if JOGL hides those threading problems from the user it is even more transparent Wink.

As for the "faster", look at Jake2 benchmark results which reflect what a real life situation looks like, not just some random GL code written by amatures.

Thanks for calling me an amateur Grin or Amos, who wrote the (real life) game, that I wanted to run with LWJGL. Just because the LWJGL API is worse than JOGL's one, we are no anateurs when we (or I) complain about it Wink.

Marvin
Offline darkprophet

Senior Devvie




Go Go Gadget Arms


« Reply #6 - Posted 2007-01-02 19:14:15 »

Quote
Well, even if it is a subjective feeling, it should of high interest for any API designer
Heh, if you had *any* idea how OGL worked, you wouldn't have even thought about this let alone said it.

First of all, your comparing a released and very successful game to a game that I haven't seen and im sure no one besides the inner circle of friends that Amos have will have heard about it. Are you seriously suggesting that them two are comparable? If you are....your living in coocooland Smiley

2nd of all, no matter what type of game it is, if the engine used to make the game doesn't utilise OpenGL properly, nothing can save it. And well, we all know how Xith3D is doing these days in terms of performance...

I dont dislike you or Xith3D and im a big supporter of community projects. But you brought this upon yourself Smiley

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Reply #7 - Posted 2007-01-02 19:31:43 »

First of all, your comparing a released and very successful game to a game that I haven't seen and im sure no one besides the inner circle of friends that Amos have will have heard about it. Are you seriously suggesting that them two are comparable? If you are....your living in coocooland Smiley

Hey, I don't want to compare these two games Huh. I just made a very tiny comparison of LWJGL's and JOGL's API. I just don't like these static methods all over the API. Of course this is subjective, but noone can seriously have anything against it, that I tell my opinion publicly Smiley.

2nd of all, no matter what type of game it is, if the engine used to make the game doesn't utilise OpenGL properly, nothing can save it.

It's not the game's fault, but xith's one (-> my fault Wink).

And well, we all know how Xith3D is doing these days in terms of performance...

I'm working on it Wink.

I dont dislike you or Xith3D and im a big supporter of community projects. But you brought this upon yourself Smiley

Well, of course, I brought this upon myself, if I use LWJGL's API the wrong way. It's just that I think, the lib could maybe handle it internally. That's all. But certainly I don't know LWJGL well enough to tell this Wink.

Marvin
Offline darkprophet

Senior Devvie




Go Go Gadget Arms


« Reply #8 - Posted 2007-01-02 19:37:03 »

You just negated what yourself!

You explicitly said that LWJGL is slower (which is your opinion, everybody is entitled to an opinion) and then you said that Xith needs work. How can you make a comparison between JOGL and LWJGL if your lib isn't complete and doesn't utilise both libs the same way?

Im finding it really hard not to take what you say with a grain of salt. But lets just cool this matter down and hope that the issue of  mulithreading your app with LWJGL has been resolved with the releaseContext() method call Smiley

DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Reply #9 - Posted 2007-01-02 19:45:19 »

You just negated what yourself!

I didn't Smiley

You explicitly said that LWJGL is slower (which is your opinion, everybody is entitled to an opinion) and then you said that Xith needs work. How can you make a comparison between JOGL and LWJGL if your lib isn't complete and doesn't utilise both libs the same way?

We do utilize them the same way (as far as possible). The work, that needs to be done, is related to state sorting, but not to renderer API utilization.

Im finding it really hard not to take what you say with a grain of salt. But lets just cool this matter down and hope that the issue of  mulithreading your app with LWJGL has been resolved with the releaseContext() method call Smiley

Agreed (even if I don't exaclty understand this "grain of salt" thing. But I guess it is something bad.). The issue is workarounded and doesn't matter for Xith users. So it's ok.

Marvin
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 840
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #10 - Posted 2007-01-02 19:54:41 »

Quote
JOGL does it [...] and its even faster

I just want to point out that the above is not just an opinion, so can you back it up with facts?

What exactly is faster anyway?
And I never had to deal with contexts at all in LWJGL, what makes you so sure LWJGL forgets it?

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social
Offline darkprophet

Senior Devvie




Go Go Gadget Arms


« Reply #11 - Posted 2007-01-02 19:59:58 »

Utlising both libs in the same way as possible isn't being optimal to either libs. And IIRC, JOGL was used before LWJGL , this means your API was designed with JOGL so there is bias there...

But thats nor here or there lets just end the argument now.

DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Reply #12 - Posted 2007-01-02 20:04:07 »

I just want to point out that the above is not just an opinion, so can you back it up with facts?
What exactly is faster anyway?

Well, any test case I ran was a bit (and only a bit) slower with LWJGL. Even though I heard from Windows users, that LWJGL performs better than JOGL on Windows.

And I never had to deal with contexts at all in LWJGL, what makes you so sure LWJGL forgets it?

Well I already removed the comment line about this forgetting thing from our project source. I just placed it there, because I was a bit angry, that one has to deal with it. LWJGL doesn't forget it.

An example:

I have a loading screen, that renders information about loading progress. It is a lot faster, if it is only updated, when a new progress information is available. But the game runs in a constant loop in a separate thread, which I call the "actual render thread". So when the actual render thread is started and wants to render the next frame, the contet needs to be switched. In this case I have to handle this context change in some way, which is not necessary (for me as the reedner API user) in JOGL.

Marvin
Offline Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Reply #13 - Posted 2007-01-02 20:05:04 »

Utlising both libs in the same way as possible isn't being optimal to either libs. And IIRC, JOGL was used before LWJGL , this means your API was designed with JOGL so there is bias there...

I guess, you're right.

But thats nor here or there lets just end the argument now.

OK
Offline Amos Wenger

Senior Devvie




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


« Reply #14 - Posted 2007-01-03 16:29:33 »

@DP : yes the LWJGL renderer was implemented aftwards the JOGL one (in fact it was derived from the JOGL one). Following Qudus's test on his Linux box, the current use of LWJGL by Xith3D leads to less FPS than the current use of JOGL by Xith3D. Period. About Xith3D performances, they have been improved greatly since jME benchmarks (with the Quake3 loader) : they're now really similar. Also, the ones you call "amateur" have a right to try and make their own random hacks, as you do with volatile-engine (impressive screenshots, though I'm looking forward to being able to download something of your work.) And I think a little bit more of "savoir-vivre" would not do great harm to you. EOF.

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

Senior Devvie




Go Go Gadget Arms


« Reply #15 - Posted 2007-01-03 17:11:08 »

I never said you dont have the right to do anything. You can go and throw yourself off a bridge if you want; after all, you do have the right to do so.

2nd of all, the last place im going to learn any manners from is from forums. No offence, but you dont lecture me about good manners. Period. Afterall, If you are posting a topic about a particular problem in LWJGL, dont go mouthing off about LWJGL after you get the help..

3rd of all, i wasn't bashing Xith3D at all, its a great effort and by all means carry on doing what you do. Its just at the moment, its not on par with other libraries out there and thats my opinion. You are ofcourse working towards making it better, but I believe you have a long way to go; again, thats my opinion and you can't argue with opinions Smiley

PS. you do realise EOF stands for End Of File right ?

DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Reply #16 - Posted 2007-01-03 17:26:47 »

2nd of all, the last place im going to learn any manners from is from forums. No offence, but you dont lecture me about good manners. Period. Afterall, If you are posting a topic about a particular problem in LWJGL, dont go mouthing off about LWJGL after you get the help..

Ah! That's the point... Well, let me tell you, that I really appreciate the help, that I got here on the Forum. Thank you very, very much. It was fast and competent help. Mouthing off about the API design of LWJGL had nothing to do with that. I just wanted to tell you may opinion about the API design. And maybe I did it the wrong way.

Marvin
Offline Amos Wenger

Senior Devvie




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


« Reply #17 - Posted 2007-01-03 17:28:32 »

3rd of all, i wasn't bashing Xith3D at all, its a great effort and by all means carry on doing what you do. Its just at the moment, its not on par with other libraries out there and thats my opinion. You are ofcourse working towards making it better, but I believe you have a long way to go; again, thats my opinion and you can't argue with opinions Smiley
Run benchmarks again, with SVN Xith3D.
I'm afraid your "at the moment" correspond to early-2006. But we're 2007, you know. On my crappy GF4 440MX SE I get 63.49 FPS with jME on the Q3 bench and 66.71 FPS with Xith3D-LWJGL.... So you know Xith is just alright for me, "on par" enough.

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




May the 4th, be with you...


« Reply #18 - Posted 2007-01-03 17:30:47 »

Run benchmarks again, with SVN Xith3D.
I'm afraid your "at the moment" correspond to early-2006. But we're 2007, you know. On my crappy GF4 440MX SE I get 63.49 FPS with jME on the Q3 bench and 66.71 FPS with Xith3D-LWJGL.... So you know Xith is just alright for me, "on par" enough.

jME is better for more high performance graphics cards and Xith for lower end cards... at the moment Wink. That's, waht renanse found out through his webstartable tests.

Marvin
Offline Amos Wenger

Senior Devvie




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


« Reply #19 - Posted 2007-01-03 17:31:39 »

Ah! That's the point... Well, let me tell you, that I really appreciate the help, that I got here on the Forum. Thank you very, very much. It was fast and competent help. Mouthing off about the API design of LWJGL had nothing to do with that. I just wanted to tell you may opinion about the API design. And maybe I did it the wrong way.
Remember, that what you're not used to often seems to you not as good as what you're used to... Think about some experiments of Window users discovering Linux...

For my experiments between JOGL and LWJGL with my amateur-game Smiley I get pretty similar FPS. (And DP, remember I don't work on the rendering code... so I just deal with high-level issues, hence the fact I'm probably an "amateur" doesn't impact Xith3D use of JOGL or LWJGL. Though if you have some hints&tips of how LWJGL is different from JOGL, what can be often easily optimized, or so on, just tell us).

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




May the 4th, be with you...


« Reply #20 - Posted 2007-01-03 17:34:19 »

Remember, that what you're not used to often seems to you not as good as what you're used to... Think about some experiments of Window users discovering Linux...

Yeah, you may be right...
Offline Amos Wenger

Senior Devvie




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


« Reply #21 - Posted 2007-01-03 17:34:57 »

his webstartable tests.
They're getting old, you know..

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

Senior Devvie




Go Go Gadget Arms


« Reply #22 - Posted 2007-01-03 17:43:41 »

Heh, you think display list creation is something amazing when it comes to performance?

* darkprophet sighs

I give up, go do whatever you want to do....i dont care anymore. I'll keep myself away from Xith from now on.

DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline woogley
« Reply #23 - Posted 2007-01-03 17:46:05 »

you people are seriously boring.
Offline princec

« JGO Spiffy Duke »


Medals: 429
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #24 - Posted 2007-01-03 18:14:46 »

I'd be surprised if there were any significant performance difference between LWJGL and JOGL. After all the fill-rate and geometry bottlenecks are the same so the negligible difference will just be down to the noise of context handling.

As for not likeing static APIs - OpenGL is a static API so we designed the LWJGL like that. It looks much nicer if you use Java 5's static import feature to get rid of all the GL11 prefixes. Almost like C code. Something you can't do in JOGL unfortunately.

Cas Smiley

Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 840
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #25 - Posted 2007-01-03 18:51:01 »

Did you know Java3D uses vertex-arrays under the hood? No VBOs yet.

It's already hard to beat Java3D, we can only imagine how the next version of Java3D (beyond 1.5) is going to perform..

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social
Offline Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Reply #26 - Posted 2007-01-03 20:17:40 »

As for not likeing static APIs - OpenGL is a static API so we designed the LWJGL like that.

Well, OpenGL is not object oriented while Java is an oo language. So a lib designed for use with Java should be in an oo style. That's why I don't like LWJGL's API.

It looks much nicer if you use Java 5's static import feature to get rid of all the GL11 prefixes. Almost like C code. Something you can't do in JOGL unfortunately.

It is for the GL constants in the GL class Wink. For all the other methods it is not, you're right. But I wouldn't want to to.

Marvin
Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #27 - Posted 2007-01-04 09:23:30 »

Well, OpenGL is not object oriented while Java is an oo language. So a lib designed for use with Java should be in an oo style. That's why I don't like LWJGL's API.
[...]

CPUs aren't object oriented, therefore OO languages are generally incorrect.

Amazing logic huh? Smiley

Well, I disagree. I also think that something like a non-static version of Math wouldn't make much sense for the same reasons. And yea, I picked LWJGL *because* it was static.

弾幕 ☆ @mahonnaiseblog
Offline K.I.L.E.R

Senior Devvie




Java games rock!


« Reply #28 - Posted 2007-01-04 12:38:45 »

CPUs are designed by humans, by your logic, logic isn't OOP.

CPUs aren't object oriented, therefore OO languages are generally incorrect.

Amazing logic huh? Smiley

Well, I disagree. I also think that something like a non-static version of Math wouldn't make much sense for the same reasons. And yea, I picked LWJGL *because* it was static.

Vorax:
Is there a name for a "redneck" programmer?

Jeff:
Unemployed. Wink
Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #29 - Posted 2007-01-04 13:44:30 »

CPUs are designed by humans, by your logic, logic isn't OOP.

Demonstrative counter conclusion - it's not my opinion.

弾幕 ☆ @mahonnaiseblog
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.

rwatson462 (29 views)
2014-12-15 09:26:44

Mr.CodeIt (20 views)
2014-12-14 19:50:38

BurntPizza (40 views)
2014-12-09 22:41:13

BurntPizza (76 views)
2014-12-08 04:46:31

JscottyBieshaar (37 views)
2014-12-05 12:39:02

SHC (50 views)
2014-12-03 16:27:13

CopyableCougar4 (47 views)
2014-11-29 21:32:03

toopeicgaming1999 (114 views)
2014-11-26 15:22:04

toopeicgaming1999 (102 views)
2014-11-26 15:20:36

toopeicgaming1999 (30 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

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