Jump to content
The Dark Mod Forums

Revelator's TDM Branch

nbohr1more

By nbohr1more
in The Dark Mod

 Share

Recommended Posts

SteveL

SteveL

Posted
Posted

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.

  • Like 1
  • Replies 284
  • Created
  • Last Reply

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Popular Posts

revelator
revelator

Started work on porting ioquake3's framebuffer code to idtech4 as we need this anyway if we want shadowmaps. Also usefull for other effects such as hdr lighting bloom etc.   Had to port it as idtech3

revelator
revelator

Hmm since the above function was only ever used in the disabled exp renderer i had a look at the code and it might be possible to use it since the missing shaders for it can be found in Doom3-BFG's ca

revelator
revelator

Actually starting on my new part time job tomorrow so a bit less time to work on this, no worries though ill still work on this.

Posted Images

revelator

revelator

Posted
Posted

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 :P so my hopes up on that part.

motorsep

motorsep

Posted
Posted

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

revelator

Posted
Posted (edited)

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 by revelator
  • Like 1
Tels

Tels

Posted
Posted

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

 

Agreed.

"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

motorsep

motorsep

Posted
Posted

@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

HMart

Posted
Posted

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

revelator

Posted
Posted

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

Tels

Posted
Posted

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

"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

Tels

Tels

Posted
Posted (edited)

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

Edited by Tels

"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

revelator

revelator

Posted
Posted

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

Tels

Posted
Posted

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

"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

Tels

Tels

Posted
Posted

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

"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

Tels

Tels

Posted
Posted

It's already half build.

"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

Tels

Tels

Posted
Posted

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.

 

 

"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

Tels

Tels

Posted
Posted (edited)

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 by Tels

"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

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Go to topic listing

  • Recent Status Updates

    • JackFarmer

      JackFarmer

      "The Year of the Rat." 
      😄

      Al Stewart must be proud of you!
      Happy testing!
      @MirceaKitsune
      · 1 reply
    • datiswous

      datiswous

      I posted about it before, but I think the default tdm logo video looks outdated. For a (i.m.o.) better looking version, you can download the pk4 attached to this post and plonk it in your tdm root folder. Every mission that starts with the tdm logo then starts with the better looking one. Try for example mission COS1 Pearls and Swine.
      tdm_logo_video.pk4
      · 2 replies
    • JackFarmer

      JackFarmer

      Kill the bots! (see the "Who is online" bar)
      · 3 replies
    • STiFU

      STiFU

      I finished DOOM - The Dark Ages the other day. It is a decent shooter, but not as great as its predecessors, especially because of the soundtrack.
      · 5 replies
    • JackFarmer

      JackFarmer

      What do you know about a 40 degree day?
      @demagogue
      · 4 replies
×
×
  • Create New...