Compiling for Windows (Thread Tracking for Thyranim)

[Thyranim]

a quick filesize compare showed me this

odie own one file more
libgtkglext-win32-1.0.a 17.12.2008 19:46 405466

copy this file from odie to my C::B inside the same directory
recompile ufo.exe
and try again

Done...
GLSL active -> models black, cpu-usage nearly 100%
GLSL deactive -> models shown, cpu-usage ok (approximately 5%)
i've played with the ingame video-options
it works either with deactivated GLSL-Shaders, or with deactivated Realtime lighting (never tested this before

all activated with precompiled-package by odie works fine... don't get it ...

If this dosent help to produce the same result as with odies C::B
please do this
replace V:\MinGW with your path to mingw and %tmp%\Muton.txt with odie for odies C::B
for /f %a in ('dir V:\MinGW\lib\* /B /S /A') do @V:\MinGW\bin\md5sum.exe -b "%a" >>"%tmp%\Muton.txt"
for /f %a in ('dir V:\MinGW\include\* /B /S /A') do @V:\MinGW\bin\md5sum.exe -b "%a">>"%tmp%\Muton.txt"

Done ->

Code: [Select]

for /f %a in ('dir D:\_Development\codebl~1\MinGW\lib\* /B /S /A') do @D:\_Development\codebl~1\MinGW\bin\md5sum.exe -b "%a" >>"D:\libMuton.txt"
for /f %a in ('dir D:\_Development\codebl~2\MinGW\lib\* /B /S /A') do @D:\_Development\codebl~1\MinGW\bin\md5sum.exe -b "%a" >>"D:\libOdie.txt"
for /f %a in ('dir D:\_Development\codebl~1\MinGW\include\* /B /S /A') do @D:\_Development\codebl~1\MinGW\bin\md5sum.exe -b "%a">>"D:\includeMuton.txt"
for /f %a in ('dir D:\_Development\codebl~2\MinGW\include\* /B /S /A') do @D:\_Development\codebl~1\MinGW\bin\md5sum.exe -b "%a">>"D:\includeOdie.txt"and compress to 1 zip
used same md5sum.exe for all 4 loops


IMPORTANT
something i was told as perhaps very important thing:
I'm not only using "Windows Vista" ... I'm using "Windows Vista 64" !?
Perhaps Problem between compiling under 32bit and 64bit? Wat are you using?

[odie]

Done...
GLSL active -> models black, cpu-usage nearly 100%
GLSL deactive -> models shown, cpu-usage ok (approximately 5%)
i've played with the ingame video-options
it works either with deactivated GLSL-Shaders, or with deactivated Realtime lighting (never tested this before

all activated with precompiled-package by odie works fine... don't get it ...

Done ->

Code: [Select]

for /f %a in ('dir D:\_Development\codebl~1\MinGW\lib\* /B /S /A') do @D:\_Development\codebl~1\MinGW\bin\md5sum.exe -b "%a" >>"D:\libMuton.txt"
for /f %a in ('dir D:\_Development\codebl~2\MinGW\lib\* /B /S /A') do @D:\_Development\codebl~1\MinGW\bin\md5sum.exe -b "%a" >>"D:\libOdie.txt"
for /f %a in ('dir D:\_Development\codebl~1\MinGW\include\* /B /S /A') do @D:\_Development\codebl~1\MinGW\bin\md5sum.exe -b "%a">>"D:\includeMuton.txt"
for /f %a in ('dir D:\_Development\codebl~2\MinGW\include\* /B /S /A') do @D:\_Development\codebl~1\MinGW\bin\md5sum.exe -b "%a">>"D:\includeOdie.txt"and compress to 1 zip
used same md5sum.exe for all 4 loops


IMPORTANT
something i was told as perhaps very important thing:
I'm not only using "Windows Vista" ... I'm using "Windows Vista 64" !?
Perhaps Problem between compiling under 32bit and 64bit? Wat are you using?

Been giving it a thought to this....
Unfortunately, i do not have any 64 bit windows, nor do i run a linux machine for games.....

Either way, I have a crazy idea -> Can i suggest u trying to run this application (UFOAI's ufo.exe of course!) on the vista 64 bit machine, BUT force run it as a 32 bit application.

This is done by forcing it to be compatible with an older windows.
Microsoft dubid forums has the guide on this here.

Try it and see if this fix the shaders issues.
PS: And if it does, someone will have to look into the issues of 64 bits application compilation..... hmmm...

PS2: Is anyone here running Linux 64 bit? If so, do u run into similar problems??

[Thyranim]

Been giving it a thought to this....
Unfortunately, i do not have any 64 bit windows, nor do i run a linux machine for games.....

Either way, I have a crazy idea -> Can i suggest u trying to run this application (UFOAI's ufo.exe of course!) on the vista 64 bit machine, BUT force run it as a 32 bit application.

This is done by forcing it to be compatible with an older windows.
Microsoft dubid forums has the guide on this here.

Try it and see if this fix the shaders issues.
PS: And if it does, someone will have to look into the issues of 64 bits application compilation..... hmmm...

PS2: Is anyone here running Linux 64 bit? If so, do u run into similar problems??

Hm, don't know if windows is executing the program in 32-bit mode when using compatibility but i'll give it a try

Starting the game in WindowsXPSP2-Mode don't changes anything

Starting codeblocks in XPSP2-Mode und doing a recompile
didn't change anything either


is there an option in codeblocks to tell for what architecture to compile? so i can say compile for x86 ? can't find anything like that

[Another Guy]

I did a quick check and Code::Blocks download page states separate downloads for Linux 32 and 64 bits, but a unique download for Windows version, so windows version should support both.
Not directly related to ur issue, but Tortoise SVN does have a Windows 64 bits version (which I am using) that might help with ur problem with SVN download issue I've seen in other topic. 

Weird thing is that I am using same mutton's C::B package as you, and compile works fine for me on any video options (I have tested around). Even as it looks a videocard issue, updated libs for C::B might still help ya.

Good luck!

[Thyranim]

I did a quick check and Code::Blocks download page states separate downloads for Linux 32 and 64 bits, but a unique download for Windows version, so windows version should support both.
Not directly related to ur issue, but Tortoise SVN does have a Windows 64 bits version (which I am using) that might help with ur problem with SVN download issue I've seen in other topic. 

don't using TortoiseSVN, using SVN-Plugin in Eclipse

Weird thing is that I am using same mutton's C::B package as you, and compile works fine for me on any video options (I have tested around). Even as it looks a videocard issue, updated libs for C::B might still help ya.

Good luck!

don't have a clue how to do this

but it's a weird problem, exactly

[Muton]

the only diff between odie and me is
the rest is FULLY identical

odie place
MinGW\\include\\gdk\\glext\\glext-extra.h
MinGW\\include\\gdk\\glext\\glext.h
MinGW\\include\\gdk\\glext\\glxext-extra.h
MinGW\\include\\gdk\\glext\\glxext.h
MinGW\\include\\gdk\\glext\\wglext-extra.h
MinGW\\include\\gdk\\glext\\wglext.h
MinGW\\include\\gdk\\win32\\gdkglwglext.h
MinGW\\include\\gdk\\win32\\gdkglwin32.h

Muton place
MinGW\\gtkglext\\gdk\\glext\\glext-extra.h
MinGW\\gtkglext\\gdk\\glext\\glext.h
MinGW\\gtkglext\\gdk\\glext\\glxext-extra.h
MinGW\\gtkglext\\gdk\\glext\\glxext.h
MinGW\\gtkglext\\gdk\\glext\\wglext-extra.h
MinGW\\gtkglext\\gdk\\glext\\wglext.h
MinGW\\gtkglext\\gdk\\win32\\gdkglwin32.h
MinGW\\gtkglext\\gdk\\win32\\gdkglwglext.h

and this headers seems to be unimportant during compilation
My last guess is C::B itself
Because C::B stores settings under documents and settings
you will still usings the same gcc even if you use a different C::B build
But i'm not shure how Vista handles this
Take a look at
Settings->compiler and debugger->toolchain executable
if the path and exe's are the same on odies C::B and mine
replace on my C::B package C::B with
http://download.berlios.de/codeblocks/CB_20090214_rev5456_win32.7z
http://download.berlios.de/codeblocks/
If the problem persists use a newer C::B rev5678

[Thyranim]

My last guess is C::B itself
Because C::B stores settings under documents and settings
you will still usings the same gcc even if you use a different C::B build
But i'm not shure how Vista handles this
Take a look at
Settings->compiler and debugger->toolchain executable
if the path and exe's are the same on odies C::B and mine
replace on my C::B package C::B with
http://download.berlios.de/codeblocks/CB_20090214_rev5456_win32.7z
http://download.berlios.de/codeblocks/
If the problem persists use a newer C::B rev5678

i was changing the settings/pathes everytime i was changes the package.
so when using odies package, i was changing all pathes to odies directory and vice versa with mutons directory

will give it a try with R5678

[Muton]

Than mabe its gcc

determine the used gcc version
Settings->compiler and debugger->toolchain executable->C compiler
this executable can be found at mingw\bin\
run a cmd and append the parameter --v

[Thyranim]

sorry but identical

Code: [Select]

D:\_Development\codeblocks - Muton\MinGW\bin>gcc.exe --v
Using built-in specs.
Target: mingw32
Configured with: ../gcc-4.3.3/configure --prefix=/mingw --build=mingw32 --enable-languages=c,ada,c++,fortran,objc,obj-c++ --with-bugurl=http://www.tdragon.net/recentgcc/bugs.php --disable-nls --disable-win32-registry --enable-libgomp --disable-werror --enable-threads --disable-symvers --enable-cxx-flags='-fno-function-sections -fno-data-sections' --enable-fully-dynamic-string --enable-version-specific-runtime-libs --enable-sjlj-exceptions --with-pkgversion='4.3.3-tdm-1 mingw32'
Thread model: win32
gcc version 4.3.3 (4.3.3-tdm-1 mingw32)

D:\_Development\codeblocks - Odie\MinGW\bin>gcc.exe --v
Using built-in specs.
Target: mingw32
Configured with: ../gcc-4.3.3/configure --prefix=/mingw --build=mingw32 --enable-languages=c,ada,c++,fortran,objc,obj-c++ --with-bugurl=http://www.tdragon.net/recentgcc/bugs.php --disable-nls --disable-win32-registry --enable-libgomp --disable-werror --enable-threads --disable-symvers --enable-cxx-flags='-fno-function-sections -fno-data-sections' --enable-fully-dynamic-string --enable-version-specific-runtime-libs --enable-sjlj-exceptions --with-pkgversion='4.3.3-tdm-1 mingw32'
Thread model: win32
gcc version 4.3.3 (4.3.3-tdm-1 mingw32)
i'll try new c::b-revision next time... but no time actually, other projects with deadline ^^


Update:
Downloaded C::B-R5678
copied "MinGW"-Folder from Mutons-Folder to R5678-Folder
copied wxmsw28u_gcc_cb.dll
checked gcc-version (it's identical, so see above)
loaded last SVN 25237 and rebuild game.... without errors, as before

but again, with activated GLSL Shaders and realtime lighting i get only black models and cpu-usage of app. 90% -_-
deactivating one of them shows the models and drops cpu-usage back to normal...

any other ideas ?
anyone ?

Currently downloading R25206 by odie for further approval...

[odie]

So Thyranim,

Did 25206 solved your problem?
Aka any progress since...... ??


Odie

[Thyranim]

Same as everytime ... Works with your build without any problems, doesn't work with my self-build ...

[Muton]

> Same as everytime ... Works with your build without any problems, doesn't work with my self-build ...

Wait a min.
If you build ufoai on your own with odies C::B
it dosent work correctly?

[Thyranim]

it doesn't work with odies c::b-paket
it doesn't work with your c::b-paket
it doesn't work with the new-revision c::b-paket

[odie]

Same as everytime ... Works with your build without any problems, doesn't work with my self-build ...

Eh, this is very strange...... have u checked to make sure your CB settings are set correctly? Could u attach your CB build logs?

I have a feeling that there are some non critical errors that might have occurred and still went thru......

Perhaps the CB logs could shed some light.

[Muton]

Somthing you can try is
Install your selfcompiled UfoAI
and then replace 0maps.pk3 from odie's package

What CPU are you using?