Testers and reviewers wanted: BFG-style vertex cache

[duzenko 643]

16 hours ago, lowenz said:

version 8530 (with its GLProgs)

ShadowMaps problem (not present with Stencil) on a Radeon RX 570 (Catalyst 20.1.3) with NPC ! Shadows are.....partial.

 

 

 

Maybe now that the SVN version is complete (GLProgs) it's time to create a related dedicated thread for betatesters?

Map name? Save game & .cfg download link?

I have seen md5 shadows broken for a while e.g. the bad guy in Closemouthed Shadows.

But for sanity check, I need a specific case to investigate.

[lowenz 584]

"A new Job" - first 2 guards encountered

No particular hack in the cfg about soft shadows (stencil ones are perfect).

[duzenko 643]

Just now, lowenz said:

"A new Job" - first 2 guards encountered

No particular hack in the cfg about soft shadows (stencil ones are perfect).

getviewpos?

[lowenz 584]

getviewWHAT?

[duzenko 643]

3 minutes ago, lowenz said:

getviewWHAT?

These two?

[duzenko 643]

I think the problem with shadow geometry models is that

1. material 'textures/common/shadow' is marked as translucent and
2. translucent surfaces (e.g. glass and water) are excluded from shadow mapping

I would like to hear opinions on which point is problematic?

[lowenz 584]

Yes, those 2 !

[lowenz 584]

On 11/14/2019 at 7:06 PM, lowenz said:

Good news guys!

 

1.91.1 OpenAL.lib -> no issue!

1.20.1 released if you want to use it in TDM.....the dev has solved a good number of old and new  issues !

https://github.com/kcat/openal-soft/releases/tag/openal-soft-1.20.1

Edited January 26 by lowenz

[lowenz 584]

The lastest version(s) built from the source have the console and screen FPS space black. Totally black.

[lowenz 584]

On 1/24/2020 at 3:58 PM, duzenko said:

I think the problem with shadow geometry models is that

1. material 'textures/common/shadow' is marked as translucent and
2. translucent surfaces (e.g. glass and water) are excluded from shadow mapping

I would like to hear opinions on which point is problematic?

Now they seem fixed!

[duzenko 643]

@cabalistic

1. The last parameter here is in nanoseconds, right?

   		result = qglClientWaitSync( bufferLock[frame], GL_SYNC_FLUSH_COMMANDS_BIT, 1000000 );

   That amounts to 1 millisecond? Why so?

2. At game start this routine gets called twice on frame 0, causing a first sync object to leak.

static void LockGeoBufferSet( int frame ) {

3. What happens on wait timeout? Is it safe to delete the sync object when it has not signaled yet?

4. Any idea why wait always times out on Intel HD 2000 (other than driver bug)?

[cabalistic 656]

Hm, I don't remember the context right now, but I think the timeout should probably be longer, more like 1 second. Perhaps I made a mistake with the number, or someone accidentally changed it.

Nothing happens on wait timeout. The docs say it is safe to call glDeleteSync either way.

Try calling glFlush or even glFinish (just as an experiment, definitely don't commit that ) right before the wait. It may also be the case that the timeout is simply too short, as mentioned above. If it still times out even with glFinish, it is absolutely a driver bug.

[stgatilov 996]

32 minutes ago, duzenko said:

1. The last parameter here is in nanoseconds, right?That amounts to 1 millisecond? Why so?

3. What happens on wait timeout? Is it safe to delete the sync object when it has not signaled yet?

1 millisecond is way tooo small! It should be something like 500 ms, or otherwise there must be some proper handling for timeout

[cabalistic 656]

No, wait, this is happening within a loop. So small timeout is fine:

	while ( result != GL_ALREADY_SIGNALED && result != GL_CONDITION_SATISFIED ) {
		result = qglClientWaitSync( bufferLock[frame], GL_SYNC_FLUSH_COMMANDS_BIT, 1000000 );
		if ( result == GL_CONDITION_SATISFIED )	{ 
			backEnd.pc.waitedFor = 'S'; 
		}
		if ( result == GL_WAIT_FAILED ) {
			common->Warning( "glClientWaitSync failed.\n" );
			break;
		}
	}