System - Window for the $ graphic not handled correctly when the System has transparency

[Mimigris]

Name of the game:

Yume 2kki version 0.120b. (Note that said graphic got edited in version 0.120c, hence why I'm precising this version, but the issue is present for both).

Player platform:

Windows, 64 bits continuous build version of the Player.

Describe the issue in detail and how to reproduce it:

Likely related: #2961

When a $ message is displayed with this System graphic in Yume 2kki (e.g. when using a vending machine), the transparency for the window will incorrectly be set compared to the RPG_RT, making the window shown as transparent while it should not be the case.

System before version 0.120c: RPG_RT: EasyRPG:

System in version 0.120c: RPG_RT: EasyRPG:

[Ghabry]

The transparency must come from the opacity setting of the "Show Message Option" command but unsure why RPG_RT renders this different. Maybe some timing thing like #2932

[Ghabry]

Original comment by @Lt-Knb

When you use a vending machine in Yume Nikki, the background is missing in the system message. It only shows the frame (and text).

It's there in RPG RT.

RPG RT (Default theme): EasyRPG:

RPG RT (Second theme): EasyRPG:

RPG RT (Third theme) EasyRPG:

Unrelated: I assume the big difference in colors is just the 16-bit behavior of RPG RT?

[Lt-knb]

Apparently, the RPG_RT in the Steam version of Yume Nikki (1.12a, I think) has the same issue

[Lt-knb]

It seems this was introduced in EasyRPG 0.6.2.

It was this change in 2k3 1.11 (which is why the RPG_RT in YN Steam is affected too):

When Battle Mode is one (traditional) the transparency setting of on-map message boxes is still respected (before they appeared opaque) (->0.6.2)

0.6.1: 0.6.1 renders the background like older versions of 2k3, but the transparent color turns black and visible (could be #2961 or related, as it wasn't fixed yet back then)

[Ghabry]

So you think that this is an incorrect engine detection? Interesting. For Yume Nikki you can try overwriting the rpg_rt.exe of the game with an old exe from the Japanese one. Then the player should detect an old engine and no longer render transparent.

@Mimigris do you have a save game close to a vending machine so I can test this theory?

[Mimigris]

@Mimigris do you have a save game close to a vending machine so I can test this theory?

I don't have a save game on me, no, but if you want the full data on where those vending machines can be found, there you are:

You can interact with the vending machines in the game at the following coordinates: Map 42, player coordinates are [125, 30] (money is 100 or more) Map 47, player coordinates are [86, 45] (money is 130 or more) Map 111, player coordinates are [73, 103] (money is 150 or more) If you have enough money (see the money requirement), the vending machine will be called, otherwise, the drink will not be able to be bought and the message will not be displayed (so not interesting for this test).

To change the current System graphic, you can go at Map 78, player coordinates are [14, 9], and interact with the event above you to switch between 3 different System graphics (it's a bit random on which one you get so you may want to give it several tries, it can be repeated).

[Ghabry]

Are you sure about the coordinates? Map 42 is just a blue map that warps me back.

Map 47 is a black map with nothing in it.

Map 111 is

Map 78 is also a black map.

[Mimigris]

The last message in the conv was about Yume Nikki, so I thought you wanted this for Yume Nikki, not Yume 2kki. For which game do you want info to test?

[Lt-knb]

I tried manual engine detection, and the background is always missing, even if you detect Yume Nikki as 2k (which explains why Yume 2kki is affected). So automatic detection isn't failing. It seems a "Use pre-v1.11 message behavior" is just missing (?)

Here's three saves (for Yume Nikki) I made with TestPlay, each with a different theme, so you don't need to go to the mall (Map 78). There's also 650 Yen. They spawn you in front of the vending machine in the woods (from my screenshots)

YN Vending Machine Save.zip

[Ghabry]

@Mimigris oh I was refering to Yume2kki as this was the initial issue. But its okay I tested now with the Vending machine in the bathhouse. I remembered it from a bug where it only dispensed tasty chocolate milk in older versions of EasyRPG Player.

Can conclude that the problem is unrelated to this "English Engine" flag.

[Lt-knb]

It seems a "Use pre-v1.11 message behavior" is just missing (?)

So, is this the problem?

[Ghabry]

We are looking at the wrong thing here.

Actually the 1.11 transparency is a "semi-transparency" via some battle setting. This doesn't apply here anyway because when this would be used it would be "half-transparent".

---

There is always only full transparency or full opaque in the issue here.

This transparency of the gold window is synchronized with the transparency setting of the message window.

Now the question is: Did this behaviour change across various versions of RPG Maker 🤔

---

I bisected this now: (see #1908)

a77aa7580ec751afcf4e8271426ee87390cfc796 is the first bad commit
commit a77aa7580ec751afcf4e8271426ee87390cfc796

Fix gold window opacity
    
Fix: #1908

 src/window_message.cpp | 3 +++
 1 file changed, 3 insertions(+)

[Lt-knb]

Interesting. I checked the new addition in #1486. One more difference in 2k3 < 1.10 is that the background's transparent color (if present) is supported too when a message is set to Transparent, in case you didn't notice in my first screenshot (there's no corners): The system image (notice the Index 0 corners):

[Ghabry]

hm yeah there seems to be a bug in the transparency handling in the new version >.>

But this looks even more obscure, no idea how to replicate this one 😅

[Lt-knb]

Oh wait, I did some more tests.

Alright, I found the original problem (invisible gold window background): In 2k3 < 1.10, SysTransp was located near Large Window in Battle Screen. It was grayed out for Type A and C. Despite that, it worked for the latter if you enabled it on Type B then switched to C (my brain...). Unlike C, Type A was really not supported, so if you tried the same trick, SysTransp stayed off.

The Steam version fixed those issues by making Type C stop being grayed out, and by adding support for Type A. So if you use the Steam RPG_RT to play a game made with 2k3 < 1.10, it incorrectly assumes SysTransp is on for Type A, if the checkbox looks ticked, despite being grayed out.

In EasyRPG, I tried Battle Type B and C with SysTransp off, and the background is still invisible in the gold window >.> So it's just always invisible regardless, when Message is Transparent, since that gold window PR you mentioned.

---

Now, the other problem (transparent color in gold window background): I tried the Steam RPG_RT (1.12a), and it actually uses the transparent color like 2k3 < 1.10, when SysTransp is off and Message is Transparent. Here's the resulting table:

TC = Transparent color used NB = Not used, turns black N = Not used, doesn't turn black N/A = Background is invisible so doesn't matter (!) = This issue (!*) = #3187

2k3 < 1.10

SysTransp	Battle	Message Opaque	Message Transparent
No	A	NB	TC (!)
No	B/C	NB	TC (!)
Yes	A	NB	TC (!)
Yes	B/C	N (!*)	N/A

---

2k3 > 1.10

SysTransp	Battle	Message Opaque	Message Transparent
No	A	NB	TC (!)
No	B/C	NB	TC (!)
Yes	A	N (!*)	N/A
Yes	B/C	N (!*)	N/A

---

2k: Transparent color isn't used but it doesn't turn black (!*)

---

To fix both issues (but not 3187): -If Engine is not rpg2k3e, and Battle is Type A, ignore SysTransp and pretend it's off. -If Engine is not 2k, SysTransp is off, and Message is Transparent, use transparent color for the gold window's background. -If SysTransp is off and Message is Transparent, or Engine is 2k, make the gold window's background visible

[Lt-knb]

So it does this:

void Window_Message::InsertNewPage() {

   	[...]

	// Invisible message boxes
	bool msg_invisible = Main_Data::game_system->IsMessageTransparent()
		// Gold window is still opaque in 2k, or if system transparency is disabled, affected by RPG_RT < 1.11 bug
		&& (Player::IsRPG2k() || lcf::Data::battlecommands.transparency == lcf::rpg::BattleCommands::Transparency_opaque || lcf::Data::battlecommands.battle_type == lcf::rpg::BattleCommands::BattleType_traditional)
		&& (!Player::IsRPG2k3E() || lcf::Data::battlecommands.battle_type != lcf::rpg::BattleCommands::BattleType_traditional);
	if (msg_invisible) {
		SetOpacity(0);
		gold_window->SetBackOpacity(255);
	} else if (Main_Data::game_system->IsMessageTransparent()) {
		SetOpacity(0);
		gold_window->SetBackOpacity(0);
	} else {
		SetOpacity(255);
		gold_window->SetBackOpacity(GetBackOpacity());
	}

	// 2k3 transparent color in gold window
	bool gold_tc = Player::IsRPG2k3()
		&& (Main_Data::game_system->IsMessageTransparent())
		// If system transparency is disabled or battle type is A
		&& (lcf::Data::battlecommands.transparency == lcf::rpg::BattleCommands::Transparency_opaque || lcf::Data::battlecommands.battle_type == lcf::rpg::BattleCommands::BattleType_traditional);
	if (gold_tc) {
		// Would this work?
		gold_window->SetWindowskin(system, pic.data.use_transparent_color);
	}

And that would replace this (286-292 in window_message.cpp):

void Window_Message::InsertNewPage() {

   	[...]

	if (Main_Data::game_system->IsMessageTransparent()) {
		SetOpacity(0);
		gold_window->SetBackOpacity(0);
	} else {
		SetOpacity(255);
		gold_window->SetBackOpacity(GetBackOpacity());
	}

But that SetWindowskin is a placeholder, as I don't know how it works 😅 Hence the "Would this work?"

[Ghabry]

This transparent colour being displayed as-is instead of black in the system graphic is a bit more complex. Currently not sure how to fix this in our renderer. Better move this to #3187 .

Will only fix the gold transparency issue here.

[Lt-knb]

This transparent colour being displayed as-is instead of black in the system graphic is a bit more complex. Currently not sure how to fix this in our renderer.

That's 3187, yes. It doesn't affect Yume Nikki. The issue in Yume Nikki is that the gold window's background uses the transparent color in RPG_RT:

Now, I remember that the first time you fixed the transparent color in string pictures (#2961), it was unconditional, so the system background always used it, and that broke OFF. But then you found a proper fix (a446cdb5194f2715011b7e6d8d5f74d6a0666fd7). So can't we use the same fix for a gold window, just like a string picture?

[Ghabry]

Oh is this windowskin code from string pic doing already the correct thing? Have to check :)