Revelator's TDM Branch

[revelator]

Not sure where in that map you took the shot but i have no such problems with the sky ?

[revelator]

hopefully final changes to get the linux build going again.

Added missing glew initializer to linux specific code.

split up qgl headers in os specific versions.

 

Im unable to locate the opengl lib flags -lGL anywhere in scons or otherwise so i suspect it uses autodepend, but if you get any linker errors let me know.

[Tels]

hopefully final changes to get the linux build going again.

Added missing glew initializer to linux specific code.

split up qgl headers in os specific versions.

 

Im unable to locate the opengl lib flags -lGL anywhere in scons or otherwise so i suspect it uses autodepend, but if you get any linker errors let me know.

 

Unfortunately not:

 

g++ -o build/release/core/framework/Session_menu.o -c -pipe -Wall -Wno-unknown-pragmas -fmessage-length=0 -fpermissive -fvisibility=hidden -m32 -O3 -march=pentium3 -ffast-math -fno-unsafe-math-optimizations -fomit-frame-pointer -DXTHREADS -fno-strict-aliasing -Winvalid-pch -D__DOOM_DLL__ -Iframework -Ibuild/release/core/sys/scons -Isys/scons -Iinclude -Iinclude/zlib -Iinclude/minizip -Iinclude/libjpeg -Iinclude/devil -I. framework/Session_menu.cpp
build/release/core/glimp/sys/gllog/gl_extensions.cpp:15: warning: missing braces around initializer for ‘glExtName_t’
build/release/core/glimp/sys/gllog/gl_extensions.cpp:19: error: ‘GLExtension_t’ does not name a type
build/release/core/glimp/sys/gllog/gl_extensions.cpp:17: warning: ‘void StubFunction()’ defined but not used
include/boost/system/error_code.hpp:221: warning: ‘boost::system::posix_category’ defined but not used
include/boost/system/error_code.hpp:222: warning: ‘boost::system::errno_ecat’ defined but not used
include/boost/system/error_code.hpp:223: warning: ‘boost::system::native_ecat’ defined but not used
scons: *** [build/release/core/glimp/sys/gllog/gl_extensions.o] Error 1
scons: building terminated because of errors

 

I might take a look tomorrow and see if I can fix it.

[revelator]

Hmm seems the m4 defines are peppered with that damn pointer, guess ill have to kill off all of em,

tbh i suspect i have to remove most of the m4 scripts since those functions are now handled by glew anyway and might collide with it.

[revelator]

Ok removed that pointer and all vestiges of functions using it, crossing fingers.

Edit comitted btw.

Edited November 20, 2014 by revelator

[Tels]

You are fixing these things before I even can look at them. And not sure what "m4" is, but now it runs to this point

 

 

 

g++ -o build/release/core/framework/DeclFX.o -c -pipe -Wall -Wno-unknown-pragmas -fmessage-length=0 -fpermissive -fvisibility=hidden -m32 -O3 -march=pentium3 -ffast-math -fno-unsafe-math-optimizations -fomit-frame-pointer -DXTHREADS -fno-strict-aliasing -Winvalid-pch -D__DOOM_DLL__ -Iframework -Ibuild/release/core/sys/scons -Isys/scons -Iinclude -Iinclude/zlib -Iinclude/minizip -Iinclude/libjpeg -Iinclude/devil -I. framework/DeclFX.cpp
scons: building `build/release/core/glimp/sys/linux/glimp_dlopen.cpp' because it doesn't exist
cd sys/linux && m4 -E < glimp_dlopen.cpp.m4 > /home/te/src/tdm_experimental/The-Darkmod-Experimental/src/build/release/core/glimp/sys/linux/glimp_dlopen.cpp
m4:stdin:36: undefined macro `f363_ret'
m4:stdin:48: undefined macro `f363_ret'
m4:stdin:105: undefined macro `f363_ret'
scons: *** [build/release/core/glimp/sys/linux/glimp_dlopen.cpp] Error 1
scons: building terminated because of errors.

 

 

[Tels]

Speaking of cleanup, do we still need to support the MD3 model format?

 

renderer/Model_md3.h and renderer/Model_md3.cpp. It isn't much code, and only referenced in one place, but AFAICS we don't have any .md3 models. Does this format have any special abilities that make it worthwhile to keep?

[revelator]

m4 is general purpose macro processor used in autotools normally and in doom3 for autogenerating headers and source files based on which opengl capabilities your linux distro has.

It also requires knowledge im not sure posses when tinkering with it .

 

Besides i have the grimm feeling that after the change to glew it cannot be fixed because some of the m4 chain also autogenerates some source files that we need so we cant simply remove it, even though most of that functionality is now provided by glew.

 

Probably last try here, removed the defines for those function pointers from m4, if it does still not compile then we need someone with better understanding of the m4 macros to fix this im afraid.

Changes have been committed.

 

As for md3 support i wouldnt mind getting rid of it as its mostly a remnant of idtech3 code that seems to have been left in, its up to the modelers though if they want it removed ?.

[Bikerdude]

As for md3 support i wouldnt mind getting rid of it as its mostly a remnant of idtech3 code that seems to have been left in, its up to the modelers though if they want it removed ?.

Springheel will know more about this, but I think we only use MD5.

[AluminumHaste]

Md3 was the quake 3 model format.

[Tels]

m4 is general purpose macro processor used in autotools normally and in doom3 for autogenerating headers and source files based on which opengl capabilities your linux distro has.

It also requires knowledge im not sure posses when tinkering with it .

 

Besides i have the grimm feeling that after the change to glew it cannot be fixed because some of the m4 chain also autogenerates some source files that we need so we cant simply remove it, even though most of that functionality is now provided by glew.

 

Probably last try here, removed the defines for those function pointers from m4, if it does still not compile then we need someone with better understanding of the m4 macros to fix this im afraid.

Changes have been committed.

 

Thanx!

 

Would we get rid of m4 if we replace scons by automake/autobuild/autowhatever? I'm not a big fan of changing things for the change's sake but I think scons itselfs has a few problems now and then.

 

My biggest wish would get back the "if you change one file, only this .o is compiled". Ever since the switch to the pre-compiled header on Linux every is re-compiled every time.

[revelator]

Not if using autotools they rely even more on m4 than scons, cmake maybe though i have to have a look at dhewm3 to see how that gets around it.

I just installed kubuntu in wmware and tried a compile with my latest comitted changes and it builds but fails on devil because kubuntus zlib is to new, any hints on how to downgrade zlib ?.

[Tels]

Not if using autotools they rely even more on m4 than scons, cmake maybe though i have to have a look at dhewm3 to see how that gets around it.

I just installed kubuntu in wmware and tried a compile with my latest comitted changes and it builds but fails on devil because kubuntus zlib is to new, any hints on how to downgrade zlib ?.

 

Downgrading isn't a good idea, unless you statically link the downgraded library into the executable (and even then it's questionable).

 

The Linux/Unix way is to use the libary on the system, not ship outdated ones with the executable.

 

However, I can see how upgraded libraries cause problems (see boost). So, not sure what you can do.

 

For me it stops here:

 

g++ -Wall -o framework/precompiled_engine.h.gch -x c++-header -c -pipe -Wall -Wno-unknown-pragmas -fmessage-length=0 -fpermissive -fvisibility=hidden -m32 -O3 -march=pentium3 -ffast-math -fno-unsafe-math-optimizations -fomit-frame-pointer -DXTHREADS -fno-strict-aliasing -Winvalid-pch -D__DOOM_DLL__ -Iframework -Ibuild/release/core/sys/scons -Isys/scons -Iinclude -Iinclude/zlib -Iinclude/minizip -Iinclude/libjpeg -Iinclude/devil -I. framework/precompiled_engine.h
scons: Cannot explain why `build/release/core/glimp/sys/linux/glimp_dlopen.cpp' is being rebuilt: No previous build information found
cd sys/linux && m4 -E < glimp_dlopen.cpp.m4 > /home/te/src/tdm_experimental/The-Darkmod-Experimental/src/build/release/core/glimp/sys/linux/glimp_dlopen.cpp
m4:stdin:36: undefined macro `f363_ret'
m4:stdin:36: undefined macro `f363_name'
m4:stdin:36: undefined macro `f363_params'
m4:stdin:48: undefined macro `f363_ret'
m4:stdin:48: undefined macro `f363_name'
m4:stdin:48: undefined macro `f363_params'
m4:stdin:66: undefined macro `f363_name'
m4:stdin:105: undefined macro `f363_ret'
m4:stdin:105: undefined macro `f363_name'
m4:stdin:105: undefined macro `f363_params'
m4:stdin:132: undefined macro `f363_name'
scons: *** [build/release/core/glimp/sys/linux/glimp_dlopen.cpp] Error 1
scons: building terminated because of errors.

[revelator]

i removed all those macros from m4 huh ?!?.

Yep just checked those macros dont exist anywhere in the source, might be scons caching of things from old builds so it keeps picking them up, could you do a fresh checkout and build ? just in case.

[wesp5]

May I ask as a newbie what this TDM branch is all about? Is it related to the D3:BFG improvements or something? Like what can we endusers expect ?

[motorsep]

i removed all those macros from m4 huh ?!?.

Yep just checked those macros dont exist anywhere in the source, might be scons caching of things from old builds so it keeps picking them up, could you do a fresh checkout and build ? just in case.

 

Why don't you install Linux on your PC and test it hands on ?

[Tels]

i removed all those macros from m4 huh ?!?.

Yep just checked those macros dont exist anywhere in the source, might be scons caching of things from old builds so it keeps picking them up, could you do a fresh checkout and build ? just in case.

 

Ah, yes, I deleted the file scons.signatures.dblite - hopefully it works now. Will report back.

[Tels]

May I ask as a newbie what this TDM branch is all about? Is it related to the D3:BFG improvements or something? Like what can we endusers expect ?

 

It is just work in progress and nothing comes out of yet for end-userss.[0]

 

It's a "cleanup" effort, basically a house cleaning. It will allow (maybe) later enhancing the engine and modernize the grafics. Maybe.

 

0: Ok, that was a lie. You can expect about twice the performance, defered lighting, tissue-soft shadows, your manhood will be enlarged, beautiful women will flock to you and of course it will bring world peace.

[HMart]

Md3 was the quake 3 model format.

 

Does it even work with the doom 3 shader system? If yes then IMO Is better to have the option then to not to have it, imagine that someone wants to use the new TDM engine for his or her mod and has a bunch of old MD3 models from a older Quake 3 mod? That was perhaps the reason why id left it in.

[AluminumHaste]

Not sure, this might help: http://en.wikipedia.org/wiki/MD3_%28file_format%29

[revelator]

worked with idtech3 shaders and since the idtech4 shaders are an offshot of the former they should still work to some degree.

 

Why don't you install Linux on your PC and test it hands on ?

I did i installed kubuntu unfortunatly the distro i selected used a version of zlib that devil is not happy with,

and i cannot downgrade it it seems.

[motorsep]

Why would anyone want MD3 models?! It's almost impossible to author the format nowadays.

 

IQM model format would be interesting to add, or OpenGEX.

[revelator]

Gonna have a look at updating the devil sources to support the latest zlib, seems to be the only futureprof way.

[revelator]

Not up to me but might be nice to have the support for some mod if you have a ton of md3 models laying around, best thing to do would be updating them to a newer format ofc.

[HMart]

Why would anyone want MD3 models?! It's almost impossible to author the format nowadays.

 

IQM model format would be interesting to add, or OpenGEX.

 

Even tho i was talking about already existent models i'm really curious, impossible to author how so, theres still some idtech 3 based games being worked on like Tremulous, Xonotic, Alien Arena, and others, i'm sure they have tools for it. About IQM what makes it better against MD5? About the OpenGEX format i'm with you on that, it would be a good format to support has it is trying to replace Collada, but thinking about it they are ultimately useless for TDM IMO.

Edited November 21, 2014 by HMart