MP2 Ground Zero - not using menu images in baseq2/pics

[abalfoort]

Both MP1 The Reckoning (xatrix) and MP2 Ground Zero (rogue) have a sub-directory pics which only contains one background image.

MP1 The Reckoning uses the menu images in baseq2/pics:

Even Zaero does that, but MP2 Ground Zero does not:

This is the same in the subsequent screens.

I've found that this is where it all starts:
src/client/ui/script.c

void UI_LoadScript(void)
{
    Parse_File("q2rtx.menu", 0);
}

But when I debug further I just go deeper down the rabbit hole and get lost. I cannot seem to find where the logic is that decides to use (or not use in rogue's case) the baseq2/pics images.

I end up here:
./src/refresh/images.c:1320:static int find_or_load_image

Anyone has any idea?

Here are the menus used:
rogue-q2rtx.menu.zip
xatrix-q2rtx.menu.zip

[res2k]

rogue ships with basically copies of all the menu images in pics/. Since "game" files have precedence over "base" files, those "old" graphics shipped with rogue are used.

The idea is because games/mods typically ship graphics that differ from the original ones their versions should be preferred.

FWIW, for material images (wall textures, skins) there exists a mechanism to detect this case (game ships copy that is unmodified from base game) and "ignore" the game file in that case. That has not been adapted for UI images, but probably could.

[res2k]

Relevant code for material image "unmodified copy" handling:

Q2RTX/src/refresh/vkpt/material.c

Line 773 in a50fe35

static qboolean game_image_identical_to_base(const char* name)

Q2RTX/src/refresh/vkpt/material.c

Line 844 in a50fe35

There's also the wrinkle that some games ship with a copy of an image

[abalfoort]

Thanks. At first glance I see that it is by design:

Q2RTX/src/refresh/vkpt/material.c

Line 846 in a50fe35

in that case, _do_ use the material definition. */

However, this comment says differently:

Q2RTX/src/refresh/vkpt/material.c

Line 778 in a50fe35

If that is the case, ignore the game image, and just use everything

If it is by design it is better not to change its behavior. But I still find it confusing. Can't we at least make an exception for the menu items (m_banner* and m_main*)?

[res2k]

First off, be aware that this applies to material images only. Menu images will not go through that code path!
To deal with menu images the idea would have to be adapted somehow, also probably move to a more general place (images.c, probably).

FWIW, the behavior for material images is somewhat complicated because it has to cover a number of cases...

1. There are material definitions (consider them appearance options for RTX mode) for a lot of skins and wall textures in the base game (baseq2). They're assumed to look "better" than the default pcx or wal files, so use them.
2. However, if you're using another game/mod/mission pack, and they replace a skin or wall texture, the replaced version should be used; otherwise, the appearance wouldn't be right with the explicit material definition, so don't use that.
3. But, there is the special case where eg rogue and xatrix ship identical copies of baseq2 skins & wall textures. If we just follow the logic of 2. above, that'd mean the lower-quality pcx or wal files would be used, despite the material definition being viable and preferable in this case - so that's what's done. game_image_identical_to_base() is used for that.

Did this clarify things for you?

I actually coded a somewhat more generic version of the "identical image" approach earlier: res2k@199eb4d
However, if I remember right, I went with the more focused "material system only" approach b/c "hiding" the redundant files at filesystem level may have weird consequences/cause unexpected behavior when applied to files other than images.
The suggestion above - move the "identical image detection" to the image loading code in images.c - could be more appropriate "middle way".

[abalfoort]

Thanks for the explanation.
I'll look into it. However, this is a steep learning curve for me: new to the project and new to C (Python and C# programmer).