UFO:Alien Invasion
Development => Coding => Topic started by: hwoarangmy on August 06, 2015, 10:34:31 pm
-
Hello,
First, thanks again for this great game. I've played 2.5 a year ago (finished it in normal) and I've recently started a new campaign to try 2.6 in hard mode and it seems you have done some great work. I will give you some more feedback when I will have played a little bit more.
I've recently downloaded the code source from github and compiled it (at least game, ifo2map, ufoed and ufo). Have you ever considered using cmake ?
Would you be interested in using it ?
If yes, I'm not a cmake expert but I can give a try ^^
-
Hi,
Glad you are enjoying the game, and sure if you could get cmake working that would be very nice :)
-
I've done a little research regarding cmake at some point, it's likely a lot of work. Stackoverflow has some valuable info.
cmake would allow generating an MSVC project file, as it seems the ability to compile with MSVC was present some time way in the past and then got lost due to nobody maintaining it. That is bad, since it should have a positive effect on code stability if you're able to compile and/or debug using various tools, and developer interest can rise.
-
Well, actually, it was easier than I expected. I choose to not use a bundle for dependencies to try the latest versions I can find. Note that I use code blocks with MinGW64.
ATM, I can build every project excepted uforadiant because it needs gtk. I've downloaded gtk dev libraries but it seems an older version is used in this project as I get errors complaining that only gtk/gtk.h should be included (from what I've seen, many files here include gtkwidget or only what they need - which seems not the way to do in the new version).
Because of that, I've downloaded ufoai codeblocks zip to get the includes and libraries used in the project (since I cannot use the latest version, the easier is to use this one).
For finding the dependencies, I've tried to use the scripts bundled with cmake as much as possible (because they probably include more search paths than the ones I will think of - especially on environments I don't know like MAC OS). Fortunately, I could find those for most of the required dependencies.
Once I get uforadiant to compile, I will have a look with linux (with Ubuntu running in virtualbox). I guess it will be easier as with windows, no dependency is found by itself.
That is bad, since it should have a positive effect on code stability if you're able to compile and/or debug using various tools, and developer interest can rise.
Yes, finding people who want to join an open source project is hard enough to not have them have to change the environment they like.
The good point with cmake is that it sets up the environment you like (be it MSVC, codeblocks MinGW, ...) by itself. The problem with maintaining project files is that when there is no more coder using it (for example MSVC), it will die fast (when a new file is addedn for example). When using cmake, you had a new file in the makefile and it will change all configurations ^^ (even some you had never tried and even knew they exist)
-
Good to hear that you are making good progress, looking forward to it :)
To be fair uforadiant has always caused us problems... I'm not even sure if it actually compile on windows right now — see bug #5252 (http://ufoai.org/bugs/ufoalieninvasion/issues/5252) (I know it compiles on linux)
-
Yes, I had this error when using the headers/libraries from the codeblocks+mingw package.
The error comes from this commit:
https://github.com/hwoarangmy/ufoai/commit/bf841a7ff5325e10775cae7a67eaf7ebea67a30f#diff-3062a8827676e9b846c0ac56236a4744L340
because g_mutex_init and the mutex related functions are not found. For my tests, I've rolled back this commit and it worked.
If I am not mistaken, those functions are from glib. I guess your Linux distros have more recent glib. The best would probably be to update the bundled glib. I will try with a new version and tell you if it works.
Concerning cmake, I was able to build all the projects (including radian). There were too many dependencies so I didn't want to mess with gtk and all their dependencies. That's why I used the package libraries. For cmake finding module, I will assume there is 1 include directory per needed library (in the bundle, the include directory will be the same for all dependencies).
Now, the last missing thing is the icon ^^
Then, I will try on linux
-
I've tried with a newer version of glib (the one bundled with the latest gtk version) and, as expected, it fixes the compilation problem with mutex functions.
Concerning cmake, could make it work and found a way to use icons with only a small modification of the rc files. ATM, they use a flag to know if they should use a relative path. I've removed the flag and replaced it with the path to use. That makes the rc file more straight forward.
Concerning the bundle, I can make a new one to fix the issue by replacing glib headers + libs. Do you want me to do that ?
Concerning cmake, I'm testing on linux.
-
Concerning the bundle, I can make a new one to fix the issue by replacing glib headers + libs. Do you want me to do that ?
That would be nice for our windows users.
Concerning cmake, I'm testing on linux.
Great!
-
I'm done with the first version. I've tested on Linux and it builds successfully on my Ubuntu as well as on windows.
I've rebased tonight and made the required changes due to lua.
Note that I've tried to follow what was done on the makefiles while working on cmake. But I couldn't test on Solaris or MacOSX.
If you want to integrate it, I can make a pull request on guthub.
The next steps, if you want, could be to turn building projects optional (with only game + ufo checked by default).
It might also be a good idea to allow to enter a dependency path so that users can compile without having to mess with the dependencies (that would be very close to the codeblocks current zip but with the dependencies only).
To test, you can have a look:
https://github.com/hwoarangmy/ufoai
WDYT ?
-
This is great!
Will a better look later, but just from what I can see: There seems to be no support for SDL2? I'm sure that's the direction Mattn wanted to move on. Is that something that can be made optional choosing between SDL 1.x and SDL 2.x? (Or maybe its already in and I'm just not seeing it...)
Also yes, having the option to turn projects on and off would be nice, as for dependecies, I gues that would be most useful for windows user I'd think?
-
There seems to be no support for SDL2?
It works with both. I've tested on windows with SDL2 (I downloaded) and SDL (from the package). Both worked. You just have to choose the corresponding includes you want and the libraries.
Also yes, having the option to turn projects on and off would be nice, as for dependecies, I gues that would be most useful for windows user I'd think?
I guess that most users won't use radiant and it has many dependencies so it could be nice to be able to turn it off. And if we are there, we can do the same for all.
BTW, note that I've simplified the rc files to allow choosing the path. Do you want me to change the codeblocks projects in build/projects to match ?
Moreover, I don't know how to choose the icon on linux (the equivalent to the rc files). Do you know how does it work ?
EDIT: I've installed SDL2/SDL2-mixer/SDL2-ttf and I confirm it works when we change the include paths/libraries. I remember having read news about bugs in UFOAI when using SDL2. Later, the makefile can be changed to look for SDL2 before SDL.
Note that I've tested and if SDL2 is installed but not SDL, SDL2 is not found
EDIT2: If you want to try, I've updated the commit in my repo so that if SDL is found, it is used. And if not, it will search for SDL2.
-
It works with both. I've tested on windows with SDL2 (I downloaded) and SDL (from the package). Both worked. You just have to choose the corresponding includes you want and the libraries.
I've now had time to actually test and I see this now, my bad.
I guess that most users won't use radiant and it has many dependencies so it could be nice to be able to turn it off. And if we are there, we can do the same for all.
But on linux after running cmake you can just do make ufo game to build just the game, so most helpful to windows user (but now that I think VS should have something similar...) anyway I mostly meant that a dependency path would be most helpful to windows users, still making the other modules optional would be nice anyway.
BTW, note that I've simplified the rc files to allow choosing the path. Do you want me to change the codeblocks projects in build/projects to match ?
For consistency I'd have to say yes please.
Moreover, I don't know how to choose the icon on linux (the equivalent to the rc files). Do you know how does it work ?
Linux executables don't have icons
EDIT: I've installed SDL2/SDL2-mixer/SDL2-ttf and I confirm it works when we change the include paths/libraries. I remember having read news about bugs in UFOAI when using SDL2. Later, the makefile can be changed to look for SDL2 before SDL.
Note that I've tested and if SDL2 is installed but not SDL, SDL2 is not found
EDIT2: If you want to try, I've updated the commit in my repo so that if SDL is found, it is used. And if not, it will search for SDL2.
Well we currently have SDL2 taking priority over SDL (and the worst bugs are already fixed :) ) so this is maybe backwards, but OK for starting.
-
But on linux after running cmake you can just do make ufo game to build just the game, so most helpful to windows user (but now that I think VS should have something similar...)
Well, it is always possible to compile only one project but the point with turning them optional is to not ask for dependencies. This way, if you disable uforadiant, for example, cmake will not ask for GTK (or at least won't complain if it is missing)
Linux executables don't have icons
Ok, nice to know
Well we currently have SDL2 taking priority over SDL (and the worst bugs are already fixed :) ) so this is maybe backwards, but OK for starting.
Ok. So, I will change so that SDL2 is chosen in priority to SDL.
For consistency I'd have to say yes please.
Ok. I will do that.
Note that I won't be around for a few days so I won't have time to do requested changes now. I will do them once I'm back ^^
-
Well, it is always possible to compile only one project but the point with turning them optional is to not ask for dependencies. This way, if you disable uforadiant, for example, cmake will not ask for GTK (or at least won't complain if it is missing)
You have a good point there.
Note that I won't be around for a few days so I won't have time to do requested changes now. I will do them once I'm back ^^
That's OK, take care!
-
I'm almost done with what I wanted to do. I could build all the projects with Windows and Linux. All of them are optional (only UFO and GAME checked by default).
However, I'm lacking quick description for the projects:
- GAME: "Build the library handling the battlescape"
- UFO2MAP: "Build the tool to compile maps"
- UFODED: ?
- UFO: "Build the main game"
- UFOMODEL: ?
- UFOSLICER: ?
- UFORADIANT: "Build UFO AI editor"
- UFOTESTALL: "Build unitary tests"
If someone could fill unknow projects (or complete the other ones if needed), it would be nice.
I'm also building a package with UFO AI dependencies only (allowing to build with any code-blocks/MinGW anyone has installed instead of having to use a full bundle)
Now, I'm going to try to build the game with an older computer with MinGW32 (I've currently used MinGW64) and with MSVS2013 (except radiant and maybe testall because they have too many dependencies). If I can build it with MSVS2013, I will add required dependencies in the bundle.
-
- UFODED: Dedicated server
- UFOMODEL: Tool for pre-compiling lightmaps for models
- UFOSLICER: Tool for creating fancy map overviews
The latter two I cannot describe better. :)
-geever
-
I'm done with cmake. I could build all the projects on:
- MinGW32 with WinXP
- MinGW64 with Win7
- GCC with Ubuntu
- MSVC with win7 (except uforadiant as there are too many dependencies related to GTK)
I had to make some changes to allow compilation with MSVC. Moreover, this compiler has seen a few problems I've fixed.
I've also created a bundle with mingw/msvc dependencies. If the path is given to cmake (by filling corresponding field or by creating an env variable), all the dependencies should be found automatically.
Do you want me to create a github pull request ?
-
Note that I've updated my fork (after rebasing) if you want to try:
https://github.com/hwoarangmy/ufoai
-
I've updated my repo to allow to output executables in the correct directory when using MSVC (instead of Debug/Release)
-
BTW, I've also made a bundle with the dependencies only. It allows to compile everything with MinGW and everything excepted uforadiant with MSVC 2013.
Note that to use it, with cmake, you can set cmake variable UFOAI_DEPENDENCIES_DIR to where you unzip the bundle.
You can also create a windows env variable UFOAI_DEPS set to where you unzip the bundle to help cmake find the dependencies.
Do you want me to upload it somewhere ?
-
UFO:AI supports win xp, MSVC 2013 does not. Should work with an older MSVC version too. Needs to be 2008 then, as 2010 and 2012 are not recommendable I hear. (I know 2010 - unstable and slow)
Says the lazy one who's nitpicking about your probably amazing work.
-
Well, I'm talking about MSVC2013 because that's what I have. But it might work with an older version I've not tried ^^
-
Sorry for the late answer
So its ready for Pull request? (or I could just lift it from your repo too) and yes having the dependencies bundle would be nice, but I'm not sure where you should upload it to.
-
I've uploaded the bundle. You can get it and upload it wherever you want
http://dl.free.fr/nUwn4l4zh
I'm currently compiling after rebase. I will create the PR as soon as I've checked it still compiles
-
I confirm it still compiles. The pull request is created. You can review it ^^
-
Very nice job. It would be cool if the cmake file could get some more love though. Using:
add_library(common ${COMMON_SRC})
target_link_libraries(common ${COMMON_DEPS})
add_executable(ufoded ${UFODED_SRC})
target_link_libraries(ufoded common)
would greatly reduce compile times.
-
Using:
add_library(common ${COMMON_SRC})
target_link_libraries(common ${COMMON_DEPS})
add_executable(ufoded ${UFODED_SRC})
target_link_libraries(ufoded common)
would greatly reduce compile times.
I'm comfortable with C/C++ but I'm not a cmake expert and I didn't look into UFOAI code very deep (only for the errors the compiler was complaining about).
However, every projects do not share the same common sources files. Using a project with the common sources would decrease compile time but increase executables size since they will embed not wanted stuff. That's a choice to make ^^
BTW, same goes for "shared" sources I guess.
-
true - but the symbols are stripped anyway.
I did something for my sideproject at https://github.com/mgerhardy/caveexpress - the cmake scripts will try to find a system wide installed lib, if not found, it will pick the embedded one. This would be cool for linux.
Would also be cool to get some feedback from some Xcode users whether the cmake script works for them.
-
I've found something interesting:
http://www.cmake.org/pipermail/cmake-developers/2012-March/003693.html
I will keep you in touch
EDIT: other link:
http://www.cmake.org/Wiki/CMake/Tutorials/Object_Library
-
That's what I meant.
-
I've had a look but it might be more complicated than expected. From what I've seen, some compiler flags are used in the common files (at least COMPILE_MAP/COMPILE_UFO but also some more that I don't know like PARANOID)...
-
Note that one solution could be to separate in the common folder the files that requires some flags and the files that can be safely compiled and linked. We could do that separation in the makefile and compile the common files that need the flags twice. But that would mean that if someone adds COMPILE_UFO in a common source that did not had it, the project will fail with a linker error and it won't be straihtforward to find where the error comes from.
I guess the best would be to split the common folder and make clear that the first part is for common not flagged code and that the second if for COMPILE_UFO/COMPILE_MAP. But I'm not sure the compile time gained is worth it (because it makes a strong link between source files architecture and the flags allowed to be used).
WDYT ?
-
I've added appveyor and travis-ci build support on github. Please check it out at the readme of the project at https://github.com/ufoai/ufoai/ (the badges)
the files might need some tweaks in .travis.yml and appveyor.yml in the ufoai git root.
-
I'm not used to travis or appveyor but in travis, it seems like cmake is not used (we can see the error comes from not finding ufo2map not being found).
In appveyor, cmake is used but dependencies are not found. Have you uploaded them ? The easiest (if possible) would be to upload the dependencies in the bundle (link in this thread) and set the UFOAI_DEPS variable.
EDIT: In any case, I'm interested in this kind of build systems for another open source project I'm involved in (Open Dungeons if you want to know) and I will take the opportunity to have a look.
-
I could setup appveyor to compile UFOAI. If there somewhere where I can upload the deps ? For my tests, I've used a private server to host the file but it would be good to use some UFOAI storage ^^
Note that I just need the deps I've uploaded in this thread available somewhere. If someone could upload it and post the link here, it will be enough.
I will go for a PR as soon as I know where to download the deps from.
-
So, I'm guessing that the silence here means no one besides Mattn has the right to upload files to our server...
-
He uploaded the file today on sourceforge. link:
https://sourceforge.net/projects/ufoai/files/UFO_AI%202.x/2.5/ufoai-deps.zip/download
I'm currently checking there is no problem and I will create a PR when it is done
-
DarkRainX and ShipIt: you now have all the needed rights, too. Sorry that it took so long.
-
Compilation is fixed with appVeyor and Travis ^^
Travis PR is released
-
very nice. Someone should maybe configure it in a way that build reports are send to the ufoai irc channel
-
oh.. btw. I've also prepared the travis build config to build for osx. But as ufoai needs brew stuff installed, someone who knows osx better should check that out, install all the deps and request osx build support activation for travis. Then all the major platforms are build.
-
Note that I've never used OSX. The cmake build is likely to fail as I did nearly nothing about it.
-
That's exactly why travis ci is so cool - i don't have a mac, too - but building a cmake based project for macosx and ios.
-
I've just created a PR with MinGW build with appVeyor (with MinGW, I've activated Radiant build)
Note that I've tried to activate unit tests but for some reason, I get no output with appVeyor. The tests are launched but nothing happens. It seems to work well on Travis (but some tests fail).
-
That's something with SDL command line applications I think, on windows they output to stdout.txt and stderr.txt instead, there ought to be a way to make it output to the console but I can't remember it.
-
Well, when I try my mingw compiled version, I get the output in the dos prompt...
Might be something with appVeyor or maybe the stage at which we launch the tests do not allow to have a command output
-
see cmake/macros.cmake - ufo_add_executable - the WINDOWED flag adds WIN32 to add_executable. This should be done to distinguish between console and windowed apps, too.
-
started a new pull request to work on the cmake build system: https://github.com/ufoai/ufoai/pull/27
-
Are the CodeBlocks files in build/projects/ for Linux or windows or both ?
The downloadable dependency package is for windows + MinGw or windows + MSVC only I presume ?
I tried setting up a environment with integrated debugging by generating a project file with cmake. win xp + MSVC 2008 seems too problematic, as UFO:AI is using newer C++ features while MSVC is behind g++/Linux or MinGw in supporting them, but Linux + CodeBlocks works pretty well.
cmake seems to find and use the dependencies from the OS rather than the ones in src/libs/.
-
Are the CodeBlocks files in build/projects/ for Linux or windows or both ?
I guess it is for both (but tested only on windows.
The downloadable dependency package is for windows + MinGw or windows + MSVC only I presume ?
It works with both MinGW and MSVS2013 (at least - only tested). This can be checked on github by looking at appVeyor's results.
I tried setting up a environment with integrated debugging by generating a project file with cmake. win xp + MSVC 2008 seems too problematic, as UFO:AI is using newer C++ features while MSVC is behind g++/Linux or MinGw in supporting them, but Linux + CodeBlocks works pretty well.
I've not tested with MSVS2008. But if you say the code uses newer features, I guess nobody will want to rollback to such an old version.
cmake seems to find and use the dependencies from the OS rather than the ones in src/libs/.
It depends on how your PATH is set. However, src/libs are sources files AFAIK. So, the needed ones have been used. The others are not.
-
Something about the Version shown on the start screen is wrong. CMAKE_BUILD_TYPE is set to Debug with cmake -i and the resulting executable after make does contain debugging information (file size is much larger, line numbers are shown in backtraces) but it keeps showing Release on the start screen.
-
Something about the Version shown on the start screen is wrong. CMAKE_BUILD_TYPE is set to Debug with cmake -i and the resulting executable after make does contain debugging information (file size is much larger, line numbers are shown in backtraces) but it keeps showing Release on the start screen.
That probably means that in debug mode, we should define some flag that we don't
-
That probably means that in debug mode, we should define some flag that we don't
Yes, I found it. We should add_definitions(-DDEBUG). I've submitted a patch:
https://ufoai.org/bugs/ufoalieninvasion/issues/5748