VCMI for macOS

International board Development
#1

Installation instructions on Wiki:

Build instructions for developers:

#2

archive with prebuilt dependecies dl.dropbox.com/u/1777581/dependency.zip

#3

CMakeLists.txt

  • disabling video - I’d rather see this as option similar to DISABLE_ERM but I can do this later myself.

client/CMakeLists.txt

  • rpath - why not use CMAKE_INSTALL_RPATH instead or link these libraries statically? Same goes to server rpath
  • bundle creation:
    • should be placed in root cmakelist

client/vcmi.icns file - why not generate it during bundle creation?

larger icons - OK but there is just too much blur.
Don’t know if author is still here to render bigger one but at least you could use this one as base: vcmi.eu/logo.png

#4

It is first iteration only. Video is disabled for now because I need to compile all ffmpeg libs fox OS X. So it’s temporary. Just like video for x64 Windows version.

As for icons I just upscaled existing icon for now. We probably need a vector vcmi icon for the future.

As for bundle it is not a kind of installation package like (.deb, .msi or OSX’s .dmg) so it should be built even by simple build command, not install or package commands. So I’m not sure that I can use CPack for it. Thought it is intended to build end-user install packages - .dmg for OSX in our case. Same for placing bundle creation in root CMakeList. I think only install and package commands that generate final .dmg should be located in it. Correct me if I’m wrong.

#5

How about this one?

http://vcmi.eu/logo.png

#6

Warmonger, I already linked to exactly same URL:

There is no “true” vector icon. Dikamilo had psd that could be rendered to any size. I send PM to him but I don’t know if he is still around or if he still have the icon.
If somebody will make vector one - that’s great. But this site is not popular among artists.

Regarding bundle - the main reason why I asked for this is that client should not depend on AI, scripting libs or server - any of those can be compiled separately or even located on different system (in case of server).

And CPack has “bundle generator” - check my link. Don’t know much about Mac OS but making client to depend on everything else is a bad idea.

#7

Ok I will use icon you linked but it is 200x200 what is still far from 1024x1024 normally needed for OS X icon (1024 version is used as a big icon for Retina). Would be great if you could recover that source psd.

Regarding bundle. OS X way of installing such applications - you just drag and drop bundle to your /Applications folder and run. Because server is needed for client to work in single player - it should be located in bundle. It is really frustrating to have to copy something inside bundle for game to work. So it is absolutely normal to place everything that could be potentially needed into the bundle. Just like VCMI_server.exe is located in zip archive with Windows binaries. And please note that client does not actually depend on server. You can easily remove vcmiserver executable from bundle and it will work until you try to start a single player game. And considering that end-users will use this bundle I don’t see any need for developers to compile a standalone non-bundle version of a client. It would be really annoying to run packaging after every change to test bundle.

#8

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.

#9

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?

#10

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).

#11

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

#12

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”

#13

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

#14

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

#15

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.

#16

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.

#17

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

#18

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?

#19

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 */
#20

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