Treat built-in hotbar, nametags, minimap, crosshair like Lua HUD elements

Warr1024 commented 4 years ago

Minetest version

Minetest 5.2.0-dev-44458896 (Linux)
Using Irrlicht 1.8.4
BUILD_TYPE=Release
RUN_IN_PLACE=1
USE_GETTEXT=0
USE_SOUND=1
USE_CURL=1
USE_FREETYPE=1
USE_LUAJIT=0
STATIC_SHAREDIR="."

OS / Hardware

Operating system:

Linux 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11) x86_64 GNU/Linux

CPU:

Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz

Summary

Unable to draw HUDs beneath built-in HUDs using z_index.

EDIT by SmallJoker: Progress so far:

[x] hotbar
[ ] nametags
[x] minimap
[ ] crosshair

Steps to reproduce

Minimal test case mod init.lua:

minetest.register_on_joinplayer(function(player)
        player:hud_add({
                hud_elem_type = "image",
                position = {x = 0.5, y = 0.5},
                text = "[combine:1x1^[noalpha",
                scale = {x = -100, y = -100},
                z_index = -1000000000
        })
end)

Applied on top of MTG (or probably most other games).

Expected result

A full-screen black HUD covers the entire screen, with all existing built-in HUD elements drawn over top of it.

Actual result

Correct: New HUD is drawn beneath health bar and chat.
Incorrect: New HUD obscures hotbar and crosshair.

SmallJoker commented 4 years ago

https://github.com/minetest/minetest/blob/44458896d9097c15c722c5bffb3d72e14962b7ce/doc/lua_api.txt#L1263-L1266

If this does not work, please rephrase this as a bug report. z_index was added for this purpose.

Warr1024 commented 4 years ago

Oops, according to the doc, it should be z_index not z_order, right?

Well, I tested it both ways and it behaved the same...

Warr1024 commented 4 years ago

All the Lua-defined HUD elements are all drawn together at https://github.com/minetest/minetest/blob/master/src/client/render/core.cpp#L90, so they are always above the crosshair and hotbar, and always beneath the nametags and minimap.

SmallJoker commented 4 years ago

You are right that it's currently impossible to change the order of C++-defined HUD elements. They would need to be treated like Lua HUD elements (or even added from Lua rather than C++). Updated title.

Warr1024 commented 4 years ago

Actually defining them in Lua would be awesome, because not only could they then be subject to the same sorting rules, but it would also provide a template for replacing them, or creating additional elements that connect with them properly.

Right now, defining Lua HUD elements that align properly with the built-in ones is a lot of guess-work and fine-tuning, and requires taking into account things like custom font sizes, different screen sizes and DPI, and different scaling options, and in some cases it's not possible to reliably align elements at all.

hecktest commented 4 years ago

+1 for unhardcoding anything that can be unhardcoded. The hearts bar belongs in minetest_game and it's just a nuisance otherwise. So is the built-in concept of "health" or "breath".

SmallJoker commented 4 years ago

For minimap, see #9079.

Wuzzy2 commented 4 years ago

:+1: I need this for MCL2 when the player wears a pumpkin as head armor. The screen is supposed to

Personally, I don't care whether crosshair and hotbar are hardcoded or not. Obviously, unhardcoding would be nice, but is no means neccessary. It would be good enough if the offending HUD elements are subject to the same z_index rules as any Lua HUD elements.

For a quick lazy fix: Render crosshair and hotbar after all Lua HUD elements are those are critical. I can see no use case for obstructing those, tbh.

rubenwardy commented 4 years ago

I've had this exact issue recently, and ended up having to make my own hotbar element

I can see no use case for obstructing those, tbh

Custom damage/poison colors. Styling that only partially obscures

Wuzzy2 commented 4 years ago

Yeah, right. My quick lazy fix was dumb. So there is no quick lazy fix, apparently.

minetest / minetest