reimplement: SHC_3BB0A8C1_0x0047BF20 97.5% | SHC_3BB0A8C1_0x0046BB60 100%

[TheRedDaemon]

No description provided.

[gynt]

Are you sure it is int? Some & operations naturally produce negative right-hand-sides if an int.

[TheRedDaemon]

It increased the matching and actually started producing the binary mask instead of just using a mov to a 16bit register.
But this function is another one of these annoying ones. A lot of branch optimization, gotos.
Always in the hope that there is a when: When we manage to match the function, I will try reverting this change and test around a bit.
If this goes through, all other methods need to be tested again, of course.

[TheRedDaemon]

Main issue:
The second early return is considered a "hot path", based on what I read, and its return resolved in place.
This did not happen in the original, which placed this block at the end of the function. The rest of the body is currently identical.
I assume the structure of the rest of the function might be at fault, at least I currently see nothing that could switch this in the condition itself.
Interestingly, inverting the condition (while breaking other stuff), seems to also switch the part order.

Still I would guess the complexity of the rest of the function might be responsible, but I was unable to find something that keeps the logic and does not break other stuff. It might actually be needed to break matching again in the search for the solution.

[gynt]

I think if logic wise it is correct it is fine to merge.

[TheRedDaemon]

Yeah, I still do not have learned my lesson to not overdo it.
There are over 3000 functions, to hell if one or two hundred of them do not match...
In this case I also do not feel like I can return with anything. The branching is a mess in this function and I can both see this as a sign of either a messy function or the compiler having mangled a lot of the original logic...
I just do not think they would write such a weird mix of a switches and really big if else cases?

Fun fact, I managed to push the body of the early return back by wrapping the condition in an do {} while(false); block and use breaks on the inverted and split early return conditions. However, that messed the rest of the function up. These systems are really fragile.

Anyway, the type of the SoundFlagsAndLoopCount still needs to be changed, since this created also non-structural opcode diffs if not and I also added the SHC_3BB0A8C1_0x0046BB60, because I was testing something.