Jump to content


Photo

Revelator's TDM Branch


  • Please log in to reply
284 replies to this topic

#51 revelator

revelator

    Advanced Member

  • Development Role
  • PipPipPip
  • 574 posts

Posted 20 November 2014 - 03:35 PM

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

#52 revelator

revelator

    Advanced Member

  • Development Role
  • PipPipPip
  • 574 posts

Posted 20 November 2014 - 04:55 PM

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.

#53 Tels

Tels

    Mod hero

  • Member
  • PipPipPipPipPip
  • 15024 posts

Posted 20 November 2014 - 06:09 PM

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.
"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

"Remember: If the game lets you do it, it's not cheating." -- Xarax

#54 revelator

revelator

    Advanced Member

  • Development Role
  • PipPipPip
  • 574 posts

Posted 20 November 2014 - 06:38 PM

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.

#55 revelator

revelator

    Advanced Member

  • Development Role
  • PipPipPip
  • 574 posts

Posted 20 November 2014 - 06:55 PM

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

Edited by revelator, 20 November 2014 - 06:55 PM.


#56 Tels

Tels

    Mod hero

  • Member
  • PipPipPipPipPip
  • 15024 posts

Posted 21 November 2014 - 03:01 AM

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 :)

Spoiler

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

"Remember: If the game lets you do it, it's not cheating." -- Xarax

#57 Tels

Tels

    Mod hero

  • Member
  • PipPipPipPipPip
  • 15024 posts

Posted 21 November 2014 - 06:20 AM

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?
"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

"Remember: If the game lets you do it, it's not cheating." -- Xarax

#58 revelator

revelator

    Advanced Member

  • Development Role
  • PipPipPip
  • 574 posts

Posted 21 November 2014 - 07:15 AM

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 ?.

#59 Bikerdude

Bikerdude

    Member

  • Banned
  • PipPipPipPipPip
  • 20320 posts

Posted 21 November 2014 - 07:20 AM

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.

#60 AluminumHaste

AluminumHaste

    Darkmod Contributor

  • Development Role
  • PipPipPipPipPip
  • 6306 posts

Posted 21 November 2014 - 07:30 AM

Md3 was the quake 3 model format.

I always assumed I'd taste like boot leather.

 

#61 Tels

Tels

    Mod hero

  • Member
  • PipPipPipPipPip
  • 15024 posts

Posted 21 November 2014 - 07:52 AM

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.
"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

"Remember: If the game lets you do it, it's not cheating." -- Xarax

#62 revelator

revelator

    Advanced Member

  • Development Role
  • PipPipPip
  • 574 posts

Posted 21 November 2014 - 08:13 AM

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 ?.

#63 Tels

Tels

    Mod hero

  • Member
  • PipPipPipPipPip
  • 15024 posts

Posted 21 November 2014 - 08:15 AM

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.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

"Remember: If the game lets you do it, it's not cheating." -- Xarax

#64 revelator

revelator

    Advanced Member

  • Development Role
  • PipPipPip
  • 574 posts

Posted 21 November 2014 - 08:41 AM

:blink: 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.

#65 wesp5

wesp5

    Advanced Member

  • Member
  • PipPipPip
  • 690 posts

Posted 21 November 2014 - 09:39 AM

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 ;)?

#66 motorsep

motorsep

    Advanced Member

  • Member
  • PipPipPip
  • 884 posts

Posted 21 November 2014 - 10:01 AM

:blink: 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 ?

#67 Tels

Tels

    Mod hero

  • Member
  • PipPipPipPipPip
  • 15024 posts

Posted 21 November 2014 - 10:30 AM

:blink: 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.
"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

"Remember: If the game lets you do it, it's not cheating." -- Xarax

#68 Tels

Tels

    Mod hero

  • Member
  • PipPipPipPipPip
  • 15024 posts

Posted 21 November 2014 - 10:32 AM

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.
  • SteveL likes this
"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

"Remember: If the game lets you do it, it's not cheating." -- Xarax

#69 HMart

HMart

    Advanced Member

  • Member
  • PipPipPip
  • 821 posts

Posted 21 November 2014 - 11:27 AM

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.

#70 AluminumHaste

AluminumHaste

    Darkmod Contributor

  • Development Role
  • PipPipPipPipPip
  • 6306 posts

Posted 21 November 2014 - 11:50 AM

Not sure, this might help: http://en.wikipedia....3_(file_format)

I always assumed I'd taste like boot leather.

 

#71 revelator

revelator

    Advanced Member

  • Development Role
  • PipPipPip
  • 574 posts

Posted 21 November 2014 - 11:59 AM

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.

#72 motorsep

motorsep

    Advanced Member

  • Member
  • PipPipPip
  • 884 posts

Posted 21 November 2014 - 12:02 PM

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.

#73 revelator

revelator

    Advanced Member

  • Development Role
  • PipPipPip
  • 574 posts

Posted 21 November 2014 - 12:03 PM

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

#74 revelator

revelator

    Advanced Member

  • Development Role
  • PipPipPip
  • 574 posts

Posted 21 November 2014 - 12:05 PM

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.

#75 HMart

HMart

    Advanced Member

  • Member
  • PipPipPip
  • 821 posts

Posted 21 November 2014 - 12:29 PM

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 by HMart, 21 November 2014 - 12:30 PM.





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users