Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (481)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (548)
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  
  64x64 limit problem  (Read 4613 times)
0 Members and 1 Guest are viewing this topic.
Offline sally

Junior Member





« Posted 2004-07-16 06:21:56 »

On page 371 of the red "OpenGL Programming Guide" (para 2) it states: "The maximum size of a texture map depends on the implementation of OpenGL, but it must be at least 64 x 64 (or 66 x 66 with borders). Does this mean that I will have problems rendering my 8 x 16 pixel png rectangles images as textured quads?

Have done some initial testing using textured quads and the speed is (as I'd hoped) much faster than gldrawpixels, but am unable to display the images at their original size or at a coordinate point that I can understand (yet).   It's all good fun though. Wink

Any help appreciated.

Regards,

Sally
Offline tom
« Reply #1 - Posted 2004-07-16 08:34:32 »

You can have as smal (pow2) textures as you want. So 8x16 is ok. What the line says is that you can be sure that opengl supports 64x64, and smaler, textures. If you need larger textures, you'll need to check if they are supported. Most cards support 4096x4096 nowdays.

Offline nnevatie

Junior Member




It is slightly better to be simple than correct.


« Reply #2 - Posted 2004-07-16 09:10:53 »

Quote

Any help appreciated.


Hi! I prepared a very simple tile demo for JOGL. It basicaly benchmarks two different methods of rendering textured quads to screen (immediate mode vs. display lists). The demo simply loads one tile (.png) and draws it to screen multiple times. You can find the pre-compiled binary and source at:

http://www.g0dmode.com/javastuff/jogl-tiledemo.zip

ps. On my Amilo laptop with Radeon 9600 Mobility card, the demo renders ~600000 16x16 tiles per second. Interestingly enough, the display list method is a bit slower (about 500000 tiles / s) - this is definitely due to the small size of used list (just one textured quad).

Cheers

Awards:
- Nobel Prize in Physics for inventing his Doomsday Machine
- Nobel Peace Prize for not using it

http://www.g0dmode.com -- a collection of things not real
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline atze

Senior Newbie




It's just me.


« Reply #3 - Posted 2004-07-16 09:33:10 »

um...

Exception in thread "main" java.lang.Error: Do not use javax.swing.JFrame.add() use javax.swing.JFrame.getContentPane().add() instead
       at javax.swing.JFrame.createRootPaneException(JFrame.java:465)
       at javax.swing.JFrame.addImpl(JFrame.java:491)
       at java.awt.Container.add(Container.java:307)
       at TileDemo.execute(TileDemo.java:37)
       at TileDemo.main(TileDemo.java:22)
Offline nnevatie

Junior Member




It is slightly better to be simple than correct.


« Reply #4 - Posted 2004-07-16 10:08:25 »

Doh. Worked for me (of course if should not have  Shocked) I've updated the zip.

Modified: Ahah! It was my 1.5.0-beta2 JVM that had a more laid-back attitude towards adding stuff directly to JFrame Wink.

Awards:
- Nobel Prize in Physics for inventing his Doomsday Machine
- Nobel Peace Prize for not using it

http://www.g0dmode.com -- a collection of things not real
Offline atze

Senior Newbie




It's just me.


« Reply #5 - Posted 2004-07-16 10:48:51 »

power mac g4, 1ghz (values change with every run a bit):
1  
2  
3  
4  
5  
6  
7  
      public void renderMethod2(int x, int y, GL gl)
      {
            MATRIX_TRANSLATION[12] = x;
            MATRIX_TRANSLATION[13] = y;
            gl.glLoadMatrixf(MATRIX_TRANSLATION);
            gl.glCallList(displayListHandle);
      }

1000000 tiles rendered with method1(immediate) in 6003ms, which makes 166000 tiles/s
1000000 tiles rendered with method2(display lists) in 6853ms, which makes 145000 tiles/s

instead of using a full matrix, let's just translate:
1  
2  
3  
4  
5  
6  
7  
      public void renderMethod2(int x, int y, GL gl)
      {
            gl.glPushMatrix();
            gl.glTranslated(x, y, 0);
            gl.glCallList(displayListHandle);
            gl.glPopMatrix();
      }

1000000 tiles rendered with method1(immediate) in 6081ms, which makes 164000 tiles/s
1000000 tiles rendered with method2(display lists) in 6393ms, which makes 156000 tiles/s

and now, let's assume we're at the right position already (which is - in most cases - pretty useless) Smiley
1  
2  
3  
4  
      public void renderMethod2(int x, int y, GL gl)
      {
            gl.glCallList(displayListHandle);
      }

1000000 tiles rendered with method1(immediate) in 6131ms, which makes 163000 tiles/s
1000000 tiles rendered with method2(display lists) in 3846ms, which makes 260000 tiles/s

what a slow video-card i have...

and apple states:
for a list use a minumum of 16 verticies, less slows you down
Offline nnevatie

Junior Member




It is slightly better to be simple than correct.


« Reply #6 - Posted 2004-07-16 10:54:14 »

Quote

and apple states:
for a list use a minumum of 16 verticies, less slows you down


Apple knows its OpenGL Smiley.

Awards:
- Nobel Prize in Physics for inventing his Doomsday Machine
- Nobel Peace Prize for not using it

http://www.g0dmode.com -- a collection of things not real
Offline sally

Junior Member





« Reply #7 - Posted 2004-07-19 07:11:37 »

Thank you very much for that demo.  That was very useful indeed.

I only got 11000/s in both modes though which seems very slow compared to yours figures :-/

Am using a Matrox G450 card, Red Hat Linux 7.2, 512 Megs Ram and a 1 Gig processor.  

Thanks again for the demo.

Regards,

Sally
Offline turquoise3232

Junior Member




Java (games) rock!


« Reply #8 - Posted 2004-07-19 09:38:42 »

For having worked (or tried to work) with a G450, I think that you have good figures for this very nice card  Cheesy
Offline sally

Junior Member





« Reply #9 - Posted 2004-07-20 13:09:01 »

Have tried using your 3 classes, Tile, Texture and TextureIO.  My 8x16 png images render at roughly 17000 tiles per second (both modes) and it is simple to position the images at their correct size and at any location on the glcanvas.  Thank you for that.   Kiss

But using my original gldrawpixels method I am getting about 34500 images per second (over twice as fast as the textured quad methods) - this is still too slow - that's why I attempted writing textured quads in the first place(hoping to speed up my application). Cry

My original testing of textured quads (a day or so before I got your code), I appeared to be getting about 175000 tiles per second (blindingly fast for what I want) but did not know how to control the size or location. Tongue

The code which gave me a wonderful 175000 tiles per second is below.  The figures are all arbitary and were just a way of getting the quads to come out within a loop.

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
gl.glBegin(GL.GL_QUADS);
for (int i = 0; i< 7000; i++)  // send it round in large loop
{
   gl.glTextCood2f(0.0f, 0.0f); gl.glVertex2f(x+(5*i),
      x + (5* i));
   gl.glTextCood2f(1.0f, 0.0f); gl.glVertex2f(x+(5*i),
      x + (5* i));
   gl.glTextCood2f(1.0f, 1.0f); gl.glVertex2f(x+(5*i),
      x + (5* i));
   gl.glTextCood2f(0.0f, 1.0f); gl.glVertex2f(x+(5*i),
      x + (5* i));
}

}


Any ideas ?

Regards,

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

Senior Member





« Reply #10 - Posted 2004-07-20 13:45:28 »

Why not use batch commands ? Put quads into big array and draw it at once. Currently you are testing performance of JNI binding/opengl driver, not that of the GPU itself.

Artur Biesiadowski
Offline nnevatie

Junior Member




It is slightly better to be simple than correct.


« Reply #11 - Posted 2004-07-20 14:06:15 »

Quote
Why not use batch commands ? Put quads into big array and draw it at once. Currently you are testing performance of JNI binding/opengl driver, not that of the GPU itself.


Yes, I'm aware of that. The original point was to test fast blitting of "tiles" to arbitrary locations on screen. So, no simple batching can be applied (display lists, VBO, etc).

Edit: sally, what kind of use cases you're facing? Arbitrary blitting or somekind of grid scheme?

Awards:
- Nobel Prize in Physics for inventing his Doomsday Machine
- Nobel Peace Prize for not using it

http://www.g0dmode.com -- a collection of things not real
Offline sally

Junior Member





« Reply #12 - Posted 2004-07-20 15:01:13 »

It's more like a grid display, I guess.  All I'm trying to do at the moment is draw 8x16 rectangles just like your demo.  I use 2 seperate tiles (from 2 png files of the same size), (tileone and tiletwo). Supposing I had 40 rows of these images and 70 columns, I would have 2800 images on my glcanvas (some of them would be tileone and some tiletwo).  When the user presses a . key, the whole screen is redrawn and where some grid areas were tileone, they now become tiletwo and visa versa.  When the user keeps his/her finger on the . key, the canvas should change constantly and at a reasonable rate (it's an analysys tool and the user's eye is looking for raster patterns) and whilst the program does work correctly, the changing of the display is slow and jerky with the techniques I have tried so far.  If I could only get this to work at a decent rate I would be a very, very happy lady. Roll Eyes

I am really very new to graphics programming and opengl etc although I have done a fair bit of Java programming (mainly for fun and learning) when I was at school.

Thanks for your help.

Sally



Offline sally

Junior Member





« Reply #13 - Posted 2004-07-20 15:26:34 »

Quote
Why not use batch commands ? Put quads into big array and draw it at once. Currently you are testing performance of JNI binding/opengl driver, not that of the GPU itself.



Yes, I understand what you mean.  I shall give that a whirl.

Thanks

Sally
Offline tom
« Reply #14 - Posted 2004-07-20 15:48:32 »

sally, are you doing anything else per tile. Possibly binding the texture? It will slow you down. Instead bind texture1, then draw all tiles using texture1. Bind texture2 and draw all tiles using texture2, etc.


Offline nnevatie

Junior Member




It is slightly better to be simple than correct.


« Reply #15 - Posted 2004-07-20 20:16:14 »

Quote
When the user keeps his/her finger on the . key, the canvas should change constantly and at a reasonable rate (it's an analysys tool and the user's eye is looking for raster patterns) and whilst the program does work correctly, the changing of the display is slow and jerky with the techniques I have tried so far.


Ok, roughly, what kind of  frame rates are you after? Even the most unoptimal way of drawing the tiles(showcased in the demo) would result in ~4 frames/s for your setup (11000 / 2800). I think this figure could be quite easily raised to 10 or 20 fps. Are the tiles changed arbitrarily or are there somekind of patterns or rules in the process? Also, what kind of scheme are using for the keyboard input?

Cheers

Awards:
- Nobel Prize in Physics for inventing his Doomsday Machine
- Nobel Peace Prize for not using it

http://www.g0dmode.com -- a collection of things not real
Offline nnevatie

Junior Member




It is slightly better to be simple than correct.


« Reply #16 - Posted 2004-07-20 23:54:26 »

I've updated the demo to include a simple example (run with tiledemo2.cmd) of using vertex arrays to achieve better fillrate. There's a new class called TileGrid which is a grid based representation of tiles. The grid can be modified dynamically - i.e. the tile images can be changed at each grid location separately.

PS. On my Amilo P4-HT 2.6GHz, ATI Radeon 9600 Mobility the following is printed out:

"10000 20x20 tile grids rendered in 1313ms, which makes 7000 grids/s and 2800000 tiles/s"

Awards:
- Nobel Prize in Physics for inventing his Doomsday Machine
- Nobel Peace Prize for not using it

http://www.g0dmode.com -- a collection of things not real
Offline sally

Junior Member





« Reply #17 - Posted 2004-07-21 11:14:02 »

Quote


Ok, roughly, what kind of  frame rates are you after? Even the most unoptimal way of drawing the tiles(showcased in the demo) would result in ~4 frames/s for your setup (11000 / 2800). I think this figure could be quite easily raised to 10 or 20 fps. Are the tiles changed arbitrarily or are there somekind of patterns or rules in the process? Also, what kind of scheme are using for the keyboard input?

Cheers


I think I would be happy with 20fps, but 30 would be better. To give you a bit more detail about what I'm doing: the program is a bit analyser.  The data (1s and 0s represented by the 2 tiles) are read in and stored in an array.  If the user sets a rasterwidth of 70 then the 1s and 0s in the array would be displayed wrapping around over 70 columns.  So when the user presses the . key (also the > key on a qwerty keyboard) the rasterwidth would increase by 1 making all the bits wrap around 71 columns.  If the user presses the , (or < key) the rasterwidth would decrease by 1 giving 70 again.  Each time the appropriate key is pressed all the tiles are re-read in from the array and appear to be shuffled around on the canvas.  If the user kept their hand on , key, for instance the rasterwidth should slikly move down to 1 column (going through each rasterwidth from 70 - 1 on the way of course).  Interesting patterns can be spotted by the human eye over various widths which give frame lenghts of some types of data.  

For my keyboard input I have just used an awt.Event KeyListener.

Regards,

Sally
Offline sally

Junior Member





« Reply #18 - Posted 2004-07-22 07:04:18 »

Quote
I've updated the demo to include a simple example (run with tiledemo2.cmd) of using vertex arrays to achieve better fillrate. There's a new class called TileGrid which is a grid based representation of tiles. The grid can be modified dynamically - i.e. the tile images can be changed at each grid location separately.

PS. On my Amilo P4-HT 2.6GHz, ATI Radeon 9600 Mobility the following is printed out:

"10000 20x20 tile grids rendered in 1313ms, which makes 7000 grids/s and 2800000 tiles/s"


Thanks for the new demo.  Although my results were far from impressive on my 1Ghz Intel Pentium III, Matrox G450 - the program stood still for about 10 minutes before giving:

10000 20x20 tile grids rendered in 325425ms, which makes 0 grids/s and 0 tiles/s
10000 20x20 tile grids rendered in 325325, which makes 0 grids/s and 0 tiles/s

Do these results mean I'm not going to get my 20fps? :-/

Regards,

Sally
Offline nnevatie

Junior Member




It is slightly better to be simple than correct.


« Reply #19 - Posted 2004-07-22 07:34:21 »

Quote

10000 20x20 tile grids rendered in 325425ms, which makes 0 grids/s and 0 tiles/s
10000 20x20 tile grids rendered in 325325, which makes 0 grids/s and 0 tiles/s

Do these results mean I'm not going to get my 20fps? :-/

Regards,

Sally



Hmmm, it seems that the vertex arrays are really ineffective on your board. That's no surprise really, because the arrays are transferred to the GPU from Java heap each time they are drawn. I'm actually working on a VBO version of the demo (this is the last one, I promise Wink ), which should perform quite nicely on board with VBO capabilities. I'll post it here later on today...

Awards:
- Nobel Prize in Physics for inventing his Doomsday Machine
- Nobel Peace Prize for not using it

http://www.g0dmode.com -- a collection of things not real
Offline nnevatie

Junior Member




It is slightly better to be simple than correct.


« Reply #20 - Posted 2004-07-22 09:14:19 »

Ok, I've uploaded the VBO (vertex buffer object) version of the demo. Run the tiledemo3.cmd to see it in action. I had to change the demo structure a little to overcome some odd timing problems..

Well, anyways the tiledemo3 shows an FPS counter in the caption of the window instead of a printout in the console.

This demo requires the GL_ARB_vertex_buffer_object extension to work.

I'm experiencing 800-900 FPS with grid size of 40x40 and 1 tile modification per frame. With 100x100 grid the FPS drops to around 500 or 600. Basically this method of drawing/modifying the grid should be the ultimate one, although the code is optimized for clarity Smiley.

This has been a fun experiment, since I'm trying to learn some more advanced OpenGL too. Hope it works for you.

Cheers

Awards:
- Nobel Prize in Physics for inventing his Doomsday Machine
- Nobel Peace Prize for not using it

http://www.g0dmode.com -- a collection of things not real
Offline tom
« Reply #21 - Posted 2004-07-22 15:38:08 »

Quote
Hmmm, it seems that the vertex arrays are really ineffective on your board. That's no surprise really, because the arrays are transferred to the GPU from Java heap each time they are drawn. I'm actually working on a VBO version of the demo (this is the last one, I promise  ), which should perform quite nicely on board with VBO capabilities. I'll post it here later on today...

I would say the drivers are broken. If it can't even do vertex arrays, then it won't do VBOs either. Try changing the drivers, or better yet, buy another gfx card Wink

There are still things you can do to improve performance using immediate mode.
1) Do you need textures? If the rectangles are single colored, then you can use vertex colors instead. Or generate a texture that is uploaded once per frame and drawn with one quad that covers the screen.
2) Use Triangle strips or quad strips.
3) Generate one big texture that contains one of the sprites tiled across it. The texture is drawn first using one quad covering the screen. Then you draw sprite nr 2 where it is needed. Basicly swapping gl calls for overdraw.

Offline sally

Junior Member





« Reply #22 - Posted 2004-07-23 08:03:09 »

Thanks for that info.

You were right ... the VBO extension isin't available.

I'm a bit confused ... I am using Red Hat Linux 7.2 and a Matrox G450 which the documentation sais does have OpenGL support, however my installastion is about 3 years old.  Do you think it would just be a question of downloading the latest Matrox G450 drivers for Linux or does it mean that my physical card would never support VBOs under Linux?

Thanks

Sally

Offline turquoise3232

Junior Member




Java (games) rock!


« Reply #23 - Posted 2004-07-23 11:17:42 »

Quote


I'm a bit confused ... I am using Red Hat Linux 7.2 and a Matrox G450 which the documentation sais does have OpenGL support, however my installastion is about 3 years old.  Do you think it would just be a question of downloading the latest Matrox G450 drivers for Linux or does it mean that my physical card would never support VBOs under Linux?


Hi,
For sure your G450 will never support VBO's and don't even try to search new drivers, this card is really dead now! (In fact it was already 2 years ago, when we try to get support from Matrox...)  :-/
Offline sally

Junior Member





« Reply #24 - Posted 2004-07-23 12:48:38 »

Thanks for that info.  It's best to know these things in advance.

Just to compond my misery Sad I just tired to run the tiles demo on a friend's machine (Red Hat Linux 8 os) which uses an Nvidia geforce 4 card.  The frame came up but I received the following (none of it makes much sense to me).   So presumably the Nvidia geforce 4 is not very compliant either Huh

Any clues Huh

Regards,

Sal

java.awt.AWTException: cannot open XIM
       at sun.awt.motif.X11InputMethod.<init>(X11InputMethod.java:147)
       at sun.awt.motif.X11InputMethodDescriptor.createInputMethod(X11InputMethodDescriptor.java:76)
       at sun.awt.im.InputContext.getInputMethodInstance(InputContext.java:734)
       at sun.awt.im.InputContext.getInputMethod(InputContext.java:684)
       at sun.awt.im.InputContext.dispatchEvent(InputContext.java:210)
       at sun.awt.im.InputMethodContext.dispatchEvent(InputMethodContext.java:180)
       at java.awt.Component.dispatchEventImpl(Component.java:3476)
       at java.awt.Container.dispatchEventImpl(Container.java:1437)
       at java.awt.Window.dispatchEventImpl(Window.java:1566)
       at java.awt.Component.dispatchEvent(Component.java:3367)
       at java.awt.EventQueue.dispatchEvent(EventQueue.java:445)
       at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:190)
       at java.awt.EventDispatchThread.pumpEventsForHierarchy
Offline nnevatie

Junior Member




It is slightly better to be simple than correct.


« Reply #25 - Posted 2004-07-23 13:45:02 »

"
XIM (= X Input Method) is a generic API to build applictions which have support for international input.

All applications which have support for the XIM-protocol build in, can be used to input Japanese, Chinese and Korean.

Many X11 applications already support XIM, for example:


most KDE 2 and most Gnome applications
Browsers like Mozilla, Netscape, Konqueror
Editors like Emacs, XEmacs, gvim
terminals like mlterm, kterm, and rxvt
Java applications
"

Awards:
- Nobel Prize in Physics for inventing his Doomsday Machine
- Nobel Peace Prize for not using it

http://www.g0dmode.com -- a collection of things not real
Offline sally

Junior Member





« Reply #26 - Posted 2004-07-23 14:24:30 »

Interesting. Smiley  I wonder why the error did not comp up when I ran the JOGLBasics demo though (from the "Jumping into JOGL" page) on the Geforce 4 card.  Why would it only be  Vertex Arrays that cause the error and only on this machine?  To say: "I'm confused" would be the biggest understatement of the decade  Grin

Either way ... it seems I cannot use either my Matrox G450 card or my friend's Nvidia Geforce 4 card to have any success with my application.  

I think I'll try using Motif Tongue

Thank you to everybody who has taken the trouble to reply though. Smiley

Regards,

Sally

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #27 - Posted 2004-07-23 14:31:15 »

Quote


Hi,
For sure your G450 will never support VBO's and don't even try to search new drivers, this card is really dead now! (In fact it was already 2 years ago, when we try to get support from Matrox...)  :-/


That's a foolish thing to say -  especially since there are drivers on the Matrox.com website dated 2004 (windows only) and 2003 (linux).

Quote

Millennium G450
5.92.006
19feb04

BETA 3.0
21jul03

Microsoft Windows XP 64-Bit Edition driver for AMD-64 platforms
(13jan04)



EDIT: (snipped some irrevelvant bits above) + here's the URL for downloading matrox G450 drivers:

http://www.matrox.com/mga/support/drivers/latest/home.cfm

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

Junior Member





« Reply #28 - Posted 2004-07-24 07:13:03 »

Quote


There are still things you can do to improve performance using immediate mode.
1) Do you need textures? If the rectangles are single colored, then you can use vertex colors instead.


I'd rather use images or textures but hey ... when you're desperate I'll make do with rectangular colors if I have to Cheesy   I have actually tried solving the problem with vertex rectangles before and they gave about the same speed as gldrawpixels (too slow).

Quote
Or generate a texture that is uploaded once per frame and drawn with one quad that covers the screen.

If I understand you correctly - there would need to be several million combinations of screen texture depending on where the 2 tiles are within the grid so this couldn't be an option.

Quote
2) Use Triangle strips or quad strips.

Don't know much about these ... do you think these would give me more speed than drawing vertex rectangles???

Quote

3) Generate one big texture that contains one of the sprites tiled across it. The texture is drawn first using one quad covering the screen. Then you draw sprite nr 2 where it is needed. Basicly swapping gl calls for overdraw.
 

Not sure  how I'd go about implementing it but I'd like to give it a try before I give up completely.  Does anybody know where I could find an example of how to implement a system like this?

Many thanks for your reply,

Sally
Offline turquoise3232

Junior Member




Java (games) rock!


« Reply #29 - Posted 2004-07-24 09:23:46 »

Quote

That's a foolish thing to say -  especially since there are drivers on the Matrox.com website dated 2004 (windows only) and 2003 (linux).


Well, for spending hours with the matrox technical support and hearing them said that their new drivers(wich are generic ones) may improve something with G550 but decrease perfs with G450 ( 200 of which my compagny was about to buy...) I thought this wonderful card was dying.
But i there are new drivers that make it run like a rabbit it is certainly worth trying them!
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.

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

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

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

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

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

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

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

BurntPizza (30 views)
2014-08-08 02:01:56

Norakomi (37 views)
2014-08-06 19:49:38

BurntPizza (67 views)
2014-08-03 02:57:17
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!