[1.10.2] [SOLVED] Render progress bar for TileEntity (performance)

[Bektor]

Hi,

 

I'm wondering how I can render a progress bar for all my tile entities which store or generate energy which shows how much energy

they have stored.

My problem is now that I don't know how to only render this progress bar when the player looks directly at this block (so the bounding boxes are shown).

I also do not know how I can render this in the most efficient way, as nearly all my tile entities should render such a progress bar.

It is also to note that I don't have a tile entity yet which requires anything other than a simple json file or json model to be rendered.

 

My ideas are currently using a TileEntitySpecialRenderer for this purpose (thought I don't like the idea as it might cost a lot more performance than really necessary) or

go with the RenderGameOverlayEvent, thought I have no clue how this even works. I've only heard that Botania is using it

 

Thx in advance.

Bektor

Edited August 24, 2017 by Bektor

[draganz]

Since you mentioned Botania, I had a look, and from what I have seen, all you need to do is something along the lines of:

  Reveal hidden contents

/*
* To Note: IRenderStuff  should have the method renderStuff with the needed parameters for drawing. This method of 
* rendering a HUD (as Botania terms it) will overlay all other standard renderings, so should be a good choice. However, 
* while this is a retrofited piece of code from Botania's HUDHandler class, the code inside isn't anything special, so 
* don't worry about copying, once again, this isn't very special code (like a super-duper one-liner).
*/
@SubscribeEvent
public static void onDrawScreenPost(RenderGameOverlayEvent.Post event){//This class needs to be registered on  clinet side (i.e. yourrenderclass.class)
  if(event.getType() == ElementType.ALL){
    final Minecraft mc = Minecraft.getMinecraft();
	final RayTraceResult r = mc.objectMouseOver;
    
    if(r != null && r.typeOfHit == RayTraceResult.Type.BLOCK){
      Block block = mc.world.getBlockState(r.getBlockPos()).getBlock();
      if(block instanceof IRenderStuff){
       	final Profiler profiler = mc.mcProfiler;
        profiler.startSection("yourRenderThings");
        ((IRenderStuff) block).renderStuff();//TODO fill with needed parameters
        profiler.endSection();
      }
    }
  }
}
//Just for your reference, here is the IRenderStuff interface, just attach it to a block (or what ever you want to,
//depends on what you want to do. In Botania, it is attached to a block, that usually then calls it's associated 
//TileEntity, the tile then uses its data to draw the "HUD," (as Botania terms it). What you use it for is up to you, 
//but keep in mind that then you will need to tweak the event code (up above) to get the tileentity, rather than the
//block, and check if the tile exists, is an instanceof IRenderStuf, and isn't invalid, should you directly attach it to
//a TileEntity, rather than the block. 
public interface IRenderStuff{
  
  @SideOnly(Side.CLIENT)
   public void renderStuff();//TODO fill with needed parameters
  
}

 

As a side note though (and I could be wrong here, but what-ever), I don't believe raw TESRs create any signifiant "lag" on the system, it being more along the lines of the TileEntity updating, so as long as you do your code right, and remember the distinction between server and client, then you should be okay with TESRs (though, of course, you CAN make it very laggy, but it isn't inherently so). Finally, in the retrofitted code I provided, it used RenderGameOverlayEvent.Post, you might o use what you initially suggested, the RenderGameOverlayEvent; depends on what end result you want, in a when/where it is drawn on the screen, per render pass.

[Bektor]

  On 6/18/2017 at 1:43 PM, draganz said:

Since you mentioned Botania, I had a look, and from what I have seen, all you need to do is something along the lines of:

  Reveal hidden contents

/*
* To Note: IRenderStuff  should have the method renderStuff with the needed parameters for drawing. This method of 
* rendering a HUD (as Botania terms it) will overlay all other standard renderings, so should be a good choice. However, 
* while this is a retrofited piece of code from Botania's HUDHandler class, the code inside isn't anything special, so 
* don't worry about copying, once again, this isn't very special code (like a super-duper one-liner).
*/
@SubscribeEvent
public static void onDrawScreenPost(RenderGameOverlayEvent.Post event){//This class needs to be registered on  clinet side (i.e. yourrenderclass.class)
  if(event.getType() == ElementType.ALL){
    final Minecraft mc = Minecraft.getMinecraft();
	final RayTraceResult r = mc.objectMouseOver;
    
    if(r != null && r.typeOfHit == RayTraceResult.Type.BLOCK){
      Block block = mc.world.getBlockState(r.getBlockPos()).getBlock();
      if(block instanceof IRenderStuff){
       	final Profiler profiler = mc.mcProfiler;
        profiler.startSection("yourRenderThings");
        ((IRenderStuff) block).renderStuff();//TODO fill with needed parameters
        profiler.endSection();
      }
    }
  }
}
//Just for your reference, here is the IRenderStuff interface, just attach it to a block (or what ever you want to,
//depends on what you want to do. In Botania, it is attached to a block, that usually then calls it's associated 
//TileEntity, the tile then uses its data to draw the "HUD," (as Botania terms it). What you use it for is up to you, 
//but keep in mind that then you will need to tweak the event code (up above) to get the tileentity, rather than the
//block, and check if the tile exists, is an instanceof IRenderStuf, and isn't invalid, should you directly attach it to
//a TileEntity, rather than the block. 
public interface IRenderStuff{
  
  @SideOnly(Side.CLIENT)
   public void renderStuff();//TODO fill with needed parameters
  
}

 

As a side note though (and I could be wrong here, but what-ever), I don't believe raw TESRs create any signifiant "lag" on the system, it being more along the lines of the TileEntity updating, so as long as you do your code right, and remember the distinction between server and client, then you should be okay with TESRs (though, of course, you CAN make it very laggy, but it isn't inherently so). Finally, in the retrofitted code I provided, it used RenderGameOverlayEvent.Post, you might o use what you initially suggested, the RenderGameOverlayEvent; depends on what end result you want, in a when/where it is drawn on the screen, per render pass.

Expand  

Ah, ok thx.

Also, I didn't meant that TESRs create a significant amount of "lag". I just meant that it most likely needs more resources on your system than what is really required to draw some simple overlay UI.

 

Some more information about RenderGameOverlayEvent and it's sub-classes and how to use them properly would be nice.

Like for what is this ElementType.ALL and event.getType() and what does the profiler do?

[Note: I've got no clue about those events at all and little about how Minecraft handles the rendering internal]

[draganz]

As far as the RenderGameOverlayEvent event goes, one can find out how it is called by either opening the call heiriarchy, or by going to GuiInGameForge (net.minecraftforge.client.GuiIngameForge) class. There you will find that the event is used to render, you guessed it, the in game gui. The subclasses of RenderGameOverlayEvent are just as they sound, should your method be called before all of the rendering, or after. If not specified (you have RenderGameOverlayEvent as your parameter, rather than, for say, RenderGameOverlayEvent.Post) then it will be called during each of the rendering processes. This may be easier if you look for yourself by using the call hierarchy feature, and/or if I explain the next thing, the ElementType. The ElementType is basically the rendering type. For instance, when the player health bar is being rendered, the GuiIngameForge is called for the ElementType of HEALTH; this is then posted (forge terminology); this is when any registered methods (such as yours) might get called. However, keep in mind, that if you don't specify an element type via a boolean (i.e. if(event.getType() == ElementType.HEALTH)), then your event will be rendered for each and every time a forge event is "posted," which is unnecessary and bad. So, this can be avoided by either you using RenderGameOverlayEvent.pre (which is called once, before any of the other renderings are used) RenderGameOverlayEvent.post (which is called once, after all other renderings are done), or by having an if-statement say when to render (if(event.getType() == ElementType.HEALTH). As far as ElementType.ALL goes, however, I believe it is only used during the pre and post events.

 

So, looking at what I posted earlier, the if-statement checking if the ElementType was ElementType.ALL, might not be necessary, as the RenderGameOverlayEvent.post inherently has the ElementType set to ALL. Thus, that if-statement where you check the ElementType, seems to only be necessary if you are using RenderGameOverlayEvent in its "raw" form, rather the pre, post, or whatever subevents.

 

Final note, about the profiler; I believe that is used for if something should break, say for rendering, then if your profile hasn't closed (profiler.endSection()), then the issue might be from your rendering process, thus is able to print a log statement saying how your specified profile was still open, when the crashed occurred. This is more of a debug thing, that way if anyone (or yourself) is using your mod and a crash occurred, it is a lot easier to see what might have been the cause; particularly if the cause happened while your mod was rendering, but might have been cause because of someone else's mod doing shenanigans. Just a log/debug thing, its nice thing, that as minecraft itself does it, so ya.

[Bektor]

  On 6/18/2017 at 8:59 PM, draganz said:

As far as the RenderGameOverlayEvent event goes, one can find out how it is called by either opening the call heiriarchy, or by going to GuiInGameForge (net.minecraftforge.client.GuiIngameForge) class. There you will find that the event is used to render, you guessed it, the in game gui. The subclasses of RenderGameOverlayEvent are just as they sound, should your method be called before all of the rendering, or after. If not specified (you have RenderGameOverlayEvent as your parameter, rather than, for say, RenderGameOverlayEvent.Post) then it will be called during each of the rendering processes. This may be easier if you look for yourself by using the call hierarchy feature, and/or if I explain the next thing, the ElementType. The ElementType is basically the rendering type. For instance, when the player health bar is being rendered, the GuiIngameForge is called for the ElementType of HEALTH; this is then posted (forge terminology); this is when any registered methods (such as yours) might get called. However, keep in mind, that if you don't specify an element type via a boolean (i.e. if(event.getType() == ElementType.HEALTH)), then your event will be rendered for each and every time a forge event is "posted," which is unnecessary and bad. So, this can be avoided by either you using RenderGameOverlayEvent.pre (which is called once, before any of the other renderings are used) RenderGameOverlayEvent.post (which is called once, after all other renderings are done), or by having an if-statement say when to render (if(event.getType() == ElementType.HEALTH). As far as ElementType.ALL goes, however, I believe it is only used during the pre and post events.

 

So, looking at what I posted earlier, the if-statement checking if the ElementType was ElementType.ALL, might not be necessary, as the RenderGameOverlayEvent.post inherently has the ElementType set to ALL. Thus, that if-statement where you check the ElementType, seems to only be necessary if you are using RenderGameOverlayEvent in its "raw" form, rather the pre, post, or whatever subevents.

 

Final note, about the profiler; I believe that is used for if something should break, say for rendering, then if your profile hasn't closed (profiler.endSection()), then the issue might be from your rendering process, thus is able to print a log statement saying how your specified profile was still open, when the crashed occurred. This is more of a debug thing, that way if anyone (or yourself) is using your mod and a crash occurred, it is a lot easier to see what might have been the cause; particularly if the cause happened while your mod was rendering, but might have been cause because of someone else's mod doing shenanigans. Just a log/debug thing, its nice thing, that as minecraft itself does it, so ya.

Expand  

Ah, ok. Thx.

Hm.. I'm a bit stuck on rendering actually everything on the middle of the block (not y axis, thought)

[Bektor]

Anyone who knows how to center the text or other stuff on the screen or block?