Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (487)
Games in Android Showcase (112)
games submitted by our members
Games in WIP (553)
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  
  Yet another speed comparison,weird server results  (Read 6250 times)
0 Members and 1 Guest are viewing this topic.
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Posted 2004-06-21 17:48:29 »

On the previous thread about the article with those microbenchmarks comparing java with C++ somebody on that 'Comments' board posted some real code (a mandelbrot generator) which he converted from C to Java. On 1.4.2_04 client, it was about 8% slower.
I did a little change without altering the algo's in any way (I just made everything non static) and got to almost exactly the same performance as the C version.
Did another test on 1.5.0 beta 2 client and behold: the java version is even faster than the C version.

But: when I test on the server (both 1.4.2 and 1.5.0), the results are very disappointing. The server performs the test ~30% slower than the client!
As a matter of fact, I've seen this kind of bad performance of the server VM very often (for example in a program I wrote for a customer where huge text files are converted to even more huge XML documents).
This particular test runs 100 times (which means 100 times 15 seconds total), but performance doesn't get any better over time.

Anybody has an idea?

I know it's yet another benchmark, but the fact that I keep seeing the server VM perform so badly kind of worries me  :-/

Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #1 - Posted 2004-06-21 17:52:18 »

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  
public class JMandel {

      int[] rowBuffer_ = new int[500];
      int w_ = 500;
      int h_ = 500;
      int maxi_ = 9999;
      double ax_ = -2.0f;
      double ay_ = -1.5f;
      double ex_ = 1.0f;
      double ey_ = 1.5f;
      double sx_ = (ex_ - ax_) / ((double) w_);
      double sy_ = (ey_ - ay_) / ((double) h_);

      long msStart_;
      long msEnd_;
      long itersTotal_;

      private void run() {
            for (int i = 0; i < 100; i++) {
                  itersTotal_ = 0;
                  msStart_ = System.currentTimeMillis();
                  for (int y = 0; y < h_; y++) {
                        calcPixelRow(y, maxi_);
                  }
                  msEnd_ = System.currentTimeMillis();
                  printResults();
                  long msTotal = msEnd_ - msStart_;
                  double its = ((double) itersTotal_) / (double) msTotal;
                  System.out.println(
                        "Runtime ms=" + msTotal + " " + its / 1000.0 + " MegaIters per second");
            }
      }

      private void printResults() {
            for (int i = 0; i < rowBuffer_.length; i++) {
                  System.out.print(rowBuffer_[i]);
            }
      }

      private boolean calcPixelRow(int row, int maxi) { // C row calculation
                                                                               // routine // Calc vars
           // C row calculation routine
           // Calc vars
           double cx = ax_;
            double cy = ay_ + sy_ * ((double) row);
            double zx, zy;
            double zx2, zy2;

            for (int x = 0; x < w_; x++) {
                  // Calc Pixel
                 zx = cx;
                  zy = cy;
                  int i;
                  for (i = 0; i < maxi; i++) {
                        zx2 = zx * zx;
                        zy2 = zy * zy;
                        if ((zx2 + zy2) > 4)
                              break;
                        zy = 2 * zx * zy;
                        zx = zx2 - zy2;
                        zx += cx;
                        zy += cy;
                  }
                  cx += sx_;
                  itersTotal_ += i;
                  rowBuffer_[x] = i;
            }

            return true;
      }

      public static void main(String[] args) {
            JMandel jMandel = new JMandel();
            jMandel.run();
      }
}

Offline NVaidya

Junior Member




Java games rock!


« Reply #2 - Posted 2004-06-21 19:26:56 »

Some quick sample results...I haven't looked at the testcase in detail, but is msTotal value alone indicative of the speed diff. - lesser the better ? Hope I have these right !

server:
Runtime ms=6750 62.42653407407407 MegaIters per second

client:
Runtime ms=23500 17.93102574468085 MegaIters per second

Edit: ...on j2sdk1.4.2_03

Gravity Sucks !
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #3 - Posted 2004-06-21 20:47:38 »

Yeah, lesser is better.
I don't get it! Why am I not getting results like that?!  Shocked
I also tested on 1.4.2_03 and on 1.5.0 beta 2 but I'm getting far worse numbers on the server VM.  Cry

Offline NVaidya

Junior Member




Java games rock!


« Reply #4 - Posted 2004-06-21 20:59:16 »

I ran it on Windows - server's SSE2 possibly makes a difference here !?!

Gravity Sucks !
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #5 - Posted 2004-06-21 21:08:07 »

hmyeah, maybe. I run on an Athlon XP and those don't have SSE2 do they?
Still not sure why the server would be slower than the client though.

Could you do a re-run with the following:
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  
public class JMandel {

      int[] rowBuffer_ = new int[500];
      int w_ = 500;
      int h_ = 500;
      int maxi_ = 9999;
      double ax_ = -2.0f;
      double ay_ = -1.5f;
      double ex_ = 1.0f;
      double ey_ = 1.5f;
      double sx_ = (ex_ - ax_) / ((double) w_);
      double sy_ = (ey_ - ay_) / ((double) h_);

      long msStart_;
      long msEnd_;
      long itersTotal_;
      long rendertime;

      private void run() {
            for (int i = 0; i < 100; i++) {
                  itersTotal_ = 0;
                  rendertime = 0;
                  msStart_ = System.currentTimeMillis();
                  for (int y = 0; y < h_; y++) {
                        calcPixelRow(y, maxi_);
                        rendertime += printResults();
                  }
                  msEnd_ = System.currentTimeMillis() - rendertime;
                  long msTotal = msEnd_ - msStart_;
                  double its = ((double) itersTotal_) / (double) msTotal;
                  System.out.println(
                        "\n\nRuntime ms=" + msTotal + " " + its / 1000.0 + " MegaIters per second");
            }
      }

      private long printResults() {
            long start = System.currentTimeMillis();
            for (int i = 0; i < rowBuffer_.length; i++) {
                  System.out.print(rowBuffer_[i]);
            }
            return System.currentTimeMillis() - start;
      }

      private boolean calcPixelRow(int row, int maxi) { // C row calculation
                                                                               // routine // Calc vars
           // C row calculation routine
           // Calc vars
           double cx = ax_;
            double cy = ay_ + sy_ * ((double) row);
            double zx, zy;
            double zx2, zy2;

            for (int x = 0; x < w_; x++) {
                  // Calc Pixel
                 zx = cx;
                  zy = cy;
                  int i;
                  for (i = 0; i < maxi; i++) {
                        zx2 = zx * zx;
                        zy2 = zy * zy;
                        if ((zx2 + zy2) > 4)
                              break;
                        zy = 2 * zx * zy;
                        zx = zx2 - zy2;
                        zx += cx;
                        zy += cy;
                  }
                  cx += sx_;
                  itersTotal_ += i;
                  rowBuffer_[x] = i;
            }

            return true;
      }

      public static void main(String[] args) {
            JMandel jMandel = new JMandel();
            jMandel.run();
      }
}


It prints all output, just to make sure and the time to do it is subtracted from the final time.
It ouputs a lot, so I suggest redirecting the output to a file like java -server JMandel > mandel.log

Offline NVaidya

Junior Member




Java games rock!


« Reply #6 - Posted 2004-06-21 21:56:13 »

I think my cygwin+bash+vim didn't like the output format from the program. OK ! didn't actually run thru' the entire loop of 100, but here are the first several (system I'm using here is P4 1.6GHz):

client:
Runtime ms=44652 9.43695926274299 MegaIters per second
Runtime ms=44897 9.38546239169655 MegaIters per second
Runtime ms=45103 9.342595947054521 MegaIters per second
Runtime ms=45086 9.346118639932573 MegaIters per second
Runtime ms=36438 11.564276442175752 MegaIters per second
Runtime ms=44075 9.560501531480432 MegaIters per second
Runtime ms=43911 9.596208353260003 MegaIters per second
Runtime ms=44377 9.49543919147306 MegaIters per second
Runtime ms=42126 10.002827351279494 MegaIters per second
Runtime ms=32172 13.097696910356833 MegaIters per second
Runtime ms=27847 15.1319389880418 MegaIters per second
Runtime ms=32283 13.052662546851284 MegaIters per second
Runtime ms=23225 18.143341442411195 MegaIters per second
Runtime ms=44006 9.575492091987456 MegaIters per second
Runtime ms=46699 9.023300391871345 MegaIters per second

server:
Runtime ms=13246 31.811800166087878 MegaIters per second
Runtime ms=13342 31.582903987408187 MegaIters per second
Runtime ms=13438 31.35727824080964 MegaIters per second
Runtime ms=13543 31.114162667060473 MegaIters per second
Runtime ms=13736 30.67698784216657 MegaIters per second
Runtime ms=13335 31.599482939632548 MegaIters per second
Runtime ms=13485 31.24798702261772 MegaIters per second
Runtime ms=13437 31.359611892535536 MegaIters per second
Runtime ms=13631 30.91329359548089 MegaIters per second
Runtime ms=13410 31.422752050708425 MegaIters per second
Runtime ms=12652 33.30533552007587 MegaIters per second

Edit: erikd: The above results are for version 2 of JMandel.java

Gravity Sucks !
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #7 - Posted 2004-06-21 22:12:09 »

Just tried the first verision on Windows JRE 1.5 beta2

Client  = 9 MegaIters
Server = 31 MegaIters

Can't explain why you aren't gettign better performance on the Server VM.  I'll try this on the Mac later just for kicks.

Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #8 - Posted 2004-06-22 06:01:24 »

Hmmm, on my laptop I also get good results on the server.
Seems like a bug in the server VM to me. Does anyone else use an Athlon and get similar results?

Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #9 - Posted 2004-06-22 06:43:05 »

So, compared to the original version, on my laptop the benchmark runs about as fast as the FPU ASM version and almost 3.5 times as fast as the pure C version. Quite amazing, really.
The asm versions that use SSE instructions still beat the crap out of the java version, but still the results are far better than I expected.

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

Junior Member




... Boing ...


« Reply #10 - Posted 2004-06-22 08:24:07 »

Heavy float usage often stuffs many 'cheap' C compilers (VC6, GCC), the Intel & Visual Studio.net do a much better job, but even so they don't usually do this:

Quote

To see it more clearly, I did break into the JIT code with a debugger and saw that the JIT:

1) Arranged a 4x loop unroll. 2) Is using SSE2 code. 3) The machine code is pretty nice for a JIT. Nice work indeed.

Now, that''s why the C code is slower: the C compiler is actually using default FPU (x87) code, so that.. the comparison is not fair Wink

Of course this scores a point in favour of the JIT. The JIT can produce a code optimized depending on the actual CPU running the program, while a static compiler cannot know in advance the target platform (otherwise the static code will run ONLY on the target platform).


Nice! I wish the people who make the JITs would be more open about what the JIT can do - this sort of info would help convince developers (hey, get your free SSE2 optimisations over here!).

- Dom
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #11 - Posted 2004-06-22 10:05:35 »

Now I want 3DNow! support too to help us poor AthlonXP owners Cheesy

I think I'm going to report a performance bug regarding the worse than client performance of the server VM running on an Athlon and see what happens.

Offline Bombadil

Senior Member





« Reply #12 - Posted 2004-06-22 11:41:03 »

Quote
Now I want 3DNow! support too to help us poor AthlonXP owners :D

I think I'm going to report a performance bug regarding the worse than client performance of the server VM running on an Athlon and see what happens.


Yes.

Your Mandelbrot on an AMD Athlon XP2500+ Barton :
java version "1.4.2_04"
Client : Runtime ms=10696  39.40 MegaIters per second
Server: Runtime ms=15121  27.87 MegaIters per second

Sigh, indeed currently SUNs server VM doesn't use Athlons in the right way. :-(  Please fill a bug report.

P.S. Just some weeks ago the IT-press reported that for the first time AMD sells as many AMD desktop CPUs than Intel. Another reason for Java to use Athlons in the right way.
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #13 - Posted 2004-06-22 11:45:45 »

It's done. I'll keep you guys updated.

Offline arm

Senior Newbie




Java games rock!


« Reply #14 - Posted 2004-06-22 13:41:08 »

Results of running JMandel on Windows XP

>> pentium II 400 Mhz <<
  512 MB ram

 Java HotSpot(TM) Server VM (build 1.5.0-beta2-b51, mixed mode)

     Runtime ms=57152 7.372954664753639 MegaIters per second  Shocked
     Runtime ms=57152 7.372954664753639 MegaIters per second  Shocked
     Runtime ms=56832 7.414469049127252 MegaIters per second  Shocked

 Java HotSpot(TM) Client VM (build 1.5.0-beta2-b51, mixed mode, sharing)

     Runtime ms=34910 12.070441277570897 MegaIters per second
         Runtime ms=34910 12.070441277570897 MegaIters per second

 J2RE 1.4.1 IBM Windows 32 build cn1411-20040301a (JIT enabled)

     Runtime ms=22893 18.406460708513517 MegaIters per second  Smiley
     Runtime ms=22863 18.430612999168964 MegaIters per second  Smiley

 C++ version of JMandel compiled with g++:

     Runtime ms =22692 18.531 MegaIters per second
     Runtime ms =22753 18.481 MegaIters per second
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #15 - Posted 2004-06-23 06:57:23 »

Hmm, now it seems the very bad server VM performance is not Athlon specific, but affects any CPU not supporting SSE2, so the problem is far more serious than I thought. It seems now that currently the server VM performs far worse than the client on most systems! Well, in this particular case that is.

I'm wondering what happens with the performance difference between the client and server (on non-sse2 CPUs) if the test is converted to float instead double precision.

Offline Mark Thornton

Senior Member





« Reply #16 - Posted 2004-06-23 07:14:56 »

Quote
if the test is converted to float instead double precision.
Ok this is just being used as a test, but the Mandelbrot is a case where precision makes a significant difference to the result.
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #17 - Posted 2004-06-23 08:28:36 »

Of course but I'm not trying to alter the test in order to make it quicker.
When we use float instead of double we're not comparing to the double precision version of the original program anymore, but we should compare to the SSE version of the original (but only when we're running the test on an SSE supporting CPU).
But my reason for converting to float is that I want to see what happens to the server performance compared to the client, so we can maybe narrow down the cause of the problem.
If when using floats the server has acceptable performance compared to the client (on an AthlonXP) than I can conclude that there is probably a bug regarding SSE2 optimizations (in case those are not possible).
If not, the problem lies elsewhere and we can begin to doubt the usability of the server VM in its current state on possibly even the majority of x86 platforms... :-/
Which I am currently anyway, given my own personal (generally bad) experiences with the server VM on my Athlon.
I'll do the test when I get home.

Offline ChrisRijk

Senior Newbie




Optimise or Die


« Reply #18 - Posted 2004-06-23 11:01:33 »

I have a Mandelbrot program hanging around, which I've tested a bit too.

The inner loop is pretty much identical (actually I changed it to be identical to yours) except I'm using floats here.

On my Athlon XP, 1.4.2_04 server is twice as fast as 1.4.2_04 client. 1.5.0-b2 client is slightly slower than 1.4.2 client.

Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #19 - Posted 2004-06-23 19:44:33 »

Quote
On my Athlon XP, 1.4.2_04 server is twice as fast as 1.4.2_04 client. 1.5.0-b2 client is slightly slower than 1.4.2 client.



Be sure to report performance regressions!  Specially since you have a nice simple test case.  Catch it now while 1.5 is still beta.

What about 1.5 server??

Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #20 - Posted 2004-06-23 20:39:06 »

On my (athlon) machine:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
 * 1.5.0 beta 2:
 * Runtime ms=9372 44.9614922108408 MegaIters per second       (client, double)
 * Runtime ms=13844 30.43767010979486 MegaIters per second       (server, double)
 * Runtime ms=9531 44.20146875 MegaIters per second             (client, float)
 * Runtime ms=3470 121.407546875 MegaIters per second       (server, float)
 *
 * 1.4.2_03
 * Runtime ms=9815 42.9321553744269 MegaIters per second      (client, double)
 * Runtime ms=13752 30.641296175101804 MegaIters per second (server, double)
 * Runtime ms=10154 41.48948046875 MegaIters per second            (client, float)
 * Runtime ms=3608 116.7639140625 MegaIters per second            (server, float)


So 1.5.0 beta 2 seems to be as fast as, or a fraction faster than 1.4.2_03. The server's float performance seems good.
It's interesting to see that on the client, performance with double precision is not lower than floats.

Offline princec

JGO Kernel


Medals: 366
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #21 - Posted 2004-06-24 07:41:46 »

Bodes well for games programming doesn't it Smiley And very poorly for Java3D with its heavy reliance on doubles...

Cas Smiley

Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #22 - Posted 2004-06-24 11:35:43 »

Quote
Bodes well for games programming doesn't it Smiley And very poorly for Java3D with its heavy reliance on doubles...

Cas Smiley


On an Athlon, yeah. But on a P4, Java3D should perform excellent since doubles on the server are even faster than floats.

EDIT: correction, not faster than float, but the diff between server and client is larger when dealing with doubles.

Offline NVaidya

Junior Member




Java games rock!


« Reply #23 - Posted 2004-06-24 14:02:30 »

Quote


On an Athlon, yeah. But on a P4, Java3D should perform excellent since doubles on the server are even faster than floats.

EDIT: correction, not faster than float, but the diff between server and client is larger when dealing with doubles.


IIRC, there was a (regression) bug associated with proper alignment of doubles. Maybe this never got fixed on server (assuming, of course, that this is not a prerequisite for SSE2 which does appear to work).

Gravity Sucks !
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #24 - Posted 2004-06-24 15:45:36 »

Just a minor question...why do you have:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
for (i = 0; i < maxi; i++) {
    zx2 = zx * zx;
    zy2 = zy * zy;
    if ((zx2 + zy2) > 4)
     break;
    zy = 2 * zx * zy;
    zx = zx2 - zy2;
    zx += cx;
    zy += cy;
   }


instead of:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
for (i = 0; i < maxi; i++) {
    zx2minuszy2 = (zx + zy) * (zx - zy);
    if ((zx2minuszy2) > 4)
     break;
    zy = 2 * zx * zy;
   
    zx = zx2minuszy2;
    zx += cx;
    zy += cy;
   }


you have 4 muls and 2 adds instead of 3 muls and 2 adds...? Just going off the top of my head from when I did a fast 3D rotating mand 6 years ago, so I'm probably making some silly mistake here Sad.

IIRC, back then reducing by one the number of FP muls was noticeable (this would have been on 1.1.x JVM's)

malloc will be first against the wall when the revolution comes...
Offline Mark Thornton

Senior Member





« Reply #25 - Posted 2004-06-24 17:16:47 »

The comparison is of x*x + y*y.

However if we actually wanted x*x - y*y, then the obvious computation may actually be faster because the two multiplications can start one clock cycle apart, and when they are finished (some) 20 clock cycles later all that remains is the subtraction. By contrast in the alternative expression (x+y)*(x-y) the multiplication can't start until after both addition and subtraction have completed. The total time taken will then be very similar. A more important consideration today may be the accuracy of the result.
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #26 - Posted 2004-06-24 20:17:08 »

Quote
Just a minor question...why do you have:


It's not my program. It's a java port of a fun little program called 'FFFF' (you can find it on sourceforge), ported from the original C source by the original author just to compare java's performance to the C version. I just changed it a little bit to make it not fully static. I didn't even look at the algorithm (apart from comparing it with the original sources).
I figured if I would try to optimize the algorithm, the benchmark would become invalid.

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #27 - Posted 2004-06-24 21:50:01 »

Quote
The comparison is of x*x + y*y.


...but mandelbrot is |(a+bj)| <=2, no? In which case, that's (a2-b2) + (2ab)j <= 4? I just remember that a diff of squares was in there somewhere Wink...

Quote

However if we actually wanted x*x - y*y, then the obvious computation may actually be faster because the two multiplications can start one clock cycle apart, and when they are finished (some) 20 clock cycles later all that remains is the subtraction.


Thanks. As I said, IIRC it used to have a significant effect (presumably not-very-good JITing); I see what you mean with pipelining. Might this change have a significant effect on the abscence/presence of sse/3dnow optimizations?

malloc will be first against the wall when the revolution comes...
Offline Mark Thornton

Senior Member





« Reply #28 - Posted 2004-06-25 06:24:00 »

Quote

...but mandelbrot is |(a+bj)| <=2, no? In which case, that's (a2-b2) + (2ab)j <= 4? I just remember that a diff of squares was in there somewhere Wink...
You want a benchmark that actually computes the correct value!  Wink

Pipelines and superscalar execution certainly make estimating performance difficult. They ought to make use of a JIT very attractive if one wants optimal performance out of Pentium III, 4, Athlon XP, Athlon 64, Via Eden, Transmeta (Crusoe, Efficieon), etc.
Offline princec

JGO Kernel


Medals: 366
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #29 - Posted 2004-06-25 07:44:23 »

If only the VMs actually did JITing based on the processor. As it is it seems that it's SSE2 or nothing.

Cas Smiley

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.

TehJavaDev (16 views)
2014-08-28 18:26:30

CopyableCougar4 (25 views)
2014-08-22 19:31:30

atombrot (38 views)
2014-08-19 09:29:53

Tekkerue (34 views)
2014-08-16 06:45:27

Tekkerue (32 views)
2014-08-16 06:22:17

Tekkerue (20 views)
2014-08-16 06:20:21

Tekkerue (30 views)
2014-08-16 06:12:11

Rayexar (66 views)
2014-08-11 02:49:23

BurntPizza (44 views)
2014-08-09 21:09:32

BurntPizza (34 views)
2014-08-08 02:01:56
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!