Revelator's TDM Branch

[revelator]

need to install the x86 version do sudo apt-get install libglew1.5-dev:i386 and you should hit jackpot

[motorsep]

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.

 

Well, if you can just look into game code, you can see that BFG's codebase is D3+ROE. Maybe minor differences. Porting game code of TDM to BFG is easier than trying to make modern rendering engine from TDM engine.

[Tels]

need to install the x86 version do sudo apt-get install libglew1.5-dev:i386 and you should hit jackpot

 

$ sudo apt-get install libglew1.5-dev:i386
Reading package lists... Done
Building dependency tree	  
Reading state information... Done
E: Couldn't find package libglew1.5-dev:i386

 

Meh

Edited November 22, 2014 by Tels

[Tels]

Well, if you can just look into game code, you can see that BFG's codebase is D3+ROE. Maybe minor differences. Porting game code of TDM to BFG is easier than trying to make modern rendering engine from TDM engine.

 

Well, then we just wait until you finished the porting. We are all quite busy here with other stuff.

[revelator]

well if your package manager does not have it then the only thing you can do is build it yourself though im wondering if it has a different name on your distro, which linux are you using ?.

[Tels]

Using Kubuntu, but is a very old one 10.4 I believe. Can't upgrade, the HD is full (root partition to small, my fault back a few years ago) and the PC won't take a larger HD, anyway. It's at the EOL so I'm not gonna ugprade it, but so far hadn't had the time and money to buy a new PC.

 

Sorry, seems I can't help you here anymore.

[revelator]

Hmm just tried on the 64 bit version and it fails on libpng even though i installed the x86 version and its there i did check.

If i do the build on the x86 version of kubuntu which btw is the same version as yours it works, so seems its something in the 64 bit kubuntu acting up.

[revelator]

ah there we go

sudo apt-get install libpng12-0 libpng12-0:i386

sudo apt-get install libglew1.5-dev libglew1.5-dev:i386

and then i had to move the system zlib.h out of the place in /usr/include

 

customized linuxBuild.sh a bit to do this automatically

 

#!/bin/bash
mkdir -p ~/games/tdm/darkmod
# make sure this file exists
touch scons.signatures.dblite
# FAST=true
# --debug=explain
# move the system zlib.h header out of the place so we can use darkmods
mv -f /usr/include/zlib.h /usr/include/zlib.h.bak
cp -pf `pwd`/include/zlib/zlib.h /usr/include/zlib.h
# $@ = pass along the flags like "BUILD=profile" or "BUILD=debug"
time scons -j2 BUILD_GAMEPAK=1 NO_GCH=0 BUILD=release --debug=explain "$@"
mv gamex86-base.so gamex86.so
#strip gamex86.so
#strip thedarkmod.x86
cp thedarkmod.x86 ~/games/tdm/darkmod/
cp thedarkmod.x86 ~/games/tdm/
cp tdm_game02.pk4 ~/games/tdm/darkmod/tdm_game02.pk4
if [ -f ~/games/tdm/darkmod/gamex86.so ]; then
 rm ~/games/tdm/darkmod/gamex86.so
fi
# move zlib.h back to the original
rm -f /usr/include/zlib.h
mv -f /usr/include/zlib.h.bak /usr/include/zlib.h

[Tels]

Relevator, here is a patch to remove GLASSWARP:

 

http://swift-mazes.com/pub/tdm-patches/tels_patch_k_remove_glasswarp_2014-10-04.txt

 

The patch was discussed at lenght and we don't need GLASSWARP at all. Not sure if it was already applied to TDM.

[revelator]

Not yet thanks.

Hmm sems you only have the x86_64 version of glew installed, you need the i386 version, or wait untill we have 64 bit support.

Saw wrong btw my version of kubuntu is the 14.4 version, but i got it to compile on both the x86 and the x86_64 version now so its down to missing packages.

[revelator]

Ok removed glasswarp.

Added a function to clear matrix interactions that might interfere with the gui, one such is the POM shader from sikkmod, sliding may still happen but thats another problem caused by bad normals.

Used idlibs clampFloat to clamp color variations.

 

edit:

 

this part

 

- else if ( !token.Icmp( "glassWarp" ) ) {

- ts->texgen = TG_GLASSWARP;

- continue;

- }

was changed to

 

else if ( !token.Icmp( "glassWarp" ) ) {

- ts->texgen = TG_GLASSWARP;

continue;

}

that way we wont get an error in the unlikely case someone do actually use it.

Edited November 24, 2014 by revelator

[Bikerdude]

Keep up the good work chaps :-)

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

[Bikerdude]

Good luck and no probs, we appreciate any and all the help you can give.

[HMart]

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.

 

Good luck and we all have to pay bills so paying jobs first.

[revelator]

Thanks guys

[nbohr1more]

Added some tentative RGTC stuff to your repo.

 

It looks like the swizzle is done entirely in the shader so we'd just need change that to

something like:

 

http://forums.inside...start=90#p40692

 

the offending swizzle:

 

MOV localNormal.x, localNormal.a

 

Edit: Ha, another use case for "customLight" changing the ARB shader so it works

for texture formats that aren't compatible with the swizzle...

Edited November 25, 2014 by nbohr1more

[revelator]

Cool m8 steve is also joining in on this branch to help btw.

[nbohr1more]

Ah, I think we can encode with ATI2N (alternate swizzle) but load as RGTC, that should prevent the need

to change the swizzle in the shader:

 

http://www.ozone3d.net/tutorials/bump_map_compression_p4.php#3dc

[nbohr1more]

Rev, have you tried building this in MSVC 2013 community?

 

Since I cannot build, would you kindly post a new one with my latest Git changes?

[SteveL]

Morning guys. You might already have seen, greebo is working on upgrading our trunk solution to vs2013 this morning.

 

RGTC: thats to allow compressed normal maps isn't it? The link to mh's enhanced interaction shader was interesting. Do we have any of those techniques in our enhcanced interaction shader do you know?

 

That swizzle you quoted... I'd have to read up to be able to understand why it moves the alpha / 'w' channel to the red / 'x' channel, or is that part of the RGTC technique?

[nbohr1more]

The Swizzle is part of the RXGB compression that Doom 3 uses natively, I believe the story goes that the alpha channel has

more bits of precision than the green channel (in DXT5) so the data is written there instead then swizzled in the interaction shader.

 

RGTC (Red Green texture compression) is a variation of ATI's "3Dc" normal map compression (AKA LATC in OpenGL) there's no

swizzle there but the link I found appears to show that you can encode RGTC with a swizzle too and that should prevent the need

to change the shader.

[revelator]

MH moved most of the shader commands to the framebuffer if i remember correctly, and it was indeed interesting as he gained much more detail than normal in doom3 by doing it.

I think there was also a few engine changes needed for it to work.

 

Newer quite understood swizzle but ill see if i can find some documentation about it.

[revelator]

P.s im busted (black friday here in denmark) so ill take a nap before ill start investigating this.

[nbohr1more]

I can build our current SVN now, so no rush on this... But it would be good if your branch was also compliant. (Might be, haven't tested with all the correct SDKs installed yet)