aqrit Posted November 1, 2015 Posted November 1, 2015 in the hope of saving someone some time in the futureInstall MSYS2... _Properly_then run the mingw32_shell.bat as an administratorpaste 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 portableso instead... get http://gillibert.fr/andre/projects/python/python273-rc2.ziprenamed the python27.dll to libpython2.7.dllthen paste libpython2.7.dll and the 'Lib' folder into the same folder as gemrb.exehopefully 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 Posted November 1, 2015 Posted November 1, 2015 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 Posted November 2, 2015 Posted November 2, 2015 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 Posted November 2, 2015 Posted November 2, 2015 the ttf driver and being able to use the makefiles cmake generates? Seems pretty obvious.
SyntaxError Posted November 2, 2015 Posted November 2, 2015 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 Posted November 2, 2015 Posted November 2, 2015 oh right! It was still mentioned only in some obscure files, which I now fixed.
aqrit Posted November 4, 2015 Author Posted November 4, 2015 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 Posted November 4, 2015 Posted November 4, 2015 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 Posted November 4, 2015 Posted November 4, 2015 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.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.