Java-Gaming.org Hi !
Featured games (87)
games approved by the League of Dukes
Games in Showcase (671)
Games in Android Showcase (194)
games submitted by our members
Games in WIP (727)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1] 2 3 ... 112
1  Game Development / Game Mechanics / Re: Hardware-like software cursor. on: 2016-05-01 15:21:52
A crazy solution would be to detect frame rate drops and when those happen draw a dummy frame. You'd just copy the contents of the previous frame to the screen (without the old mouse) and redraw the mouse in its new position, effectively doubling the mouse's frame rate compared to the rest of the game's. It would have a tiny bit of overhead (1 fullscreen pass for each extra frame to copy the previous one), but could help a lot if mouse smoothness is critical.
2  Java Game APIs & Engines / OpenGL Development / Re: LWJGL 3 vs JOGL on: 2016-04-28 15:02:37
I still can't actually use it commercially, myself, because GLFW still doesn't have buffered controller input :/

Cas Smiley
Hmm? What is "buffered controller input"?
EDIT: This issue? https://github.com/glfw/glfw/issues/601
3  Java Game APIs & Engines / OpenGL Development / Re: LWJGL 3 vs JOGL on: 2016-04-28 14:27:59
I'd like to chime in that I do not consider GLFW to be the gold standard of windowing systems yet. It's lacking certain features from LWJGL 2, but most of these have been fixed last month or so. Fullscreen switching without having to recreate the window is in, but it still isn't possible to change from normal windowed to borderless windowed for example. Also, the window icon support is very limited right now. That being said, LWJGL 3 is really frigging great in general.
4  Game Development / Networking & Multiplayer / Re: Port Mapper port forwarding library on: 2016-04-28 02:24:02
How did this not get more attention?!
5  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-04-27 01:58:11
It took me a few months, but I finally decided to sit down and try my luck at R-trees again. I managed to get basic insertion/split logic working at last.


There's currently a lot of overlap (I think I'm using quadratic splitting right now? o_O), so I'm gonna try my luck at implementing R*-insertion and possibly try my luck on some refining tomorrow.

6  Game Development / Game Mechanics / Re: [java] Rapid trigonometric calculations on: 2016-04-19 18:51:14
See this link: http://www.java-gaming.org/topics/extremely-fast-sine-cosine/36469/view.html
Feel free to compare it against those implementations.
7  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-04-14 20:12:45
I drew my first Vulkan triangle! Grin Grin Grin
8  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-04-14 19:20:24
Hmm. I could've just hardcoded all the variables of course, but I decided to intentionally generate all the boilerplate constants to make the generated code more easy to read.

I use simple reflection to analyze the template class, extracting the fields for it.

Oh, and execute(int fbo) (or whatever args the generator puts in there) is supposed to be private. x___x Gonna go fix that. =P That should be enough to make it clear that the private execute() method is meant to do work.
9  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-04-14 02:20:07
Why have you decided to do this much work to support both OpenGL and Vulkan through an abstract layer?
Because it's awesome? Jokes aside, I want to support OGL3 hardware as well, and they don't support Vulkan. Also it'll be interesting to have a perfect comparison between the two.
10  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-04-14 02:09:34
Finally finished writing software command buffers for OpenGL. I ended up going with raw memory pointers for writing commands instead of storing commands as objects.

Before you start reading this, keep in mind that I am well aware of how crazy this sounds. xd I realized that I will probably need hundreds of commands to do everything I want in OpenGL, which isn't exactly fun to maintain if I also have to write and read the data from these commands to a memory pointer manually, so I decided to......... write a program which generates the code. >___> <___< For example given this input class:
1  
2  
3  
public class CmdBindFramebuffer {
   public int fbo;
}
it outputs the following class:
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  
package engine.age.objects.cmd.glcmd;

import static org.lwjgl.system.MemoryUtil.*;
import static org.lwjgl.system.MemoryStack.*;


import static org.lwjgl.opengl.GL11.*;
import static org.lwjgl.opengl.GL12.*;
import static org.lwjgl.opengl.GL13.*;
import static org.lwjgl.opengl.GL14.*;
import static org.lwjgl.opengl.GL15.*;
import static org.lwjgl.opengl.GL20.*;
import static org.lwjgl.opengl.GL21.*;
import static org.lwjgl.opengl.GL30.*;
import static org.lwjgl.opengl.GL31.*;
import static org.lwjgl.opengl.GL32.*;
import static org.lwjgl.opengl.GL33.*;

@SuppressWarnings("unused")
public class CmdBindFramebuffer {

    public static final int COMMAND_ID = 0;

    public static final int SIZE = 8;

    private static final int FBO_OFFSET = 4;


    private CmdBindFramebuffer() {}


    public static long store(long address, int fbo) {
        memPutInt(address, COMMAND_ID);
        memPutInt(address + FBO_OFFSET, fbo);
        return address + SIZE;
    }

    public static long execute(long address) {
        int fbo = memGetInt(address + FBO_OFFSET);

        execute(fbo);

        return address + SIZE;
    }


    public static void execute(int fbo) {
        glBindFramebuffer(GL_FRAMEBUFFER, fbo); //<--- inserted by me manually after generation
    }
}


To store the command in a memory pointer, I just do the following:
1  
2  
      prepareCommand(CmdBindFramebuffer.SIZE);
      currentAddress = CmdBindFramebuffer.store(currentAddress, activeFramebuffer.getFBO(currentSubpass));


Now, the generator also goes through all template classes and regenerates them each time I run the generator (leaving the execute() function intact so that it doesn't remove the code I've written manually) and assign a unique ID to each one. It also outputs to System.out a huge switch() statement for running a command buffer as well. Currently I only have two commands, so it's not that big yet. =P
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
long address = pageAddresses[i];
for(int j = 0; j < commandCount; j++){

    int commandID = memGetInt(address);
           
    //This part is generated.
    switch(commandID){
        case CmdBindFramebuffer.COMMAND_ID: address = CmdBindFramebuffer.execute(address); break;
        case CmdClearBuffer.COMMAND_ID: address = CmdClearBuffer.execute(address); break;
        default: throw new RuntimeException("Unknown command: " + commandID);
    }
}


It's pretty neat. xd I'm now at feature parity with the Vulkan version, where I can start render passes and have them automatically clear the attachments for me (it's a feature in Vulkan, emulated using glClearBuffer**() in OpenGL the first time a color attachment is used).

EDIT:
More advanced example with static final variables preserved:
 Input: http://www.java-gaming.org/?action=pastebin&id=1443
 Output: http://www.java-gaming.org/?action=pastebin&id=1444 (execute() method written manually by me of course)
11  Discussions / General Discussions / Re: Blog six replies limit on: 2016-04-11 18:56:16
Like SHC said, JGO should not be used as a blog. If people haven't responded after you made 5 consecutive posts, odds are you're not doing it quite right.
It's okay to reach out to the community to work around this limit, the point of it is mainly to address the issue and hopefully alter the behavior somewhat Wink Even on a technical forum such as this you have to think a little about your 'marketing'.
That's not entirely true. People can find it interesting without responding.
12  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-04-11 12:12:34
I read about them but quickly decided against them since, they require OpenGL version 4.3, compared to TBO's only needing 3.0.
Why not just use a 3D texture? It's a volume after all.
13  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-04-07 14:13:01
@theagentd

Maybe try Enums? You can encode the specific command as the enums .ordinal() and retrieve the command by EnumClass.values()[ordinal]. No switch needed. Maybe it's faster? It kind of mixes the approaches of #1 and #2 Smiley
I think Enums are literally singleton objects so we'd have the same virtual method call overhead. I already tried using the command ID to index into a static list of commands, but it was a tiny bit slower than just storing a command singleton, which makes sense (read object --> call virtual function VS read command ID ---> index into array to find object ---> call virtual function).

I tried out encoding data to a piece of native memory using MemoryUtil of LWJGL (which uses Unsafe), and got a solid 15% performance boost over using an int[] for the data. That should solve the encoding issue. The only problem now is writing 50+ command encoders and decoders. I'm gonna look into generating those.
14  Game Development / Shared Code / Re: Fastest Way To Clear Screen? on: 2016-04-07 04:20:14
Try Arrays.fill().
15  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-04-07 01:23:40
I've managed to get render passes in my graphics abstraction for Vulkan working. Now it's time to implement software command buffers for OpenGL. I decided to do an experiment to find out what the best way of encoding OpenGL commands would be.


Method 1: The most obvious way is to use objects as commands. For each command added to the command buffer, I create an object for that specific command, store the arguments for the command in it and add it to a list. This has the advantage of being easy to handle. Adding a new command is simply making a new implementation of an interface. However, I've heard that calling virtual methods like that can be slow, and in my case there would be 100s of different commands (although 95% would be used very rarely). To avoid insane amount of garbage generated, I'd need to pool commands aggressively.
1  
2  
3  
4  
      int value = 0;
      for(int i = 0; i < NUM_COMMANDS; i++){
         value = objectCommands[i].process(value); //Each command is its own object
      }


Method 2: Secondly, I wanted to try encoding the commands as a command ID number (an int) and then storing the arguments to the method encoded in the same int array after the command ID. To execute the command buffer, I'd read the command ID, do a switch() on it to find the correct function to call and then read arguments from the int array depending on the command. Floats would be encoded using floatToRawIntBits() and stored in the array too. This is much more complicated to maintain as adding a new command means manually encoding arguments to the int array, adding a new ID to the switch() statement and decoding the arguments again in the function, but it has the potential to be much faster since all commands are stored sequentially in memory instead of being spread out all over the entire heap in objects, and virtual method calls are avoided.
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
      int value = 0;
      for(int i = 0; i < NUM_COMMANDS; i++){
         int cmd = intCommands[(i<<1) + 0];
         int arg = intCommands[(i<<1) + 1];
         switch(cmd){
            case 0: value = ADD_COMMAND.process(value, arg); break; //Call singletons to calculate value.
            case 1: value = SUB_COMMAND.process(value, arg); break;
            case 2: value = MUL_COMMAND.process(value, arg); break;
            case 3: value = DIV_COMMAND.process(value, arg); break;
         }


Method 3: Thirdly, I wanted to try something something inbetween 1 and 2. Instead of creating a new object for each command invocation, I would create singletons of each possible command. When encoding a command, the singleton for that command would be placed in a list, and the arguments for it would be encoded into an int array again. This also has perfect cache coherence as all the command arguments are sequentially in memory, while being a bit easier to maintain as each command is again contained in its own class implementing an interface (although arguments still have to be encoded and decoded into the int list).
1  
2  
3  
4  
5  
6  
      int value = 0;
      for(int i = 0; i < NUM_COMMANDS; i++){
         Command cmd = staticObjectCommands[i]; //References to just 4 singleton commands
         int arg = staticObjectArgs[i];
         value = cmd.process(value, arg);
      }



My guess here was that method 1 would be significantly slower than the other two as the command objects will end up all over the heap after pooling and virtual methods are used. Comparing method 2 and 3, I assumed that they would perform almost identically as Java should essentially do the exact same thing as I'm doing internally (method 2 does a switch over the command ID while method 3 would internally do a switch over the command classes to pick the right function to call).

Actual results:
 - Method 1: 16.204294 ms (29.375046 ms with shuffling)
 - Method 2: 8.42079 ms
 - Method 3: 15.7727375 ms

When cache coherency is good, method 1 and 3 are pretty much identical. If the command array of method 1 is shuffled (simulating what would happen after a few minutes of garbage collection and pooling), performance drops noticeably due to bad cache coherency, potentially becoming less than half as fast as method 3. Performance is apparently limited by the virtual function call overhead. What surprised me was that manually doing a switch-statement in method 2 was significantly faster than Java's virtual method selection, up to 2x faster.

Something to remember is that this does not take into consideration command "encoding" or advanced decoding of arguments and is a fairly synthetic benchmark with only simple functions. Encoding is not as important as command buffers can be encoded from multiple threads, but decoding will be extremely time critical as it is done solely on the OpenGL thread. I think I'll have to do more experiments before I decide on what to do...


EDIT: Hmm. Encoding command data into an int[] is pretty silly. Better to just use ByteBuffer or even a raw memory pointer to write data to. Something really awesome would be if I could "map" the buffer to a struct to give me a cleaner interface to it. Maybe it's time to revisit the good old MappedObject stuff?
16  Discussions / Miscellaneous Topics / Re: Unsolicited blank CD in post - huhh? on: 2016-04-04 20:16:06
April's Fool? =P
17  Game Development / Newbie & Debugging Questions / Re: Time, delays, etc on: 2016-04-01 14:27:33
Simplest solution: If you limit your update loop to X updates per second, you can wait (delay * X) ticks until you fire off the event.
18  Game Development / Newbie & Debugging Questions / Re: Questions on GLSL lighting on: 2016-03-31 13:43:19
I also strongly recommend you start out with forward shading if you haven't already done that. It helps you get all the important things together and teaches you a lot of important things (shaders, lighting in general).

You're a bit off on your idea of deferred rendering. You seem to be describing a variation of deferred lighting, while the most commonly used technique is deferred shading. To do deferred shading, you would do this:

1. In a single pass, render all geometry to an FBO with multiple render targets, storing diffuse albedo, emissive color, normals, lighting parameters (roughness, specular intensity, specular power, stuff like that) and depth.
2. Switch to a new FBO and accumulate lighting with additive blending into a texture. Lights are drawn as actual geometry (point lights are spheres, cone lights are cones, directional lights are fullscreen passes) to avoid processing unaffected pixels, or you can use more advanced techniques like tile-based deferred shading, where you determine which tiles on-screen are affected by which light using compute shaders. Lighting is (overly simplified):
        light = calculateDiffuseLighting(diffuseAlbedo, normal, lightDirection) + calculateSpecular(normal, lightDirection, lightingParameters).
3. After lighting, you have the lit scene in the light buffer. Most likely you have HDR light values to avoid being limited to a (0 - 1) range of light values and need to tone map the values from (0 - infinity) to (0 - 1). You can also do postprocessing like bloom, SSAO, motion blur, etc at this point.


You're describing an older technique which relied on multiple passes in an attempt to limit the bandwidth used. It was pretty inefficient, and is even more inefficient on today's hardware.
19  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-03-28 21:41:30
Working on an abstraction layer to allow me to switch between OpenGL and Vulkan without having to write my graphics engine twice. The idea is to provide an interface that lies somewhere inbetween Vulkan and OpenGL, basically taking Open GL adding all new features that Vulkan requires (render passes, memory barriers) while abstracting away everything that Vulkan requires but OpenGL doesn't support. I've managed to get most of the setup code done so far. I can bring up windows and swap buffers with both APIs, but not draw anything yet.
20  Game Development / Shared Code / Vulkan/OpenGL enum name lookup on: 2016-03-27 16:41:55
Hello, everyone. I wrote this code to help me understand Vulkan. It searches through the Vulkan classes to convert enum values to enum names. Here's an example of it in action:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
      VkSurfaceFormatKHR.Buffer formats = ...;
      System.out.println("    Surface formats: " + formats.limit());
      for(int i = 0; i < formats.limit(); i++){
         System.out.println("    Surface format " + (i+1) + ":");
         VkSurfaceFormatKHR format = formats.get(i);
         System.out.println("        Format: " + getEnumName("VK_FORMAT", format.format()));
         System.out.println("        Colorspace: " + getEnumName("VK_COLORSPACE", format.colorSpace()));
      }
     
      VkSurfaceFormatKHR format = formats.get(0);

     
      IntBuffer presentModes = ...;
      System.out.println("    Surface present modes: " + presentModes.limit());
      for(int i = 0; i < presentModes.limit(); i++){
         int presentMode = presentModes.get(i);
         System.out.println("        Surface present mode " + (i+1) + ": " + getEnumName("VK_PRESENT_MODE", presentMode));
      }

Output:
Quote
    Surface formats: 2
    Surface format 1:
        Format: VK_FORMAT_B8G8R8A8_UNORM
        Colorspace: VK_COLORSPACE_SRGB_NONLINEAR_KHR
    Surface format 2:
        Format: VK_FORMAT_B8G8R8A8_SRGB
        Colorspace: VK_COLORSPACE_SRGB_NONLINEAR_KHR
    Surface present modes: 3
        Surface present mode 1: VK_PRESENT_MODE_FIFO_KHR
        Surface present mode 2: VK_PRESENT_MODE_FIFO_RELAXED_KHR
        Surface present mode 3: VK_PRESENT_MODE_MAILBOX_KHR
This is obviously only useful when debugging to make readable printouts, but it's extremely powerful (thank you, Java reflection!) and easy to use. Here's the code for getEnumName():
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
   private Class<?>[] enumClasses = new Class[]{
         VK10.class,
         KHRSurface.class,
         KHRSwapchain.class,
   };
   private String getEnumName(String prefix, int value){
      for(Class<?> c : enumClasses){
         for(Field f : c.getFields()){
            try {
               if(f.getName().startsWith(prefix) && (Integer)f.get(null) == value){
                  return f.getName();
               }
            } catch (Exception e) {
               e.printStackTrace();
            }
         }
      }
      return "Unknown enum " + value + " (0x" + Integer.toHexString(value) + ")";
   }

The enumClasses array can be tailor made so it only searches through the classes you use. Theoretically this function should work for OpenGL as well. In Vulkan each set of enums (formats, present modes, etc) all start at 0, but they're all prefixed with the set they belong to. In OpenGL the enums do not start with the name of the enum set, but I do think that they're unique in the entirety of OpenGL, so this function should still work for OpenGL too by just removing the prefix argument needed for Vulkan.
21  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-03-23 03:34:57
I've been thinking about reworking my window system for the sake of multiple windows lately, and I finally went and tried it out today. I create a single invisible main context which is the one that I will be drawing from. The main context is shared to all window contexts. After drawing what I want on the main context, I pass over a texture handle and x, y, width, height of the area of the texture to present to the window's own thread, which does a glFramebufferBlit() using that texture to copy it to that window. This avoids all the stupid shared context quirks (VAOs, FBOs aren't shared so I'd have to recreate them all on each context, it'd be a mess). I can draw in a single context and pass the result to whichever context I want to.

It turns out that to accomplish this you need to do two OpenGL context syncs, one to make sure that the main context has finished rendering the texture before the window context starts to blit it, and one afterwards to make sure that the main context doesn't modify the texture before the window context is done blitting... EXACTLY what'd you'd have to do with semaphores if you were using Vulkan and different queues for rendering and presenting.


EDIT: OK, this was a VERY bad idea it seems. Getting random permanent drops to 30 FPS that won't go away. Was faster to just swap contexts when presenting on the main thread.
22  Java Game APIs & Engines / OpenGL Development / Re: GLFW now supports switching between windowed and fullscreen on: 2016-03-23 01:59:31
Might wanna report that on their GitHub. xd
23  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-03-22 23:08:25
Fixed the JGO notification-bar... why didn't anybody tell me it had been down for 2 weeks Emo
I actually noticed, and was surprised to see it working just now. >___> I'll try to mention it next time...
24  Java Game APIs & Engines / OpenGL Development / Re: GLFW now supports switching between windowed and fullscreen on: 2016-03-22 23:07:13
Yup pretty cool feature. It's already part of the LWJGL3 nightly builds. Was probably the last feature LWJGL2's Display had which GLFW was missing.
Indeed, that's why I felt it made sense to make a post about it. I'd say LWJGL3 is now objectively better than LWJGL2 in every single way now and ready for real use. Maybe not the Vulkan part yet (still getting tweaks all the time =P) but OpenGL and GLFW is mature now IMO.
25  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-03-22 22:52:57
theagentd: is the area just above the shoulders correct? I would think that there would be more light closer to them. Still, looks good.
The whole thing is really really fake. That's actually a good property in this case, since it hides aliasing on edges, allowing me to use lower resolution rendering.

EDIT: Crysis 1 screenshot:
26  Java Game APIs & Engines / OpenGL Development / GLFW now supports switching between windowed and fullscreen on: 2016-03-22 20:37:37
GLFW now supports switching windows between windowed and fullscreen without having to recreate the context. Before it was possible to resize windows and change video modes of fullscreen windows without destroying and recreating the window, but switching from windowed to fullscreen and vice versa required recreating the window, usually requiring a complete restart of the game.

https://github.com/glfw/glfw/commit/6570d0c4b7a1868ad8af4e61dd5f50bf826d9c76

27  Discussions / General Discussions / Re: Interesting proposals: Java 9 and beyond on: 2016-03-22 20:35:07
If you really need a list with primitives, why not just write a class like the arraylist class with the data an int[] instead of an Object[]?
Because it's annoying? And it's not that simple when you get to stuff like HashMap<X, Y> because then you have n^2 combinations to worry about.
28  Java Game APIs & Engines / Engines, Libraries and Tools / Re: Java Library written IN Java on: 2016-03-22 20:33:57
Actually, there is a good use for software rendering: Occlusion Culling by Software Depth Testing.

Draw a bunch of occlusion bounding boxes with a software renderer into a depthbuffer, then check with another pass if the bounding boxes of any object are hidden by the pixels in the software depthbuffer. Its one of the fastest ways to do occlusion culling; the company Umbra is selling a library that uses this technique.

Someone should write a software renderer for occlusion culling in java...
The primary reasons for doing this was either having a very weak GPU where culling a single triangle no matter the CPU cost was a win (Playstation 3) or attempting to avoid a number of expensive single-threaded draw calls with threadable occlusion testing while avoiding expensive synchronization by reading back the depth buffer. Hopefully with Vulkan-based engines this won't actually be needed any more, as draw calls can be threaded and there's no high driver overhead of doing GPU occlusion culling.
29  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-03-22 18:06:31
Cool, what algorithm did you follow?
I just coded it from my memory of a few presentations.

1. Render a sun at 1/4 resolution, blocked by depth and transparent effects.
2. Run radial blur of image on image, centered on the sun.
3. Upscale and additively blend onto the original scene.

EDIT:

Before radial blur. There's a blob of light around the sun.


After radial blur.


30  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-03-22 16:48:54
Hacked together a radial blur volumetric lighting postprocessor in 1h 45m flat.





Will hopefully replace it with something physically correct in the future. Also, FPS values are low due to the tiles. The volumetric lighting postprocessor takes only 0.2ms @ 1920x1080 on my GTX 770.
Pages: [1] 2 3 ... 112
 
IanParcs (38 views)
2016-04-18 14:18:53

KaiHH (38 views)
2016-04-18 08:35:41

KaiHH (69 views)
2016-04-15 12:43:58

theagentd (71 views)
2016-04-14 02:16:17

theagentd (79 views)
2016-04-14 02:15:43

IanParcs (95 views)
2016-04-12 03:51:16

IanParcs (39 views)
2016-04-12 03:50:03

IanParcs (35 views)
2016-04-12 03:49:54

IanParcs (32 views)
2016-04-12 03:49:52

IanParcs (40 views)
2016-04-12 03:49:52
Website offering 3D Models specifically for games for free
by vusman
2016-04-29 12:56:17

List of Learning Resources
by SilverTiger
2016-02-05 09:39:47

List of Learning Resources
by SilverTiger
2016-02-05 09:38:38

List of Learning Resources
by SilverTiger
2016-02-05 09:35:50

Rendering resources
by Roquen
2015-11-13 14:37:59

Rendering resources
by Roquen
2015-11-13 14:36:58

Math: Resources
by Roquen
2015-10-22 07:46:10

Networking Resources
by Roquen
2015-10-16 07:12:30
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!