Testers and reviewers wanted: BFG-style vertex cache

[duzenko]

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]

"A new Job" - first 2 guards encountered

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

[duzenko]

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]

getviewWHAT?

[duzenko]

3 minutes ago, lowenz said:

getviewWHAT?

These two?

[duzenko]

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]

Yes, those 2 !

[lowenz]

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, 2020 by lowenz

[lowenz]

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

[lowenz]

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]

@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]

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]

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]

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;
		}
	}

 

[duzenko]

I think we need to allow a fixed initial buffer size, static data included

Cards with little VRAM (e.g. 1GB) tend to end up with the VBO in the system RAM because it the VRAM is already filled with textures at the time of resize

[stgatilov]

26 minutes ago, duzenko said:

I think we need to allow a fixed initial buffer size, static data included

Cards with little VRAM (e.g. 1GB) tend to end up with the VBO in the system RAM because it the VRAM is already filled with textures at the time of resize

I believe there are cvars for that.

Also, static data is now stored in a separate VBO again: 5598