Github master branch working?

Hi fellows,

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 :slight_smile:

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 …

Could be grafic driver stuff as well, also the lwjgl version might habve changed in master maybee an additional source of bugs :P?

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.

Note: asset manager has always cached.

I kinda fell that you might have relied on a buggy behaviour all the time, and it now triggers due to the changes.

Maybe you can run your app in OpenGL debug mode, e.g.

AppSettings settings = new AppSettings(true);
settings.putBoolean("GraphicsDebug", true);
app.setSettings(settings);

EDIT: Regarding AssetManager caching, I don’t recall of any changes happening there, so not sure how it is related.

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’ll check that out. Thanks :slight_smile:

How have you determined this?

If you are not doing anything strange with JME or (ugh) directly to lwjgl then you really shouldn’t have this kind of issue.

Can you put together a simple test case that illustrates the problem?

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 :wink:

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 seems like the more likely cause is an unset vertex attribute buffer or unset texture… these might have accidentally worked before due to garbage hanging around in the right place.

Other than you doing a diligent audit of your code, I’m not sure how to suggest you go about finding such issues, though. I don’t know what the debug mode does… maybe it helps with stuff like that.

Debug mode checks the OpenGL error code after each GL call, also it will enable OpenGL to generate more verbose output regarding what’s going on internally.

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.

Maybe I used it wrong but not a single additional log line was printed when I used this setting. Sure it’s “GraphicsDebug”?

I temporary removed the direct buffer deallocation that I added but nothing changed. Does JME also deallocate direct buffer now?

Can you give me the revision that worked with you? That way I could quickly check if there really is a problem with the current revision.

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.

So there is still an official SVN repo alongside the GIT one?

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.