Adventure Game Studio | Forums

AGS Development => Editor Development => Topic started by: Babar on 09 Mar 2017, 20:07

Title: Compiling the Full Editor (are there still native.dll problems?)
Post by: Babar on 09 Mar 2017, 20:07
Hello!

I was preaching earlier to someone about how more of the community should be involved in developing AGS, and realised, I'm not doing it myself! :D
I'm not some supercoder, but I figured I'd look under the hood and get a feel for things.
So according to this link: http://www.adventuregamestudio.co.uk/wiki/Compiling_AGS
I need a specific version of VS2008 to be able to compile the full editor? Is this still a requirement?
I don't think VS2008 is even available anywhere. When I had a dreamspark account (2 years ago?), and it didn't even list 2008.

So...next question, what exactly is in the Native.dll? Would it be some really low level stuff that I would probably never need to bother with?

(also, sorry if I posted in the wrong place, this seemed the most appropriate)
Title: Re: Compiling the Full Editor (are there still native.dll problems?)
Post by: Crimson Wizard on 09 Mar 2017, 20:28
That's an interesting coincidence, because I am finally going to make a modification that would remove the need to use MSVS 2008. In fact, I made first attempt back in August, but we had certain difficulties back then, which is a long story, but now I am definite about that, and will commit these changes on this weekend.

And I would appreciate testers, not regular testers, but "coder-testers".

Basically, what you need to do:

1) clone the code from my personal repository at "https://github.com/ivan-mogilko/ags-refactoring.git" and checkout branch called "win-libraries--al-4.4.2".
2) follow these instructions to build 3rd party libraries and AGS: https://github.com/ivan-mogilko/ags-refactoring/blob/win-libraries--al-4.4.2/Windows/README.md

You may use your favourite version of MSVS. Although I cannot guarantee it will work "out-of-the-box", because AGS uses outdated code style. But I think few people were able to work around that.


Regarding the current code from our main "official" branch, you would need VS2008 SP1 to compile Engine too. So basically if you do not have that you can only build Editor (without AGS.Native.dll part).
What is inside AGS.Native.dll -- various code mainly related to importing binary data of all kinds. Since main game data is persistent in the project in the form of XML since AGS 3.0, and it is saved to binary by C# code too since AGS 3.4.0, it is the room files (*.crm) that are still managed inside native code.
Title: Re: Compiling the Full Editor (are there still native.dll problems?)
Post by: Babar on 12 Mar 2017, 13:31
Thanks CW!
I'm still going through the stuff you linked, currently struggling through building the libraries!
Title: Re: Compiling the Full Editor (are there still native.dll problems?)
Post by: Crimson Wizard on 12 Mar 2017, 13:37
I'm still going through the stuff you linked, currently struggling through building the libraries!

Please ask if you have any questions, because I want to ensure that this process is comprehensible!

In my opinion Allegro is the only library that may cause issues, because you need to learn how to use Cmake tool, if you do not know beforehand. Other libraries already have working MSVC projects in their sources.
Title: Re: Compiling the Full Editor (are there still native.dll problems?)
Post by: Crimson Wizard on 14 Mar 2017, 14:59
Well, I merged this change to master branch today.

Next thing to try is to create project files for contemporary version of MSVS. I was planning to use MSVS 2015 Community Edition, but since its 2017 now, is there any reason to try newer MSVS 2017 instead? I'd still like to use 2015, because it is probably more stable...
Title: Re: Compiling the Full Editor (are there still native.dll problems?)
Post by: Monsieur OUXX on 14 Mar 2017, 16:33
Just a thought: with NuGet, the hassle of including Allegro (and having to build it) would now be greatly reduced wouldn't it?

https://www.allegro.cc/forums/thread/615945
Title: Re: Compiling the Full Editor (are there still native.dll problems?)
Post by: Crimson Wizard on 14 Mar 2017, 17:53
Just a thought: with NuGet, the hassle of including Allegro (and having to build it) would now be greatly reduced wouldn't it?

https://www.allegro.cc/forums/thread/615945


1) This is Allegro 5 package, while AGS needs Allegro 4. These libraries are non-compatible, Allegro 5 has very different API (functions).
2) AGS still requires to patch the library source, as explained in the readme referenced above. This is needed to keep existing plugin support.
IDK how that would work with nuget, if Allegro 4 package were there.
Title: Re: Compiling the Full Editor (are there still native.dll problems?)
Post by: Monsieur OUXX on 15 Mar 2017, 14:31
1) This is Allegro 5 package, while AGS needs Allegro 4. These libraries are non-compatible, Allegro 5 has very different API (functions).
Yes I thought I remembered that, but then I saw no evidence in the sources, so I thought "hey maybe those magicians managed to upgrade to Allegro 5 after all!"

And indeed, if we're using a patched Allegro 4, it wouldn't work as NuGet is meant to reference compiled libraries (that said my knowledge in patching is very blurry, I have no idea how the magic happens when patching files "externally" -- by externally I mean applying some external automated set of targetted changes rather than editing the file directly) (I'm not asking you to explain -- just saying I don't know) ('cause I know that you're always willing to help so don't waste time explaining how patching works) ( :wink: :wink: :wink: )
Title: Re: Compiling the Full Editor (are there still native.dll problems?)
Post by: Crimson Wizard on 29 Mar 2017, 15:43
Well, patching works through git command (because the code is under git source control). The patching itself is a relatively simple text format which describes which code lines to remove and which to add or modify.

Under spoiler is our allegro 4.4 patch:
Spoiler: ShowHide

Code: C++
  1. From 5bf1e9c45202eafd2be467dddfb22f5cfad2bf02 Mon Sep 17 00:00:00 2001
  2. From: Ivan Mogilko <ikm_spb@yahoo.com>
  3. Date: Sun, 26 Feb 2017 18:37:11 +0300
  4. Subject: [PATCH] Allegro-4.4.2 patch for AGS
  5.  
  6. Supplied allegro-4.4.2.patch which has to be applied over Allegro 4.4.2 library sources before building Windows version of the engine.
  7.  
  8. This patch simply makes several variables non-static, allowing them to be referred from the external code.
  9. ---
  10.  src/win/wdsound.c | 2 +-
  11.  src/win/wkeybd.c  | 4 ++--
  12.  src/win/wmouse.c  | 2 +-
  13.  3 files changed, 4 insertions(+), 4 deletions(-)
  14.  
  15. diff --git a/src/win/wdsound.c b/src/win/wdsound.c
  16. index 6f33a22..485c340 100644
  17. --- a/src/win/wdsound.c
  18. +++ b/src/win/wdsound.c
  19. @@ -151,7 +151,7 @@ static DIGI_DRIVER digi_directsound =
  20.  
  21.  
  22.  /* sound driver globals */
  23. -static LPDIRECTSOUND directsound = NULL;
  24. +LPDIRECTSOUND directsound = NULL;
  25.  static LPDIRECTSOUNDBUFFER prim_buf = NULL;
  26.  static long int initial_volume;
  27.  static int _freq, _bits, _stereo;
  28. diff --git a/src/win/wkeybd.c b/src/win/wkeybd.c
  29. index d85f079..174cf94 100644
  30. --- a/src/win/wkeybd.c
  31. +++ b/src/win/wkeybd.c
  32. @@ -40,12 +40,12 @@
  33.  static HANDLE key_input_event = NULL;
  34.  static HANDLE key_input_processed_event = NULL;
  35.  static LPDIRECTINPUT key_dinput = NULL;
  36. -static LPDIRECTINPUTDEVICE key_dinput_device = NULL;
  37. +LPDIRECTINPUTDEVICE key_dinput_device = NULL;
  38.  
  39.  
  40.  /* lookup table for converting DIK_* scancodes into Allegro KEY_* codes */
  41.  /* this table was from pckeys.c  */
  42. -static const unsigned char hw_to_mycode[256] = {
  43. +const unsigned char hw_to_mycode[256] = {
  44.     /* 0x00 */ 0, KEY_ESC, KEY_1, KEY_2,
  45.     /* 0x04 */ KEY_3, KEY_4, KEY_5, KEY_6,
  46.     /* 0x08 */ KEY_7, KEY_8, KEY_9, KEY_0,
  47. diff --git a/src/win/wmouse.c b/src/win/wmouse.c
  48. index ff85b73..346012f 100644
  49. --- a/src/win/wmouse.c
  50. +++ b/src/win/wmouse.c
  51. @@ -82,7 +82,7 @@ HCURSOR _win_hcursor = NULL;  /* Hardware cursor to display */
  52.  #define DINPUT_BUFFERSIZE 256
  53.  static HANDLE mouse_input_event = NULL;
  54.  static LPDIRECTINPUT mouse_dinput = NULL;
  55. -static LPDIRECTINPUTDEVICE mouse_dinput_device = NULL;
  56. +LPDIRECTINPUTDEVICE mouse_dinput_device = NULL;
  57.  
  58.  static int dinput_buttons = 0;
  59.  static int dinput_wheel = FALSE;
  60. --
  61. 1.9.5.msysgit.0
  62.  
Title: Re: Compiling the Full Editor (are there still native.dll problems?)
Post by: Crimson Wizard on 29 Mar 2017, 15:58
Here's the latest explanation on how to build AGS:

https://github.com/adventuregamestudio/ags/blob/master/Windows/README.md

Just in case, here are all libraries built for MSVS2008 SP1:
https://www.dropbox.com/s/9ww09tkkilh1qgf/ags-libs.zip?dl=0
You should be able to use them if you are using exactly MSVS2008 SP1 to make AGS.

I need to know if this readme can be used to make the libraries (and AGS).

Babar mentioned that he was struggling to build them, but did not tell what was the problem, and I do no hear from him again since.
Also, I know that Gurok found it difficult to use cmake scripts when building Allegro.

Personally, I found learning CMake most time consuming stage of this process, because I did not use it before, but that's also because I had to modify cmake scripts to add extra features for our case.

Please, list all problems you had when following the readme, and I'll see if I need to add more elaborate instructions, or modify something in the biild process.


Title: Re: Compiling the Full Editor (are there still native.dll problems?)
Post by: Crimson Wizard on 03 Apr 2017, 21:14
I found there seem to be a mistake in current instructions, related to making Debug version of Editor (or rather AGS.Native dll).

Apparently for every native library you link (allegro and alfont) not only the method you link to runtime C libraries must match (dynamic link, as opposed to static link, which is required for engine), but also you must link to exactly Debug version of C libraries when you are building AGS.Native in Debug config (/MDd flag vs just /MD). This is something that I forgot to mention, and set up in existing solutions.

Otherwise some standard C functions cause program to crash.

From the user's perspective this may seem to be largerly random, so far I found that such crash occurs when trying to compile the game with compressed sprite file.

Release configuration seem to be set up properly and appear unaffected.
Title: Re: Compiling the Full Editor (are there still native.dll problems?)
Post by: Gurok on 04 Apr 2017, 04:00
I experienced crashes when saving room files using the debug build. I don't know if this is related or not. I haven't got around to building the remaining libraries myself yet (changed machines).
Title: Re: Compiling the Full Editor (are there still native.dll problems?)
Post by: Crimson Wizard on 04 Apr 2017, 07:45
I experienced crashes when saving room files using the debug build. I don't know if this is related or not.
Yes that's it, it also crashes during lzw compression at room save.

Here's libraries for debug config:
https://www.dropbox.com/s/pfrgs372ofse4x4/ags-libs-debug.zip?dl=0
Title: Re: Compiling the Full Editor (are there still native.dll problems?)
Post by: Crimson Wizard on 08 May 2017, 16:02
Does anyone know a way to upload files to github, so that they do not relate to particular tag, but rather to whole project? While not pushing them in repository itself.
I would like to upload precompiled libraries there.

Otherwise, what is a good file storage? I used mediafire for many years, but I sometimes hear people have troubles with it.
Title: Re: Compiling the Full Editor (are there still native.dll problems?)
Post by: ChamberOfFear on 08 May 2017, 16:16
Paket (https://fsprojects.github.io/Paket/) maybe? It's intended as Nuget wrapper to avoid certain pitfalls related with NuGet, however it can also be used to download git repos or even files.
Title: Re: Compiling the Full Editor (are there still native.dll problems?)
Post by: Alan v.Drake on 08 May 2017, 17:42
You could make a separate repo just for the compiled libs.
Probably simpler that way, and you don't have to gamble on the permanence of file sharing services.

- Alan
Title: Re: Compiling the Full Editor (are there still native.dll problems?)
Post by: Crimson Wizard on 08 May 2017, 17:53
If we are to put these into repository (any repository) anyway, then we could use Github's LFS (https://git-lfs.github.com/). If I understand correctly, it overrides commit action for certain files and physically stores them in specialized storage.