Author Topic: Compiling Outpost 2 Dlls With Mingw/gcc  (Read 2338 times)

Offline TH300

  • Hero Member
  • *****
  • Posts: 1404
    • http://op3game.net
Compiling Outpost 2 Dlls With Mingw/gcc
« on: January 04, 2013, 08:26:15 AM »
Just out of curiosity, today I tried to compile an Outpost 2 mission dll with Mingw32. Worked almost flawlessly. All I had to do was change some paths. I tested the DLL in Outpost 2 under Wine and it worked.

It was a cross-compile, using my Linux system and the native Code::Blocks IDE.

I didn't check whether the produced dll has any dependencies, but according to the Mingw documentation it is supposed to depend on MSVCRT.DLL and possibly other DLLs. The produced DLL was also larger than what I got with the VC++ Toolkit 2003 and LibCTiny (even with the -s switch).

I didn't look any further into this, because I was originally going to do something else and I think, I distracted myself for long enough, now.
« Last Edit: January 04, 2013, 08:29:23 AM by TH300 »

Offline CK9

  • Administrator
  • Hero Member
  • *****
  • Posts: 6226
    • http://www.outpost2.net/~ck9
Compiling Outpost 2 Dlls With Mingw/gcc
« Reply #1 on: January 04, 2013, 11:37:29 PM »
If the resultant file is larger than other methods, would there be any counter-balancing benefits to this one?  If it's a more user-friendly method, it might be worth the size difference...especially considering how larger memory storage has become more easily available.
CK9 in outpost
Iamck in runescape (yes, I still play...sometimes...)
srentiln in minecraft (I like legos, and I like computer games...it was only a matter of time...) and youtube...
xdarkinsidex on deviantart

yup, I have too many screen names

Offline TH300

  • Hero Member
  • *****
  • Posts: 1404
    • http://op3game.net
Compiling Outpost 2 Dlls With Mingw/gcc
« Reply #2 on: January 05, 2013, 01:37:57 AM »
A benefit would be that we could redistribute the compiler (since its GPL licensed). We could also integrate it in our own tools.

The size difference is not big. Its 3 KB compared to 4.5 KB for a mission DLL that does nothing. And the 3 KB are only reached when linking with LibCTiny instead of the default LibC. And people said that LibCTiny isn't compatible with newer Microsoft compilers (than MSVC++ 2003) and I guess few people are still using 2003, so they are probably creating bigger DLLs, already.

Linking with a big Standard C library is not actually needed, since most standard functions are already compiled into Outpost2.exe and its not hard to access them from within custom DLLs. I did that already. I don't like the idea of duplicating the same code over and over for each new DLL.

The reason why I am concerned about size, though, is that whereas it doesn't matter too much for a single DLL, it can make a noticeable difference if we decide to include many new missions in our download package (even although its unlikely that we'll ever get many new).

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4954
Compiling Outpost 2 Dlls With Mingw/gcc
« Reply #3 on: January 05, 2013, 05:19:15 AM »
Quote
A benefit would be that we could redistribute the compiler (since its GPL licensed). We could also integrate it in our own tools.
That's actually a surprisingly compelling reason.

It's also interesting that you got this working under Linux, since I'm now using Linux for my desktop.
 

Offline CK9

  • Administrator
  • Hero Member
  • *****
  • Posts: 6226
    • http://www.outpost2.net/~ck9
Compiling Outpost 2 Dlls With Mingw/gcc
« Reply #4 on: January 05, 2013, 01:41:36 PM »
Well, I'm sold.  I still have not gotten aroud to messing with mission coding (just too many fun games and very little free time and my own lack of knowledge of the tools needed...leading to going on the forum to find out and then me getting distracted, lol).  
CK9 in outpost
Iamck in runescape (yes, I still play...sometimes...)
srentiln in minecraft (I like legos, and I like computer games...it was only a matter of time...) and youtube...
xdarkinsidex on deviantart

yup, I have too many screen names