Jump to content

cc_julian

Community Members
 View Profile  See their activity

  • Posts

    21

  • Joined

  • Last visited

 Content Type 

Posts posted by cc_julian

  2. precompiled mac version done

    in Applications and Contributions

    Posted

    >Why do you include ps/Pyrogenesis.h in several source files?

    i've included pyrogenesis.h in all files that use psLogDir(), which is declared in this header, so i don't know how it could ever compile without it being included

    >Why the #undef _T in UniDoubler.h?

    i got an warning for an double definition there, and there already were some undefs there so i added it. you can just skip that part because it's just a warning.

    >As a general question, does your build support precompiled headers?

    yes xcode supports a single precompiled header. i've created the xcode/Sources/_ad_Prefix.pch as the precompiled header

    >In Memory.h, it's conventional to name the macro guard after the file, so MEMORY_H.

    oh yes sorry, i meant to do that but the namespace name confused me ;-)

    >In AtlasUI, I notice several files have changed <> includes to "", any particular reason for that?

    consistency. 95% of the WX includes use the local header "" notation, and just very few the system header includes <>. i could just add the wx header directory as a user header directory AND as a system header directory, but that would be kinda ... wrong ... just because a few includes deviate from the others. actually using <> everywhere would be even more "right"

    >Why is RGBColor renamed to RGBColorVector?

    it conflicts with RGBColor as defined somewhere deep in the headers of the mac version of WX. i bet one could work around this with some namespace things, but i am not that fluent in c++ things.

  7. precompiled mac version done

    in Applications and Contributions

    Posted

    ok thanks ;) got it too compile. weirdly changing c_str() to wc_str() doesn't fix the archiveviewer issue, but as you noted we don't need that file ;-)

    although it compiles now, it doesn't link ;( the atlas stuff depends on all the core stuff like CRenderer and CSimulation2 etc. what to do here? can't include these sources in the dll for atlas, as that would lead to duplicate symbols when loading it, or?

    anyway, i am off for the weekend ;)

  8. precompiled mac version done

    in Applications and Contributions

    Posted

    progress on atlas.

    got most of it to compile after some work, remaining problems:

    • whats with the DEVIL dependency in DDT.cpp, is this really necessary?

    • XMP.cpp, whats all this xercesc stuff?

    • archiveviewer.cpp:464, gcc complains:

    /Users/julian/Desktop/trunk/build/xcode/../../source/tools/atlas/AtlasUI/ArchiveViewer/ArchiveViewer.cpp:464:0 /Users/julian/Desktop/trunk/build/xcode/../../source/tools/atlas/AtlasUI/ArchiveViewer/ArchiveViewer.cpp:464: error: no matching function for call to 'std::set<std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >, std::less<std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > >, std::allocator<std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > > >::insert(wxCStrData)'

    /Xcode3/SDKs/MacOSX10.6.sdk/usr/include/c++/4.2.1/bits/stl_set.h:304:0 /Xcode3/SDKs/MacOSX10.6.sdk/usr/include/c++/4.2.1/bits/stl_set.h:304: note: candidates are: std::pair<typename std::_Rb_tree<_Key, _Key, std::_Identity<_Key>, _Compare, typename _Alloc::rebind<_Key>::other>::const_iterator, bool> std::set<_Key, _Compare, _Alloc>::insert(const _Key&) [with _Key = std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >, _Compare = std::less<std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > >, _Alloc = std::allocator<std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > >]

    /Xcode3/SDKs/MacOSX10.6.sdk/usr/include/c++/4.2.1/bits/stl_set.h:331:0 /Xcode3/SDKs/MacOSX10.6.sdk/usr/include/c++/4.2.1/bits/stl_set.h:331: note: typename std::_Rb_tree<_Key, _Key, std::_Identity<_Key>, _Compare, typename _Alloc::rebind<_Key>::other>::const_iterator std::set<_Key, _Compare, _Alloc>::insert(typename std::_Rb_tree<_Key, _Key, std::_Identity<_Key>, _Compare, typename _Alloc::rebind<_Key>::other>::const_iterator, const _Key&) [with _Key = std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >, _Compare = std::less<std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > >, _Alloc = std::allocator<std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > >]

  12. precompiled mac version done

    in Applications and Contributions

    Posted

    i've updated all 3 files and can confirm it "working" now.

    there are some remaining problems though

    • game freezes for a few seconds or even minutes after loading a map (and being sluggish even afterwards), may be related to having to use the debug version of the javascript library cause of linker issues

    • i've seen the game hang in opengl code on lion

    for both of these issues it would be good to set the game to windowed mode in the config file in Library/Application Support/0AD/config/

    i'll look at these later on.

  15. precompiled mac version done

    in Applications and Contributions

    Posted · Edited by cc_julian

    Snow Leopard 10.6.8.

    2.5ghz intel core i5 iMac 2011...

    i'll have a look

    EDIT: found the problem, this was already working, will fix it soon.

    i've tried to compile it, but it fails (xcode) what means choose the release-mode?

    just FYI, saying something like "it fails" is completely useless at it doesn't give any information on what the actual problem is

    ok, i found the release-config... but somehow it still does not work. a lot of files in the xcode list are red.

    means the files couldnt be found, means you didn't put the xcode folder into the build folder of the 0ad sources. the xcode project is meant for *developers*

  18. precompiled mac version done

    in Applications and Contributions

    Posted

    Something like a shell script that downloads and builds and installs the libraries might be sufficient.

    might be difficult, since even just installing macports might make built libraries "silently" dependent on in and therefore non-deployable.

    libpng is included with macosx anyway, enet didnt update in the last 5 years, boost isn't security relevant, and probably nvtt neither. leaves us with libjpeg and mozjs.

    i bet i can build those libraries 50 times in the time it takes to build a system that automatically generates deployable binaries from their latest versions.

  19. precompiled mac version done

    in Applications and Contributions

    Posted · Edited by cc_julian

    Interesting, thanks for all the info and files, it's a very welcome contribution to the community (people have been begging recently for an Alpha 7 binary for OS X) :)

    i am glad if its of use

    I'll see if we can get some stats on how many OS X 10.5 or previous users we have and also how many 32-bit Macs (there are these semi-unrelated stats, which show 10.5 is at least as popular as 10.7 among browsers of that website, but I don't think we can assume 0A.D. players break down the same way). My feeling is that it's not a big deal, 0A.D. requires fairly good hardware to be enjoyed and Mac users seem to not mind spending out on new stuff, on an annual basis :P

    if someone provides prebuilt versions of the dependencies (boost, enet, collada, libjpeg, mozjs, nvtt), i'd be happy to update the project to support 32 bit and 10.5

    With Alpha 7 we include a new build system (not default yet) that generates an Xcode project on OS X (you'll see it using the normal build instructions but substitute update-workspaces-new.sh). Some effort has been spent getting this far, but it's not perfect. What we would prefer is to get that working correctly as it does on other platforms, instead of having to construct the Xcode project by hand (since we might refactor/restructure the code, add new files and folders, and we want that handled automatically to make the process as painless as possible, which it's not currently). Probably that involves fixing small bugs and deficiencies in Premake. I think it's close but I'm not that knowledgeable about app bundles and the OS X build process. It would benefit from an expert opinion ;)

    i know generating project files is popular right now, but in my opinion it just doesnt work and i don't have an interest to spend a single minute on using premake/cmake/whatever or even messing with sucky generated projects ;)

    you can of course continue using premake, and just use my xcode project if you want to create deployable DMGs, that would be the least effort

    MacPorts is annoying and I wouldn't mind finding an alternative, but it doesn't really fit in with our build process to require manually downloading and compiling a bunch of libraries from source. I seem to recall reading somewhere that Xcode can manage these dependencies, I may be mistaken.

    the solution here is just to pre-build the dependencies once and include the pre-built libraries, so its easy to build for everyone

    The paths patch will definitely need to be more specific, we want the standard Unix path scheme for SVN builds. That code is due for changes anyway, even Windows builds need more reasonable data paths.

    hm ok but storing files in ~./local/ on Mac OS X is just wrong, regardless how the binary is being built ;-)

    i suggest making the data path change only for the xcode build, but the location of the folder where files are being written to should be changed for all Mac OS X builds.

    i've done just that in the linked patch and xcode folder.

    if you want the other path change to be only for the xcode builds too, just change __APPLE__ to MAC_NATIVE

  20. precompiled mac version done

    in Applications and Contributions

    Posted · Edited by cc_julian

    BTW:

    i've completely ignored the existing build system (premake) and instead created an xcode version from scratch. using something other than xcode always has difficulties creating something that is actually deployable to end-users. of course i generated stand-alone versions of all dependent libraries too - again, using macports installed versions would lead to dependencies that make deployment impossible.

  21. precompiled mac version done

    in Applications and Contributions

    Posted · Edited by cc_julian

    hey

    i came across the 0ad alpha 7 announcement today, was encouraged by the fat "Instructions for Mac OS" button, but as you all know it only leads only to an compilation instructions site instead of precompiled downloads.

    i've therefore spent some time creating:

    • a distributable binary version of 0ad alpha 7 for Mac OS X

    • an xcode project and assorted support infrastructure for 0ad that makes creating distributable binary mac versions easy

    1.) here is a very small patch for 0ad that fixes some compile errors (pyrogenesis.h is needed for the psLogDir declaration) and fixes up the runtime paths so that 0ad reads the data files from inside its application bundle (because we have a proper double clickable moveable app now) and also uses better paths for storing preferences. you could also change the ifdefs from __APPLE__ to something we define in _ad_Prefix.pch if you don't want these path changes to apply to mac versions built from the command line

    http://dl.dropbox.co..._mac_patch.diff

    http://dl.dropbox.com/u/7221986/atlas_mac_patch.diff

    2.) here is an zipped folder containing an xcode project for building 0ad and misc support files including pre-built libraries etc etc. this should be added to the build/ folder

    http://dl.dropbox.co...d_mac_xcode.zip

    3.) here is a pre-built deployable version of 0AD beta 7 - i've personally tested it on an NVIDIA equipped MacPro with 10.6.6 and an ATI equipped iMac with 10.7.1

    0ad-r10288-alpha-mac.dmg

    ___

    for building deployable binaries yourself you just need to open the build/xcode/0ad.xcodeproj in Xcode 3.2 (4.x may also work, but is untested), select the "Release" configuration and hit "Build" from the "Build" menu. this will create the "0 A.D." application. now just right click it, select "show package contents" and add the *complete* "data" folder into the application bundle, because without data the binary won't run ;-) now zip the result or make a DMG with Disk Utility.

    EDIT: boost_1_47_0 must also be downloaded and decompressed into the xcode folder

    __

    the generated binary runs on Mac OS X 10.6 or later and only on 64-bit Macs. i don't consider the requirements problematic, 10.5 is unsupported by apple themselves by now, and apple only shipped very few 32-bit intel macs, most of which additionally only have sucky integrated GPUs like the GMA 950 and are barely able to run a game anyway. it would be easy to create a version that runs on 32 bit and 10.5 too, would just require a few hours creating updated version of the library dependencies, and a few changes to the xcode project

    bye, julian

×
×
  • Create New...