Add Hud Render Events #4119

kevinthegreat1 · 2024-09-25T04:47:46Z

Originally discussed here.

Deprecate HudRenderCallback.

Fixes #3908.

...endering-v1/src/client/java/net/fabricmc/fabric/api/client/rendering/v1/HudRenderEvents.java

...1/src/testmodClient/java/net/fabricmc/fabric/test/rendering/client/HudRenderEventsTests.java

...endering-v1/src/client/java/net/fabricmc/fabric/api/client/rendering/v1/HudRenderEvents.java

Fuzss · 2024-09-25T06:41:43Z

Not sure this really goes far enough. The system used by NeoForge has always been pretty ideal (although quite invasive): splitting gui rendering into all the different parts (health, hotbar, status effects, etc.) and allowing mods to render their custom gui layers anywhere in-between.

Also it would be awesome to finally get shared height parameters for bars (health bar + armor bar on the left side, food + air on the right side) rendered above the hotbar in Fabric Api. So that multiple mods adding their own bars know at what height to render without interfering with others.

kevinthegreat1 · 2024-09-25T12:39:12Z

Not sure this really goes far enough. The system used by NeoForge has always been pretty ideal (although quite invasive): splitting gui rendering into all the different parts (health, hotbar, status effects, etc.) and allowing mods to render their custom gui layers anywhere in-between.

I agree that Forge's implementation (last when I saw it) is much more versatile and comprehensive. It would be great to be able to cancel certain components too. However as you mentioned it is quite invasive, and in the past, this injection point hasn't exactly been the most stable. A more comprehensive api would need a bit more discussion with the maintainers, but I'd be happy to see it.

Also it would be awesome to finally get shared height parameters for bars (health bar + armor bar on the left side, food + air on the right side) rendered above the hotbar in Fabric Api. So that multiple mods adding their own bars know at what height to render without interfering with others.

The height problem is just reading the code to see the height where bars and components render right? Are you suggesting we provide z constants for different HUD elements?

Fuzss · 2024-09-25T12:44:40Z

The height problem is just reading the code to see the height where bars and components render right? Are you suggesting we provide z constants for different HUD elements?

No. NeoForge adds Gui#leftHeight and Gui#rightHeight. Those update automatically as vanilla bars are drawn above the hotbar. Mods drawing their own bars should update them as well. So e.g. if I have a mod that draws an armor toughness bar above the vanilla armor bar on the left hotbar side I know at what height to draw my bar at, and then another mod that also draws a bar at the left hotbar side can use the left height variable that has been updated by me to draw above me once more.

...endering-v1/src/client/java/net/fabricmc/fabric/api/client/rendering/v1/HudRenderEvents.java

modmuss50

Im not sure events like this are the best way to do this. An API that allows you to register LayeredDrawer.Layer's in the desired order may be better?

...endering-v1/src/client/java/net/fabricmc/fabric/api/client/rendering/v1/HudRenderEvents.java

...-rendering-v1/src/client/java/net/fabricmc/fabric/mixin/client/rendering/InGameHudMixin.java

modmuss50 · 2024-10-11T15:13:06Z

...endering-v1/src/client/java/net/fabricmc/fabric/api/client/rendering/v1/HudRenderEvents.java

+	/**
+	 * Called at the start of HUD rendering, right before anything is rendered.
+	 */
+	public static final Event<Start> START = EventFactory.createArrayBacked(Start.class, listeners -> (client, context, tickCounter) -> {


Are events like this the best solution here? Would it be better to allow mods to register their own LayeredDrawer.Layer in a similar way to how the vanilla hud elements work?

I have updated the code to use one interface, but I don't see a difference with registration methods. Wouldn't it still be implemented with an event?

I was thinking they could just be static? I dont think there is a need for an even unless im missing something.

I was under the impression that not using events is more complicated than just using events? So there's no need for registration methods? Are you saying just implement it with a synchronized list? Events also allow phase ordering if some mod wants to render before another.

modmuss50 · 2024-10-11T15:14:02Z

Please let me know if you want to discuss this more

Fuzss · 2024-10-15T06:45:56Z

Im not sure events like this are the best way to do this. An API that allows you to register LayeredDrawer.Layer's in the desired order may be better?

This please! It would be really great if mods were to properly register their GUI layers with an identifier that allows for ordering with callbacks firing before and after those layers render, as is done on NeoForge. That way other mods can interact with those new layers.
Like the Raised mod (for moving the hotbar up) could selectively move modded layers via translating the pose stack, or a minimap could move a custom effects hud out of the way and so on.

Ideally vanilla layers should also be accessible via an identifier, although not sure how to implement that in a way that’s not too invasive.

kevinthegreat1 · 2024-10-16T01:45:59Z

Im not sure events like this are the best way to do this. An API that allows you to register LayeredDrawer.Layer's in the desired order may be better?

This please! It would be really great if mods were to properly register their GUI layers with an identifier that allows for ordering with callbacks firing before and after those layers render, as is done on NeoForge. That way other mods can interact with those new layers. Like the Raised mod (for moving the hotbar up) could selectively move modded layers via translating the pose stack, or a minimap could move a custom effects hud out of the way and so on.

Ideally vanilla layers should also be accessible via an identifier, although not sure how to implement that in a way that’s not too invasive.

I had a discussion with him on discord here, and I think you're misunderstanding his proposal. Under his idea, the API would still have the same capability as the events here, since what you're describing uses many more mixins and is significantly more invasive. I have looked at neo's API, and the number of patches required will probably make it not acceptible for fabric.

modmuss50 · 2024-10-23T18:24:39Z

Yes, as discussed on discord I think it would be better to statically register (or maybe register in events similar to the ones in the current state of the PR a vanilla LayeredDrawer.Layer.

kevinthegreat1 · 2024-10-23T21:39:19Z

Yes, as discussed on discord I think it would be better to statically register (or maybe register in events similar to the ones in the current state of the PR a vanilla LayeredDrawer.Layer.

Done in 0d2bcf2.

...-rendering-v1/src/client/java/net/fabricmc/fabric/mixin/client/rendering/InGameHudMixin.java

Octol1ttle · 2024-10-25T08:28:49Z

Yes, as discussed on discord I think it would be better to statically register (or maybe register in events similar to the ones in the current state of the PR a vanilla LayeredDrawer.Layer.

Done in 0d2bcf2.

I think what modmuss meant here is that we would have a HudRenderRegistry (or HudRenderRegistrationEvents) where mods would put their LayeredDrawer.Layers. Then, all these layers would be added to the drawer directly with addLayer

kevinthegreat1 · 2024-10-26T15:41:06Z

I think what modmuss meant here is that we would have a HudRenderRegistry (or HudRenderRegistrationEvents) where mods would put their LayeredDrawer.Layers. Then, all these layers would be added to the drawer directly with addLayer

He said it’s fine to register in events. I used events because it allows ordering the layers within one phase/event.

Also, directly adding to the vanilla list would require similarly many injection points or rely on the indices which is even more undesirable.

maityyy · 2024-11-07T16:36:06Z

...endering-v1/src/client/java/net/fabricmc/fabric/api/client/rendering/v1/HudRenderEvents.java

+	/**
+	 * Called after the entire HUD is rendered.
+	 */
+	public static final Event<LayeredDrawer.Layer> LAST = createEventForStage();


Maybe END? There is START, not FIRST or smth

The names are taken from WorldRenderEvents, which has both LAST and END, and LAST is the last place where you should render stuff in most cases. However, I'm happy to change this if modmuss agrees.

modmuss50

This is looking really good now, I have just a few comments (mostly about my own changes :D ) Do let me know if you have any questions or disagree.

...ring-v1/src/client/java/net/fabricmc/fabric/api/client/rendering/v1/FabricLayeredDrawer.java

...rc/client/java/net/fabricmc/fabric/api/client/rendering/v1/HudLayerRegistrationCallback.java

...endering-v1/src/client/java/net/fabricmc/fabric/api/client/rendering/v1/IdentifiedLayer.java

modmuss50 · 2025-01-15T18:51:15Z

...endering-v1/src/client/java/net/fabricmc/fabric/api/client/rendering/v1/IdentifiedLayer.java

+	Identifier STATUS_EFFECTS = Identifier.ofVanilla("status_effects");
+	Identifier BOSSBAR = Identifier.ofVanilla("bossbar");
+	Identifier DEMO_TIMER = Identifier.ofVanilla("demo_timer");
+	Identifier DEBUG_HUD = Identifier.ofVanilla("debug_hud");


Maybe remove hud from the names? Might be worth looking over these names in general to make sure they are consitent.

I've tried to update the names to be consistent.

...-rendering-v1/src/client/java/net/fabricmc/fabric/mixin/client/rendering/InGameHudMixin.java

...ring-v1/src/test/java/net/fabricmc/fabric/test/client/rendering/FabricLayeredDrawerTest.java

...1/src/testmodClient/java/net/fabricmc/fabric/test/rendering/client/HudRenderEventsTests.java

modmuss50 · 2025-01-15T18:59:20Z

...1/src/testmodClient/java/net/fabricmc/fabric/test/rendering/client/HudRenderEventsTests.java

+import net.fabricmc.fabric.api.client.rendering.v1.HudLayerRegistrationCallback;
+import net.fabricmc.fabric.api.client.rendering.v1.IdentifiedLayer;
+
+public class HudRenderEventsTests implements ClientModInitializer {


I wonder what automated testing we can do with the new client tests? Might need to wait until #4381 has been merged. Don't let this block this PR, but its a nice thing to keep in mind.

Yep, I was planning for that. All the tests in here can be easily made automated after the screenshots stuff become available.

kevinthegreat1 · 2025-01-28T14:55:49Z

Fixed the random commits, I didn't notice that branches already diverged when I made this pr.

Earthcomputer · 2025-01-28T15:29:12Z

...lient/java/net/fabricmc/fabric/impl/client/gametest/TestScreenshotComparisonOptionsImpl.java

@@ -49,6 +49,11 @@ public TestScreenshotComparisonOptionsImpl(NativeImage templateImage) {
 		this.templateImage = Either.right(templateImage);
 	}

+	@Override
+	public TestScreenshotComparisonOptions save() {
+		return saveWithFileName(getTemplateImagePath());


Unfortunately this is wrong in a couple of ways. Firstly, it writes the template image before reading it, causing the test to always succeed (at least in dev). Secondly this path points to the runtime resources of the test mod, and not the location where you probably want to write it which is the resource folder in the gradle source set. At dev time this will actually be a folder, but in production this will be a path pointing inside your test mod jar and therefore not writable.

There is already a mechanism to automatically save these templates, I'd suggest you rely on that instead. If you set the system property fabric.client.gametest.testModResourcesPath to the path to your test mod resources folder, then screenshot comparisons will write the grabbed screenshot to the templates directory for next time instead of failing. This system property might not be super easy to discover right now but Loom 1.10 will be setting it by default.

Sorry, but I don't understand your comment. I just wanted a shorthand for saving the screenshot with the same name as the template name, .saveWithFileName(templateName), and this addition seems to work as expected for my case. It saves the screenshot with templateName in the screenshot directory as expected. The test fails normally in the same way as using .saveWithFileName(templateName). getTemplateImagePath() just seems to return the templateName.

Hmm, okay I thought this was something else. The name getTempalteImagePath() misled me into thinking it's the full path, that function should probably be renamed.

Do you want to add this shorthand in your clean-up pr and rename getTemplateImagePath? I think that would be best.

Hmm, I don't know, @modmuss50 which would be better?

Yes, please rename it in the test PR, thats ready to merge whenever, so I can do that fairly swiftly to not block this for too long.

Earthcomputer · 2025-01-28T15:30:48Z

...ering-v1/src/testmodClient/java/net/fabricmc/fabric/test/rendering/client/HudLayerTests.java

+		// Set up required test environment
+		context.getInput().resizeWindow(1708, 960); // Twice the default dimensions
+		context.runOnClient(client -> {
+			client.options.hudHidden = false;


This shouldn't be necessary as the client gametest runner resets all game options to the defaults before each test

The test failed a previous time without these two lines. (4303293 fails on github actions.)

As discussed on Discord, the GUI scale was the problem, which makes sense because GUI scale 2 isn't the default.

modmuss50

Looks great now, thanks for persisting with this, Im glad we spent the time on it and got something thats really good in the end. I also love the tests. 👍

modmuss50 · 2025-01-30T20:13:28Z

...ing-v1/src/client/java/net/fabricmc/fabric/api/client/rendering/v1/LayeredDrawerWrapper.java

+	 * @param layer      the layer to add
+	 * @return this layered drawer
+	 */
+	LayeredDrawerWrapper attachLayerBefore(Identifier beforeThis, IdentifiedLayer layer);


Good name 👍

kevinthegreat1 · 2025-01-31T07:30:26Z

Small bug fix where the return value of visitLayers of sub-layers, modified, was not propagated to parent drawers. Comes with a side of documentation and tests.

...rc/client/java/net/fabricmc/fabric/api/client/rendering/v1/HudLayerRegistrationCallback.java

...g-v1/src/client/java/net/fabricmc/fabric/impl/client/rendering/LayeredDrawerWrapperImpl.java

...dering-v1/src/client/java/net/fabricmc/fabric/impl/client/rendering/LayerInjectionPoint.java

...ing-v1/src/client/java/net/fabricmc/fabric/api/client/rendering/v1/LayeredDrawerWrapper.java

Co-authored-by: Juuz <6596629+Juuxel@users.noreply.github.com>

...g-v1/src/client/java/net/fabricmc/fabric/impl/client/rendering/LayeredDrawerWrapperImpl.java

...endering-v1/src/client/java/net/fabricmc/fabric/api/client/rendering/v1/IdentifiedLayer.java

...g-v1/src/client/java/net/fabricmc/fabric/impl/client/rendering/LayeredDrawerWrapperImpl.java

* Add HudRenderEvents * Add HudRenderEventsTests and deprecate HudRenderCallback * Update tests * Add client parameter and apply suggestions * Split HudRenderEvents into separate interfaces * Fix before chat and last * Add after sleep overlay event and update after main hud injection point * Add comments for injection points * Revert splitting HudRenderEvents into separate interfaces * Use vanilla layered drawer layer interface * Cleanup InGameHudMixin * POC of hud modification * Implement HudLayerRegistrationCallback * Delete HudRenderEvents * Fix sub drawers and add basic documentation * Fix checkstyle * Apply suggestions from code review * Add Javadocs * Add more unit tests * Apply suggestions from code review - Update Javadocs - Remove vanilla sub drawer flattening - Improve LayeredDrawerWrapperImpl internals * Javadoc oddities * Add client gametests * Finish client gametests * Change method and add documentation * Ensure test environment is correct * Move test class to same package * Add render condition for tests * Fix merge conflicts * Update javadocs * Small bug fixes, documentation, and sub drawer tests * Update javadocs some more * Add contract and get around return value not used warnings * Apply suggestions from code review Co-authored-by: Juuz <6596629+Juuxel@users.noreply.github.com> * Migrate AtomicBoolean to MutableBoolean * Update javadocs on render condition * Use ListIterator#set --------- Co-authored-by: modmuss50 <modmuss50@gmail.com> Co-authored-by: Juuz <6596629+Juuxel@users.noreply.github.com> (cherry picked from commit 44a0820)

apple502j suggested changes Sep 25, 2024

View reviewed changes

Octol1ttle suggested changes Sep 25, 2024

View reviewed changes

...endering-v1/src/client/java/net/fabricmc/fabric/api/client/rendering/v1/HudRenderEvents.java Outdated Show resolved Hide resolved

kevinthegreat1 requested review from Octol1ttle and apple502j September 26, 2024 14:07

Octol1ttle reviewed Sep 28, 2024

View reviewed changes

...endering-v1/src/client/java/net/fabricmc/fabric/api/client/rendering/v1/HudRenderEvents.java Outdated Show resolved Hide resolved

kevinthegreat1 requested a review from Octol1ttle October 3, 2024 04:41

Octol1ttle reviewed Oct 3, 2024

View reviewed changes

...endering-v1/src/client/java/net/fabricmc/fabric/api/client/rendering/v1/HudRenderEvents.java Outdated Show resolved Hide resolved

...endering-v1/src/client/java/net/fabricmc/fabric/api/client/rendering/v1/HudRenderEvents.java Outdated Show resolved Hide resolved

kevinthegreat1 requested a review from Octol1ttle October 3, 2024 16:17

Octol1ttle approved these changes Oct 3, 2024

View reviewed changes

modmuss50 reviewed Oct 11, 2024

View reviewed changes

modmuss50 added the enhancement New feature or request label Oct 11, 2024

Octol1ttle reviewed Oct 24, 2024

View reviewed changes

...-rendering-v1/src/client/java/net/fabricmc/fabric/mixin/client/rendering/InGameHudMixin.java Outdated Show resolved Hide resolved

kevinthegreat1 requested review from Octol1ttle and modmuss50 October 25, 2024 04:15

Octol1ttle approved these changes Nov 7, 2024

View reviewed changes

maityyy reviewed Nov 7, 2024

View reviewed changes

kevinthegreat1 mentioned this pull request Dec 5, 2024

[1.21.1] Add HudPreRenderCallback Event and HudPostRenderCallback.EVENT #4275

Closed

kevinthegreat1 changed the base branch from 1.21.1 to 1.21.4 January 10, 2025 20:36

kevinthegreat1 requested a review from Octol1ttle January 15, 2025 18:01

modmuss50 reviewed Jan 15, 2025

View reviewed changes

kevinthegreat1 added 2 commits January 28, 2025 09:52

Move test class to same package

2c79985

Add render condition for tests

f2bf391

kevinthegreat1 force-pushed the hud-render-events branch from 36da421 to f2bf391 Compare January 28, 2025 14:55

Earthcomputer suggested changes Jan 28, 2025

View reviewed changes

kevinthegreat1 added 3 commits January 29, 2025 09:01

Merge branch '1.21.4' into hud-render-events

b4f8aab

Fix merge conflicts

d75f794

Update javadocs

c838fcf

modmuss50 approved these changes Jan 30, 2025

View reviewed changes

modmuss50 added the last call If you care, make yourself heard right away! label Jan 30, 2025

Small bug fixes, documentation, and sub drawer tests

8209d7f

Juuxel reviewed Jan 31, 2025

View reviewed changes

kevinthegreat1 and others added 3 commits January 31, 2025 11:50

Update javadocs some more

bcbbb27

Add contract and get around return value not used warnings

cd138b3

Apply suggestions from code review

97f8874

Co-authored-by: Juuz <6596629+Juuxel@users.noreply.github.com>

kevinthegreat1 requested a review from Juuxel January 31, 2025 17:18

Earthcomputer reviewed Feb 3, 2025

View reviewed changes

...g-v1/src/client/java/net/fabricmc/fabric/impl/client/rendering/LayeredDrawerWrapperImpl.java Outdated Show resolved Hide resolved

PepperCode1 suggested changes Feb 3, 2025

View reviewed changes

...endering-v1/src/client/java/net/fabricmc/fabric/api/client/rendering/v1/IdentifiedLayer.java Show resolved Hide resolved

...g-v1/src/client/java/net/fabricmc/fabric/impl/client/rendering/LayeredDrawerWrapperImpl.java Outdated Show resolved Hide resolved

kevinthegreat1 added 2 commits February 4, 2025 13:47

Migrate AtomicBoolean to MutableBoolean

e3f65ea

Update javadocs on render condition

3384eae

kevinthegreat1 requested review from PepperCode1 and Earthcomputer February 4, 2025 18:48

Use ListIterator#set

a4c4bd7

PepperCode1 approved these changes Feb 4, 2025

View reviewed changes

Juuxel approved these changes Feb 4, 2025

View reviewed changes

modmuss50 added the merge me please Pull requests that are ready to merge label Feb 7, 2025

modmuss50 merged commit 44a0820 into FabricMC:1.21.4 Feb 9, 2025
4 checks passed

kevinthegreat1 deleted the hud-render-events branch February 11, 2025 05:00

Add Hud Render Events #4119

Add Hud Render Events #4119

Conversation

kevinthegreat1 commented Sep 25, 2024 • edited Loading

Fuzss commented Sep 25, 2024

kevinthegreat1 commented Sep 25, 2024

Fuzss commented Sep 25, 2024

modmuss50 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

modmuss50 commented Oct 11, 2024

Fuzss commented Oct 15, 2024

kevinthegreat1 commented Oct 16, 2024

modmuss50 commented Oct 23, 2024

kevinthegreat1 commented Oct 23, 2024

Octol1ttle commented Oct 25, 2024

kevinthegreat1 commented Oct 26, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

modmuss50 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kevinthegreat1 commented Jan 28, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

modmuss50 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kevinthegreat1 commented Jan 31, 2025

kevinthegreat1 commented Sep 25, 2024 •

edited

Loading