[Bug] Combo keys are glitched and cause many issues

[Leopard20]

Remember the new shader cache loading screen you added?! (the screenshot should refresh your memory LOL!) Well, after enabling combo keys it's not shown anymore.

Here's another weird thing:

Combo keys and some other keys have a different transparency level than action buttons and DPAD

[unknownbrackets]

It only shows if loading takes long enough. Your graphics driver will probably cache shaders in memory after they're loaded.

Is it showing a black screen for longer than it normally does when the game starts?

-[Unknown]

[Leopard20]

What I don't understand is why does it show it the first few times I run a game, but disappears later?

Yes, the game takes longer to start than normal (as compared to v1.5.4). It looks like it wants to show the same caching screen but doesn't.

[Leopard20]

I also compared two ini's for two different games (one that didn't show this screen and one that did) but there was no difference.

[Leopard20]

Here are my main configs + the two games I compared:
SYSTEM.zip
Maybe you can spot the real cause.

[Leopard20]

Here is the game config after deleting it and recreating it (it shows the screen now)

NPJH50465_ppsspp.ini.zip

[Leopard20]

@unknownbrackets @hrydgard
Good news! I found the culprit! It's caused by touch controls. If you replace the controls section from NPJH... (the first archive, system.zip) with that of any other game, the screen won't work anymore.
So it's definitely a bug, but don't know why it happens.

[Leopard20]

I just found the ultimate culprit! It generally happens when you manually edit the controls (through the ini file). The reason I do this manually is that the emulator editor is very inaccurate.
Here's another config file that I manually edited but doesn't have this issue:
ULJM05681_ppsspp.ini.zip
Really weird!

Just a rough guess, but does it have anything to do with floating point operations/significant figures?
For example, if I change the value of a variable from 1.279987 to 1.280000 does it cause any issue?

[hrydgard]

That is seriously weird. Good job finding a hint to the problem! :)

[Leopard20]

Glad to help! But let's hope it's not a bogus culprit, like the texture hashing issue I reported! Or the controls-not-working one. That one was a bummer!

[hrydgard]

Just to clarify, was it when you replaced the [Control] or [ControlMappings] section? Also I really don't understand how this makes any sense :) Can't seem to repro.

[Leopard20]

[Control] (i.e touch controls)
Just copy all of my config for NPJH50465 into another game config. (the one inside System.zip) Then run the game.
It may be game-specific. In that case here's another config for Tekken 6 US (I recall you saying you had that game right?)
ULUS10466_ppsspp.ini.zip

[unknownbrackets]

Is that simplest way to reproduce this? Does it require a game-specific ini with game-specific control positions? Or does it happen even if you change the controls manually in ppsspp.ini?

-[Unknown]

[Leopard20]

Well I'm not entirely sure about this. Like I said there was an exception (ULJM... archive above) But the rest of games I edited have this problem (3rd Birthday, Assassin's Creed, Tekken 6, PD Extend, etc)
Here is what you should look for:
Tekken 6 with the config I posted above:

Tekken 6 after deleting its config and using the default config:

You may need to click on these GIF files to see them better in a separate window.

[Leopard20]

Just to be sure let me test it on my PC too

[Leopard20]

OK now I'm 100% positive that:

1. It's not game specific (tried some games with the config I mentioned, all had issues)
2. It's not platform specific (same thing on PC)

So it might depend on which variable you edit.
Another possiblity is, for example, setting the center of a control at an invalid display region.
For example, both my PC and Android phone are 1080p. Now if I changed the center of a button such that it fell at (1000, 205.7), an invalid point, it might lead to issues.

[Leopard20]

Another discovery!
It's not caused by editing controls but rather by using Combo keys! I generally edit my combo key placements manually, which is what led me to believe it was the editing that caused issues!
Just make one visible and boom! Everything falls apart!

[Leopard20]

Updated the issue (see the original post)

[hrydgard]

Bizarre! I've repro'd. I tried looking the tween color value used for the background, and yeah:

loadingViewColor_->SetCallback([loadingBG, loadingTextView, loadingSpinner](View *v, uint32_t c) {
	ILOG("Tween: %08x", c);

I: emuscreen.cpp:917: I: Tween: 00ffffff
I: emuscreen.cpp:917: I: Tween: 00ffffff
...

Very confused as to how combo keys has anything to do with that tween value... hm. Doesn't seem to be consistent, at least not when setting up some combo keys globally..

[unknownbrackets]

Oh. Maybe it's when a different number of views are created - it uses the persisted data thing, it might need a tag to keep the correct values.

-[Unknown]

[hrydgard]

Oh duh, forgot about that ... that makes some sense :)

[Leopard20]

Seems fixed.
Guess we (you!) 're good for 1.6 then.

[Leopard20]

Wait. I noticed that the texts are missing now. Was it intentional?
Also, are gonna do something about the transparency issue? It's not really important though.

[unknownbrackets]

The text was intentionally removed because it causes a lot of extra strings to translate for 1.6.0.

I think we should open a separate issue about the transparency - seems strange.

-[Unknown]

[Leopard20]

Ok