Another argument for techniques like TDD which is usually pushed is that they help you design cleaner and better public API's but personally not seen any advantage here over manually doing so (in fact its faster to do so manually).

When it comes to writing games (as opposed to libraries and engine code), unit testing is a complete waste of time. Jonathan Blow sums up the problem pretty nicely (including arguing pretty strongly against spending time commenting code and most types of optimisations).

I'm assuming theagentd is referring to ARB_buffer_storage when talking about persistently mapped memory.

If so, he's right in that its the fastest way now, only downside is that it seems to require pretty new hardware (OpenGL 4.3+) making it pretty much unusable for applications targeting the masses (unless you want to have an application with multiple rendering paths). Once such hardware becomes mainstream its definitely the way to go.

There a quiet a few super nice looking 2d Java games these days but as for 3d, aside from some of the ones mentioned above, two really impressive looking ones are Caromble! and the WIP game We Shall Wake (which is probably the most impressive I've seen).

I'm well aware that I should be using VBO's. I just wanted to get an image displayed before I tried anything else...

OpenGL is pretty low level, so it not as straight forward as high level libraries to draw an image.

To draw an image you would normally first need to set up your matrices on how to draw your vertices on the screen which you can pass to a shader, then draw a square (using two triangles, the vertices and texture coordinates of which would be in a VBO). Then you would load your image as an OpenGL texture and pass that to a shader which draws it on the triangles when rendering them.

One thing to keep in mind, DirectX is for Windows only (and other Microsoft platforms).

OpenGL is supported on a lot more platforms (including Windows). The tech landscape has changed a lot in the last few years, so if you intend to also target growing platforms such as Mac, Linux/SteamOS, Mobile/Tablet (e.g iOS, Android), WebGL, etc OpenGL may be the better and future proof choice.

1.4GB isn't really that much, why not just set the files to automatically sync to a number of free secure cloud service providers, Dropbox, Mega, Google Drive, Spideroak, etc, then once you are nuked, your dead man's switch could send out instructions on how to recover such files.

@kappa, quick question, I've tried to use LWJGL3 but there seems to be a lot of different stuff... any tutorials?

I tryied to follow the guide on the LWJGL website but it was broken.. at least it didn't work...

Thanks,Joao Lourenco

Yeh, LWJGL3 is still pretty new so there aren't many tutorials yet. A few of the good ones i've seen include the ones by SHC found here and on the LWJGL3 wiki here. The GLFW3 documentation is also pretty good and simple to follow. The rest should be pretty much the same as LWJGL2 (i.e. just OpenGL, AL and CL).

It's been an awesome run. I can't thank Spasi and everyone else involved enough for the effort.

Cas

Yup agreed, LWJGL2 was released back in 2008 so maintaining API compatibility since then has been a pretty good success. The design and simplicity of LWJGL's single window API has also held up pretty well considering the first release was back in 2002. Its only now started to show its age once multiple monitors, touch screens and HiDPI resolutions have started becoming more common.

Been using LWJGL3 for a while now and must say it really is much nicer and more flexible to use. Further its already pretty stable (thx to the choice of the GLFW library) so anyone still using LWJGL2 should start considering making the switch.

There is also LWJGLX for those that wish to test out a LWJGL2 codebase on LWJGL3 with minimal source code changes or as an example of how to emulate some of the LWJGL2 windowing behaviour in LWJGL3.

Looking at the code you posted there doesn't seem to be any declaration of it being the core package which could be why you are getting that error.

Also one cool thing with LWJGL3 is that you do not need to point to the exact folder containing the system specific natives (in org.lwjgl.librarypath or java.library.path), you can just point to the LWJGL natives folder and it will automatically pick up the relevant natives from the linux, window, mac sub folders. Pretty useful when using the same workspace across different platforms as you do not need to change the native path once set.

I've been working on a LWJGL2 compatibility layer which runs on LWJGL3 (allows running LWJGL2 apps with very little source code changes). I did attempt to use it to port LibGDX to LWJGL3 (the audio part should work), however ran into a problem as LibGDX's LwjglApplication class seems to want to run LWJGL on a secondary thread which didn't sit well with GLFW. Ended up giving up after that point, did however get jMonkeyEngine3 working with it .

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