historic_bruno

Normally I build the OS X release bundles, but my dev computer has been down for a while and I'm stuck on an old XP laptop. wraitii has kindly volunteered to assist in building the OS X bundle for A16. Since I realized there hasn't ever been a really authoritative document on how to do this, I'm going to post my thoughts here. ----- There's an outline of the process on ReleaseProcess. You should update BUNDLE_VERSION to "0.0.16". Most of the work is done by running build-osx-bundle.sh. When it's done, if it works, you'll get a 0ad.app bundle in the workspaces directory. My suggestion for A16 and maybe indefinitely, is to build against the 10.7 SDK (already default in build-osx-bundle.sh) assuming your Xcode version includes it, and 10.7 API using MIN_OSX_VERSION="10.7" (sets the earliest OS X version the game will run on). You could also try the 10.6 API, but as of the SM upgrade it's no longer possible to build on 10.6, and I don't know if you will encounter issues if you go down that route. For now, I'm thinking we've lost compatibility with older OS X and it's probably not a big deal. We can forget about a 32-bit bundle. General recommendations: don't have Homebrew/MacPorts/whatever installed if you can help it, they will only break things. If you find errors, there's probably no quick and dirty solution, it's better to fix each error. config.log's are your friend if a library configure script fails. Commenting out bits of build-osx-bundle.sh can save a lot of time during troubleshooting, if they already worked (like the forced library rebuild, or the clean game build, or the archive builder). The new SpiderMonkey doesn't support GCC 4.2, so it won't work with llvm-gcc bundled previously with Xcode, it now requires clang. Depending on your Xcode version, "gcc" might already be clang, if not, you'll need to set CC=clang and CXX=clang++ in build-osx-bundle.sh. I would almost recommend that anyway, so stupid configure scripts don't assume "gcc" really is GCC. Mavericks will require even more massaging to get it working. Atlas is broken due to a runtime error (see #2356). A couple of options: 1) use an experimental dev version of wxWidgets but it's risky, it may have other bugs, 2) extract the patch(es) that fix that and apply to 3.0.0, 3) downgrade to 2.9 (but config options have changed so that's a pain too), 4) don't build Atlas... Another special OS X release blocker is #2338. You could try commenting out the offending UPnPc free lines (even better put them in #if OS_MACOSX ... #endif wrappers), or disable UPnP in the build as a last resort (--without-miniupnpc?). Since A15, multiplayer hosting is broken on OS X due to this bug. leper and I agreed a small memory leak is better than a crash. With A16, we have internationalization/localization support, some modification of build-osx-bundle.sh will be required so it copies the necessary files from binaries\data\l10n into the bundle (hopefully only one line). Also, only approved+reviewed translations should be included, sanderd17 and Gallaecio would know more about that. Check the binaries (0ad.app/Contents/MacOS/pyrogenesis, and AtlasUI/Collada dylibs in the shared frameworks directory) for the correct architecture using the "file" command (should be x86_64), check which dylibs they link with "otool -L" (none of those built in libraries/osx should be listed there, they are static libs, look for weird ones that would break the bundle, like /opt/* or /usr/local/*). Check that the game runs, Atlas runs, and tests pass You need to put 0ad.app into a bzip2-compressed disk image (DMG) or it will be a huge download: 1) create an uncompressed DMG big enough to hold the bundle, 2) make a shortcut to /Applications so people can "install" the game in the Mac fashion, 3) copy 0ad.app into the folder, 4) set the icon positions and background image as desired, 5) convert the uncompressed DMG into a compressed read-only DMG with hdiutil. Again that's outlined on ReleaseProcess with additional references. When you have the compressed DMG, you'll need to let Philip know, and host it somewhere so he can download it remotely into http://releases.wildfiregames.com/rc. I usually turn on the OS X web server and host it directly, long enough for him to download it - you might have another web server you can use. I would recommend testing the DMG first, on another machine if possible, to verify it opens properly, and that it works on as many versions of OS X as you can access. If you only have one, then round up as many OS X volunteers for testing as you can, the more the merrier

This has been proposed in the past, one idea was to use pre-rendered textures with the names in ancient scripts. Really I don't think they would add much to the game other than confusion, since almost nobody will be able to read them. It would be interesting to see, maybe not cluttering the session UI, but for an in-game "encyclopedia". Would it be difficult to change that? Perhaps more of a challenge would be finding fonts that include them...

Have you made any local changes to the game? If not, take us through the exact steps you're using. Is it single player or multiplayer match? Which match settings do you use? Exactly when do the error/warnings occur? Is there some part of the UI which is missing? (if a texture failed to load, you should see that)

Thanks! Sure, that would be good to know I suspect it's a driver bug.

Can you attach your system_info.txt? (from the game's log directory) That will tell us more about your graphics card and drivers. You could also mention the graphics options you have enabled in local.cfg (if applicable) and user.cfg.

Fun fact: early in 0 A.D.'s development, it was officially decided to use 2D graphics instead of 3D (I can't find the log of that discussion, but the reasons were something like, 2D art is easier to create than 3D, not everyone has blazing fast graphics cards, etc).

Then we would be testing MinGW cross-compilation, not MSVC native compilation, while MSVC is going to be our compiler and IDE of choice on Windows for the foreseeable future. We also wouldn't be testing the MSVC runtime libs, which can have peculiar issues (see r14983 for one of many). Of course, if someone wants to put the effort into getting the game to build and run with MinGW, that's fine by me I don't think anyone will use it, and it's probably wasted effort, but in that case, we would certainly want to test it as well.

I often use VMs for development, but in my experience they have too much input lag for gaming, even if the rest of the system is OK (graphics, CPU, RAM).

Which Linux distro and version? Do any of the Alt hotkeys work?

The symbol paths need to be set up, I recently wrote a section specifically for that in Debugging Then you can set VS to load the symbols either automatically or on demand. Then you should have a decent call stack that shows which function in pyrogenesis is triggering the crash.

I think the warnings are a good thing, as they help raise the awareness that undefined is a special value in JS and should be treated as such. The programmer should know if a variable can ever be in the undefined state without it being a bug, and in that case they should test for it explicitly. I would argue it's bad practice if a variable can either evaluate to false in some other way (e.g. false, 0, "", null, NaN) or be undefined, it should be one or the other by choice, so the type+value test is more appropriate: "if (foo !== undefined)". That's also part of our coding conventions. I think a lot of subtle bugs can be caught by warnings like that (and a good understanding of the peculiarities of JS).

Good Eventually we will rebuild all the libraries with a single compiler version (one of the newer versions), then only one of the debug runtime libraries will be needed for a debug build. Right now there is an unpleasant mix going back to VC++ 2005, explaining the large number of runtime libs in binaries/system.

Their Nvidia drivers are being more strict about conforming to the GLSL spec. I don't think it's an issue with the version, other than the one uniform warning/error that could be fixed, but it's probably better fixed by moving to the shader definition with all the other constants. The rest don't seem related to the version, but I don't know why it's crashing.

What we need is the call stack once it crashes and you have entered the debugger. You should see the call stack window, which you can select and copy/paste here. I think that's a problem with the Visual Studio installation, but it shouldn't have any effect on debugging this.

Yeah, at this point I need to know if anyone else gets the crash after applying the patch. Another thing that might help is to get the call stack when it crashes, using debugging techniques described here. IF it occurs in the shader program itself, that sounds like a driver bug, if it's in the game code, maybe the call stack will show something we can fix. Alternatively, if someone knows a lot about GLSL shaders and can check my patch for mistakes, that would be good

I suppose it's really a 32-bit Mac, too? http://support.apple.com/kb/HT3696 I think this was an issue with how Alpha 15 was packaged, I will try to fix it for Alpha 16. In the meantime, you *should* be able to work around the problem by disabling sound, which is unfortunate but better than nothing The game needs to be run with the "-nosound" option, you can do something like this from the terminal: open 0ad.app --args -nosoundor if you know some other way to pass command line options to bundles.

Yves is correct, the redistributable packages are what we could legally offer already, and those are only the release builds of the C runtime libraries. You actually have two options: acquire the debug runtime (e.g. install some version of Visual Studio 2008), or only use the release build of the game. Most of the time, the release build is sufficient and performs much better.

I would like to see the full details of the "error report". Which OS X bundle did you download, the 32-bit or the 64-bit? Which version, Alpha 15?

It shouldn't crash and I've never heard of that happening, you should report it on Trac, http://trac.wildfiregames.com/wiki/ReportingErrors If you include a sample script with an error that leads to the crash (or maybe it's a simple change), we can try to reproduce it and debug the crash.

Visual Studio is probably easier if you have it, though the game doesn't build on VS 2013 without modifications (missing prebuilt binaries for Boost libs). Here is a guide I wrote that goes into some detail on how to set up the debugger and troubleshoot, etc.: http://trac.wildfiregames.com/wiki/Debugging

Actually, I think it was planned to keep a read-only SVN repo around after the git transition, kind of like how we use git to mirror SVN now, we would reverse the process. Only team members would be required to use git to commit changes, and we'd prefer everyone else to use it for the better workflow, but SVN could still be there as a backup option.

That's odd, it worked locally (Radeon HD 6850 - Win 7/64). Do the logs contain any errors?

Does that option also set "gentangents=true"? As far as I know, that option is still required for preferglsl to work. http://trac.wildfiregames.com/wiki/Manual_Settings#AdvancedgraphicsGLSLonly

Sorry for the late response. One good discussion was in IRC on 2013-09-22, Philip gives a summary around 19:49.

In Alpha 15, Atlas won't work on OS X, that's a known problem and different than what is reported here.