updated mingw

[revelator]

its up.

going to bed

[revelator]

news from the compiler world.

putting the last dents in my mingw64 build. well actually its a combined mingw32/mingw64 build so it works even if you just use 32 bit windows .

will be up soon on google code.

[revelator]

reason why this took so long was that i had some trouble with my msys environment (gawk error) took me some time to iron it out as the error i kept getting was from sed not gawk .

well its bootstrapping now if all goes well the package will be on my google code site this evening.

this also means i dont have to use a hacked version of the mingw64 runtime anymore to get the newer directx and ddk headers

[Baker]

Are you able to compile, say, DirectQ with this?

Just wondering.

[revelator]

should be possible aye might need to recompile libraries like libpng zlib etc to get some 64 bit types for it.

works fine in codeblocks atleast but need to add some extra variables to the cflags like -m32 for 32 bit builds or -m64 for the 64 bit ones.

i hope the codeblocks devs get around to adding that as an option in the ide instead of setting it with flags since many users allready use the mingw64 compiler with it.

btw its a huge pain in the ass to compile this gcc

[revelator]

hmm bummer.

codeblocks can handle linker flags cflags and cppflags but it seems i cant set flags to windres (the resource compiler) directly so everything builds besides the icon

if you just intend on making a 64 bit executable all works fine if you got dependant 64 bit libraries.

for a 32 bit build you need to pass -m32 to cflags/linkerflags and possiby add this -m i386pe to the linker flags also.

if compiling from commandline windres can be circumvented by adding -F pe-i386 to its flags.

[revelator]

here it is.

http://code.google.com/p/mingw-wine/dow ... z&can=2&q=

enjoy

[revelator]

after some discussion with the codeblocks devs i figured out how to do the windres part.

go into settings/compiler and debugger/toolchain executables and put this in the resource compiler box "windres.exe -F pe-i386" without the quotes!. its a bit hacky since for a 64 bit build you need to remove the -F pe-i386 from it again, but atleast it works .

other option is to add a rule in codeblocks internal editor "$rescomp -F pe-i386 -i $file -J rc -o $resource_output -O coff $res_includes"

for further information http://forums.codeblocks.org/index.php/ ... 01.45.html is a good source since my build is based on that but updated to the latest gcc + support libraries.

[revelator]

ok did some preliminary testing and im able to build my own realm engine as 64 bit.

BUT! it crashes to desktop instantly

if i have to guess i would have to say the code needs a few changes
since im getting a lot of warnings about incompatible pointers, but atleast its a start

if you had time to try it out let me know maybe we can hunt the buggers down.

[revelator]

updated package avaliable soon.

small patch for the link time optimization compiler fixes build with virtual targets.

newer system libraries for the graphite optimization loops.

added 32 and 64 bit builds of gettext if you want to build localized executables.

added some support utilities like getopt popt expat pdcurses libpng zlib. both 32 and 64 bit builds.

added opencl. also 32 and 64 bit builds.

to come adding the rest of texture support libraries like tiff jpeg etc.

small warning adding libraries directly to this compilers normal search dirs can be a bit hard as it searches both a 32 and 64 bit path. using prefix like in normal builds is rather counter productive since you need to copy those libraries to the correct directories.

so a word of advice is avoid installing support libraries directly in the compiler dir install them to a seperate dir called support32 for 32 bit builds or support64 for the 64 bit builds. you can add these directories to msys search path by yanking a small script in msys/etc/profile.d like the below

prefix="/opt/irrlicht"
exec_prefix="${prefix}"
PATH="${exec_prefix}/bin/win32-gcc:$PATH"
LD_LIBRARY_PATH="${exec_prefix}/lib/win32-gcc:${LD_LIBRARY_PATH:-}"
LD_RUN_PATH="${exec_prefix}/lib/win32-gcc:${LD_RUN_PATH:-}"
C_INCLUDE_PATH="${exec_prefix}/include:${C_INCLUDE_PATH:-}"
CPLUS_INCLUDE_PATH="${exec_prefix}/include:${CPLUS_INCLUDE_PATH:-}"
MANPATH="${exec_prefix}/doc:${MANPATH:-}"

export PATH LD_LIBRARY_PATH LD_RUN_PATH C_INCLUDE_PATH CPLUS_INCLUDE_PATH MANPATH

unset prefix
unset exec_prefix

if using codeblocks you can point it to the correct dir directly

[Baker]

Are you able to get DirectX 8.1 SDK to compile with an engine source using MinGW?

Just wondering. I'd love to be able to compile either the mp3 music support or MH's Direct3D8.1 wrapper with Code::Blocks + MinGW but I get thrown countless messages involving MinGW hating the dxd8.h headers or some such thing.

[revelator]

should be working fine with this package as it contains a pretty complete directx sdk

the sdk supports dx7 -> dx11

[revelator]

hmm though comes to mind that the dx8.1 sdk was radically different in some places so might run into some compatibility issues.

would probably be easier to port the 8.1 code to dx9 but its a bit of an undertaking i remember.

[mh]

hmm though comes to mind that the dx8.1 sdk was radically different in some places so might run into some compatibility issues.

would probably be easier to port the 8.1 code to dx9 but its a bit of an undertaking i remember.

DX 8.1 -> 9 is actually extremely easy; they're almost identical. I could probably turn it around in an hour or so.

Update
I did it in maybe half an hour or so. The biggest difference was that the old IDirect3DDevice8::SetTextureStageState was split in two for D3D9 - IDirect3DDevice9::SetTextureStageState and IDirect3DDevice9::SetSamplerState. Additionally most of the types needed a "9" after them instead of an "8", some of the Render States have changed, IDirect3DDevice8::CreateImageSurface changed to IDirect3DDevice9::CreateOffscreenPlainSurface, adapter mode enumeration functions now take format as a parameter, and some of the Create* calls need a NULL as the last parameter.
/Update

im getting a lot of warnings about incompatible pointers

There are lots of pointer incompatibilities in the stock ID Quake code that need resolving for 64-bit. MDLs and QC are the biggies.

[revelator]

cool thanks for the heads up

yep i remember i had to do the same while updating another project (some of the functions where split in two).

take 2 of the x86_64 mingw compiler is up on my google code site

now includes libpng and zlib as both 32 and 64 bit types so if you need these you can yank em from the archive. but the updated compiler also has a few fixes i was made aware of.