Page 4 of 8

Re: Revelation Test

Posted: Sun Aug 17, 2014 11:37 pm
by revelator
Nice stuff :) that might indeed help.

Might even help on the occasional shadow crack sometimes visible in places with lots of brushes.

The built in debug tools sadly failed a ton when trying to hunt down the ghostly shadow images i got on some maps, some digging in the matrix calls seem to have killed of most of them though.

Re: Revelation Test

Posted: Mon Aug 18, 2014 5:29 am
by revelator
Test build to try out before i commit more crimes against humanity :P

http://sourceforge.net/projects/cbadvan ... z/download

all floating point values are now correctly suffixed.
fixed a few lvl 4 warnings about non standard types and type casting.
arrays are now 0 terminated before they have there values set.
grimm's quest for the gatherers key looks insane with this now :).
made Doom3's threads local with Thread local storage (added a macro for the pragma, TODO: linux variant).

if someone wants an XP build give me a shout and ill make one.

Re: Revelation Test

Posted: Tue Aug 19, 2014 10:53 am
by revelator
Image

Well this one still rears its ugly head from time to time :S

Re: Revelation Test

Posted: Tue Aug 19, 2014 6:00 pm
by toneddu2000
Omg revelator, you can't find peace with those shadows! :)

Re: Revelation Test

Posted: Tue Aug 19, 2014 7:01 pm
by Spike
never trust a game set in hell.
you can never get the demons out of the code. :s

Re: Revelation Test

Posted: Tue Aug 19, 2014 7:25 pm
by toneddu2000
never trust a game set in hell.
you can never get the demons out of the code. :s
Carved this phrase on my desk! :D

Re: Revelation Test

Posted: Wed Aug 20, 2014 2:33 am
by revelator
omg spike :lol: that was awesome hehehe :mrgreen:

Re: Revelation Test

Posted: Wed Aug 20, 2014 1:14 pm
by revelator
What i dont get is that the silhuette is from an object that does not seem to exist :?: it dissapears with closer distance also. Map bug :?:

Re: Revelation Test

Posted: Wed Aug 20, 2014 6:17 pm
by revelator
Well heres an updated thread handler for vanilla, based loosely on BFG.

Code: Select all

/*
==================
Sys_Createthread
==================
*/
void Sys_CreateThread( xthread_t function, void *parms, xthreadPriority priority, xthreadInfo &info, const char *name, xthreadInfo *threads[MAX_THREADS], int *thread_count ) {
	DWORD		dwFlags = 0;
	// Without this flag the 'dwStackSize' parameter to CreateThread specifies the "Stack Commit Size"
	// and the "Stack Reserve Size" is set to the value specified at link-time.
	// With this flag the 'dwStackSize' parameter to CreateThread specifies the "Stack Reserve Size"
	// and the �Stack Commit Size� is set to the value specified at link-time.
	// For various reasons (some of which historic) we reserve a large amount of stack space in the
	// project settings. By setting this flag and by specifying 64 kB for the "Stack Commit Size" in
	// the project settings we can create new threads with a much smaller reserved (and committed)
	// stack space. It is very important that the "Stack Commit Size" is set to a small value in
	// the project settings. If it is set to a large value we may be both reserving and committing
	// a lot of memory by setting the STACK_SIZE_PARAM_IS_A_RESERVATION flag. There are some
	// 50 threads allocated for normal game play. If, for instance, the commit size is set to 16 MB
	// then by adding this flag we would be reserving and committing 50 x 16 = 800 MB of memory.
	// On the other hand, if this flag is not set and the "Stack Reserve Size" is set to 16 MB in the
	// project settings, then we would still be reserving 50 x 16 = 800 MB of virtual address space.
	dwFlags |= STACK_SIZE_PARAM_IS_A_RESERVATION;
	info.threadHandle = CreateThread( NULL,									// LPSECURITY_ATTRIBUTES lpsa,
									  0,									// DWORD cbStack,
									  ( LPTHREAD_START_ROUTINE )function,	// LPTHREAD_START_ROUTINE lpStartAddr,
									  parms,								// LPVOID lpvThreadParm,
									  dwFlags,								// DWORD fdwCreate,
									  &info.threadId );
	// uh oh ....
	if( !info.threadHandle ) {
		idLib::common->FatalError( "CreateThread() error is: %u\n", GetLastError() );
	}
	// better have this set or Revelation will run very very very slow.
	if( priority == THREAD_HIGHEST ) {
		SetThreadPriority( info.threadHandle, THREAD_PRIORITY_HIGHEST );	//  we better sleep enough to do this
	} else if( priority == THREAD_ABOVE_NORMAL ) {
		SetThreadPriority( info.threadHandle, THREAD_PRIORITY_ABOVE_NORMAL );
	} else if( priority == THREAD_NORMAL ) {
		SetThreadPriority( info.threadHandle, THREAD_PRIORITY_NORMAL );
	} else if( priority == THREAD_BELOW_NORMAL ) {
		SetThreadPriority( info.threadHandle, THREAD_PRIORITY_BELOW_NORMAL );
	} else if( priority == THREAD_LOWEST ) {
		SetThreadPriority( info.threadHandle, THREAD_PRIORITY_LOWEST );
	} else {
		// if we hit this then the programmer forgot to set a default thread priority.
		SetThreadPriority( info.threadHandle, GetThreadPriority( info.threadHandle ) != THREAD_PRIORITY_ERROR_RETURN );
	}
	info.name = name;
	if( *thread_count < MAX_THREADS ) {
		threads[( *thread_count )++] = &info;
	} else {
		common->Warning( "WARNING: MAX_THREADS reached\n" );
	}
}
Not all priorities are used but i left paths for them anyway for experimentation.
The thread handler also sets a default priority in case the programmer forgot to set it.

also a small change to Sys_StartAsyncThread

after LARGE_INTEGER t;

yank this in

Code: Select all

	SYSTEM_INFO		info;
	// check number of processors
	GetSystemInfo( &info );
after #ifdef SET_THREAD_AFFINITY
change it to

Code: Select all

	switch( info.dwNumberOfProcessors ) {
	case 2:
		SetThreadAffinityMask( threadInfo.threadHandle, 2 );
		break;
	case 4:
		SetThreadAffinityMask( threadInfo.threadHandle, 4 );
		break;
	default:
		break;
	}
and in WinMain

yank this in at the top

Code: Select all

	SYSTEM_INFO		info;
	// check number of processors
	GetSystemInfo( &info );
after #ifdef SET_THREAD_AFFINITY

change it to this

Code: Select all

	switch( info.dwNumberOfProcessors ) {
	case 1:
		SetThreadAffinityMask( GetCurrentThread(), 1 );
		break;
	case 3:
		SetThreadAffinityMask( GetCurrentThread(), 3 );
		break;
	default:
		break;
	}
now try setting SET_THREAD_AFFINITY to 1

should run main and other threads on different cores.

Re: Revelation Test

Posted: Thu Aug 21, 2014 9:00 am
by revelator
Started porting BFG's thread handler to vanilla, its more complete and also more correct.
Above allready gives a nice boost on muticore machines but it can do with some more improvements.

BTW vanillas threads are not destroyed on game exit so it can bog the system in case a thread hangs, i made some more changes to fix that but its better to wait untill i finished porting the BFG version.
Boost is especially noticeable when using sikkmod or grimm quest as i can now run it with SSAO and still have playable framerates. This however does not fix the problems with SSAO doing awfull stuff to alpha materials like skies and heathaze, we need a different solution for that. I also removed a lot of defunct stuff from win_main.cpp.

Re: Revelation Test

Posted: Thu Aug 21, 2014 10:57 pm
by nbohr1more
Woot! Does this require your OMP work, or can it be applied to any vanilla code base?

Re: Revelation Test

Posted: Fri Aug 22, 2014 6:16 am
by revelator
should work right out of the box with vanilla :)

Re: Revelation Test

Posted: Fri Aug 22, 2014 9:46 am
by revelator
small note.

i forgot that you need to change the threadhandle pointer from xthreadInfo &info to HANDLE, its normally an int but i changed it to a pointer type.

also a small mistake in setting SetThreadAffinityMask( GetCurrentThread(), 1- > 4 ); needs to be a bitmask so SetThreadAffinityMask( GetCurrentThread(), info.threadHandle >> 1 -> 4 );

Re: Revelation Test

Posted: Fri Aug 22, 2014 2:03 pm
by revelator
Oops forget about this part untill i ported BFG's version.

DWORD dwFlags = 0;
// Without this flag the 'dwStackSize' parameter to CreateThread specifies the "Stack Commit Size"
// and the "Stack Reserve Size" is set to the value specified at link-time.
// With this flag the 'dwStackSize' parameter to CreateThread specifies the "Stack Reserve Size"
// and the �Stack Commit Size� is set to the value specified at link-time.
// For various reasons (some of which historic) we reserve a large amount of stack space in the
// project settings. By setting this flag and by specifying 64 kB for the "Stack Commit Size" in
// the project settings we can create new threads with a much smaller reserved (and committed)
// stack space. It is very important that the "Stack Commit Size" is set to a small value in
// the project settings. If it is set to a large value we may be both reserving and committing
// a lot of memory by setting the STACK_SIZE_PARAM_IS_A_RESERVATION flag. There are some
// 50 threads allocated for normal game play. If, for instance, the commit size is set to 16 MB
// then by adding this flag we would be reserving and committing 50 x 16 = 800 MB of memory.
// On the other hand, if this flag is not set and the "Stack Reserve Size" is set to 16 MB in the
// project settings, then we would still be reserving 50 x 16 = 800 MB of virtual address space.
dwFlags |= STACK_SIZE_PARAM_IS_A_RESERVATION;

just set it to 0 BFG sets differing stacksizes vanilla uses a constant stack so the stack reservation flag wont work.

Vanilla also uses async threads BFG use workers that require more precision but it should work a lot better on multicore machines.

Tests show that vanilla allocates 11 threads for the game with the above so it seems to work allright :)

Re: Revelation Test

Posted: Sat Aug 23, 2014 9:27 am
by revelator
Sourceforge seems to be down for maintainance atm, but ill post a link to my current source as soon as its up again.

New source has numerous changes.

Thread handler now a bit more correct and works like a charm.
All backends besides ARB2 removed.
Partly defered interaction code for light + shadows. (was part of an openmp patch for linux. Sadly the openmp part does not work on windows).
Removed all internal editors, functions have been stubbed out for compatibility but will be removed completely in a later release. Mods will then need to be rebuilt with revelation as the SDK to work.
corrected a ton of lvl 4 warnings.
removed all functions still relating to the old backends.
removed a lot of defunct functions from win_main.cpp.
curl ogg vorbis openal and glew are now prebuilt libraries (latest versions).
split up shader and non shader interactions into two seperate functions for clarity (from MHDoom).
Fixed the code for getting videoram size (actually it worked before also but printed negative numbers).
Changed default resolution to follow desktop resolution, can still set custom resolution if needed.
Merged all iodoom3 fixes.
Merged bugfixes from dhewm3.
applied above fixes to game dll sources from cdoom / grimm quest / sikkmod also.
changed light interactions to also use depthbounds testing (RBDoom3 BFG).
Made glColor into a C++ wrapper function. Can handle vector float and byte colors.
merged a few functions from BFG like entity sorting.

TODO.

FIX sikkmods SSAO by checking shader flags for alpha surfaces (maybe MC_OPAQE ?).
Merge BFG's thread handler.
shadow maps.