Revelation Test

Discuss anything not covered by any of the other categories.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: Revelation Test

Post 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.
Productivity is a state of mind.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: Revelation Test

Post 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.
Productivity is a state of mind.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: Revelation Test

Post by revelator »

Image

Well this one still rears its ugly head from time to time :S
Productivity is a state of mind.
toneddu2000
Posts: 1395
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Re: Revelation Test

Post by toneddu2000 »

Omg revelator, you can't find peace with those shadows! :)
Meadow Fun!! - my first commercial game, made with FTEQW game engine
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: Revelation Test

Post by Spike »

never trust a game set in hell.
you can never get the demons out of the code. :s
toneddu2000
Posts: 1395
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Re: Revelation Test

Post 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
Meadow Fun!! - my first commercial game, made with FTEQW game engine
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: Revelation Test

Post by revelator »

omg spike :lol: that was awesome hehehe :mrgreen:
Productivity is a state of mind.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: Revelation Test

Post 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 :?:
Productivity is a state of mind.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: Revelation Test

Post 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.
Productivity is a state of mind.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: Revelation Test

Post 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.
Productivity is a state of mind.
nbohr1more
Posts: 54
Joined: Fri Dec 09, 2011 7:04 am

Re: Revelation Test

Post by nbohr1more »

Woot! Does this require your OMP work, or can it be applied to any vanilla code base?
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: Revelation Test

Post by revelator »

should work right out of the box with vanilla :)
Productivity is a state of mind.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: Revelation Test

Post 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 );
Productivity is a state of mind.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: Revelation Test

Post 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 :)
Productivity is a state of mind.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: Revelation Test

Post 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.
Productivity is a state of mind.
Post Reply