Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (690)
Games in Android Showcase (200)
games submitted by our members
Games in WIP (764)
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 ... 91
1  Game Development / Newbie & Debugging Questions / Re: TexturePacker - sprite blip on: 2016-09-18 20:47:34
looks like typical texture bleeding when using a texture atlas, a couple of options you could try to avoid the problem:

- leave a space/margin between different sprites on your texture atlas
- if you can, use GL_NEAREST instead of GL_LINEAR when loading your atlas texture
- handle the issue in your shader so that it doesn't pick up pixels from adjacent textures
2  Game Development / Shared Code / Starting JVM on Mac with -XstartOnFirstThread programmatically on: 2016-08-24 14:05:42
One of the nice features in LWJGL3 is that it comes with the SharedLibraryLoader, this automatically extracts any required natives.

This means you can create single executable fat jars without jumping too many hoops or having to fiddle with natives thus making distribution and running applications a lot easier. This works well on Windows and Linux as the user can just click a jar to start the application (or simply use 'java -jar app.jar' without having to type a long classpath or class name).

However one problem that I ran into was that on Mac you have to specify the "-XstartOnFirstThread" parameter and there is no easy solution to do this automatically with executable jars.

Therefore I've written a small method that basically checks if you are on Mac and if the XstartOnFirstThread option has been enabled, if not, it launches a new JVM and executes the same main method, settings, parameters and with the XstartOnFirstThread option enabled.

The above is difficult to get right and the code belows uses some nice tricks to detect everything, so should be useful for others who also want to use single file executable jars with LWJGL3 on Mac.

   public static boolean restartJVM() {
      String osName = System.getProperty("");
      // if not a mac return false
      if (!osName.startsWith("Mac") && !osName.startsWith("Darwin")) {
         return false;
      // get current jvm process pid
      String pid = ManagementFactory.getRuntimeMXBean().getName().split("@")[0];
      // get environment variable on whether XstartOnFirstThread is enabled
      String env = System.getenv("JAVA_STARTED_ON_FIRST_THREAD_" + pid);
      // if environment variable is "1" then XstartOnFirstThread is enabled
      if (env != null && env.equals("1")) {
         return false;
      // restart jvm with -XstartOnFirstThread
      String separator = System.getProperty("file.separator");
      String classpath = System.getProperty("java.class.path");
      String mainClass = System.getenv("JAVA_MAIN_CLASS_" + pid);
      String jvmPath = System.getProperty("java.home") + separator + "bin" + separator + "java";
      List<String> inputArguments = ManagementFactory.getRuntimeMXBean().getInputArguments();
      ArrayList<String> jvmArgs = new ArrayList<String>();
      // if you don't need console output, just enable these two lines
      // and delete bits after it. This JVM will then terminate.
      //ProcessBuilder processBuilder = new ProcessBuilder(jvmArgs);
      try {
         ProcessBuilder processBuilder = new ProcessBuilder(jvmArgs);
         Process process = processBuilder.start();
         InputStream is = process.getInputStream();
         InputStreamReader isr = new InputStreamReader(is);
         BufferedReader br = new BufferedReader(isr);
         String line;
         while ((line = br.readLine()) != null) {
      } catch (Exception e) {
      return true;

To use the above method, you simply put the follow at the start of your main method

public static void main(String[] args) throws Exception {
   if (restartJVM()) {
   // the rest of your main method

The only downside is that as the new JVM runs in a new process you can't get the console output in the same location without leaving the initial jvm running. If you don't need the output in the same location the the original jvm can just terminate.

With the above you can run executable jars which use LWJGL3 on Mac by simply clicking on them.
3  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3.0.0 released on: 2016-06-03 18:49:55
Congrats on the release and thanks for the years of hard work behind making this happen. GitHub history says the initial commit was December 2012.
4  Game Development / Game Mechanics / Re: Hardware-like software cursor. on: 2016-05-04 09:35:03
This doesn't really help in this case. It's not that the mouse isn't polled often enough; it's that the screen isn't redrawn fast enough. Interpolation won't help if the mouse position only updates 10 times per second.
If the frame drop is that large then I agree with you. However if the application is running that slow then its unlikely the other techniques mentioned above are going to help much and in general the application has serious issues which need to be addressed first.

For smaller frame drops though, mouse interpolation should work well enough.

Oh, that sounds pretty interesting Smiley Though not perfect, it may be enough of a compromise. I'll probably give it a try. Do you have any examples of this or is this just idea from top of your head?
It's a technique used in many commerical games and triple A titles (sometimes you can even toggle it on/off in the options), IIRC (not 100% sure) it was also used in Revenge of the Titans (OpenGL game with source code).

I don't have a link to an article setting out the implementation, however the concepts at the end of the fix your game loop articles are pretty similar such as here, here and here.
5  Game Development / Game Mechanics / Re: Hardware-like software cursor. on: 2016-05-03 11:49:17
have you tried implementing mouse smoothing?

Usually done by interpolating the mouse position between either:

1) where the mouse was and where it should be (previous polled position and current polled position)
2) where it currently is and by predicting where it will be the next time its polled (current polled position and predicted next position).

Rather than jumping between mouse positions you can move the cursor at a constant speed between mouse positions or draw it at an interpolated position between the two positions at the time the frame is rendered.

This should hide small amounts of lag and give the appearance of smooth movement.
6  Java Game APIs & Engines / OpenGL Development / Re: LWJGL 3 vs JOGL on: 2016-04-28 15:05:32
I still can't actually use it commercially, myself, because GLFW still doesn't have buffered controller input :/

Cas Smiley
Why not just continue using JInput for Controllers with GLFW/LWJGL3? At least until GLFW controller support catches up. If you were using LWJGL2's Controller class, you could probably just continue using that as that was just a wrapper around JInput.
7  Java Game APIs & Engines / OpenGL Development / Re: GLFW now supports switching between windowed and fullscreen on: 2016-03-22 20:47:16
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.
8  Discussions / General Discussions / Re: Vulkan 1.0 Release on: 2016-03-18 14:33:38
In theory Wayland would be just great. Still some question over mouse/keyboard/touch of course.

Cas Smiley
LibInput seems to be the most commonly used library by Wayland compositors to handle mouse/keyboard/touch. As the backend is still experimental not sure input support has been added yet but should eventually just be as simple as using GLFW's api to handle input.
9  Discussions / General Discussions / Re: Vulkan 1.0 Release on: 2016-03-18 12:33:57
Wouldn't using Wayland (which GLFW3 already supports to an extent) be a possible solution instead of X11 on the Pi? Its alot more lightweight than X11 and won't require using any Pi specific API's.
10  Discussions / General Discussions / Re: Power consumption of desktops vs ARM SOC's such as Odroid-C2 or Rpi3 on: 2016-03-11 17:10:04
One advantage that the RaspberryPI now has over other boards is that it has a driver for running the full desktop OpenGL 2.0 on it (as opposed to just OpenGL ES), should make porting stuff to it much easier.
11  Game Development / Newbie & Debugging Questions / Re: [LWJGL] Attributes and VBO on: 2016-03-02 15:21:20
Oh and I should may be start using LWJGL3, last time I checked it, it did not include any math utils classes for matrices and vectors, I was pissed and thought I should check it later when it would be less brutal!
You should use JOML with LWJGL3 for matrices and vectors. Its unlikely that LWJGL3 will add math util classes of its own.
12  Discussions / General Discussions / Re: Amazon releases "Lumberyard" on: 2016-02-09 20:33:25
From my reading, they haven't written the engine from scratch but just licensed Crytek’s CryEngine. So basically a modified CryEngine thats been re-skinned and a few components that are tailored towards Amazon's online services.
13  Game Development / Game Mechanics / Re: 2D point in polygon algorithm on: 2016-01-24 19:44:13
Thats very cool stuff, a polygon of that complexity is not something i'd have ever considered testing using its edges. An approach such as using bit masks (like Worms) to test such complex shapes might have been easier to implement (also would handle holes). Nonetheless very impressive results.

btw on OS X i get the following error message when running the jar

java -jar polydraw.jar
Exception in thread "main" java.lang.UnsatisfiedLinkError: org.lwjgl.system.MemoryAccess.getPointerSize()I
   at org.lwjgl.system.MemoryAccess.getPointerSize(Native Method)
   at org.lwjgl.system.Pointer.<clinit>(
   at org.lwjgl.glfw.GLFW.<clinit>(
   at org.joml.lwjgl.PolygonDrawer.main(
14  Game Development / Game Mechanics / Re: 2D point in polygon algorithm on: 2016-01-24 18:24:26
In case you cannot/wantnot Smiley build, here is a jar of that:
Uses LWJGL 3 with OpenGL 1.1 and GLFW and works under Windows, Linux, OS X.
the jar is missing the linux and os x lwjgl3 natives Smiley
15  Discussions / General Discussions / Re: app idea on: 2015-12-09 14:05:28
The Java distribution landscape has changed alot and there is no guarantee anymore that computers even have a system JVM installed (let alone applet or java web start support).

Therefore the way to distribute java applications is to bundle it with your own jvm. In which case jvm sandboxing makes little sense (on top of the sandboxing most OS's have for local applications).

Its better to spend time looking at some of the web brower tech's that allow you to run Java applications in the browser (GWT, WebGL, Asm.js, EMScripten, TeaVM, etc) for app's which require sandboxing and need to be mass distributed like applets.
16  Discussions / General Discussions / Re: SMF is falling apart. on: 2015-11-17 07:44:53
the RSS feed has also been down for a while.
17  Discussions / Miscellaneous Topics / Re: What I did today on: 2015-11-06 10:40:54
Wrote a brute force distance field generator for use on fonts.

Very nice implementation, I see the generated field also makes some adjustments to compensate for lack of sharp corners (which is the usual weakness of distance field fonts). This is different from the algorithm mentioned by Green in the Valve paper, are you using a different algorithm or some custom solution?
18  Java Game APIs & Engines / Engines, Libraries and Tools / Re: WebGL4J - Simple GWT based WebGL wrapper for Java on: 2015-10-22 15:37:06
Not really looked to deeply into WebAL but does look well organised.

Emscripten uses the MIT license so there is no real problem about permission to use.

Writing and maintaining your own OpenAL implementation around Web Audio API would have its advantages (more control, faster fixes, etc) but also disadvantages (more code to maintain, write, test, etc).

I wouldn't worry too much about supporting internet explorer at this point, Microsoft have already put their weight behind Edge and there is not much point in complicating your code base for a browser that's on the decline. Any serious application using the library won't be ready for at least a year or so in which time it'll have declined even more. Besides WebGL support is pretty rubbish on IE anyway so not much use jumping so many hoops to support it. Alternatively if you must support it you could go for a library like SoundManager2 which adds more backends.

Sorry for going off topic, maybe a seperate thread would be a better idea.
19  Java Game APIs & Engines / Engines, Libraries and Tools / Re: WebGL4J - Simple GWT based WebGL wrapper for Java on: 2015-10-22 10:43:24
Yeh I've come across that but looks a bit dead as its not had any commits to the main source code in over 5 years (maybe it's just complete?).

Emscripten's OpenAL implementation is just a single js file (library_openal.js), last updated 2 months ago.

Interestingly just noticed that Emscripten also seem to have a GLFW3 implemetation. Maybe its not to far fetched to think that it might be possible to write an API compatible subset of LWJGL3 that can run in the browser and desktop Smiley
20  Java Game APIs & Engines / Engines, Libraries and Tools / Re: WebGL4J - Simple GWT based WebGL wrapper for Java on: 2015-10-22 09:52:51
This library seems pretty cool and useful for porting existing codebases to the web.

However the roadblock that I always run into is sound. If you could also add bindings for OpenAL that would be the final piece in making it super awesome and useful to a lot more java libraries, engines and games.

The cool thing is the EMScripten project has already implemented OpenAL in the browser (I believe it wraps the Web Audio API). Its already used by many projects including the web version of the Unreal Engine. Therefore I assume to implement a binding its just a matter of linking to the javascript methods of the Emscripten OpenAL implemention.
21  Game Development / Performance Tuning / Re: Pathfinding for tons of creatures on: 2015-10-13 15:59:39
Heres a comparison of a flowfield algorithm vs an old A* style one (a rather crappy implemenation by the looks of it but demonstrates the point)

<a href=";hl=en_US&amp;start=" target="_blank">;hl=en_US&amp;start=</a>
22  Discussions / General Discussions / Re: On-site IRC error on: 2015-10-13 13:26:43
Seems like a recent change has broken the JGO RSS feed.
23  Game Development / Performance Tuning / Re: Pathfinding for tons of creatures on: 2015-10-13 10:12:07
Grid based A* isn't really suitable for multi-unit pathfinding. You'll have to implement lots of hacks just to get it working nicely and even then unit movement often looks unnatural.

For less than a hundred or so units, a much nicer algorithm is Cooperative Pathfinding, which is similar to A* but with the addition of time (where position of other units a number of time steps ahead is considered as part of the pathfinding).

For thousands of units, you'll want to go for one of the pathfinding algorithms that use flocking with a combination of either a navmesh or a flowfield. Such as those seen in games like Supreme Commander, Planetary Annihilation and Starcraft 2. These calculate the path just once for a whole group, scale well and allow you to implement various types of group formations and movement patterns much more easily then with more rigid algorithms such as A* for each unit.
24  Game Development / Newbie & Debugging Questions / Re: [LWJGL3] load natives next-to-jar on: 2015-10-12 09:26:16
LWJGL3 has a new feature (nightly builds) in that you can just put the natives in a jar file and add that jar to the classpath (or even put them in the lwjgl.jar if you don't want a seperate jar). LWJGL3 will automatically detect them and load them from there (they should be in the root of the jar/zip and not in a subfolder).

Alternatively if you still want to do it the old way you can try
System.setProperty("org.lwjgl.librarypath", new File("Resources/native").getAbsolutePath());

There is also the new org.lwjgl.system.Configuration class for setting LWJGL variables at run time, the path to the natives can be set at runtime as follows:

25  Java Game APIs & Engines / OpenGL Development / Re: Set minimum display size on: 2015-09-29 11:59:12
LWJGL2's Display class doesn't support setting a minimum window size limit.

LWJGL3 will have this feature once GLFW3.2 is released.
26  Game Development / Newbie & Debugging Questions / Re: Box2D - CircleShape Bounces when walk! on: 2015-09-20 14:29:03
have you tried setting the restitution value to 0 for both the circle and the ground?
27  Discussions / General Discussions / Yeppp! fast vector math library on: 2015-09-17 18:06:56
A while back some people here attempted to implement a Java SIMD's library, not sure how far along they got, but came across a pretty cool looking library called Yeppp! which has a Java binding and claims to be a really fast vector maths library with SIMD's support, more details here.
28  Games Center / WIP games, tools & toy projects / Re: Attack of the Green Aliens 2 on: 2015-09-11 19:38:37
The problem might be that you haven't  specified forward compatibility mode, if you wish to use an OpenGL 3.x or 4.x context on OS X you have to enable forward compatibility and the core profile context, its an OS X requirement. Details on how to do this with LWJGL3/GLFW are available here.
29  Games Center / WIP games, tools & toy projects / Re: Attack of the Green Aliens 2 on: 2015-09-11 19:17:23
Tested on mac, just getting a blank black window which is frozen, theres no output on the console. Maybe put in a few System out's to help determine how far it gets in before the freeze. Since there is a window unlikely to be a LWJGL natives issue.

EDIT: Adding the lwjgl 3 debug flag (-Dorg.lwjgl.util.Debug=true), I am able to see an exception in the console as follows:

[LWJGL] Version 3.0.0b | Mac OS X | x86_64
[LWJGL] MemoryUtil MemoryAccessor: MemoryAccessorUnsafe
[LWJGL] Failed to locate address for GL function glProgramUniform1dEXT
[LWJGL] Failed to locate address for GL function glProgramUniform2dEXT
[LWJGL] Failed to locate address for GL function glProgramUniform3dEXT
[LWJGL] Failed to locate address for GL function glProgramUniform4dEXT
[LWJGL] Failed to locate address for GL function glProgramUniform1dvEXT
[LWJGL] Failed to locate address for GL function glProgramUniform2dvEXT
[LWJGL] Failed to locate address for GL function glProgramUniform3dvEXT
[LWJGL] Failed to locate address for GL function glProgramUniform4dvEXT
[LWJGL] Failed to locate address for GL function glProgramUniformMatrix2dvEXT
[LWJGL] Failed to locate address for GL function glProgramUniformMatrix3dvEXT
[LWJGL] Failed to locate address for GL function glProgramUniformMatrix4dvEXT
[LWJGL] Failed to locate address for GL function glProgramUniformMatrix2x3dvEXT
[LWJGL] Failed to locate address for GL function glProgramUniformMatrix2x4dvEXT
[LWJGL] Failed to locate address for GL function glProgramUniformMatrix3x2dvEXT
[LWJGL] Failed to locate address for GL function glProgramUniformMatrix3x4dvEXT
[LWJGL] Failed to locate address for GL function glProgramUniformMatrix4x2dvEXT
[LWJGL] Failed to locate address for GL function glProgramUniformMatrix4x3dvEXT
[LWJGL] Failed to locate address for GL function glVertexArrayVertexAttribDivisorEXT
[LWJGL] Failed to locate address for GL function glTextureStorage1DEXT
[LWJGL] Failed to locate address for GL function glTextureStorage2DEXT
[LWJGL] Failed to locate address for GL function glTextureStorage3DEXT
[LWJGL] Failed to locate address for GL function glVertexArrayVertexAttribLOffsetEXT
Exception in thread "main" org.lwjgl.opengl.OpenGLException: Cannot use offsets when pixel unpack buffer object is disabled
   at org.lwjgl.opengl.GLChecks.ensureBufferObject(
   at org.lwjgl.opengl.GL12.glTexImage3D(
   at minusk.render.core.Game.gameloop(
30  Java Game APIs & Engines / Tools Discussion / Re: jBullet3 on: 2015-08-28 14:27:48
One thing to keep in mind is that Bullet3 is still pretty much experimental (under heavy development) and depends on OpenCL.

OpenCL support and drivers are still not very widespread and judging by current trends its not looking like it'll get much better any time soon (both OpenGL compute and Vulkan seem like much better bets atm). Therefore any application using Bullet3 (in its current form) will only really be usable by a small and niche target audience unlike Bullet2 which works well for the mass market.

Its a big undertaking to port and maintain a C++ code base (especially a fast moving one like Bullet3) to Java, so you should consider your options carefully (like whether to go for making a binding instead of porting).
Pages: [1] 2 3 ... 91
Wave Propagation (216 views)
2016-09-20 13:29:55

steveyg90 (329 views)
2016-09-15 20:41:23

steveyg90 (328 views)
2016-09-15 20:13:52

steveyg90 (366 views)
2016-09-14 14:44:42

steveyg90 (393 views)
2016-09-14 14:42:13

theagentd (426 views)
2016-09-12 16:57:14

theagentd (361 views)
2016-09-12 14:18:31

theagentd (294 views)
2016-09-12 14:14:46

Nihilhis (726 views)
2016-09-01 13:36:54

roseslayer (1294 views)
2016-08-06 11:43:29
List of Learning Resources
by elect
2016-09-09 09:47:55

List of Learning Resources
by elect
2016-09-08 09:47:20

List of Learning Resources
by elect
2016-09-08 09:46:51

List of Learning Resources
by elect
2016-09-08 09:46:27

List of Learning Resources
by elect
2016-09-08 09:45:41

List of Learning Resources
by elect
2016-09-08 08:39:20

List of Learning Resources
by elect
2016-09-08 08:38:19

Rendering resources
by Roquen
2016-08-08 05:55:21 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‑
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!