Open sgielen opened 2 years ago
A CI/CD flow for building the Remake does not exist. The game is built manually on a Windows machine using Embarcadero's RAD Studio for Delphi. On a normal Wine setup (without an additional obstacle of using an ARM processor) it works well on Linux for me since ~10 years with only very minor issues (no videos, and some DEs don't work well with fullscreen mode).
There used to be a possiblilty to build Remake using Lazarus, but at this moment it does not work even on Windows. I researched this for a while and gave up - some notes in https://trello.com/c/QNzpcv7m/1709-fix-compilation-for-lazarus-fpc-on-windows plus I could share my raw personal notes I still have, if needed.
One little thing you may need to ensure, is to disable videos in config. It should already be done by Remake for Wine automatically, so I am saying this only in case your setup is more unusual than I expect.
You could also make a 64-bit Windows build (unless something changed this year, it should compile successfully and work), if that could help. If you go that route, keep in mind though, that at the moment there is no plan to introduce support for allowing more than 1 "official" build of the Remake for multiplayer (at least until somebody proposes how to do it securely, and implements it). I mention it, because it blocks us from possibility of having regular 32bit Windows client play against users of hypothetical other clients (Windows 64bit, Linux, etc.)
@sado1 thanks for your reply! So the only way for me to build KaM Remake right now is to use Embarcadero's RAD Studio, which is commercial and has only a 30-day trial? I'm not sure if that's going to be feasible...
Would you happen to have an existing 64-bit Windows .exe laying around so I could try running it in Wine64?
I'm thinking the easiest way may be to build the game up to the main menu with Lazarus - that should be easier than building the whole game, hopefully - and if it turns out to crash at the same point, that should help to figure out why. Then, if I succeed in coming up with a patch, perhaps you could perform a full rebuild with that patch and we'll see if it gets further.
Out of curiosity – I can imagine you would prefer only officially built clients to play against each others, since clients have full knowledge of the game and it's easy to cheat otherwise, but what are your reasons to disallow support for officially built clients for different platforms to play against each other? :-)
There is a "community version" that we use, it is free (although registration is required), and I realized now that it should be possible to compile a Mac OS binary (also ARM) with it... (it was useless for my Linux use case, free version does not include a Linux compiler; but it may be what you're looking for...)
The alternate way would be to first fix Windows compilation in Lazarus, then try to set up a (Linux?) build server, it could use Wine to automatically build the binary, just as you wanted. For this way, as I mentioned, I am able to provide some more pointers.
@reyandme would you be able to easily provide a 64-bit Windows binary?
There is no reason for not allowing multiple official clients, other than "somebody needs to design and implement this". Currently, one of the ways the game client checks for possible cheating, from what I know, is ensuring that the binary is the same for all clients. It could be changed; however, as Wine build worked well for Linux and Intel Mac for a long time, there was never much reason to change the current state of things.
Also, our main problem for complex features is always that we have only one active developer (Rey), while I am just a sysadmin who sometimes tries to help; thing is, I really hate programming (well, at least above Python level of complexity), so you can imagine fixing bugs in Remake's Delphi code isn't one of my favorite things to do :) And, due to lack of workforce, we struggle to release the next version since a few years, even with only a few bugs left on the list.
Oh, I see! https://www.embarcadero.com/products/delphi/starter/free-download - I've added it to https://github.com/reyandme/kam_remake/wiki/ProjectCompilation for future reference.
I found a post about building with Embarcadero on GitHub Actions, but it only runs a hello world and stops short of actually starting a full build on the commandline. It would be really convenient to know how to perform a commandline build if everything else is available -- perhaps @reyandme could give a few pointers regarding this? I could spend a minute to propose a GitHub Action which automatically builds on a public Github Windows server, which then would also help me a lot in attempting fixes for my issue at hand.
You would need to start with CLI version of the compiler (along with msbuild tool). But from what I tried in the past, there seems to be no way to implement such a workflow with RAD Studio in community edition, I think CLI tools were behind a paywall.
You're right, it seems to be that way. I'm SSH'ed into my Windows PC now to see if I can get it to build, and I get to the point of running the Delphi compiler:
D:\kam_remake> "C:\Program Files (x86)\Embarcadero\Studio\21.0\bin\rsvars.bat"
D:\kam_remake> echo %BDS%
C:\Program Files (x86)\Embarcadero\Studio\21.0
D:\kam_remake>msbuild KaM_Remake.dproj /t:Build /p:config=Debug
[...]
_PasCoreCompile:
C:\Program Files (x86)\Embarcadero\Studio\21.0\bin\dcc32.exe [...]
This version of the product does not support command line compiling.
Done Building Project "D:\kam_remake\KaM_Remake.dproj" (Build target(s)).
However, "This version of the product does not support command line compiling." Right when I got this error, a representative of an Embarcadero reseller, Barnsten, called because of my trial request and I'm in touch with them about this error now...
By using printf debugging, I found that the thing that is failing here is the OpenAL initialization:
18:02:00.909 1,882s 1ms 244 OpenAL init started
18:02:00.910 1,883s 0ms 244 OpenAL init A
18:02:00.921 1,894s 11ms 244 OpenAL init B
18:02:00.921 1,894s 0ms 244 OpenAL init C
18:02:00.921 1,894s 0ms 244 OpenAL init D
Indeed, the Wine error log says:
00f4:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\OpenAL32.dll" at 7FD40000: builtin
00f4:fixme:openal32:wine_alGetProcAddress Could not find function in list: alcCreateContext
00f4:fixme:openal32:wine_alGetProcAddress Could not find function in list: alcMakeContextCurrent
00f4:fixme:openal32:wine_alGetProcAddress Could not find function in list: alcProcessContext
00f4:fixme:openal32:wine_alGetProcAddress Could not find function in list: alcSuspendContext
00f4:fixme:openal32:wine_alGetProcAddress Could not find function in list: alcDestroyContext
00f4:fixme:openal32:wine_alGetProcAddress Could not find function in list: alcGetError
00f4:fixme:openal32:wine_alGetProcAddress Could not find function in list: alcGetCurrentContext
00f4:fixme:openal32:wine_alGetProcAddress Could not find function in list: alcOpenDevice
00f4:fixme:openal32:wine_alGetProcAddress Could not find function in list: alcCloseDevice
00f4:fixme:openal32:wine_alGetProcAddress Could not find function in list: alcIsExtensionPresent
00f4:fixme:openal32:wine_alGetProcAddress Could not find function in list: alcGetProcAddress
00f4:fixme:openal32:wine_alGetProcAddress Could not find function in list: alcGetEnumValue
00f4:fixme:openal32:wine_alGetProcAddress Could not find function in list: alcGetContextsDevice
00f4:fixme:openal32:wine_alGetProcAddress Could not find function in list: alcGetString
00f4:fixme:openal32:wine_alGetProcAddress Could not find function in list: alcGetIntegerv
00f4:fixme:openal32:wine_alGetProcAddress Could not find function in list: alcCaptureOpenDevice
00f4:fixme:openal32:wine_alGetProcAddress Could not find function in list: alcCaptureCloseDevice
00f4:fixme:openal32:wine_alGetProcAddress Could not find function in list: alcCaptureStart
00f4:fixme:openal32:wine_alGetProcAddress Could not find function in list: alcCaptureStop
00f4:fixme:openal32:wine_alGetProcAddress Could not find function in list: alcCaptureSamples
00f4:err:seh:call_stack_handlers invalid frame 000000000617FE60 (0000000004B92000-0000000004C8FD20)
00f4:err:seh:NtRaiseException Exception frame is not in stack limits => unable to dispatch exception.
I installed the Creative OpenAL library from https://www.openal.org/downloads/ inside the same Wineskin app, and presto:
Sound works, and games seem to work well, too.
For future reference, these are the steps to get KAM Remake to work on an M1 Mac:
@sado1 please feel free to put this on the website and/or close this issue, whatever you prefer :)
Hi! I'm trying to run the KaM Remake in Wineskin with a WineCX64Bit engine. This is a 64-bit Wine engine which is able to run 32-bit Windows applications; it runs in Rosetta on M1 processors. This way, I've gotten for example OpenLoco to run with minor changes even though it does lots of scary things like mapping the original binary into memory and calling between its symbols and symbols reimplemented in C++, with just as scary memory management between the two.
I'd like to do the same troubleshooting with KaM Remake, and am willing to spend some time reverse engineering what's currently not working, but I'll probably need some help.
Currently, I'm getting to the point where I create a Wineskin 2.9.1.5 wrapper with the WS11WineCX64Bit22.0.1 engine, install the original GoG KaM, then install the Remake. When I run the remake, I get the splash screen for r6720, then the executable exits, supposedly successfully (exit code 0?). The test log contains the following two lines at the end:
Unfortunately, I never succeeded in running the Wine debugger in this configuration, as it always fails an assertion on startup that it's a 32bit debugger on a 64bit platform. For OpenLoco, I used the alternative approach of printf debugging, figuring out where the crash occurred and then looking in a disassembler what would be going on around that time. In order to do the same here, I'll need to be able to build everything; for OpenLoco there was a handy Github Action which built everything on
windows-latest
, perhaps we could see if that could also apply here :)