VCMI for macOS

In this case your bundle should go into root cmakelists - this is not bundle for client but for vcmi itself.
Anything global to vcmi should go into root cmakelists.
Anything specific to project should be in project cmakelists.

I did :slight_smile:
source psd + rendered png’s: dl.dropbox.com/u/22372764/vcmi/vcmi-icons.zip
I’ll upload icons to svn a bit later.

Of course I could make an empty bundle for vcmiclient target and copy everything else to it in package step. But is very very inconvinient. When I’ll start vcmiclient bundle from Xcode for debugging it will look for all resources, server executable and AI libs inside bundle. I can’t specify DATA_DIR to /Users/stopiccot/h3 while debugging executable and return to ./…/Data (relative path inside bundle) in runtime. So from some theoretical point of view it is more logical to do all copying at package step. But in real life you will end up copying files to their locations inside bundle by hand if you want to debug something. This will ruin all developing experience on OS X. Is cmake script prettiness worth of it?

Regarding CMAKE_INSTALL_RPATH it simply does not work for me. Because what I need is to get such thing in Xcode project - grab.by/hws0 so library install names containing @rpah (@rpah/SDL.framework/Versions/A/SDL) will expand correclty (@executable_path/…/Frameworks/SDL.framework/Versions/A/SDL).

Anything wrong with using server\libs from bundle?

Theoretically you can place all H3 data in ~/.vcmi directory instead of DATA_DIR and keep bundle as it - no need to manually move files.

In this case I agree.
But I think that you should check Mac-specfic generators in CPack - they can correctly copy files from cmake INSTALL command instead of manual cp’s

How I should distinguish developer case and look for game data in ~/.vcmi and look inside bundle for end-user? I see the only options to introduce something like PATH for DATA_DIR so it could be defined as: “…/Data:~/.vcmi”

I’ll look further if we could build .dmg with CPack. Still getting used to cmake :slight_smile:

VCMI always checks for both locations: data dir and user dir.
You may split data between these directories in any way you want. For example config and Mods directories can be copied from source to bundle during packaging and users will place all H3 data in ~/.vcmi (useful on Linux where DATA_DIR is owned by root)

Check config/filesystem.json to see where VCMI looks for resources
Check lib/Filesystem/CResourceLoader.cpp (method CResourceHandler::initialize ) to see code

I’ve looked through CResourceLoader.cpp but still do not understand why instead of ability to define multiple folders for DATA_DIR constant we have this hardcode with userdir. Defining DATA_DIR to “…/Data:~/.vcmi” would be a much more robust solution and BIN_DIR could leverage from this too. Defining BIN_DIR to “.:…/…/…/” would be enought to eliminate copy step in vcmiclient target for OS X.

Now OS X build supports video:
osx.path - dl.dropbox.com/u/1777581/osx.patch
dependency.zip - dl.dropbox.com/u/1777581/dependency.zip

Packaging .dmg via cmake is still work in progress. Any reviews are welcome as always.

All that *_DIR constants are coming from ancient code. VCMI definitely needs some way to specify them on startup.
Some enviroment vars like VCMI_DATA_DIR should be trivial to implement. Console arguments should work too but they should be passed to server manually on game start.

Multiple entries for data and lib dirs are fine but I think that user drectory should remain separate from data.
Binary dir can be replaced with path to server so its use will be more clear

One more problem on OS X is video playback. Currently i’m gettings this grab.by/hKcM. Seems to be BGR instead of RGB. Any ideas what could have triggered it? Maybe ffmpeg needs to be compiled with some specific flags or something eles? Any clues? Maybe somebody already had such errors and could save my time?

client/CVideoHander.cpp, line 840

Seems like incorrect detection of RGB vs BGR screens. Maybe something like this will work:

if (screen->format->Rshift < 16)
/* code for your screen */
else
/* original code */

Yeah, that was the reason. Already fixed that :wink:

Ok. Seems to be ready. Xcode project is generated. All features are supported. Packaging to .dmg is done. Looking forward to see changes in trunk.

osx.path - dl.dropbox.com/u/1777581/osx.patch
osx.diff - dl.dropbox.com/u/1777581/osx.diff
dependency.zip - dl.dropbox.com/u/1777581/dependency.zip

Patch applied, rev 3018

I’ve made a dmg package (rev 3019) so it could be added to download section on main page - dl.dropbox.com/u/1777581/vcmi-0.90-Darwin.dmg

Thank you for contribution!

By the way… How is that includes are platform specific? I see CBattleAnimations.h included in CBattleInterface.h — why is it needed?

I’m not sure if it belongs there, it is r3019, not the actual VCMI 0.9. Besides, I’m not sure how to label it or whether it needs some additional instructions.

How about creating a wiki page “Installation on OS X” with download link and instructions just like we have wiki.vcmi.eu/index.php?title=Ins … n_on_Linux ? [Or, if there’s little difference, we could make it a single page for both Linux/OS X.]
You can edit vcmi wiki after signing in with your forum account. :slight_smile:

To tell the truth I don’t know myself :slight_smile: Maybe it’s a sign of Clang immaturity. Maybe something else. But in some places forward declarations haven’t worked so I replaced them with direct includes.

I’ve already have draft “Building VCMI on OS X” but I’m waiting for my new SSD to arrive soon. I’m going to install fresh system on it anyway so it would be a great possibility to check everything one more time on a clean system.

What about end-user installing it’s really dead simple. Every OS X user will do it. The only problem is game data which anyway should be obtained separately and placed to “~/.vcmi”. I’m a bit concerned about it because for myself I installed Heroes3 + WoG on Windows machine, compressed to zip archive and copied to Mac. Not sure it’s a good solution because some people don’t have second computer with Windows. We have the same problem on Linux so maybe we need shared “Preparing game data on non-Windows system” page. Any ideas? Because Wine based manual is not very best solution from my point of view.

Strange thing is that I use clang as well. And I don’t need those includes.
The only difference I can think of is standard library (libstdc++ for me, libc++ on Mac) but it shouldn’t affect includes either.

Yeah. I’ve been asked about this multiple times. Check my wiki update (vcmibuilder script):
wiki.vcmi.eu/index.php?title=Ins … aring_data

Will commit the script to svn today so you can check how it works on Mac. Shouldn’t be a problem - it requires bash itself + some optional utilites to extract data (wget, unzip, unshield, innoextract).

EDIT: done. Script uploaded, revision 3022
sourceforge.net/apps/trac/vcmi/b … cmibuilder

Yep, I’m using libc++ because libstdc++ on OS X is way outdated (from gcc 4.2). And I can’t use libstdc++ from newer gcc installed from MacPorts because of portability.

Yeah, unshield install seems to be working fine after some patches to unshield itself. Can anyone provide me iso with InnoSetup install to test innoextract?