Messages

2071

Builds & Ports / Re: Advice for choosing the compilation way

« on: April 09, 2016, 09:06:52 pm »

Mingw is completely free and open.
Visual Studio is expensive, so you can either find a special offer (I heard it can be free for students) or get the "Express" version which has some limitations - I don't know which ones, I work as a developer and my employer pays for the full versions.

Express is now community edition that is exactly same as normal paid version. IIRC up to 5 developer VS is free, after that you need buy it normally.

2072

XPiratez / Re: Bugs & Crash Reports

« on: April 09, 2016, 02:05:52 pm »

When I try to run it,  I get a "signal 11" crash and the attached error log.

Could you compile with `-g` and then run it in gdb? This will show exactly place where program tried access invalid memory.

2073

XPiratez / Re: Miniguns and vulcan guns

« on: April 08, 2016, 01:07:15 am »

Right now engine not allow skipping animations to do next shoot because previous shoot do not "hit" until animation reach end.
This would need rewriting hit handling to support it.

2074

XPiratez / Re: Some feedback, some questions

« on: April 07, 2016, 10:02:15 pm »

If we have only "hit!" and "hit!!" then better would be "hit" and "hit!".
Another is something different than "0" maybe "glance" or "block"?

2075

Suggestions / Re: Poison Gas

« on: April 04, 2016, 08:00:39 pm »

Without any more changes it would work like smoke, this mean only line of sight would be blocked.

2076

Programming / Re: Building openXCom in 64-bits with MinGW on Windows

« on: April 04, 2016, 07:58:21 pm »

I wonder why I can't see that with 'ld --help'...

They say it has no effect if '-shared' is used and you use them both... So no reason to keep it, right? Except maybe if you sometimes build without '-static' but want to keep '-static-libstdc++'.

probably yes

2077

Suggestions / Re: Poison Gas

« on: April 04, 2016, 07:47:06 pm »

Smoke that can deal hp and armor(it's corrosive smoke! ) damage? Yankes!!

I thought about this a bit. If we limited only to one effect per tile then doing it would be not that hard.
Probably biggest problem is how handle overriding of effect e.g. when in one tile have effect A then when is possible to change it to B? Similar like in fire/smoke case but with more different types.

Overall I think this have lot of possibilities, like if tile effect could affect moving cost then you could create force field that will block units from passing.

2078

Programming / Re: Building openXCom in 64-bits with MinGW on Windows

« on: April 04, 2016, 02:05:46 am »

@Yankes

Where did you find about the "-static-libstdc++" linker option?
I tried "gcc --help" and "ld --help" but I find nothing about this option...

https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html

2079

OXCE Suggestions Abandoned / Re: Fatigue?

« on: April 04, 2016, 01:56:52 am »

I don't think is correct way to "hardcode" it. Overall this functionality is not that hard that to do it by scripts. Different people would like tweak it to fit more they taste, to do it properly in code it would need lot of config options, e.g. "do armor affect it? and how?", "do commendation reduce it?".

I think scripts are better solution, even if work need to enable this in script will be two times bigger. This is because all work you do in code to support it will be available for other functionality, like customizing wound recovery (e.g you get bigger penalty for all wounds, even if healed in battle).

Example of that is customization of reaction shots that already done in my working copy. Instead of only melee reaction I now can create in scripts "ninja" or "invisible" units. Difference between them is that first need shadow to work where other can always ignore reactions (and it can require special item in hand or be property of armor).

In current version of script it not jet possible to implement this functionality, but I think that after couple of releases scripts will be mature enough to support this.

2080

Programming / Re: Building openXCom in 64-bits with MinGW on Windows

« on: March 31, 2016, 07:44:22 pm »

Available sources doesn't mean there is someone doing builds or upgrades to newer libraries.
I have had to upgrade sources and/or rebuild toolchains many times, and please believe me, it's very hard work. There can easily be an incertainty of 4 years over which version of GCC you need to use (that's 28 stable versions), Internet links go stale, nothing is forward compatible when you need it, and libraries have depencies, which have dependencies, which have depencies, which...
Please, people : DLLs work. Users don't care that there are 16 inter-dependant DLLs along with your executable, and any future maintainer will kiss you (posthumously if necessary) as you're saving them the trouble of tracking down and compiling 16 specific versions of those libraries.

What is real difference between recompiling dll and exe? Every problem that can affect exe can affect dll too. New dll can be incompatible with old dll etc.
Sometimes recompiling one dll could be harder that recompiling whole exe because it have most dependencies.
If everything is compiled from sources then all libraries will need exactly the same toolchain and have uniform dependencies (if two have lib that have common dep then it will be in same version other wise it will fail to compile).

Right now my experience with compiling OXC as stand alone exe is that my only problem is that I need linux (to run mxe), rest of dependencies are fix by 2 commands. It work for me, nightles and for Meridian.

2081

Suggestions / Re: Add extra ruleset functions (# of uses) to psi amp, mind probes, other items

« on: March 30, 2016, 10:50:59 pm »

I'd definitely want this too in OXC, especially having separate costs for Panic & MC (I always wanted to use Panic but had not reason to against MC). And yes, maxRange is also another nice feature. Even better: unlimited range with dropoff accuracy by distance.

This exactly what I did in Extended, each attack have separate cost and power have custom reduction by range.

2082

Programming / Re: Building openXCom in 64-bits with MinGW on Windows

« on: March 30, 2016, 10:50:35 pm »

I am having a lot of compilation errors due to missing standard headers such as:

Code: [Select]

#include <algorithm>
#include <cmath>

Is there a gcc option I am missing? Or Was I wrong to check out the v1.0 tag?

fresh sources, recently this was fixed in main branch.

Yeah, but why would you do it? You're making it hard for the user.
A few years ago I had a problem with SDL 1.2 crashing whenever I pressed the key ^. The fix took about one year to reach the "stable release" (1.2.13, I think), but at least I was able to compile the DLL from the repository, and thus I could "patch" every SDL program by replacing the faulty DLL. If any program has statically linked, I would have been stuck (On Windows, even open-source programs are extremely hard to find the correct dependencies to compile. For example I've handled 3 different libPNG, incompatible with each others.)

overall GPL need that sources are available for everyone. This mean that in your case you will download custom exe, created by other that have this bug fix.

2083

Programming / Re: Building openXCom in 64-bits with MinGW on Windows

« on: March 30, 2016, 07:06:16 pm »

If I recall correctly SDL 2.0 drop LGPL and switch to more permissive license.

Overall as long you have program under GPL (in our case OXC) you can publish exe with statically linked SDL.

2084

Programming / Re: Building openXCom in 64-bits with MinGW on Windows

« on: March 30, 2016, 01:52:54 am »

If you have fresh sources then 0.5.3 should work too.

2085

Programming / Re: Building openXCom in 64-bits with MinGW on Windows

« on: March 29, 2016, 10:21:13 pm »

For mingw (with msys) build I used this makefile:

Code: [Select]

# Directories and files
OBJDIR = ../obj/
BINDIR = ../bin/
SRCS_SDL = /C/MinGW/include/SDL/
SRCS_BOOST = ../../lib/boost/
SRCS_YAML = ../../lib/yaml-cpp/
SRCS_YAML_CPP = $(wildcard $(SRCS_YAML)src/*.cpp $(SRCS_YAML)src/contrib/*.cpp)
SRCS = $(wildcard *.cpp */*.cpp */*/*.cpp)
OBJS = $(patsubst %.cpp, $(OBJDIR)%.o, $(notdir $(SRCS))) $(patsubst %.cpp, $(OBJDIR)yaml/%.o, $(notdir $(SRCS_YAML_CPP)))

BIN = OpenXcom

# Compiler settings
CXXFLAGS ?= -Og
CXXFLAGS += -Wall -std=gnu++11

CXXFLAGS += -I$(SRCS_YAML)include -I$(SRCS_BOOST) -I$(SRCS_SDL)

LIBS = -lshlwapi -lws2_32 -lopengl32 -lglu32 -mwindows -lmingw32 -lpthread -static -static-libstdc++ -lwinmm -lSDL_gfx -lSDL_mixer -lSDLmain -lSDL_Image -lSDL.dll -lm -luser32 -lgdi32 -lwinmm -ldxguid -lDbgHelp

# Rules
all: $(BINDIR)$(BIN)

$(BINDIR)$(BIN): $(OBJS)
$(CXX) $(OBJS) $(LDFLAGS) $(LIBS) -o $(BINDIR)$(BIN)

$(OBJDIR)%.o:: %.cpp
$(CXX) $(CXXFLAGS) -c -o $@ $<

$(OBJDIR)%.o:: Basescape/%.cpp
$(CXX) $(CXXFLAGS) -c -o $@ $<

$(OBJDIR)%.o:: Battlescape/%.cpp
$(CXX) $(CXXFLAGS) -c -o $@ $<

$(OBJDIR)%.o:: Engine/%.cpp
$(CXX) $(CXXFLAGS) -c -o $@ $<

$(OBJDIR)%.o:: Engine/Scalers/%.cpp
$(CXX) $(CXXFLAGS) -c -o $@ $<

$(OBJDIR)%.o:: Engine/Adlib/%.cpp
$(CXX) $(CXXFLAGS) -c -o $@ $<

$(OBJDIR)%.o:: Geoscape/%.cpp
$(CXX) $(CXXFLAGS) -c -o $@ $<

$(OBJDIR)%.o:: Interface/%.cpp
$(CXX) $(CXXFLAGS) -c -o $@ $<

$(OBJDIR)%.o:: Menu/%.cpp
$(CXX) $(CXXFLAGS) -c -o $@ $<

$(OBJDIR)%.o:: Mod/%.cpp
$(CXX) $(CXXFLAGS) -c -o $@ $<

$(OBJDIR)%.o:: Savegame/%.cpp
$(CXX) $(CXXFLAGS) -c -o $@ $<

$(OBJDIR)%.o:: Ufopaedia/%.cpp
$(CXX) $(CXXFLAGS) -c -o $@ $<

$(OBJDIR)yaml/%.o:: $(SRCS_YAML)src/%.cpp
@mkdir -p $(OBJDIR)yaml
$(CXX) $(CXXFLAGS) -c -o $@ $<

$(OBJDIR)yaml/%.o:: $(SRCS_YAML)src/contrib/%.cpp
@mkdir -p $(OBJDIR)yaml
$(CXX) $(CXXFLAGS) -c -o $@ $<

clean:
rm -f $(BINDIR)$(BIN) $(OBJDIR)*.o

.PHONY: all clean
Its need src of yaml-cpp and precompiled SDL libs (if I recall correctly from main page links). With new version yaml-cpp you could drop `boost` from it.