TDM Engine Development Page

[SteveL]

I hoped we could get rid of boost. It solves only a few problems that I'm sure we can solve without, but brings the massive downside binding the compiled version to the compatiblity version of the OS. E.g. you can't run a compiled-on-a-new Ubuntu TDM on old Ubuntu, and you can't run the compiled-on-old-ubuntu version on newers, so you have to compile TDM on a semi-old ubuntu to make it available to more users....

+2

[revelator]

+3 yeah should get rid of it unless it would be a mess rewriting it to use std instead, so far i see nothing that cant be done by the standard libraries but im probably not good enough with C++ to do it .

As for performance with the new VBO routine it differs a bit but most have noticed that it seems smoother myself included, it does offer a little more FPS compared to when its off where i get around 70 FPS

with vsync off and on where i get around 90 FPS, it would ofc depend on the muscle your GFX card has so its hard to say how much a normal user would notice it.

Edited November 13, 2014 by revelator

[revelator]

Btw i remember that i experimented with double epsilons compared to just epsilons ?, i changed idlib to test against both now and use the one that gets nearest to the correct value so next step would be

checking if it has any effect on building the engine with newer msvc. Hopefully it fixes some of the bugs that we had with newer msvc breaking the shadow volumes.

[motorsep]

Btw, MSVC2013 doesn't break shadow volumes in Doom 3 BFG.

[revelator]

Aye noticed that, it seems id fixed idlib for BFG, but atm its a bit of a guesswork for me to figure out what i need to change in vanillas for it to work correctly with msvc > 2012.

As pr microsoft itself they changed floats to use SSE math instead of FPU math so theres probably more that needs looking at.

 

Btw nbor did you have problems seeing my commits on github ?.

[nbohr1more]

yes, please post a link to where you commited. it seems that I am not seeing any changes either in my own repos our yours.

 

(hmm, it looks like github does weekly refreshes for repo updates, I hope that doesn't mean it takes a week for changes to show )

Edited November 13, 2014 by nbohr1more

[revelator]

using tortoisegit to commit but i cannot do a push as i dont have access to do that, unless you can give me temporary access ofc ?.

If i do get temporary access i can commit all changes at once and it should show emmidiatly on github.

my github name is the same as i use here -> revelator.

[revelator]

uploaded the patchset here http://sourceforge.net/projects/cbadvanced/files/gtkradiant/darkmod-vbo-patchset.7z/download

 

these hold all the changes i have made up to now.

 

i have numbered them so you can apply them in the correct order with git.

[revelator]

make a batch file and yank this in it.

 

@echo off
ATTRIB *.* -r -a -s -h /s /d
DEL src\*.suo /S /Q
DEL src\*.user /S /Q
DEL src\*.sdf /S /Q
RMDIR src\ipch /S /Q
RMDIR src\build /S /Q
RMDIR darkmod /S /Q
ECHO Done
PAUSE

 

eases keeping the directory clean when doing git uploads

[revelator]

updated patchset with some last minute changes.

 

http://sourceforge.net/projects/cbadvanced/files/gtkradiant/darkmod-patchset-14-11-2014.7z/download

 

TGA updated to TGA2

GLEW headers reordering.

added comment in the scons files for linux about the change to GLEW and removal of the deprecated and not even used gllog functions.

removed the unused glext.h header from project (all that is now handled by GLEW).

removed the APIENTRY hacks in qgl.h also handled by GLEW.

added linux GLEW header to qgl.h and encased the includes in #ifdef(WIN32) etc. because of the idlib parser.

added bilerp power of two check to the CopyDepth function and changed GL_LINEAR to GL_NEAREST because linear mode is a waste on grayscale images.

Tested works just honky dory, the bilerp seams check is probably overkill on a grayscale image but it does not hurt and better safe than sorry.

[revelator]

Agh looks like i broke my development environment i cannot create working executables anymore.

Seems like installing DXSDK breaks msvc 2010 so im about to reinstall sp1 and hope this fixes it.

0xc0000417 if you suddenly get this error in the windows logs then you most likely have the same problem.

the problem with DXSDK is that after windows update has run and you try to install it you will get an error about the msvc library because it has been updated,

and no longer matches so you have to remove it again to install DXSDK and then run windows update to reinstall the updated msvc runtimes,

well sadly windows update found nothing in my case and my compiler broke.

[revelator]

Hmm at my wits end, this one seems to be rather illusive

 

Microsoft Visual Studio C Runtime Library has detected a fatal error in TheDarkMod.exe.

 

Press Break to debug the program or Continue to terminate the program.

The thread 'Win32 Thread' (0x898) has exited with code -1073740777 (0xc0000417).

The thread 'Win32 Thread' (0xb5c) has exited with code -1073740777 (0xc0000417).

The thread 'Win32 Thread' (0x1edc) has exited with code -1073740777 (0xc0000417).

The thread 'Win32 Thread' (0x1c7c) has exited with code -1073740777 (0xc0000417).

The thread 'Main Thread' (0x23b4) has exited with code -1073740777 (0xc0000417).

The program '[3416] TheDarkMod.exe: Native' has exited with code -1073740777 (0xc0000417).

 

strangely my own engine builds and runs now after i repaired the compiler.

[SteveL]

I've fallen foul of the msvc2010 bug a couple of times before now. It won't let you install dx after you upgrade msvc to 1.1 and the recommended solution is uninstalling, then manually hacking the registry before reinstalling everything in the right order. Ugh.

 

I use only vs2013 now. I keep vs2010 versions of the solution and include files and use the 2010 compilers (from within 2013) to compile the release builds until we get to the bottom of that bug.

 

I take it your new crash doesn't happen in debug mode? I've not had that one, but googling around you should be able to use procdump http://technet.micro...ernals/dd996900 to generate a stack trace on exit. Options -t -w will let you start it before starting tdm and get it to dump a stack trace on crash.

[revelator]

Also happens in debug where it throws a debug assertion failed (stream != NULL) as far as i can see it seems to be an fclose causing it.

 

Doh i found the bug as we spoke :S i had moved a free out of a buggy function but placed it in the wrong place afterwards (facepalm)

[Tels]

[revelator]

Well atleast i live in denmark so dropping that at my doorstep will probably not be worth it now dont you get any ideas

But yeah total bummer it works fine again, for a minute i was starting to worry that my glew code was broken but i compared it with my revelation code and there 100% the same so that could not be it phew.

[revelator]

I created a fork of the TDM unofficial sources with my current changes here https://github.com/r...od-Experimental

all devs who want access PM me and ill set you up .

My current changes would not fit well with the main fork so i prefer this way as i have cleaned up a lot allready and plan on cleaning up even more of the code.

This means removing old unused gunk (theres a lot i know that from experience) fixing known bugs which allready are implemented in other engines including my own,

General optimization etc.

 

The code was formatted for better readability (tight).

Untill we can get rid of boost i have updated it to the latest version 1.57.

GLEW is also latest version and supports upto opengl 4.4.

MH's VBO code is in.

MH's precise FPS counter is in.

MH's fix for Ase models sometime turning up black is in.

I have fixed a number of places where something was allocated with new[] and deallocated with delete instead of delete[].

FIxed a few uninitialized variables.

Fixed a number of things pointed out by PVS Studio.

Fixed a fix i had done wrong, see above :S sorry i was tired when i did that number, had been up for 26 hours.

Edited November 14, 2014 by revelator

[Tels]

I created a fork of the TDM unofficial sources with my current changes here https://github.com/r...od-Experimental

all devs who want access PM me and ill set you up .

My current changes would not fit well with the main fork so i prefer this way as i have cleaned up a lot allready and plan on cleaning up even more of the code.

This means removing old unused gunk (theres a lot i know that from experience) fixing known bugs which allready are implemented in other engines including my own,

General optimization etc.

 

The code was formatted for better readability (tight).

Untill we can get rid of boost i have updated it to the latest version 1.57.

GLEW is also latest version and supports upto opengl 4.4.

MH's VBO code is in.

MH's precise FPS counter is in.

MH's fix for Ase models sometime turning up black is in.

I have fixed a number of places where something was allocated with new[] and deallocated with delete instead of delete[].

FIxed a few uninitialized variables.

Fixed a number of things pointed out by PVS Studio.

Fixed a fix i had done wrong, see above :S sorry i was tired when i did that number, had been up for 26 hours.

 

I do like the changes, but I think that for TDM, we would need these in small steps, e.g. one diff per item. That way it is easier to see what it changes.

 

However, don't let me distract you, as I no longer have access to the mod, I can't commit anything, anyway, and all the work will be done by others. Thank you again for your work!

[revelator]

Aye and it will be so from the initial checkin but since the GLEW port was a rather major change i thought it better to just start from that, the patch just for the glew changes is massive.

If the devs like i could just hand over the repository to them and they could keep a version of both models, eg one with GLEW and one without but i suspect when they notice the benefits of it that they might prefer this version.

[Tels]

Aye and it will be so from the initial checkin but since the GLEW port was a rather major change i thought it better to just start from that, the patch just for the glew changes is massive.

If the devs like i could just hand over the repository to them and they could keep a version of both models, eg one with GLEW and one without but i suspect when they notice the benefits of it that they might prefer this version.

 

I do think that we'd just add GLEW to TDM - no sense in keeping two versions. But as I said, it's not my job or decision.

[revelator]

If you have some ideas i could hook you up to my github repo, unless ofc you prefer not to but the offer is open cant break anything by just doing a pull from git,

and i should be able to see the changes you have done according to an open watcom dev i sometimes do a little work for,

but ill ask the dev from open watcom how he does it since i have a few commits accepted by him and he claims he can see my changes

when i do a pull.

[revelator]

Probably also the VBO code ? plus a cleaned source would be nice i hope

[Bikerdude]

What do I need to do a test on the large WIP Im working on atm..

http://sourceforge.n...ild.7z/download

Did a quick test and I am seeing the following -

• FPS drops in some locations compared to 2.02.
  
• some anomolies with particles
  
• and a very aweird anomoly where an AI keep changing its skin/char model
  

 

[SteveL]

Isn't #2 what particles do anyway? NB this experiment of revelator's doesn't contain any of the particle softening effects. Or does that particle look different in 2.02?

 

#3 looks like the vs2013 compilation bug, or maybe modelDepthHack has been broken so "classic" particles can't overdraw solids. Did you change or remove model depth hack at all revelator? model depth hack won't be needed with soft particles, but we'll be keeping it as a fallback option.

 

#4 is weird. My first thought was that it could be an incomplete LOD entity def, if you were testing with the svn darkmod assets. We'll find a few of those in 2.03 testing. But city guard->Builder is an odd combination.

[Bikerdude]

• Isn't #2 what particles do anyway? NB this experiment of revelator's doesn't contain any of the particle softening effects. Or does that particle look different in 2.02?
  
• #4 is weird. My first thought was that it could be an incomplete LOD entity def, if you were testing with the svn darkmod assets. We'll find a few of those in 2.03 testing. But city guard->Builder is an odd combination.
  

• ah I thought this had your particle code in it.
  
• I wanted a bullder archer, so what I did was use the model "tdm_ai_builderguard_lesser" on a "atdm:ai_citywatch_archer" entity, in 2.02 this works.