Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

[1.8] Weird Lighting Bug with RenderGameOverlayEvent

Recommended Posts


I hook into RenderGameOverlayEvent, and check for ElementType.ALL to ensure everything only renders once. The event is lowest priority, so it should render last. Within the event I render several things to the GUI, including text, items, textured quads, and some transparent textured quads. The transparency seems to break the rendering engine somehow, because whenever I render anything with a transparent colour, the following happens to the hotbar and every other transparent part of the HUD:


Everything gets weirdly bright, and I can't work out what's causing it. It seems to correspond with the day/night cycle, since at night this stops happening. Do I have to disable the day/night lighting system somewhere?


I've tried various combinations of the following set of lines:


GL11.glColor4f(1.0F, 1.0F, 1.0F, 1.0F);


Along with trying to bind textures, enabling and disabling GL_LIGHTING or GL_TEXTURE_2D. All the usual fixes don't seem to work here.


Does anyone know what's going on? What's interesting is that depending on the ElementType, sometimes this doesn't happen. However, every type I've tried so far has screwed up another part of the vanilla HUD somehow.


None of my rendering methods contain any code outside of vanilla functions (drawTexturedModalRect, drawString, bindTexture...) and the OpenGL functions above - I have also used glPushMatrix and glPopMatrix when necessary.


Thank you for reading.

Link to post
Share on other sites



Looks like your rendering methods are messing with one of the rendering settings.  There are quite a few of them.


You could try using   


.. your render stuff here...





.. your render stuff here...




glPushMatrix only stores the transformation matrix, glPushAttrib can be used to save rendering settings too


Failing that, I'd suggest you narrow it down as much as possible and then look to see exactly which vanilla code is changing rendering settings.  I don't think it's likely to be texture binding.  The day/night suggests you have turned world lighting on somehow.  The glPushAttrib should fix that.



Link to post
Share on other sites

No luck. I was already using glPushAttrib and glPushMatrix. I tried removing them, and interestingly, removing glPushAttrib and glPopAttrib (GL_ALL_ATTRIB_BITS) actually fixed the problem... Partially. When I did that, the problem appeared whenever I was looking at the skybox and not the terrain, then went away again afterwards. However, since I do change some GL states during my rendering, I can't keep it like this (and it only makes more errors, anyway...).


So, I started removing parts to see if the error would fix. In the end, I managed to narrow the entire problem down to Minecraft's vanilla function, Gui.drawRect.

I managed to narrow down my entire rendering code to the following, and the same problem persisted:

@SubscribeEvent(priority = EventPriority.LOWEST) // We want this to render last out of everything
public void onRenderTick(RenderGameOverlayEvent.Post e) {
if(mc == null) mc = Minecraft.getMinecraft();
if(fr == null) fr = mc.fontRendererObj;
if(ri == null) ri = mc.getRenderItem();

if(e.type == RenderGameOverlayEvent.ElementType.ALL) {
	if(mc != null && mc.ingameGUI != null && fr != null && mc.thePlayer != null) {
		glPushAttrib(GL_ALL_ATTRIB_BITS); {
			glPushMatrix(); {
				GL11.glColor4f(1.0F, 1.0F, 1.0F, 1.0F);

				mc.ingameGUI.drawRect(5, 5, 105, 105, 0xaaffffff);

Removing that one call to drawRect solves the problem, but then of course I'm not rendering anything. Drawing strings, interestingly, does not cause the problem.


Looking into the code from drawRect, the only rendering code is the following:

float f3 = (float)(color >> 24 & 255) / 255.0F;
float f = (float)(color >> 16 & 255) / 255.0F;
float f1 = (float)(color >> 8 & 255) / 255.0F;
float f2 = (float)(color & 255) / 255.0F;
Tessellator tessellator = Tessellator.getInstance();
WorldRenderer worldrenderer = tessellator.getWorldRenderer();
GlStateManager.tryBlendFuncSeparate(770, 771, 1, 0);
GlStateManager.color(f, f1, f2, f3);
worldrenderer.addVertex((double)left, (double)bottom, 0.0D);
worldrenderer.addVertex((double)right, (double)bottom, 0.0D);
worldrenderer.addVertex((double)right, (double)top, 0.0D);
worldrenderer.addVertex((double)left, (double)top, 0.0D);

Nothing here appears out of the ordinary, right? It enables, then disables blending, same with texture2D but reversed. Fiddling with blending or texture2D does absolutely nothing in my rendering code, regardless of whether I use MC's "GLStateManager" or just pure GL11 functions. Only thing I can think of now is the "tryBlendFuncSeparate" function, which I doubt would cause an issue... I'm completely stuck for ideas.


EDIT: drawTexturedModalRect also doesn't cause the problem (the last bound texture before my method was the font texture, if it's useful).

Link to post
Share on other sites

Well that's frustrating.  I'm out of ideas unfortunately.  The GLStateManager pushAttrib and popAttrib functions are buggy (they don't dirty the cache properly) but if you're not using that, then I don't know.


I've previously used this troubleshooting class to help track a similar problem


i.e. call dumpAllIsEnabled() before & after, then look for the difference


In your case I doubt it will help though.


You could try copying drawRect into your own class, and slowly whittling down further until you get to the statement which causes the issue.  Apart from that I'm stuck, sorry!




Link to post
Share on other sites



"You could try copying drawRect into your own class, and slowly whittling down further until you get to the statement which causes the issue.  Apart from that I'm stuck, sorry!"

Before I saw this post, this is what I started doing. I copied over drawRect into my own RenderUtil class and, as you said, whittled it down. Somehow, that came up with a solution.


Now, what I find most baffling is what was causing the problem. It was with this line:


Even though all I could find in this method was a lot of abstraction from GL11.glEnable(GL11.GL_BLEND), removing that line and replacing it with glEnable directly somehow fixed the problem. (I also removed the disabling blending part, because I imagine other parts of the GUI need blending enabled, e.g. chat).


Weird how MC's own rendering manager can cause such a glitch, when it has such a simple task to do. I couldn't even find another line of active code that would have changed anything, just lots and lots of wrapper. Anyway, it's a solution, I don't know why it's a solution, but it is. Thank you for your help, TheGreyGhost.


EDIT: Not really a solution... Sigh.

I was so happy having fixed this thing, I thought everything was great, then I typed something into the chat.

The back of the chat box (which is translucent) now has the same issue. I have nothing but my own version of drawRect in my render method now, with all the methods from GlStateManager replaced with raw GL (I don't trust that thing anymore...). I've tried just leaving GL_BLEND replaced, to no avail. When the time is evening, I look towards the sunset and the chat box becomes orange tinted, and I look away and it goes blue again. This pretty much confirms the skybox is definitely interfering with rendering somehow. But I'm not doing a single thing to let that happen.


Oh, and it's still affecting the hotbar, after I've typed a message into chat.

Link to post
Share on other sites

Writing a new post here, because I think I actually do have a solution.


I updated Minecraft Forge... Turns out I must've been using one of the early development versions rather than any of the newer ones which work properly.

Why I hadn't tried that earlier, I can't fathom.

Link to post
Share on other sites

I'm back.

After a release of the mod, and me being sure everything was working perfectly again, I found out I was wrong. Here we are again, same issue, absolutely no reason I can think of why. Seems like putting any code at all into a RenderGameOverlayEvent causes the problem. Ugh...

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing

    No registered users viewing this page.

  • Posts

    • In order, X}   1.  (Force class to load, as was explained)  and was how it was shown.. I am up for 'changing it up' & optimizing it later,     That's  just the method that was shown.  I want to optimize it later for sure. 2.o_hand  ->   is offhand   I got sick to death of doing typos, and used it & m_hand for main hand ...   (offhand is the shield slot typically) 2. .... actually [ target = (LivingEntity)event.getTarget(); ]  inside of  (AttackEntityEvent event) is 100% capable of causing an error. -- Try setting it up & smacking with any melee attack (fist or weapon) the following a.  Any Minecart b. Any End Crystal c. Any Item Frame. d. Any Boat    ----  it literally causes the game to close with an exception.   All those things can both 'trigger the attackEntity event'  and be inside the target of the player, which will cause an exception when cast into a (Living Entity), which was used to apply the potion effects... ~~ Strangely enough,  a armor stand  not only is uneffected by it, but can accept potions applied to it as well. 3.  It does do something,  It fails & does nothing, which means 'target' is null still, and no potion effects get applied to the target that was hit. --- which means, it prevents the game from being shut down from an unintended casting of a target into a living entity object (which is needed to apply potion effects on) 4.  That's just nitpicking really,  That's an old logic habit....    Some reason it slipped my mind,  either way,     (!(thing == thing)) same effect of (thing != thing)   ---likely I honestly fell back into an old habit when inverse of true statement was my thought on that. 5. I know...  It's not complete (i've not  finished the blocks, as I'm working towards combat centric things, and I'm debating what I want to do with it) --- also,  to note, I remember why I put try { atker = (LivingEntity)livi.getAttackingEntity(); } catch (Exception e) { }  (for future use)      things like minecarts & end crystals can harm the player & other entities, and that event fires when an entity get hurt.... and given I just got off of just randomly finding out that casting the target of my hit into a (living entity) object can cause fatal exceptions, it's there to 'do NOTHING' if that happens, and an prevent fatal exceptions from going off because of a weird entity causing damage that isn't a livingentity for some reason. ~~~  Yes I plan to use it later..    that was for an armor thing. 6. meh...   Again   alot of the primary page is tutorial code....   I left what was shown,  and I'm learning what does what.. .and pruning what doesn't work.    -- yes, it annoys me as well but that's not on the short list atm. 7. as for 'fall = falls'  . I don't like doing that, as i prefer the geniune fallback if some unknown reason happens  a valid variable gets assign (right or wrong) and prevents weird unknown errors. 8.  The method is 100% straight forward    It's just a nested if loop that of course tests each string once (effectively) and doesn't attempt to assign an empty tooltip. _NormToolTip Is on it w/ no shift or cntl held down (either one) _When shift or cntrl is held down,  it shows the correct one. _When Shift & Cntrl are held down.. it shows Cntrl over Shift. ---- to be fair I actually didn't think to check for a method that checks if  a string is empty. ~~~  It uses Exclusionary logic, but if you can think of a faster way of doing  -normal tooltip (no keys held) -Shift Tooltip (either shift held) -Cntl ToolTip (either Cntrl held) -Cntl tooltip over  Shift tooltip (when a Cntrl & Shift is held, either side)  I'm all ears if you think you can do that faster and prevent it from using a null value.
    • What I've been trying to do is I have been attempting to implement an item that can create a transparent blue layer around the entire player. I am using Curios' API for this, as the item is meant to be an equippable accessory. There are also other accessories I have implemented to the mod using the API. I have been able to implement everything that handles this rendering with the accessory item, however I've become stuck after running into a specific issue: when the transparent blue layer is active, it will prevent any accessories specifically on the player's arms from rendering. As far as I can tell, this only happens with the accessories on the player's arms (such as the gloves or even Curios' template knuckles item), as accessories rendering on the player's body for some reason render just fine under the transparent layer. Images for better context: I have been at this for quite awhile but haven't able to figure out what is causing this issue, especially since the inconsistency between rendering for body parts has made me even more confused. It could be a Curios issue, but nothing in its accessory layer code exactly stands out as a cause (if it is indeed Curios' fault though it would at least be good to know what the issue is to pass on to the mod dev). The pendant and glove accessories both render with the same RenderType and render buffer, which I duplicated based on the vanilla armor layer's choices for that, as the vanilla armor layer is also immune to the transparency issue on the arm model part: The relevant code for items and renderers can be found below: Pendants: - https://github.com/Gilded-Games/The-Aether/blob/1.16/src/main/java/com/gildedgames/aether/common/item/accessories/pendant/PendantItem.java - https://github.com/Gilded-Games/The-Aether/blob/1.16/src/main/java/com/gildedgames/aether/client/renderer/accessory/model/PendantModel.java Gloves: - https://github.com/Gilded-Games/The-Aether/blob/1.16/src/main/java/com/gildedgames/aether/common/item/accessories/gloves/GlovesItem.java - https://github.com/Gilded-Games/The-Aether/blob/1.16/src/main/java/com/gildedgames/aether/client/renderer/accessory/model/GlovesModel.java Repulsion Shield (the item creating the transparency layer): - https://github.com/Gilded-Games/The-Aether/blob/1.16/src/main/java/com/gildedgames/aether/common/item/accessories/misc/RepulsionShieldItem.java - https://github.com/Gilded-Games/The-Aether/blob/1.16/src/main/java/com/gildedgames/aether/client/renderer/accessory/model/RepulsionShieldModel.java and, if necessary, Curios' Accessory Layer (code not mine, obviously): - https://github.com/TheIllusiveC4/Curios/blob/1.16.x-forge/src/main/java/top/theillusivec4/curios/client/render/CuriosLayer.java Any help would be appreciated, as I've run out of ideas for what could be causing this issue and how I could fix it. I can provide more information if needed.
    • Ok that's fair. But it's still terrible.
    • Really old Minecraft versions are no longer supported on this forum. Please update to a modern version of Minecraft to receive support.
    • Ah sorry, you're right. I can refer you to the way Lycanites renders all of their .obj model entities, and best of all it's up to date for 1.16, but it is pretty complicated than just your standard java model. Depending on what you're doing it might not be worth it... https://gitlab.com/Lycanite/LycanitesMobs/-/tree/master/src/main/java/com/lycanitesmobs/client
  • Topics

  • Who's Online (See full list)

  • Create New...

Important Information

By using this site, you agree to our Privacy Policy.