Newbe needs info on where to find what in code

[Meridian]

I also suffer a very notable performance loss using my own exe, probably because of these not native functions.

The most likely reason for performance loss (and bigger size) is that you are compiling in debug mode, instead of release mode.

Could be something else too... but I wouldn't know how to help if it's not that.

I also added my exe with the new reaction fire system. I should be closer to OG from what I've seen in the few test I made yet.

Better if you share a github link.

[Yankes]

Confusing. Using O3 -s increased the size of the exe by 0.3 MB.
Dissecting the exe, I found the main trouble to be "AddVectoredExceptionHandler" and "RemoveVectoredExceptionHandler" of Kernel32.dll / Kernel32.lib. They are not existent in the Kernel of my Win 2k, but only in my transplanted DLLs.
I also suffer a very notable performance loss using my own exe, probably because of these not native functions.

I have identified them to be part of the MinGW-64 defines, Bin, Include and Lib. I'll try to manually remove them from the MinGW files to stop the linker from adding them.
Patching the content of my MinGW-64 with old stuff from MinGW32 may do the trick better yet.
Does anyone have those files available? The installer for the old MinGW version is offline.

@Meridian, it might be you have those files for compiling.
Can you check if you have the files:
libwinpthread-1.dll
errhandlingapi.h
libkernel32.a
libntdll.a
libpthread.a
libwinpthread-1.dll
libwinpthread.a
libwinpthread-1.dll

I also added my exe with the new reaction fire system. I should be closer to OG from what I've seen in the few test I made yet.

O3 mean make code fast as possible, it sometime can reduce complex function to one line, but sometimes its can increase size (loop unrolling, cloning function and hardcoding one execution path in it, etc. )
Overall most libs you link are used because what config you choose during installation of MinGW-w64, if you switch them result could be different.

[Callahan]

I'm using this makefile configuration as of now.

Code: [Select]

# Directories and files
OBJDIR = ../obj/
BINDIR = ../bin/
SRCS_SDL = C:/MinGW/mingw32/include/SDL/
SRCS_YAML = C:/work/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 = -Wall -O3 -s -std=gnu++11
CXXFLAGS += -I$(SRCS_YAML)include -I$(SRCS_SDL)
ARCH ?= i686-w64-mingw32.static

LIBS = -lshlwapi -lws2_32 -lopengl32 -lglu32 -mwindows -lmingw32 -lpthread -static -static-libstdc++ -lwinmm -lSDL_gfx -lSDL_mixer -lvorbisfile -logg -lmodplug -lvorbis -logg -lFLAC -lFLAC++ -lws2_32 -lSDLmain -lSDL_Image -ljpeg -lpng12 -lz -lsmpeg -lSDL -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
$(CXX) $(CXXFLAGS) -c -o $@ $<

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

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

How could I switch the libs/config linked with MinGW-64. On install I did choose the default 7.3.0 version.
Or do I have to reinstall MinGW-64 to experiment with that?
I want to get rid of this kernel exception handling. It's just ballast.

[Callahan]

Victory!!! After playing around with various MinGW-64 installs, I finally got rid of both the lag/stuttering and the VectorExceptionHandler.
Problem with the lag seemed to be caused by the Multithreading method POSIX, that was recommended on StackOverflow. Win32 Multithreading seems to be better for Win 2k.
Exception setting from Dwarf to Sjlj also helped, and is probably responsible for the removal of the hated VectorExceptionHandling.
Exe is still a bit large, but I can live with that as it seems to be unavoidable due to the compiler and the OS it is being used in.

Very special thanks to Meridian and Yankes for all the support, information, links and files that I was able to study to get to the bottom of things.

As for the reaction fire code upload - Should I upload the entire code, or just the file that got edited?

[Yankes]

Proper way of sharing changes is publishing git commit usually through github, in this way everyone will see only what you changed.

[ps]
example: https://github.com/Yankes/OpenXcom/commit/259229d8ae8393c107cfd825f5ac60d099dbe68a commit where I add file I created for you for future use.

[Callahan]

I put the relevant file into GitHub. Probably not using the very way you recommended, but I had no time today to read the entire beginner guide.

https://github.com/Callahan2/OXCE-Stuff

[Yankes]

Do you have git? or you always used zip files to download source code?
If not then you should grab this: https://superuser.com/questions/1153883/git-for-windows-xp

[Callahan]

I am using .zip files for download. That's already quite modern for me. I'm dating back from a time where "quick" code exchanges between people where made by a typewriter and a fax machine.

So, if I read this right, GIT stores data based on only storing files that got changed, and using a pointer to the old unchanged files. So one can browse forth and back between versions. Could be handy if I manage to make notable changes to the code, thanks for the link.
I'll dig into it eventually.

[Yankes]

I am using .zip files for download. That's already quite modern for me. I'm dating back from a time where "quick" code exchanges between people where made by a typewriter and a fax machine.

So, if I read this right, GIT stores data based on only storing files that got changed, and using a pointer to the old unchanged files. So one can browse forth and back between versions. Could be handy if I manage to make notable changes to the code, thanks for the link.
I'll dig into it eventually.

small correction git store WHOLE history of project, if you download OXC repo you could go back to first version that SupSuper created
Another is that you can easy toggle between different version like OXC, OXCE and OXCE+ (not meeting other peoples works) and compare them and exchange changes between them.

[DoxaLogos (JG)]

Also, if you check in your change over the original file, it's WAY easier to see the changes to the code then searching for a "callahan code" tag in the source file   Github will automatically highlight the differences between commits in fancy schmancy red (deletions) and green (additions) colors for all to see.

Typical github development:

Fork the project into your GitHub accounts (makes a new repository).
Clone it to your desktop
Create a new branch to make your changes
commit your changes locally
push your changes back to your github account.

Once the changes are pushed, you could potentially create a "pull request" back to the main project that you forked from, and the maintainers of the project can review your pull request to see if they want to accept your changes or not.  It acts as a code review, and you can continue to update the pull request by push changes into the branch that the pull request originated from.

If the PR (pull request) gets accepted, you can delete your branch if you want.



However, working in OXCE+ is not typical since it's already a fork of an existing GitHub project (OXC+OXCE), and Meridian prefers to cherry-pick changes without pull requests.

So, I've forked from original OXC project.
Cloned it to desktop
Created an oxce3.5-plus-proto branch
Added Meridian's repo as remote branch to my project
switched to my oxce3.5-plus-proto branch and pulled down Meridian's oxce3.5-proto-branch into my branch (not a merge per se, but direct full copy of branch - have to look up the git commands again).
I use my  oxce3.5-plus-proto branch as a starting point to make other branches if I'm making changes to OXCE+.

[Callahan]

Thanks for the explanations. For a beginner, this all does sound a bit complicated. Once I grow familiar with it, it will better understand the interaction of forks, branches and the other stuff.
I'm going to make this step by step. I've started to take a look at some of the mods and rules to see how these work and what is possible.