Storage Drawers

Storage Drawers

151M Downloads

1.8-2.0.0alpha2 objects rendering with gray textures

kreezxil opened this issue · 18 comments

commented

I took the mod out and objects in the world rendered correctly again.

The grey texture can be seen on everything not just the drawers.

unlisted video: https://www.youtube.com/watch?v=DFIWpPKcigs&feature=youtu.be

commented

Is this just objects you mouse-over?

commented

What about the mod that puts the name and icon of a block at the top of the screen (Waila?). Does this still happen if you disable that mod?

Waila will catch and log errors while trying to draw the icon, and this usually leaves the GL in a weird state causing all kinds of funny graphics. Maybe there's an error somewhere in the middle of the minecraft log about that.

commented

That's NEI, I've long since disabled WAILA because of just that issue.

-----Original Message-----
From: "David Vierra" [email protected]
Sent: ‎5/‎5/‎2015 1:42 PM
To: "jaquadro/StorageDrawers" [email protected]
Cc: "kreezxil" [email protected]
Subject: Re: [StorageDrawers] 1.8-2.0.0alpha2 objects rendering with graytextures (#75)

What about the mod that puts the name and icon of a block at the top of the screen (Waila?). Does this still happen if you disable that mod?
Waila will catch and log errors while trying to draw the icon, and this usually leaves the GL in a weird state causing all kinds of funny graphics. Maybe there's an error somewhere in the middle of the minecraft log about that.

Reply to this email directly or view it on GitHub.

commented

Yes

-----Original Message-----
From: "Justin Aquadro" [email protected]
Sent: ‎5/‎5/‎2015 1:19 PM
To: "jaquadro/StorageDrawers" [email protected]
Cc: "kreezxil" [email protected]
Subject: Re: [StorageDrawers] 1.8-2.0.0alpha2 objects rendering with graytextures (#75)

Is this just objects you mouse-over?

Reply to this email directly or view it on GitHub.

commented

that comes from the Custom Selection Box by tennox at http://minecraft.curseforge.com/mc-mods/229349-customselectionbox

also, i have another update to this bug report.

When I take all of the items out of all of the storage drawers, the gray textures disappear. If put just one item in one storage drawer, the gray textures come rushing back. take that one item out and the textures quit happening.

I'll try disabling the Custom Selection Box and see what happens and report back to you accordingly. I'm uploading a let's play that shows this recent thing with texture issues, i'll give you link and time index on that when it finishes uploading.

commented

I've noticed a very subtle version of the issue with the vanilla wirebox. It wasn't immediately obvious but it turns the same shade of gray under certain circumstances. Specifically seems to be related to normal-item-render rather than block-render.

I'll have to track down what GL state the vanilla ItemRenderer is trashing and make sure I save and restore it properly. It took me 3 weeks to even release that flat item rendering in 1.7.10 because I had no idea the slime mob renderer was trashing some important piece of state. sigh.

commented

This is so disgusting. Mojang introduced a new GL state manager abstraction between the game and GL11. Not only does this risk running inconsistency between GL11 and the state manager, but the state manager itself can create inconsistencies within itself. I also can't query the manager's state.

Sorry, useless details. I just want to document my disappointment and frustration somewhere.

commented

It's good information. I'm developing a mod too and will likely come upon this issue later.

-----Original Message-----
From: "Justin Aquadro" [email protected]
Sent: ‎5/‎5/‎2015 11:22 PM
To: "jaquadro/StorageDrawers" [email protected]
Cc: "kreezxil" [email protected]
Subject: Re: [StorageDrawers] 1.8-2.0.0alpha2 objects rendering with graytextures (#75)

This is so disgusting. Mojang introduced a new GL state manager abstraction between the game and GL11. Not only does this risk running inconsistency between GL11 and the state manager, but the state manager itself can create inconsistencies within itself. I also can't query the manager's state.
Sorry, useless details. I just want to document my disappointment and frustration somewhere.

Reply to this email directly or view it on GitHub.

commented

The way I previously handled render state was pushing GL attributes onto the attrib stack that I knew would be modified, letting me easily restore the state to its original condition when I was done.

Mojang has provided its own version of pushAttrib and popAttrib in its GLStateManager class, which pushes/pops the GL_LIGHTING and GL_ENABLE bits in the underlying GL11 class.

The problem? Mojang does not push their own cached state in these operations. Modifying those bits through GLStateManager and then popping attribs in GLStateManager is guaranteed to fuck up GLStateManager's own state. Completely unbelievable.

commented

Is it possible to patch their function to make work correctly?

-----Original Message-----
From: "Justin Aquadro" [email protected]
Sent: ‎5/‎5/‎2015 11:30 PM
To: "jaquadro/StorageDrawers" [email protected]
Cc: "kreezxil" [email protected]
Subject: Re: [StorageDrawers] 1.8-2.0.0alpha2 objects rendering with graytextures (#75)

The way I previously handled render state was pushing GL attributes onto the attrib stack that I knew would be modified, letting me easily restore the state to its original condition when I was done.
Mojang has provided its own version of pushAttrib and popAttrib in its GLStateManager class, which pushes/pops the GL_LIGHTING and GL_ENABLE bits in the underlying GL11 class.
The problem? Mojang does not push their own cached state in these operations. Modifying those bits through GLStateManager and then popping attribs in GLStateManager is guaranteed to fuck up GLStateManager's own state. Completely unbelievable.

Reply to this email directly or view it on GitHub.

commented

ASM patching is always a thing, but one that I avoid at almost any cost.

If I ASSUME that GLStateManager is consistent when I get it (which I very much doubt in a diversely modded game), then I could ask GL11 directly for the current states, and then conditionally undo my changes on the state manager. I could also try to infer what the starting states should be at that point in the render chain, and just force them back to that. Either way, I need to have a good idea what bits are going to get flipped.

commented

I'm sure it boils down to a bad interaction between Storage Drawers and NEI. The pulsating highlight isn't something I recognize from vanilla or 1.7.10. Further changes in Vanilla's handling to particular GL attributes means everyone needs to debug them again.

At the moment, I can't get any of chickenbones' mods working in my dev environment, so it's a little hard to test. Can you try placing drawers with only basic items inserted, and separately, with only 3D blocks inserted? Do a full client restart between tests.

commented

Here's something to chew on.

NEI has the same behavior as Waila when rendering the icon into the HUD. It calls Minecraft's item renderer inside of a try...except block, logs the exception, and continues on as if nothing had happened. However, something did happen. The exception raised while rendering the item was very likely raised between a call to pushAttrib and popAttrib, or between setting a GL state and restoring it to its previous value. The GL state is now borked and info about the exception that caused it is buried somewhere in the middle of the minecraft client log.

I've looked at the rendering code for at least a dozen mods, and not one of them uses the try...finally idiom to ensure that popAttrib/popMatrix/any other cleanup code is called when an exception occurs. All of the rendering code I've seen is written as if no exceptions will occur between a push and pop, assuming that any exception will be fatal and shut down the game. StorageDrawers is no, um, exception.

There probably is an exception coming from your rendering code somewhere, and NEI is catching it and logging it, and the only symptom is the weird visual glitches. The exception apparently happens only while NEI is trying to call your item renderer and you'll have to dig into the client log to find it (or have a scrolling console window open so you can see it when it appears).

commented

I'm not going to comment on the GlStateManager because that shit is, frankly, crazy.

commented

Good News! Alpha 3 solves the issue! Good Job! 💯

commented

Surprisingly perhaps, the mod has never been reported to fail rendering items, hence I've not thought to guard anything.

I can't comment on NEI, but my own balanced use of push/pop attrib, as mentioned, caused this issue. WAILA, which has been reported to have similar issues, is probably doing the same thing. We're going to see this over and over again I'm sure.

commented

Thanks to your thoughts I have learned a great deal about some specific things to look out for during my own mod development. So don't stop be wordy, which is something I do as well as seen on my own blog at www.kreezcraft.com.

-----Original Message-----
From: "Justin Aquadro" [email protected]
Sent: ‎5/‎6/‎2015 7:06 AM
To: "jaquadro/StorageDrawers" [email protected]
Cc: "kreezxil" [email protected]
Subject: Re: [StorageDrawers] 1.8-2.0.0alpha2 objects rendering with graytextures (#75)

Surprisingly perhaps, the mod has never been reported to fail rendering items, hence I've not thought to guard anything.
I can't comment on NEI, but my own balanced use of push/pop attrib, as mentioned, caused this issue. WAILA, which has been reported to have similar issues, is probably doing the same thing. We're going to see this over and over again I'm sure.

Reply to this email directly or view it on GitHub.