Revelator's TDM Branch

[SteveL]

The problem with continuing to support old formats is it's not free, even if the code is already in place. If we wanted to improve model rendering in some way for example, we have to write and test the code once for each supported format. Old formats can even block new development completely, if there's no users / use cases around to test it.

[revelator]

IQM is a skeletal model format if i remember correctly, and yeah md3 still has its uses .

Ok got a bit further on the linux build but now it cannot find libpng (zlib problem again i suspect).

no errors from m4 though and the generated files seem to be... well generated so my hopes up on that part.

[Springheel]

We've never used md3 and I highly doubt we ever would ( I don't even know what program saves in that format).

[motorsep]

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.

 

Xonotic uses IQM almost exclusively. MD5 is fine for Doom 3 engines, as long as animation system stays in place. IQM has robust Blender exporter and I believe it can already convert FBX to IQM. So there is no need to struggle searching for working exporters for several 3D apps. It also supports vertex color.

 

One disadvantage of MD5 and existing animation system is that bones inside MD5 have absolute coordinates. Meaning you can share animations with models that have different skeletons (as far as locations of the bones). So let's say you have 2 characters with exactly the same bones, except that one has longer spine and wider shoulders. With IQM, you can export 2 models, and 1 set of animations. With MD5, you have to have 2 models and 2 sets of animations. It's not totally bad, but just pointing the disadvantage (which I experienced first hand last week).

 

Note I am not advocating to replace anything in TDM

[revelator]

Also ok to discuss other stuff that might be of interrest lets just not derail it to much i think blender at one time supported md3 but yeah its not really something you should consider when doing a modern game. Also if the darkmod devs dont even use it i dont see much speaking for keeping it, IQM could be interresting to add but i might need a hand on that one if the devs want it in atleast. Atm ill focus on getting this building on linux/windows then we can allways go from there

Edited November 21, 2014 by revelator

[Tels]

Atm ill focus on getting this building on linux/windows then we can allways go from there

 

Agreed.

[motorsep]

@revelator: I think (and that's just a thought) it would be better to begin porting game code to Doom 3 BFG code base. This way you could figure out all the incompatibilities and when I release my engine, you could just merge the game code of TDM and that would solve all the issues at once

[HMart]

The problem with continuing to support old formats is it's not free, even if the code is already in place. If we wanted to improve model rendering in some way for example, we have to write and test the code once for each supported format. Old formats can even block new development completely, if there's no users / use cases around to test it.

 

Hum didn't think of that, in that case i also don't see a reason to keep md3.

[revelator]

Bit more than just the game code but thanks motorsep i will definatly look at it at some point.

[revelator]

Got rid of the remaining qgl function pointers (seems i did not catch all of em the first round as there are also qgl pointers in the m4 files).

Comitted to trunk feel free to test if it builds on linux now, still having problems with kubuntu :/

[Tels]

@revelator: I think (and that's just a thought) it would be better to begin porting game code to Doom 3 BFG code base. This way you could figure out all the incompatibilities and when I release my engine, you could just merge the game code of TDM and that would solve all the issues at once

 

Porting isn't easy and free. We can't just "port", we would need to bring over a lot of stuff and basically merge the two engines. Greebo spent a lot of time on this already when we switched to the OS version of D3. I guess BFG is even more work as it is vastly different from D3 vanila.

[Tels]

Rechecked out the source and it now compiles libgame.so \o/ but then stops with:

 

 

 

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.

 

 

 

Edit:

 

At the top of sys/gllog/gl_def.m4 I see:

 

define(`gl_start', `0')
define(`gl_end', `335')
define(`wgl_start', `336')
define(`wgl_end', `357')
define(`glX_start', `358')
define(`glX_end', `363')

 

These are used in sys/linux/glimp_dlopen.cpp.m4 here:

 

define(`instance_funcptr', ``$1' ( * glX`$2' )(`$3');')
forloop(`i', glX_start, glX_end, `instance_funcptr(indir(`f'i`_ret'), indir(`f'i`_name'), indir(`f'i`_params'))
')

 

which would then result in these strange f363_end definitions. Maybe here is the problem

Edited November 22, 2014 by Tels

[revelator]

Aye i just committed some new changes where im getting rid of the logging functions completely, it now runs to the end in scons but fails on linking to glew so i suspect the better way would be doing it the same way we do libjpeg and devil and simply compile in glew.c as part of the build. i noticed greebo made a lot of work in that department so if he could lend a hand i would be gratefull this is the only thing keeping it from building now.

[Tels]

Just updated and started the compiling again, will look after it's through.

[revelator]

One error left im getting there undefined reference to glColorMask adding -lGL and -lGLU before linking with GLEW and hopefully we are done.

[revelator]

Annnd we have a winner took a few more fixes but it builds now.

[revelator]

Full build done damn this was a bitch to get working, comitting final changes now.

[Tels]

Damn, you mean I just waited 18mins for it to build for nothing?

[revelator]

Hehe i get very stubborn when something wont build

 

Heres a test you can try http://sourceforge.net/projects/cbadvanced/files/gtkradiant/tdm_game02.pk4.tar.gz/download

 

These are the compiled binaries from my kubuntu build.

[Tels]

It's already half build.

[revelator]

lets just hope it runs also.

[Tels]

Doesn't build:

 

 

 

scons: Cannot explain why `build/release/game/idlib/Heap.os' is being rebuilt: No previous build information found
g++ -o build/release/game/idlib/Heap.os -c -fPIC -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 -Iidlib -Ibuild/release/game/sys/scons -Isys/scons -Iinclude -Iinclude/zlib -Iinclude/minizip -Iinclude/libjpeg -Iinclude/devil -Iinclude/glew -I. idlib/Heap.cpp
idlib/Heap.cpp: In function ‘void* _aligned_malloc(size_t, size_t)’:
idlib/Heap.cpp:34: error: ‘GC_init’ was not declared in this scope
idlib/Heap.cpp: In member function ‘void* idHeap::Allocate16(dword)’:
idlib/Heap.cpp:349: warning: suggest parentheses around ‘+’ in operand of ‘&’
include/boost/system/error_code.hpp: At global scope:
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/game/idlib/Heap.os] Error 1
scons: building terminated because of errors.

 

 

[revelator]

stray leftover from removing GC, fixed on trunk now.

[revelator]

since im running linux on a vm i cannot test the build so if anyone has a build done let me know if it works.

[Tels]

Getting close:

 

 

 

/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../libGLEW.so when searching for -lGLEW
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../libGLEW.a when searching for -lGLEW
/usr/bin/ld: skipping incompatible /usr/lib/libGLEW.so when searching for -lGLEW
/usr/bin/ld: skipping incompatible /usr/lib/libGLEW.a when searching for -lGLEW
/usr/bin/ld: cannot find -lGLEW
collect2: ld returned 1 exit status
scons: *** [build/release/core/sys/scons/doom] Error 1
scons: building terminated because of errors.

 

 

 

I have the following:

 

 

 

$ whereis libGLEW

libGLEW: /usr/lib/libGLEW.so /usr/lib/libGLEW.a /usr/lib64/libGLEW.so /usr/lib64/libGLEW.a

 

 

 

So may I miss the 32bit packet of libGLEW (I do remember that I had to install some of the to build on my 64bit Linux), or SConstruct has a path missing.

Edited November 22, 2014 by Tels