LWJGL 2.8.5

[Matzon]

The LWJGL team is proud to present the latest release of the fabulous LWJGL: 2.8.5

LWJGL 2.8.5

LWJGL:

   
• Fix: Matrix*f.negate(Matrix*f dest) methods in Matrix2f, Matrix3f and Matrix4f classes
• Fix: issue with get x/y returning client-area coords (Windows)

OpenAL:

   
• Fix: Changed ALC10's alcGetString and alcOpenDevice to use UTF8 decoding/encoding
• Fix: Updated to nightly openal-soft (785f52aa29d...)

   
OpenGL:

   
• Add: Support for OpenGL 4.3 and OpenGL ES 3.0
• Add: Support for AMD_shader_trinary_minmax, INTEL_map_texture and NV_draw_texturem EXT_multiview_draw_buffers, AMD_sparse_texture, APPLE_sync, EXT_copy_texture_levels, EXT_map_buffer_range, EXT_shader_framebuffer_fetch, NV_compute_program5, NV_shader_storage_buffer_object, NV_shader_atomic_counters, NV_deep_texture3D, QCOM_binning_control, AMD_query_buffer_object
• Fix: GLContext.getCapabilities throw a RuntimeException instead of returning null when there's no GL context current in the current thread
• Fix: Removed some re-defined GL11 enums
• Fix: Removed ARB_debug_group, ARB_debug_label and ARB_debug_output2

OpenCL:

   
AppletLoader:

   
• Fix: NumberFormatException when parsing version string on an EA or beta JVM

Input:

   
• Fix: KEYBOARD_SIZE issue
• Fix: Translate extended keys before the state check
• Fix: Lost key up events when Display is out of focus (Windows)

   
Eclipse:

Download: https://sourceforge.net/projects/java-game-lib/files/
Changelog: http://www.lwjgl.org/changelogs/2.8.5-changelog.txt

Remember to donate

Notice: We'd like to remind people to include the copyright, conditions and disclaimer statement for LWJGL in their products, as required by the license. Though we are not about to claim foul in any way, it would be nice to see a link back to lwjgl.org in the credits or documentation at the very minimum.

[CodeBunny]

Nice.

Btw, what's the current status on 3.0? I've seen several references made to it.

[Matzon]

Btw, what's the current status on 3.0? I've seen several references made to it.

afaik, no work has been done on 3.0. Current focus is on getting osx and java7 to play nicely.

[erlend_sh]

(...) Current focus is on getting osx and java7 to play nicely.

Maybe that should be made clear in the release thread as well, for instance under a "Known Bugs" heading. Anything to attract more testers

[princec]

Nice one Matzon. I feel guilty in my neglect.

Cas

[Matzon]

Tbh, I wouldn't mind getting more people involved (not necessarily you, but in general). A lot of the code doesn't even require c/c++ knowledge - it's just normal java code.

[spasi]

I've allocated 3-4 weeks of my time to do the initial work for 3.0. I'm currently wrapping things up in my other projects and waiting for the MacOS changes to stabilize, so should start soonish.

One thing we need to do to attract more contributions is move the codebase to Git and host LWJGL on github, asap. Git is more powerful and popular than SVN (I honestly only use SVN for LWJGL, all other OS projects use Git or some other DCVS), it would be very convenient for potential contributors to not have to go through SVN's shitness. Also, github's pull request automation is too awesome.

[kappa]

@spasi that sounds really cool, please if you could start a new RFE thread so that we can start listing, discussing and narrowing down what 3.0 will and will not be. Should help focus where we want to go. Also got a list somewhere in one of my projects where I've been storing API complaints that ppl have been complaining about over the years which we can fix in 3.0.

As for GIT, SourceForge also supports that now, not sure if its any good compared some of the more hyped services like GitHub and BitBucket. However one could still argue that SVN isn't broken and still works well enough but still its slow now, no built in support in Eclipse and all the cool kids are using Git now.

[l3dx]

+1!

One thing we need to do to attract more contributions is move the codebase to Git and host LWJGL on github, asap. Git is more powerful and popular than SVN (I honestly only use SVN for LWJGL, all other OS projects use Git or some other DCVS), it would be very convenient for potential contributors to not have to go through SVN's shitness. Also, github's pull request automation is too awesome.

[spasi]

@spasi that sounds really cool, please if you could start a new RFE thread so that we can start listing, discussing and narrowing down what 3.0 will and will not be. Should help focus where we want to go. Also got a list somewhere in one of my projects where I've been storing API complaints that ppl have been complaining about over the years which we can fix in 3.0.

Yes, I've been planning to do that. I have a list of my own too, we should merge all the pending issues and agree on the best way to move forward.

[Matzon]

As for GIT, SourceForge also supports that now, not sure if its any good compared some of the more hyped services like GitHub and BitBucket. However one could still argue that SVN isn't broken and still works well enough but still its slow now, no built in support in Eclipse and all the cool kids are using Git now.

We still rely on the SF file release stuff - but I guess both can be used? - Git on github and SF for actual releases.
Either way, we should go all in. I don't want to maintain multiple repositories.

[mc78]

FWIW: I already have my personal svn mirror on GitHub for anyone wanting to try it out. I've imported all the SVN history and branches too so you can git blame at will and it's just as complete as the svn repo.

If you want to take it for a spin to see what the move could feel like for new contributors and also see how the history remains intact:
http://github.com/mcunha/lwjgl

I used svn2git to complete the migration of all the history so you have proper tags imported. There's not much science involved, but I'll be happy to help with migration anyway I can. Workflow with github and git is just that much easier for distributed teams without having to fling patch files at kappa or worrying that my commit will break main repo.

[jakj]

I'm a newbie-nobody, but I thought I'd chime in that I have nothing against GitHub but I really like SourceForge and what they've done for the community over the years.

Also, not having to use the alphabet-soup crap that is the default GL commands most of the time is really nice, and I'm disappointed about moving away from that (though I understand why). I think it's much cleaner and more readable to do glUniform(id, (float)0, (float)6.1) (and even more clear using parameter values instead, so they're already cast) instead of glUniform2f.

I also am going to miss being able to do things like glGetUniformLocation(Id,"Name"). To do GL subroutines, I basically had to copy code from APIUtils and reimplement it, because glGetSubroutineIndex and glUniformSubroutinesu require buffers (and oh lord, is that 'u' at the end of that name confusing and annoying).

Like I said...I read the rationale posted about switching back to the GL-style names, and I can't disagree with your reasoning...but I still prefer the cleaner way. I just see those weird names as a hack to get around C's lack of typing which Java has.

[matheus23]

Just have seen the last sentence you posted (in the topic), and now included a link to lwjgl.org on my github project.

I also wanted to tell you, that I'd really appreciate a move to github, as you can see I really like it.

And I look forward to LWJGL 3.0, sounds promising!

[spasi]

Also, not having to use the alphabet-soup crap that is the default GL commands most of the time is really nice, and I'm disappointed about moving away from that (though I understand why). I think it's much cleaner and more readable to do glUniform(id, (float)0, (float)6.1) (and even more clear using parameter values instead, so they're already cast) instead of glUniform2f.

I also am going to miss being able to do things like glGetUniformLocation(Id,"Name"). To do GL subroutines, I basically had to copy code from APIUtils and reimplement it, because glGetSubroutineIndex and glUniformSubroutinesu require buffers (and oh lord, is that 'u' at the end of that name confusing and annoying).

Like I said...I read the rationale posted about switching back to the GL-style names, and I can't disagree with your reasoning...but I still prefer the cleaner way. I just see those weird names as a hack to get around C's lack of typing which Java has.

I'm a bit confused, what post are you referring to? The way LWJGL handles the GL/CL/AL APIs is the best thing about it imho and I don't think there's been any plan to change that. I also absolutely love the alternative signatures, that's why I added them in the first place.

As for the two subroutine functions you mentioned, that was simply an omission on my part, they've been added now. Feel free to report any other functions that miss alternative signatures.