The LWJGL team is proud to present the latest release of the fabulous LWJGL: 2.8.5
LWJGL 2.8.5LWJGL:
- 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 (http://lwjgl.org/donations.php) ;)
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.
Nice.
Btw, what's the current status on 3.0? I've seen several references made to it.
Quote from: CodeBunny on November 04, 2012, 19:50:33
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.
Quote from: Matzon on November 04, 2012, 19:54:10
(...) 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 :)
Nice one Matzon. I feel guilty in my neglect.
Cas :)
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.
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.
@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.
+1!
Quote from: spasi on November 05, 2012, 11:15:07
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.
Quote from: kappa on November 05, 2012, 11:54:25@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.
Quote from: kappa on November 05, 2012, 11:54:25
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.
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.
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.
Just have seen the last sentence you posted (in the topic), and now included a link to lwjgl.org on my github project (https://github.com/matheus23/WorldOfCube).
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!
Quote from: jakj on November 06, 2012, 14:18:27Also, 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.
We migrated libgdx to github and so far it has been awesome there have been a lot of new contributions and using the pull request system is quite nice, you can see the proposed changes, comment on them, ask them to fix something and the pull request is automatically updated. In my experience the change to github is much more than the change to git, so I would vote for going to github instead of just using git in sourceforge.
P.S. I already made the 2.8.5 release of lwjgl in maven central, but it hasn't been synced yet
Quote from: spasi on November 06, 2012, 16:27:34
Quote from: jakj on November 06, 2012, 14:18:27Also, 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'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.
I'm referring to this: http://lwjgl.org/forum/index.php/topic,4721.0.html
Perhaps I'm just overreacting and read too much into that post. If it's done only because overloading can't account for return type as part of the signature, then hey, that's the right thing to do, but I had been under the impression that the API in general was going to change back to the GL-style names.
Yes, that change affects glGet functions only. Nothing else will be modified.
Quote from: spasi on November 07, 2012, 07:39:55
Yes, that change affects glGet functions only. Nothing else will be modified.
My apologies for jumping to conclusions, then: Keep up the good work. :-)
When is the "3.0 RFE discussion" thread going up? I'm curious what the current ideas are.
Quote from: Matzon on November 05, 2012, 08:13:19
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.
Is there any roadmap/feature list for what to do. So that interested developers can think about contributing to the project?
not really ... there is the 3.0 thread though: http://lwjgl.org/forum/index.php/topic,4800
Quote from: Evil-Devil on November 13, 2012, 11:12:55
Is there any roadmap/feature list for what to do. So that interested developers can think about contributing to the project?
Yeh the 3.0 thread above is the direction we are heading but there is also the BUG/RFE forum, it has a list of bugs and various requests for enhancements, just pick a thread in there and fix or implement it, probably the best way to start contributing.