TDM Engine Development Page

[SteveL]

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

I'll be committing particles to the trunk for testing within a few hours... tonight or tomorrow. I've got it working nicely in the engine as of tonight, instead of being controlled through material files, so it's ready for testing on existing maps. I just took a run through a few maps and it's all looking good so far

 

Re the builder archer, that a good point. I think we catered for skin switches in AI LOD already, but maybe not model swaps. We might have to disable LOD for any AI whose model has been fiddled with if there's not a cleverer solution.

[Springheel]

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.

 

Huh. That's a problem I didn't anticipate. If mappers switch the "model" spawnarg in any existing maps, LOD will result in the wrong models being displayed at distances in 2.03.

[revelator]

If using a build from my fork on github, remember that the FPS counter code was replaced by a 64 bit precision counter version from MH

Its much more precise and does not suffer from the sometimes drastic FPS variations the vanilla version had.

[Tels]

I'll be committing particles to the trunk for testing within a few hours... tonight or tomorrow. I've got it working nicely in the engine as of tonight, instead of being controlled through material files, so it's ready for testing on existing maps. I just took a run through a few maps and it's all looking good so far

 

Re the builder archer, that a good point. I think we catered for skin switches in AI LOD already, but maybe not model swaps. We might have to disable LOD for any AI whose model has been fiddled with if there's not a cleverer solution.

 

That would be ther exception, wouldn't it be? In that case I'd say its the mappers "fault" and LOD on such AI will not be available. (and still be available for 99% of the AI out there).

 

Or is changing the model spawnarg commonplace? It certainly is unorthodox, I'd say. It never occured to me.

[Tels]

If using a build from my fork on github, remember that the FPS counter code was replaced by a 64 bit precision counter version from MH

Its much more precise and does not suffer from the sometimes drastic FPS variations the vanilla version had.

 

That change alone would be great, as I get wildly varying FPS counts on my (old) system.

[VanishedOne]

Or is changing the model spawnarg commonplace? It certainly is unorthodox, I'd say. It never occured to me.

 

It's mentioned at http://forums.thedar...post__p__350265 (presumably for the scientist in Ulysses: Genesis). I found that post when I'd run into the same problem of getting a scientist to fight properly.

Edited November 14, 2014 by VanishedOne

[SteveL]

I suspect it's not commonplace, but I'm having trouble thinking of a way to query the existing missions to do an exact count. You need to find all entities that have a "model" spawnarg and that inherit from any entityDef with spawnclass idAI. It's no big deal if we have to disable LOD for AI with custom models though. LOD is a new enhancement, so no existing map will get *worse* in 2.03 through having a few AI who don't benefit from LOD, because no AI at all benefited from LOD in 2.02.

[Bikerdude]

Huh. That's a problem I didn't anticipate. If mappers switch the "model" spawnarg in any existing maps, LOD will result in the wrong models being displayed at distances in 2.03.

It dosent work on all AI, eg I tried using the Haunt model on the zombie Ai when I had the hausnt not sleeping on the ground issue etc. But if the option is there 'some' mapper will try it, if its too hard to work around we will just have to tell mappers not to do it.

 

Would turning off LOD on my ' Builder archer ai' fix the random model switching..? if so whats the arg..?

[SteveL]

Would turning off LOD on my ' Builder archer ai' fix the random model switching..? if so whats the arg..?

Yes it will fix it. The arg is "no_lod" "1", but if we don't think of a better plan, then we'll take care of that in the game code so that existing maps don't have to be changed. But in the meantime, setting no_lod on your AI will stop the abrupt costume changes.

[revelator]

That change alone would be great, as I get wildly varying FPS counts on my (old) system.

 

Its a simple function if the darkmod guys want it in the main repository i could just post it here, its pretty much just a question of replacing 1 function with the new one.

Also saves them digging through the source to find out where it is

 

else i could upload a build with the new changes for you to test out.

[revelator]

Heres a built with the latest changes for testing http://sourceforge.net/projects/cbadvanced/files/gtkradiant/darkmod.20141115-015433.7z/download

 

Try out the new FPS counter

[Bikerdude]

Try out the new FPS counter

Whats different and is the commdna still the same, eg "com_showfps 1"

[revelator]

command is the same as for whats different its a 64 bit precision version originally created by MH.

Its a lot more accurate and it does not suffer from the wildly variating FPS values the original had.

[Bikerdude]

tested with the latest version got the following results, with my system (Core i5 2500k, GTX970, Intel Z77 mobo & 240 EVO ssd)

 

std settings - just big fps drop

 

 

'full' settings - massive fps drop, halo effect and abnormal edge lit on objects.

 

[AluminumHaste]

SSAO will kill FPS along with soft shadows.

[Bikerdude]

SSAO will kill FPS along with soft shadows.

It was just for kicks to see how it perf'd on a high end system.

 

What am I supposed to be testing when running stock settings, as I havent been reading all of this thread. Whats causing the 30fps drop im seeing..?

[nbohr1more]

Try toggling ( 1 or 0 ) r_useArbMapBufferRange and see if performance goes up or down.

 

Also, we are looking for evidence that CPU cost is down with the new VBO enabled.

 

Try a map with LOTS of AI and\or scripting and see if the performance fairs favorably to the current SVN build.

[revelator]

r_useArbMapBufferRange can cause problems on some older AMD / ATI cards so good advise if you have one of those

new FPS counter averages the FPS so you get the theoretical max FPS your card is capable of with certain effects enabled, also why it does not spike as much.

with vsync enabled your card will only show up to and newer (mark newer) ever go above your monitors refresh rate which in most cases is 60 FPS, turn it off and get the unlimited result which can vary a lot

but you might get tearing as a result.

 

Not sure if CPU cost would be affected by the VBO code as these are done on the GPU not the CPU, only way to get CPU work down would be moving more of the old stuff to GPU.

 

Read here on how VBO's work http://www.songho.ca/opengl/gl_vbo.html

[AluminumHaste]

Soft shadows takes 3 times the work, ssao takes a lot too

[revelator]

Ah ok i was wrong VBO's use GPU memory but can also use system memory if your gfx cards memory is not large enough to hold all the data.

 

Soft shadows are extremely wastefull but should be a bit lighter on resources now that we have access to the engines depthbuffer.

SSAO should not be a big resource waste, are you using sikkpins version from sikkmod ? asking because that version is from before we had access to the engines depthbuffer so he had to create a hack to get the depthimage and it was rather hard on resources.

 

edit SSAO can also be a bit resource intensive it seems, but it seems downsampling the ssao image can get rid of a good portion of that allbeit with a bit lower quality of the occlusion factor.

Also stumbled upon some new techniques to optimize SSAO called screen space ambient obscurance instead of screen space ambient occlusion.

Theres a little info on the unity page http://docs.unity3d.com/Manual/script-SSAOEffect.html

Edited November 15, 2014 by revelator

[revelator]

Gonna call it a night its 4.18 in the morning here and im starting to feel like a night owl with these late night coding sessions

So night folks

[revelator]

Ok todays work included adding the Boehm garbadge collector to test for memory leaks, to my dismay i actually found that both vanilla darkmod and my own engine seems to leak memory from Mem_Alloc

and Mem_Alloc16, Boehm GC unfortunatly could not tell me where in the code the leak is but i noticed that especially Mem_Allloc seems to run through some rather insane data ammounts (allocations of allmost 2 GB Oo) and it does warn about that this may lead to leaks. Bringing the load down could probably save some trouble, but first i need to find out where those large data allocations come from.

 

I Have made code to disable GC if not needed but it does not seem to make the engine run worse and if i can figure out how to make it print the code location for debug calls it would be a nice tool to have (bit like a built in valgrind) .

[SteveL]

Hmm that's worth checking out although I've not noticed any reports of memory leaks. They normally manifest as ever-increasing usage if memory isn't getting returned don't they?

[revelator]

Normally yes, it might not be a huge leak but its still worth checking out

it could also be a leak in msvc's own malloc implementation since it uses this to prime the built in memory allocator in case the pointer is empty at start.

I did notice it throwing a debugbreak in msize so it seems thats a good place to look.

[revelator]

//===============================================================
//
// Boehm GC Wrappers
//
//===============================================================
/*
==================
GC_malloc_wrapper
==================
*/
ID_INLINE void *GC_malloc_wrapper(size_t required_bytes) {
void *p;
GC_INIT();
if ((p = (void *)GC_malloc_uncollectable(required_bytes)) == NULL) {
 return NULL;
}
return p;
}
/*
==================
GC_free_wrapper
==================
*/
ID_INLINE void GC_free_wrapper(void *p) {
if (p != NULL) {
 GC_free(p);
}
}
/*
==================
GC_aligned_malloc_wrapper
Missing from Boehm GC
==================
*/
ID_INLINE void *GC_aligned_malloc_wrapper(size_t required_bytes, size_t alignment) {
void *p1; // original block
void **p2; // aligned block
int offset = alignment - 1 + sizeof(void *);
GC_INIT();
if ((p1 = (void *)GC_malloc_uncollectable(required_bytes + offset)) == NULL) {
 return NULL;
}
p2 = (void**)(((size_t)(p1) + offset) & ~(alignment - 1));
p2[-1] = p1;
return p2;
}
/*
==================
GC_aligned_malloc_wrapper
Missing from Boehm GC
==================
*/
ID_INLINE void GC_aligned_free_wrapper(void *p) {
if (p != NULL) {
 GC_free(((void**)p)[-1]);
}
}
#define USE_GC_ALLOCATORS
#ifdef USE_GC_ALLOCATORS
#define GC_MALLOC_WRAPPER(x) GC_malloc_wrapper(x)
#define GC_FREE_WRAPPER(x) GC_free_wrapper(x)
#define GC_ALIGNED_MALLOC_WRAPPER(x, y) GC_aligned_malloc_wrapper(x, y)
#define GC_ALIGNED_FREE_WRAPPER(x) GC_aligned_free_wrapper(x)
#else
#define GC_MALLOC_WRAPPER(x) malloc(x)
#define GC_FREE_WRAPPER(x) free(x)
#define GC_ALIGNED_MALLOC_WRAPPER(x, y) _aligned_malloc(x, y)
#define GC_ALIGNED_FREE_WRAPPER(x) _aligned_free(x)
#endif

 

My current test code in case others might want to try it out, use GC_MALLOC_WRAPPER instead of malloc and GC_FREE_WRAPPER instead of free.

the aligned versions are for Mem_Alloc16 and Mem_Free16 (which btw used unaligned malloc so duh).