4 ms·
Semi-related: Is anyone aware of a Proton neophyte's guide to fixing a Windows game? I've got a few old games that get stuck various places and I imagine that t
by Scramblejams 5y ago
Semi-related: Is anyone aware of a Proton neophyte's guide to fixing a Windows game? I've got a few old games that get stuck various places and I imagine that there may be a simple Windows call that needs implementing, but I don't know the first thing about how to diagnose that.
- iforgotpassword 5y agoI once had a game that always crashed under wine. Instead of trying to understand the bug, I got as far as figuring out that this was a virtual function call into nowhere and then just 909090'd the crap out of it. The game then seemed to work perfectly and I couldn't even tell what was missing/different after removing a totally random function call.
- coldpie 5y agoI wrote an intro to Wine dev: https://www.codeweavers.com/blog/aeikum/2019/1/3/working-on-wine-part-1-the-wine-ecosystem https://www.codeweavers.com/blog/aeikum/2019/1/3/working-on-... It doesn't go into a lot of debugging detail, as that's its own huge topic, but may get you started. If you're debugging a thing in Proton, you'll want to use that project environment instead of Wine's directly, but the concepts are the same.
- simion314 5y agoI would start by running the game from the terminal and read all warnings and errors, compare those with games that work because some of the warnings are always there but don't affect the games.
- mike_hearn 5y agoI used to work on Wine, at first as a hobby and then later as a job (for CodeWeavers). As part of that I contributed to the Wine Developers Guide. The Wine docs to help new devs are (or were) remarkably good given the enormous complexity of the project. Unfortunately "how to fix a bug in Wine" can still devolve very rapidly into: Step 1. Learn Windows programming. Step 2. Then learn Linux programming, the Wine architecture, X86 assembly, low level debugging etc. Step 3. Draw the rest of the owl. Nonetheless it's a good place to start: https://wiki.winehq.org/Developer_Hints https://wiki.winehq.org/Developer_Hints https://wiki.winehq.org/Wine_Developer%27s_Guide https://wiki.winehq.org/Wine_Developer%27s_Guide The days when fixing games involved just straight implementation of simple library calls were mostly over, even back when I was doing this a long time ago. Broken apps or games are much more likely to be hitting obscure "bugs" in Wine (which can mean failure to replicate Windows bugs), or other even more subtle compatibility issues, like the one this blog post documents.
- mindwok 5y agoIf you don’t mind me asking, why did you stop? I’ve been fascinated with Wine development lately and love what Codeweavers do.
- mike_hearn 5y agoBecause I was graduating university and needed a full time job. Around that time Google offered me a position, which came with an office (and therefore, new friends to make, an important consideration if you're 22). This was 2006 and there were only about 5000 people in Google engineering worldwide, so it was quite a prestigious offer. Friends/family actually couldn't quite believe it because the media was full of stories about how selective they were. The company's reputation was stellar, the pay was good and so it made sense. Also, CodeWeavers had started getting into the Mac port around that time. The main reason I worked on Wine was to try and support the free Linux desktop. Writing code to benefit Apple didn't appeal. I figured if that was the choice I may as well just go work on something fully proprietary but that worked on Linux anyway (like ... Google's web apps).
- Scramblejams 5y agoThanks for the overview. Guess I'm not surprised that the low-hanging fruit has all been plucked, hopefully someone at Valve fixes $RANDOM_GAME for me. :-)