# Compiling native cgame/ui on Windows

**URL:** <https://discourse.ioquake.org/t/compiling-native-cgame-ui-on-windows/1519>\
**Category:** Uncategorized\
**Created:** [July 16, 2020, 9:08pm UTC](https://discourse.ioquake.org/t/compiling-native-cgame-ui-on-windows/1519 "2020-07-16T21:08:57Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![easyfrag](https://avatars.discourse-cdn.com/v4/letter/e/db5fbb/32.png) [@easyfrag](https://discourse.ioquake.org/u/easyfrag)\
**Post date:** [July 16, 2020, 9:08pm UTC](https://discourse.ioquake.org/t/compiling-native-cgame-ui-on-windows/1519/1 "2020-07-16T21:08:57Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![MrNuclearMonster](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.ioquake.org/mrnuclearmonster/32/820_2.png) [@MrNuclearMonster](https://discourse.ioquake.org/u/MrNuclearMonster)\
**Post date:** [July 17, 2020, 12:13am UTC](https://discourse.ioquake.org/t/compiling-native-cgame-ui-on-windows/1519/2 "2020-07-17T00:13:06Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![easyfrag](https://avatars.discourse-cdn.com/v4/letter/e/db5fbb/32.png) [@easyfrag](https://discourse.ioquake.org/u/easyfrag)\
**Post date:** [July 17, 2020, 2:59pm UTC](https://discourse.ioquake.org/t/compiling-native-cgame-ui-on-windows/1519/3 "2020-07-17T14:59:34Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![easyfrag](https://avatars.discourse-cdn.com/v4/letter/e/db5fbb/32.png) [@easyfrag](https://discourse.ioquake.org/u/easyfrag)\
**Post date:** [July 17, 2020, 10:20pm UTC](https://discourse.ioquake.org/t/compiling-native-cgame-ui-on-windows/1519/4 "2020-07-17T22:20:18Z")

</div>

Ok, I painstakingly figured out the issue.

Adding cJSON.c from [https://github.com/DaveGamble/cJSON](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.