wine: elementary support

[AleXoundOS]

Since there are obstacles preventing installation of the full-flavored client on wine,
maybe there is possibility to get a stripped-down core variant of ShieldBattery client? Just to be able to:

• login into the server
• choose 1v1 or 2v2 ladder
• wait for matchmaking to complete
• play without altering client graphics code

This will enable access to 2v2 matchmaking (when ready) at least in its simplest form.

[2Pacalypse-]

That seems like more work than just figuring out what's preventing the installation of the client on wine and fixing that instead ^^.
Though I know nothing about Wine so I can't really be sure either way.

[tec27]

From this:

play without altering client graphics code

I feel like you might have some misconceptions about how things work ingame, leading you to believe this would be simpler than it actually is. Our ingame code is not simply graphics modifications, it's a ton of things:

• Handling game initialization and communication with the Electron process
• Custom netcode
• Various gameplay and replay fixes
• UI enhancements (like the transparent FoW and stack count, which I assume is what you mean by "altering client graphics code")
• Improved management of Window events
• Delivering game results back to the server
• etc.

This kind of stuff isn't optional, without it there the system simply doesn't work.

As it is currently, the Electron client fails to launch for whatever reason on Wine, but I don't think trying to work around this is a particularly great path forward. Instead, it'd probably be better to build a Linux Electron binary that only uses Wine for the game portions. It's also incredibly likely that either the injection of the ingame client code, or the ingame client code itself will be problematic in some ways under a Wine environment, and all of that would need to be worked through after getting the Electron client functional.

I have no idea how much effort it is to make that work, though, as it is not something we are currently pursuing. I understand that there are a few people that are interested in running this stuff on Linux, but it is a few. We have 3 core developers, only 1 of us working full time. Each release already takes quite a lot of manual QA since writing automated tests with a proprietary game client is a pretty hard problem. We really can't afford to double the amount of manual testing that needs to be done at this point in time, and we already have way too many high priority things that need to get done so we can get an actual player-base.

If you're really interested in making this work, the source is all here, I encourage you to investigate and work through the issues yourself. Otherwise, we're not going to be investing time supporting Linux at this time, and throwing ideas at us every week or two isn't particularly helpful.

[AleXoundOS]

Thank you for some explanations!

So the key thing here is:

This kind of stuff isn't optional, without it there the system simply doesn't work.

Intuitively, I'm most worried about UI enhancements since they can be the most unpredictable performance wise (involve DirectX?). And the ability to turn them off may become crucial in supporting Linux&MacOSX.

it'd probably be better to build a Linux Electron binary that only uses Wine for the game portions

Alright, there is a wine builder mentioned on electron website. Maybe I could try something if it can be done from Linux machine.

It's also incredibly likely that either the injection of the ingame client code, or the ingame client code itself will be problematic in some ways under a Wine environment

Not so incredibly, but yeah there is some uncertainty. Though all of SC 1.16 tools needed injection always worked under wine. For example: InfectedStarcraft.exe, ChaosLauncher with multiple plugins (i.e. APM alert), iCCup Launcher with AntiHack, and the most significant - BWAPI.dll. If the DLL injection method for ShieldBattery is no other than of mentioned above, there must be no problems in this regard.

I understand that there are a few people that are interested in running this stuff on Linux, but it is a few.

Of course, people interested in running StarCraft under wine are a minority.
I slowly try to investigate what's going on with running ShieldBattery battery under wine. But the sequence of actions inside the application is pretty difficult to figure out without digging into sources, since the project has already attained some complexity. The situation worsens with the minified js code in the output. On a fun note, further investigation looks like reverse engineering some injected code, which is a result of reverse engineering some another :)

Each release already takes quite a lot of manual QA since writing automated tests with a proprietary game client is a pretty hard problem.

Agree. Proper QA for this may even require developing a special framework.

We have 3 core developers, only 1 of us working full time.

Wow, this is great that 1 is working full time!

[tec27]

Thank you for some explanations!

So the key thing here is:

This kind of stuff isn't optional, without it there the system simply doesn't work.

Intuitively, I'm most worried about UI enhancements since they can be the most unpredictable performance wise (involve DirectX?). And the ability to turn them off may become crucial in supporting Linux&MacOSX.

I think it's pretty unlikely anything as far as DirectX goes will have unpredictable performance consequences for Linux or MacOS, we don't do anything particularly complex or different from things that the game already does. For instance, transparent Fog of War is implemented via a modified shader (but the game is already using a shader for the minimap anyway). If you're referring to trying to turn off things SC:R does even without ShieldBattery, well, that's a whole other can of worms :)

it'd probably be better to build a Linux Electron binary that only uses Wine for the game portions

Alright, there is a wine builder mentioned on electron website. Maybe I could try something if it can be done from Linux machine.

Those instructions are referring to building Windows binaries/installers on a Linux machine, which isn't really the problem that we'd need to solve. Rather, we'd be building native Linux binaries on Linux. In general this stuff is something that would need to be worried about much further down the line though, the first step to working towards these things would be to get Linux support working with a local development copy (which doesn't require electron-builder at all)

It's also incredibly likely that either the injection of the ingame client code, or the ingame client code itself will be problematic in some ways under a Wine environment

Not so incredibly, but yeah there is some uncertainty. Though all of SC 1.16 tools needed injection always worked under wine. For example: InfectedStarcraft.exe, ChaosLauncher with multiple plugins (i.e. APM alert), iCCup Launcher with AntiHack, and the most significant - BWAPI.dll. If the DLL injection method for ShieldBattery is no other than of mentioned above, there must be no problems in this regard.

Unfortunately SC:R tries significantly harder to prevent things from injecting into its memory, so the implementation is indeed quite different and more involved than any tools that worked for 1.16. It may just work, but no one has gotten a version running on Wine that gets anywhere near that point yet, so we'd have to see.

[AleXoundOS]

I think it's pretty unlikely anything as far as DirectX goes will have unpredictable performance consequences for Linux or MacOS, we don't do anything particularly complex or different from things that the game already does.

I thought in case OpenGL renderer backend is used (which wine benefits) the DirectX requirement would be confusing. But most likely not the case since the performance of HD graphics under wine is mediocre. I couldn't find exact proofs that SC:R still has 2 available backends for windows (3f2697a and tl thread give some hints).

If you're referring to trying to turn off things SC:R does even without ShieldBattery, well, that's a whole other can of worms :)

Had no ideas turning anything off in the SC:R itself for the sake of wine platform.
But in case OpenGL renderer backend is off but present, turning it on would improve performance under wine drastically. Currently, HD graphics without dynamic lightning are playable competitively on Intel UHD Graphics 620, but some UMS or crowded 4v4 can drop FPS to 75. Same hardware with dynamic lightning is unplayable competitively. Nonetheless, original (SD) graphics run flawlessly including aged (10 years) hardware.

the first step to working towards these things would be to get Linux support working with a local development copy (which doesn't require electron-builder at all)

Sounds promising. I have to try.

Unfortunately SC:R tries significantly harder to prevent things from injecting into its memory, so the implementation is indeed quite different and more involved than any tools that worked for 1.16.

Whoops.