102 replies to this topic

[cc_julian]

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.

[Ykkrosh]

Uploaded the new .dmg here again (md5 f708e3a565137402aaf843c360e474c0).

[JuliusColtranePille]

cc_julian, on 19 September 2011 - 06:16 PM, said:

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.

superbe!!! thx a lot.

where/how do i set the game in windowed mode? where is the config file located?

warm regards

[cc_julian]

read the post you quoted again

[cc_julian]

>Uploaded the new .dmg here again (md5 f708e3a565137402aaf843c360e474c0).

thanks. sorry but i've now fixed the javascript slowness bug and updated the file again runs fine now

[JuliusColtranePille]

cc_julian, on 19 September 2011 - 07:25 PM, said:

>Uploaded the new .dmg here again (md5 f708e3a565137402aaf843c360e474c0).

thanks. sorry but i've now fixed the javascript slowness bug and updated the file again runs fine now

i (we) owe you one. big time.

[Ykkrosh]

Uploaded again (650f5ea5f0d80b27c43547cecc10b8e7). (Well, downloaded rather than uploaded, but whatever )

[JuliusColtranePille]

cc_julian, on 19 September 2011 - 07:25 PM, said:

>Uploaded the new .dmg here again (md5 f708e3a565137402aaf843c360e474c0).

thanks. sorry but i've now fixed the javascript slowness bug and updated the file again runs fine now

somehow the freezing still happens...
am i the only one?

EDIT:

works totally fine now...

Edited by JuliusColtranePille, 19 September 2011 - 08:13 PM.

[mpsii]

Thanks for the files. Testing the pre-built binary now.

[JuliusColtranePille]

is there a possibility to get atlas running somehow?

outside the game or elsewhere?

thx,
regards

[historic_bruno]

JuliusColtranePille, on 20 September 2011 - 05:54 PM, said:

is there a possibility to get atlas running somehow?

outside the game or elsewhere?

thx,
regards

As of r10300, this is possible

Note: you'll need the wxWidgets-devel (2.9.x) library also known as wxOSX/Cocoa, because a 64-bit build is only possible with Cocoa (the stable 2.8 version of wxMac used Carbon instead). cc_julian will need to create the Xcode projects for Atlas, if not already, and bundle that dependency Otherwise just use the usual build instructions for OS X (update-workspaces, etc).

[cc_julian]

i am a bit short of time currently. if someone provides me with a pre-built deployable binary of wxWidgets devel 64 bit (.a or .dylib or .framework) i will give it a try tomorrow, else i will look at it next week.

check dependencies of libraries with "otool -L"

[JuliusColtranePille]

cc_julian, on 20 September 2011 - 11:43 PM, said:

i am a bit short of time currently. if someone provides me with a pre-built deployable binary of wxWidgets devel 64 bit (.a or .dylib or .framework) i will give it a try tomorrow, else i will look at it next week.

check dependencies of libraries with "otool -L"

sounds cool.
everything you made till now was great, so i think the community can wait.

(i think i will not be able to manage things mentioned above on my own )

thx a lot!
regards,
claas

[cc_julian]

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> > >]

[historic_bruno]

cc_julian, on 23 September 2011 - 12:45 AM, said:

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:

The Atlas code is shared among several utilities (such as AoE3Ed) which aren't built by default. I would guess all the above are optional.

Quote

/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)'

Looks like the problem where we want to initialize a std::wstring with a wxString and use c_str() instead of wc_str(). Possibly worth fixing, but see the above

[historic_bruno]

I believe Atlas in particular requires source\tools\atlas\AtlasUI built as a shared library (libAtlasUI) that ends up in binaries\system and which is dependent on source\tools\atlas\AtlasObject and source\tools\atlas\AtlasScript and of course source\tools\atlas\GameInterface (gets built in any case). All the rest is optional as far as I know, but if you want you can include the ActorEditor project which should create a separate binary. Hope this sheds some light on the situation

[Ykkrosh]

Yeah, the stuff that premake4.lua wraps in 'if _OPTIONS["aoe3ed"]' shouldn't be compiled and isn't expected to be portable.

[cc_julian]

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

[Ykkrosh]

The source in tools/atlas/GameInterface shouldn't get compiled into the AtlasUI library. (That code is part of the engine; AtlasUI only uses some headers from that location, since it's the other side of the interface.)

[cc_julian]

ok thanks! links mostly now, except for a boost issue. will continue sunday or monday.