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

[1.15.2] [SOLVED] HUD Texture Has Wrong Scale


Papa_Prime
 Share

Recommended Posts

Hello, I am having a rendering issue which I could not seem to figure out. Here are the relevant files and code. I have changed the texture mappings for the texture that is having issues to show that it is loading but not in the intended way. The capability works as intended.

 

Original Texture:

https://postimg.cc/MnDNyRcN

How it is rendered:

https://postimg.cc/9zQdM9Vz

Event

@OnlyIn(value = Dist.CLIENT)
public class HudRender extends AbstractGui {

    @SubscribeEvent
    public void renderOverlay(RenderGameOverlayEvent event) {
        float partial = event.getPartialTicks();

        if (event.getType() == RenderGameOverlayEvent.ElementType.EXPERIENCE) {

            VoidBarElement.element(partial);
            BarCapsuleElement.element();
        }
    }
}

VoidBarElement

public class VoidBarElement {

    private static float cycle;
    private static ResourceLocation tex = new ResourceLocation(Main.modid, "textures/hud/void_bar.png");;

    public static void element(float sch)
    {
        RenderSystem.pushMatrix();
        cycle += sch;

        if(cycle > 100000)
        {
            cycle = 0;
        }

        Minecraft mc = Minecraft.getInstance();

        int posY = mc.getMainWindow().getScaledHeight() - 15;
        int posX = mc.getMainWindow().getScaledWidth() - 110;

        ClientPlayerEntity player = Minecraft.getInstance().player;
        IVoid cap = player.getCapability(VoidProvider.VOID, null).orElse(null);
        int width = (int) ((cap.getVoid() / 800) * 100);

        RenderSystem.pushTextureAttributes();
        RenderSystem.enableAlphaTest();
        RenderSystem.enableBlend();
        RenderSystem.color4f(1F, 1F, 1F, 0.6F);
        mc.getTextureManager().bindTexture(tex);
        mc.ingameGUI.blit(posX, posY, 0, (int) cycle, width, 8);
        RenderSystem.popAttributes();
        RenderSystem.popMatrix();
    }
}

CapsuleBarElement

public class BarCapsuleElement {

    private static ResourceLocation tex = new ResourceLocation(Main.modid, "textures/hud/capsule_bar.png");

    public static void element()
    {
        RenderSystem.pushMatrix();
        Minecraft mc = Minecraft.getInstance();

        int posY = mc.getMainWindow().getScaledHeight() /2;
        int posX = mc.getMainWindow().getScaledWidth() /2;

        RenderSystem.pushTextureAttributes();
        mc.getTextureManager().bindTexture(tex);
        mc.ingameGUI.blit(posX, posY, 0, 0, 200, 100);
        RenderSystem.popAttributes();
        RenderSystem.popMatrix();
    }
}

 

Thank you, I tried to keep the code clean.

Edited by Papa_Prime
Link to comment
Share on other sites

 

I do not know the gui but I do know textures in great resolution,

I recommend that you identify the real value of your image, is it 64 x 32? or customized.

 

it is obvious that the image you want to use is longer than the one that appears in the game

 

you can use it without modifying the code

Link to comment
Share on other sites

The texture is at a custom resolution but it did seem to work with the texture used in VoidBarElement which is 100 x 96.

I have drawn a 64 x 64 texture testing to test that element for stretching. The image is no longer distorted but each side had to be increased by a factor of 4 to render the whole image as you can see below.

https://postimg.cc/XZwLq9CZ

 

Edited by Papa_Prime
correct image url
Link to comment
Share on other sites

 

For your understanding, forge automatically adapts higher resolutions without the need to modify its code as long as the size is equivalent, so an item with a 16x16 texture can be changed to one of 32x32 or 64x64 without modifying the code

Link to comment
Share on other sites

Just now, Valtiel said:

So what dimensions of texture do you want to use? If your item or gui uses a 64x64 resolution but you want to use a 100x96 resolution, I recommend that you double the original resolution in this case 128x128.

Yes, that's what I intend on doing and to just call to get the correct scale as a temporary solution:

RenderSystem.scalef(f1, f2, f3);

 

 

2 minutes ago, Valtiel said:

 

For your understanding, forge automatically adapts higher resolutions without the need to modify its code as long as the size is equivalent, so an item with a 16x16 texture can be changed to one of 32x32 or 64x64 without modifying the code

I am not using a item/gui/block. I'm drawing directly to the screen using blit(posX, posY, offsetX, offsetY, texturesizeX, texturesizeY) which does not seem to be affected by forge in VoidBarElement, thus the confusion

Link to comment
Share on other sites

4 minutes ago, Valtiel said:

forge would take effect in "textures / hud / capsule_bar.png" but if you draw directly on the screen then we talk about different things

Yes, thank you for helping me to figure out at least the image resolutions easier to scale with.

Issue is still open as the core issue is yet to identify

Link to comment
Share on other sites

1 minute ago, Papa_Prime said:

The render engine seems to scale all blits to 256x256, as it is for GUIs, using a 256x256 resolution solved the problem. It was not noticeable with one of the elements as the image border was close to being a square.

Correct, the default texture resolution for blit is assumed to be 256x256.

However there are versions of the blit method that take the texture size as parameters.

Link to comment
Share on other sites

23 hours ago, diesieben07 said:

Correct, the default texture resolution for blit is assumed to be 256x256.

However there are versions of the blit method that take the texture size as parameters.

Thank you, I will use that in the future. I have noticed that there are different versions of the method but couldn't determine what each one takes as the mappings are not named. 

Link to comment
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.

Guest
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.

 Share



  • Recently Browsing

    No registered users viewing this page.

  • Posts

    • Your report is very hard to actually understand. Your best bet is to stop trying to 'describe' the issue and provide the actual tag files and  what you are expecting to happen. Because all of our tests in tags work just fine. Also, there is no 'registering' of tag in the sense you're talking about. All tags are 'registered' when they are read from disc in one pass. So ya, provide us a test case of your tags and we'll see if it's a real issue or not.
    • Minecraft Version: 1.16.5 Forge Version: 36.2.0 Description of issue: A loaded mod containing data pack tag registries, which creates new tags and references the new tags to further register the items in existing tags fails to register anything in the existing tags. Example: Tinkers Construct v3.1.2.265 contains Json files to register: forge:ingots/cobalt as a new tag containing cobalt_ingot and add to previously registered tag forge:ingots. In the file for forge:ingots, values of "tconstruct:seared_brick", "tconstruct:scorched_brick", "#forge:ingots/copper", "#forge:ingots/cobalt", etc. are indicated. In-game, none of the items listed as values are tagged under forge:ingots, however the new tags including forge:ingots/cobalt include the items tagged in those files. Further, copying the json file for forge:ingots and placing in a later applied datapack, such as Kubejs, and reloading, properly registers the forge:ingots tags. This would appear to be an issue with timing of registering the new tags. Before copying the json file to a datapack, the existing tag (forge:ingots) appears to be handled first, which containing references to new tags that are not yet processed (forge:ingots/cobalt) fails and does not register any of the appended values. But in the second instance because the copied json file is processed after the mod jar file as a whole, the new tags exist and the appending of the new values succeeds. While I have given Tinkers construct as an example I have viewed the same issue with multiple mods, each of which uses references to new tags in an appending of an existing tag. Likewise, mods that do not exhibit this behavior use explicit item listings rather than referencing a new tag. I looked through the log files and did not identify any error or other message relating to the registration of tags in general or specifically these exemplar tags.
    • Debug.log here: https://gist.github.com/DexTGS/4f33065cbe2ad844b76ed1b1890fd069 . Game crashing once I die.
    • I'm making a mob like zombified piglin except instead of all the mobs getting mad at you I want to make it do they all go into a panic. How can I do this?
    • What. Just register your events in your mod constructor or use the class annotation.
  • Topics

  • Who's Online (See full list)

×
×
  • Create New...

Important Information

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