Neither can I imagine any reason for such an Exception nor does it make any sense: new File() cannot return null, File#listFiles() should not return null but an empty array and pure iterating over an array shouldn’t cause any trouble at all.
Can you try backupping and then deleting your contents in C:\Users\James\AppData\Local.jmonkeyplatform (-installer)?
Unforunately, File.listFiles() can return null in some cases. From the javadoc:
“Returns null if this abstract pathname does not denote a directory, or if an I/O error occurs.”
I’ve seen this in my day job from time to time and it’s a pain. For us it was always file permission issues.
Assuming I’m driving this release, the process will be similar to that for 3.2.2, only without a beta release.
I’ve set a cutoff of 17 March for all changes destined for this release to be integrated into the master branch. Pull requests should allow extra time for discussion and integration.
Expect more details as the cutoff date approaches.
Will this commit make it in? @TheLeo has made an amazing library (SevenSky) that is unfortunately difficult to use at the moment due to this commit not being in any current releases.
Not trying to be hard-sell, although I would like to see this in a release sooner rather than later (lots more use for something like this than just SevenSky).
Couldn’t tell you off the top of my head, although I am under the very possibly mistaken impression that luminance values might be treated specially by drivers. In any case, even if they are functionally identical there’s value in having a more obvious/familiar representation of intent (luminance means something very specific, but color channels are often repurposed for other values). In any case this exposes 16 and 32 bit single or double channel floating point textures, which strike me as quite useful in general (in fact, adding RGB/RGBA 16/32 bit textures would probably be a good idea at some point if there’s well-defined support for these - don’t recall what the GL spec says about those off the top of my head).
Well don’t get me wrong, for what it is worth i would agree to add every supported format, but i want to point out that if you use core profile (and you should) Luminance32f is actually GL_R32F since luminance textures are deprecated.
Per Khronos, They have been removed in OpenGL 3.1, and some driver providers (OSx and the mesa team) are moving toward non-support for older versions of the spec, if they have not already removed it.
The commit was merged to master 9 months ago. I didn’t realize it made the library hard to use atm. On other hand, I am definitely for including the commit. Its very small and low-risk. It consists of just 8 lines of code and rest is Javadoc I think. And yes, as Riccardo said, Luminance is deprecated.
Since this commit hasn’t made it to a release, SevenSky can’t be used without building the engine from master. For those of us who prefer to develop against a released version this isn’t the best state of affairs. Not a showstopper - in my case I probably should have a local build anyway, so that’s what I ended up doing. On the other hand I could definitely see this being a deal breaker to some other folks.
Since this is a low/zero risk commit it would be great to have released.
Thanks for making SevenSky! Really looking forward to trying it out. I read your thesis and downloaded a copy to my must-read collection of papers.
I plan to publish a preliminary cherry-pick list to Google Docs this weekend. Interested parties will then have 2 weeks in which to comment. It’ll be a living document, since new commits to master branch will be considered right up until the 17 March cutoff.
You can’t edit this document directly. However, I welcome constructive feedback, particularly regarding the following commits whose inclusion status is currently “to be determined” (TBD):