Compiling native cgame/ui on Windows

general
1

Basically I can’t get it to work. The compile works fine, but running the game fails at various stages.

I’ve tried:

  • Compiling with Cygwin 64 on Windows10/64. Fail at attempting to load uix86_64.dll (it’s there!)
  • Cross-compiling with x86_64-w64-mingw32-gcc (version 8.3) under Debian 10 - Fail at attempting to load cgamex86_64.dll (uix86_64.dll loads fine)
  • Cross-compiling with MXE’s x86_64-w64-mingw32.static-gcc (version 5.5.0) under Debian 10 - Fail at attempting to load cgamex86_64.dll (uix86_64.dll loads fine).

I’m compiling with the following options:

ARCH=x86_64 PLATFORM=mingw32 make -j 16 BUILD_MISSIONPACK=0 BUILD_SERVER=0 BUILD_GAME_QVM=0 BUILD_STANDALONE=1

The first ARCH and PLATFORM options only for cross-compiling attempts. I’m only trying to build the client at this point, hence the BUILD_SERVER=0. I also don’t want to use QVMs as I need to be able to call stuff like SDL-ttf library from the renderer, for example, and basically be able to just write plain C inside cgame and such.

At this point I’m trying to compile the vanilla ioq3 master branch, without any of my modifications. I’m failing at this miserably. I mean, I compile fine. I just can get it to run.

It always ends up failing on loading either UI or CGAME DLL. I think I traced the issue to SDL_LoadFunction() ultimately, at which point it becomes kind of blurry.

Any help would be appreciated.

2

do you have the typical quake 3 installation (via steam, gog, or a disc) alongside the binaries?

3

Nope.
The typical Q3 installation would include pak0.pk3 as well as point release pakX.pk3 from ID.

These all contain cgame/ui/game QVMs which will be executed. My whole point is to make my own standalone cgame which shall not be a QVM but a native Windows 64 DLL.

I do have the baseq3 directory with a bunch of stuff such as textures/ models/ or scripts/, which contain stuff I put there, but I have no vm/ directory in there - on purpose.

4

Ok, I painstakingly figured out the issue.

Adding cJSON.c from https://github.com/DaveGamble/cJSON to the list of object to be linked into cgame.dll for some reason made SDL_LoadFunction() fail when attempting to load dllEntry() and vmMain() from that DLL.

I have no idea WHY but it works just fine without it, and fails with it. I disabled any calls to that cJSON object and it SDL_LoadFunction will still fail, as long as the cJSON.o is part of cgame.dll. Removing the object fixes the problem.

Go figure. At least I have a lead now! Jesus, I literally spent the last 3 days agonizing over this stuff. Works fine in Linux, too. Windows truly sucks sometimes.