Building GemRB on Windows using MSYS2

[aqrit]

in the hope of saving someone some time in the future

Install MSYS2... _Properly_
then run the mingw32_shell.bat as an administrator
paste the following commands:

pacman --noconfirm --needed -S \
git \
mingw-w64-i686-gcc \
mingw-w64-i686-make \
mingw-w64-i686-cmake \
mingw-w64-i686-SDL2 \
mingw-w64-i686-glew \
mingw-w64-i686-freetype \
mingw-w64-i686-zlib \
mingw-w64-i686-libpng \
mingw-w64-i686-libvorbis \
mingw-w64-i686-openal \
mingw-w64-i686-python2

git clone git://github.com/gemrb/gemrb.git $HOME/gemrb-git

cd ~/gemrb-git
mkdir build
cd build
cmake -DDISABLE_WERROR=Yes -DUSE_OPENGL=1 .. -G "MSYS Makefiles" -DCMAKE_MAKE_PROGRAM=/mingw32/bin/mingw32-make.exe
mingw32-make install

I can't figure out how to get python to be portable
so instead... get http://gillibert.fr/andre/projects/python/python273-rc2.zip
renamed the python27.dll to libpython2.7.dll
then paste libpython2.7.dll and the 'Lib' folder into the same folder as gemrb.exe
hopefully this works correctly...

copy over all needed dll files from "msys32\mingw32\bin" into the gemrb folder "C:\Program Files (x86)\gemrb"

glew32.dll
libbz2-1.dll
libfreetype-6.dll
libgcc_s_dw2-1.dll
libglib-2.0-0.dll
libharfbuzz-0.dll
libharfbuzz-gobject-0.dll
libharfbuzz-icu-0.dll
libiconv-2.dll
libintl-8.dll
libogg-0.dll
libpng16-16.dll
libstdc++-6.dll
libvorbis-0.dll
libvorbisenc-2.dll
libvorbisfile-3.dll
libwinpthread-1.dll
OpenAL32.dll
SDL2.dll
zlib1.dll

gemrb.cfg should look something like

GameType=bg2
GameName=Baldur's Gate 2
Width=640
Height=480
Bpp=32
Fullscreen=0
TooltipDelay=500
GUIEnhancements = 1
GamePath=D:\games\bg2\
CD1=D:\games\bg2\
CD2=D:\games\bg2\CD2\
CD3=D:\games\bg2\CD3\
CD4=D:\games\bg2\CD4\
CD5=
CachePath=Cache
GemRBPath=.
PluginsPath=./plugins

edit:

removed comment about printf poisoning

removed sdl2_tff

[lynx]

Thanks, looks a bit ©leaner than:

http://www.gemrb.org/wiki/doku.php?id=install:windows

 

I would advise against SDL2 for now. There's a precompiled bundle of libs on sourceforge (linked above).

 

I've ifdefed out the poisoning if using mingw.

[SyntaxError]

 

 

I would advise against SDL2 for now

He is using the OpenGL driver (which i would also advise against)

 

I dont understand why 'SDL_ttf' and 'make' are being included tho

[lynx]

the ttf driver and being able to use the makefiles cmake generates? Seems pretty obvious.

[SyntaxError]

the ttf driver and being able to use the makefiles cmake generates? Seems pretty obvious.

 

i didnt know cmake required make, but we havent depended on SDL_ttf for years now.

[lynx]

oh right! It was still mentioned only in some obscure files, which I now fixed.

[aqrit]

any thoughts on SDL20GLVideo ?

 

I'm thinking the menu problem could be fixed in a few different ways...

 

1. draw to an offscreen surface then do a full screen pixel copy instead of calling RedrawAll()

( performance impact on "mobile" unknown )

 

2. force a chu window with id:0 to always be visible while any other window from the same chu is open

( how correct would this be ? )

 

3. The original Infinity engine was double buffer "aware"... it keep track of what needed to be drawn to which buffer? I suppose when doing something like switching windows it made sure to draw to both buffers...

( this is theoretically wrong though... because I don't think there is any guarantee that Flip/SwapBuffers returns the previous buffer?? It might instead create a new buffer or just copy instead of flip )

[lynx]

Oh, you're in it for tinkering. Then sdl2 and gl are fine.

 

I haven't ran it in a while - what is the menu problem?

 

I think in some cases more than one chu is involved.

[SyntaxError]

 

 

I'm thinking the menu problem could be fixed in a few different ways...

 

I have no idea what you are talking about...

 

 

 

draw to an offscreen surface then do a full screen pixel copy instead of calling RedrawAll()

 

It hasnt been merged yet, but I've completely rewritten all of our window/view drawing and RedrawAll is no longer even in existence. Each window has its own buffer for drawing now.

 

 

 

force a chu window with id:0 to always be visible while any other window from the same chu is open

 

No idea about being incorrect, but between the view/window rewrite and "visibility" not likely being the real issue i'll wager this isnt needed.

 

dito the above as an answer to your 3rd query

 

the problem with everything I've said being the OpenGL author is a ghost and I have no idea how to update the GL driver accordingly.