Code: Add the following to MaterialState at the top
public static MaterialState prevState
Add the following to LWJGLMaterialState.apply() at the top.
if (MaterialState.prevState == this) return;
MaterialState.prevState = this;
Extend this for all the render states. Automatic RenderState sharing. I don't *see* any conflicts, but would require testing. I bring this up because it's tied very closely to the Clone idea.
Another idea was to use .equals() instead of == , but I believe the overhead of calling the equals function in ratio to the probability that two completely different states happen to be the same may not be worth while. Can take ideas on that though if needed.
Cep, perhaps you are not aware but the code already does this at the class level… Please see Geometry.applyStates() Your addition likely skips the if (parent != null) Spatial.clearCurrentStates(); part of that method which might be outdated and need removing, but your proposed additions are redundant in any case.
In the other thread I was thinking for some reason you were comparing internal properties of material state.
Yeah, I believe that’s a bug and the code is actually supposed to be ==. I’ll look into that.
Regardless, please spend some time looking through the code first before posting a change affecting numerous classes. If != is a bug, you could have been a hero for finding that.
Well I did look through the code, and it wasn’t doing what I suggested. I’m not psycic here, so how am I suppost to know intent } It looks like == will work.
Just remember, there is a strong framework layed down, written by some fairly smart people (some more than others ), if something doesn’t seem right, ask, you probably found a bug. Frustration levels tend to get MIGHTY high when rewrites are suggested to systems that are in place but just require some tweaking. This is why I want non-framework devs to focus on adding features, while Renanse and I will handle core improvements.
And, if an improvment is found, by pure accident when lets say working on Clone ideas, that could speed up an application by 30+ FPS, what is the proper order that one should go through to bring this to light?
Your previous thread woiuld be a fine place to thoroughly talk out ideas and possible improvements. Once you have thought it out and taken assignment of the task from Mojo, then you’d post in this forum. If that thread had continued, your ideas would have brought to light the existing functionality of the system.
Ok, this is fixed. The idea is that clear is suppossed to be called any time you are changing context (like in renderToTexure) to prevent the code from thinking a state is set when it isn’t. It now only calls this before and after rendering to texture. Speed increase is evident and flicker issues are gone (they came up when trying to switch to =:). The clear is removed from Geometry.
It looks like == will work.
), if something doesn’t seem right, ask, you probably found a bug. Frustration levels tend to get MIGHTY high when rewrites are suggested to systems that are in place but just require some tweaking. This is why I want non-framework devs to focus on adding features, while Renanse and I will handle core improvements.