16
Programming / Re: Build fix for OSX 10.9
« on: April 01, 2014, 10:01:42 pm »
Indeed, now fixed in the auto builder for OSX.
Welcome, Guest. Please login or register.
Did you miss your activation email? April 20, 2024, 05:04:50 pm
Did you miss your activation email? April 20, 2024, 05:04:50 pm
News: If you can't login, please contact us with your username and e-mail so we can fix it.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
17
Programming / Build fix for OSX 10.9
« on: March 31, 2014, 10:03:19 pm »
https://gist.github.com/grrussel/9899657
Fixes the OSX autobuilder.
L/usr/local/lib -L/usr/local/Cellar/yaml-cpp/0.5.1/lib -lSDLmain -lSDL -Wl,-framework,Cocoa -lyaml-cpp -lSDL_gfx -lSDL_mixer -lSDL_image -framework OpenGL -o ../bin/openxcom
Undefined symbols for architecture x86_64:
"OpenXcom::ComboBox::MAX_ITEMS", referenced from:
OpenXcom::ComboBox::setDropdown(int) in ComboBox.o
OpenXcom::ComboBox::setOptions(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&) in ComboBox.o
OpenXcom::ComboBox::setOptions(std::__1::vector<std::__1::basic_string<wchar_t, std::__1::char_traits<wchar_t>, std::__1::allocator<wchar_t> >, std::__1::allocator<std::__1::basic_string<wchar_t, std::__1::char_traits<wchar_t>, std::__1::allocator<wchar_t> > > > const&) in ComboBox.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [../bin/openxcom] Error 1
Fixes the OSX autobuilder.
L/usr/local/lib -L/usr/local/Cellar/yaml-cpp/0.5.1/lib -lSDLmain -lSDL -Wl,-framework,Cocoa -lyaml-cpp -lSDL_gfx -lSDL_mixer -lSDL_image -framework OpenGL -o ../bin/openxcom
Undefined symbols for architecture x86_64:
"OpenXcom::ComboBox::MAX_ITEMS", referenced from:
OpenXcom::ComboBox::setDropdown(int) in ComboBox.o
OpenXcom::ComboBox::setOptions(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&) in ComboBox.o
OpenXcom::ComboBox::setOptions(std::__1::vector<std::__1::basic_string<wchar_t, std::__1::char_traits<wchar_t>, std::__1::allocator<wchar_t> >, std::__1::allocator<std::__1::basic_string<wchar_t, std::__1::char_traits<wchar_t>, std::__1::allocator<wchar_t> > > > const&) in ComboBox.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [../bin/openxcom] Error 1
18
Programming / Depixelating
« on: February 27, 2014, 12:09:36 am »
https://research.microsoft.com/en-us/um/people/kopf/pixelart/supplementary/multi_comparison.html
Wonder how XCOM would look after that approach?
Wonder how XCOM would look after that approach?
19
Programming / Re: Problems compiling lastest on Mac OS X 10.8.5
« on: December 22, 2013, 09:29:11 am »
To debug,
run openxcom in a debugger e.g. gdb or lldb
gdb ./openxcom
run
...
backtrace
to show where the crash occurs; no idea what the cause is, it works for me (tm)
May also be worth doing
make -f Makefile.simple clean
before rebuilding, to not mix and match .o files between old and new OSX versions
run openxcom in a debugger e.g. gdb or lldb
gdb ./openxcom
run
...
backtrace
to show where the crash occurs; no idea what the cause is, it works for me (tm)
May also be worth doing
make -f Makefile.simple clean
before rebuilding, to not mix and match .o files between old and new OSX versions
20
Programming / Re: Problems compiling lastest on Mac OS X 10.8.5
« on: December 22, 2013, 01:50:53 am »
OK, I have found a cause of #403 (really, a workaround for the crash, not loading graphics for TFTD kneel/drain TU buttons), and cannot reproduce either #14 or #202 on OSX 10.9
I'll add git sha echoing to the jenkins job building the git builds!
I'll add git sha echoing to the jenkins job building the git builds!
21
Programming / Re: Problems compiling lastest on Mac OS X 10.8.5
« on: December 21, 2013, 11:30:36 pm »
I reproduced the crash of #403 with the latest build from the openxcomosx repo;
as for what git aha each build corresponds to, its at present guess work based on the relative time of the commit to git and the build appearing; the polling is probably hourly? for changes, so any build should be mappable onto a small number of revisions based on date and time
If there is a handy git command to show the info, it can be run as part of the build, and uploaded as a part of the uploaded build log.
as for what git aha each build corresponds to, its at present guess work based on the relative time of the commit to git and the build appearing; the polling is probably hourly? for changes, so any build should be mappable onto a small number of revisions based on date and time
If there is a handy git command to show the info, it can be run as part of the build, and uploaded as a part of the uploaded build log.
22
Programming / Re: Problems compiling lastest on Mac OS X 10.8.5
« on: December 21, 2013, 05:19:48 pm »
Git builds for OSX 10.9 are auto-uploaded to
https://bitbucket.org/grrussel/openxcomosx/src
The build commands for that are essentially
export CXXFLAGS="-Wall -Wextra -O2"
export PATH=$PATH:/usr/local/bin
cd src && make -f Makefile.simple clean && make -f Makefile.simple 2>&1 | tee build_log.txt
So, it may simply be the wrong makefile ?
https://bitbucket.org/grrussel/openxcomosx/src
The build commands for that are essentially
export CXXFLAGS="-Wall -Wextra -O2"
export PATH=$PATH:/usr/local/bin
cd src && make -f Makefile.simple clean && make -f Makefile.simple 2>&1 | tee build_log.txt
So, it may simply be the wrong makefile ?
23
Troubleshooting / Re: error Geodata/Palettes.dat not found
« on: June 19, 2013, 09:15:33 pm »
We really should put in an error message explaining that if the file is not found, the original game data is required. Same topic crops up every so often ;-)
24
Work In Progress / Re: Altering the Research Tree: Bigger, Badder, and More Explosive!
« on: June 03, 2013, 11:17:40 pm »
Patch adding the option to control the weapon destruction vs weapons from captures.
(patch also includes the sorting of saves by dates),
(patch also includes the sorting of saves by dates),
25
Open Feedback / Re: Graphics Improvements?
« on: June 03, 2013, 11:01:30 pm »
Its a nifty view; but I found an issue where the red box cursor is not displayed at the lowest corner of the battlescape, for example, so you can neither select a unit there nor move a unit out of there.
The main interface (menus, etc) was also wedged into the top left corner at the original size.
The main interface (menus, etc) was also wedged into the top left corner at the original size.
26
Programming / Re: Sort saved game list by game date and time
« on: May 30, 2013, 12:06:48 am »
Cool. Well, if looking deeper into save games would make the process too slow, then I guess the patch can applied as is ;-)
27
Programming / Re: Sort saved game list by game date and time
« on: May 29, 2013, 10:11:48 pm »
The existing system opens each save game file in any case, to get the game time - the UI then translates the game time into a localised date / time for display to the user. Sorting by time adds no noticeable overhead. It seems to be sufficiently fast at present, I have 56 save game files present in the same folder.
So, I doubt checking a) if battlescape and b) what turn in the battle it is, would add any more overhead. Its more how to determine the values for a and b.
So, I doubt checking a) if battlescape and b) what turn in the battle it is, would add any more overhead. Its more how to determine the values for a and b.
28
Programming / Re: Sort saved game list by game date and time
« on: May 29, 2013, 12:03:49 am »
Would need some means of saying a) this save is a battle save and b) it has N turns elapsed. Don't see a trivial bit of code to do that, on a quick look round in the code. Pointers?
29
Programming / Sort saved game list by game date and time
« on: May 27, 2013, 01:59:13 am »
Patch is attached.
30
Programming / Re: 0.9 Build fixes for OSX
« on: May 17, 2013, 07:58:38 pm »
So, pair vs make_pair
std::make_pair deduces its argument types, and from its function arguments, creates a std::pair
https://www.cplusplus.com/reference/utility/make_pair/
std::pair (src at https://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-html-USERS-4.3/a02030.html) takes its constructor arguments by reference. Thus, it is needed to take the address of the thing passed in (e.g. MapData::O_WESTWALL). This has no address - the variable is declared and initialised, inside the class, but not defined outside the class. Therefore, no storage was allocated, and it has no address.
For std::make_pair, the arguments to the internal call to std::pair(a,b) use the address of the arguments in the call to std::make_pair, and so that works. The compiler can see
declaration of MapData::O_WESTWALL specified a constant int value, so that can be used in the call to std::make_pair
Why did it only break on clang? No idea. The problem is that the static consts in the class are not addressable, so the problem may recur if any other code attempts to take their address (e.g. ever using those values to a function taking an int& operand). The real solution imo is to add the out of class definitions.
The code as is with the make_pair change is back up and building in the OSX buildbot as before ;-)
std::make_pair deduces its argument types, and from its function arguments, creates a std::pair
https://www.cplusplus.com/reference/utility/make_pair/
std::pair (src at https://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-html-USERS-4.3/a02030.html) takes its constructor arguments by reference. Thus, it is needed to take the address of the thing passed in (e.g. MapData::O_WESTWALL). This has no address - the variable is declared and initialised, inside the class, but not defined outside the class. Therefore, no storage was allocated, and it has no address.
For std::make_pair, the arguments to the internal call to std::pair(a,b) use the address of the arguments in the call to std::make_pair, and so that works. The compiler can see
declaration of MapData::O_WESTWALL specified a constant int value, so that can be used in the call to std::make_pair
Why did it only break on clang? No idea. The problem is that the static consts in the class are not addressable, so the problem may recur if any other code attempts to take their address (e.g. ever using those values to a function taking an int& operand). The real solution imo is to add the out of class definitions.
The code as is with the make_pair change is back up and building in the OSX buildbot as before ;-)