I wanted to add some functionality for TextureArrays to JME (see Update of TextureArrays - #3 by pspeed), so I checked out the master branch of JME. But now my game behaves totally strange. Textures are not in place, I get random IllegalStateExceptions (“Framebuffer attachments must have same dimensions”) etc.
So I have to ask if the Master branch is at all stable enough to work with? I mean I read that it should not be used for production, but is it really that instable or is my code just overfitted to the stable 3.0 version?
(Screenshot for your amusement [that thing is supposed to be the sun]: )
There are breaking changes in master yes. It’s not stable by definition, yes. But what you see doesn’t necessarily means it’s broken, it may just not be compatible.
Hard to say what’s exactly wrong in you shot, could you tell more of what you use? (stock lihghting?, custom shaders? etc…)
And a screen shot of what it should look like could help too.
Well i usually use the master for my own project, so it is acceptably stable. From time to time stuff breaks, but it generally works and has some bleeding edge stuff like tesselation wich makes it up for me
Hmm, I’m using a lot of custom stuff, like shaders, custom lighting etc. so there is a lot to rule out I suppose. (Here http://screenshots.xcylin.com you can see how the game normally looks like, please note that also the colors are wrong in this screenshot but that’s because of the class that handles the screenshots, obvioulsy it is also not compatible with the master branch)
Tesselation, nice! I guess that some of the problems are caused by my project’s code. I do a lot of optimization under the hood (also multithreading), so maybe that breaks something. I’ll try to figure out what causes the problems, but some of them are hard to debug, because when I get for example the “Framebuffer attachments must have same dimensions” exception, the framebuffer settings look good, so this could be a race condition or something …
True, but because the graphic driver worked before the upgrade to master, I tend to exclude it from the list of possible suspects. About the LWJGL, I tend to agree that there might be bugs, but at the moment I’m tracing the texture problem and I think the textures don’t get bound to the context correctly. Might have something to do with the newly(?) added caching in the assetmanager. At least there must be some reason for some textures to suddenly get unbound/corrupted.
I thought so, still there were a few new methods and I also had some caching in place (because I needed to remove items from cache which was not possible in the old assetmanager), so I started there. But it turned out, that it seems to have nothing to do with that at all.
Yes I think so, too. Is there any typical behaviour that normally leads to texture problems? My next debugging step would be to check if any texture id is handed out twice.
I’m guessing from what I see at the moment. Some textures seem to be correctly bound and after a few camera movements (and most likely other stuff that’s tied to it) the textures of some geometries suddenly are distorted (like the sun in the above image). And no: I don’t use LWJGL directly - I know where to draw the line
I tried to, but the game is quite complex. Until now I was not successful in reproducing the behaviour in a simple test app.
It does occur to me that I haven’t personally updated and run against the JME render in a while… not since the URA changes.
OP, once you’ve reasonably ruled out any issues in your end, you could also try back-reving your JME checkout and trying to isolate the commit that causes the issue. I know it’s painful… as I’ve done it before myself for 18 months of commits once… but if it is a bug in JME then this would help find it. And even if it’s not a bug in JME, knowing which commit broke your game would help figure out what broke.
It’s difficult to say because I use an svn checkout of JME git for my day-to-day operations because git still makes me want to break things. From SVN’s perspective, my JME renderer package is still at “Revision 4903”. I don’t know what that means in GIT terms.
Edit: the timestamps on the files are from December 2014… so just a few months old.
For the texture problems: I narrowed it down to my own shaders. Yes plural. What are the changes made to the shader architecture in 3.1? I might not be the only one with problematic shaders as the nifty gui is also having some trouble displaying the font correctly:
This is supposed to be a console. But of course it is also possible that one of my shaders is interfering with nifty’s shader. The only question is: in what way???
I think I stop here for today and continue my bug hunt tomorrow. At least I was able to narrow it down a bit.