fnuecke
commented
4 years ago This is awesome! Thanks so much, I really appreciate it :)
I'll browse through the changes, but don't expect me to be able to tell you anything when it comes to 1.15, I expect I'll learn a lot from the diffs myself.
I did give it a quick start, and looks good indeed!
Responding to the dynamic overlay drawing, it was really nice to have while it worked, but I totally agree that it's not a must-have and everything that goes toward better render performance has my vote anyway, so that's cool. Will be interesting to see if that z offset may need more bumping if we get people with a variety of graphics cards to use it; in my experience there's a chance for a bit of variance on different systems Nevermind, seems to be same offset used in the casing renderer, so should be fine. I suggest making the one with the bump a separate method, so callers can decide for themselves if they need it, i.e. if the caller is sure the things on the same layer don't overlap (e.g. border outline and inner parts)?
ROM/RAM copying - hmm, to make sure we're talking about the same thing: copying the contents of a RAM module on a casing into a ROM module held in hand? That seems to work for me though (sneak rclick = copy to hand, regular rclick = copy from hand). In your branch. Did you fix that since? Am I missing something?
Sturmlilie
Do not merge, this PR is against the 1.14 branch!
Hi! I took it upon myself to port the fabric branch to 1.15.2. This is my first time doing anything with MC modding / fabric / Java. The branch is not yet in a state to be merged, but it's very playable at this point and so I wanted to get an initial round of feedback before I progress. The biggest changes in 1.15 were rendering related, and so this is also what most of my code touches. I've made incremental changes in order for every commit (except the first few ones) to build and load, so if I replaced a certain interface, often I left the old methods in tact for the code to still build (eg:
RenderUtil:drawQuad); eventually those old interfaces will be removed when their last user is gone / converted.At this point every module renders (albeit with some caveats), and the core game mechanics are intact. There were a couple apparent behavior bugs (~like copying ROM from RAM modules~) that I haven't touched yet because they also appear in the 1.14 branch this is based on.
Things that are explicitly broken by me:
RenderLayersstill apply the legacy OpenGL lighting so there is a slight variance between eg. a module on top of a casing vs on one of the sides.glDisable(GL_LIGHTING)), which worst case I can inject a custom cutout entity renderlayer with lighting turned off, but that would require a bunch of invasive Mixins and I'd rather try to get to the bottom of the issue first.~Regarding module overlay drawing
In the past this was done via immediate OpenGL and so the programmer had maximum flexibility. With the new render pipeline, submitted quads are not rendered on the spot and their ordering is also not defined, so instead of the painter's algorithm we have to either not overlap quads or rely on the depth buffer. I was able to mostly work around this by only drawing opaque quads and slightly bumping certain ones within the 0.005 Z-axis margin from the casing block (see CasingBlockEntityRenderer).
Now, if one wanted to keep that flexibility (which I wouldn't advocate for), all of the module overlay rendering would have to be moved to a dynamic texture, ie. every module get's their own X by X space on an FBO and draws their state in whatever fashion onto it, and the casing renderer then uses that to texture itself.
However, seeing how I was able to reproduce 90% of the modules with the existing approach, I don't think it's worth the hassle.
Note that most of the methods added by me lack javadoc comments; if there are no bigger rewrites necessary, I will comment as many as possible in a followup commit.
Please feel free to critique any part of my code, I'm trying to learn =)