Revelation Test

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

[revelator]

Test build to try out before i commit more crimes against humanity



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.

[revelator]

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

[toneddu2000]

Omg revelator, you can't find peace with those shadows!

[Spike]

never trust a game set in hell.
you can never get the demons out of the code. :s

[toneddu2000]

[revelator]

omg spike that was awesome hehehe

[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

[revelator]

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

[nbohr1more]

Woot! Does this require your OMP work, or can it be applied to any vanilla code base?

[revelator]

should work right out of the box with vanilla

[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 );

[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

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