Jump to content
The Dark Mod Forums
Sign in to follow this  
cabalistic

Testers and reviewers wanted: BFG-style vertex cache

Recommended Posts

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.

Share this post


Link to post
Share on other sites

"A new Job" - first 2 guards encountered

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


Task is not so much to see what no one has yet seen but to think what nobody has yet thought about that which everybody see. - E.S.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites

getviewWHAT? :D


Task is not so much to see what no one has yet seen but to think what nobody has yet thought about that which everybody see. - E.S.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

Yes, those 2 !


Task is not so much to see what no one has yet seen but to think what nobody has yet thought about that which everybody see. - E.S.

Share this post


Link to post
Share on other sites
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 by lowenz
  • Like 2

Task is not so much to see what no one has yet seen but to think what nobody has yet thought about that which everybody see. - E.S.

Share this post


Link to post
Share on other sites

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


Task is not so much to see what no one has yet seen but to think what nobody has yet thought about that which everybody see. - E.S.

Share this post


Link to post
Share on other sites
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!


Task is not so much to see what no one has yet seen but to think what nobody has yet thought about that which everybody see. - E.S.

Share this post


Link to post
Share on other sites

@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)?

Share this post


Link to post
Share on other sites

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 :D ) 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.

Share this post


Link to post
Share on other sites
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 😞

Share this post


Link to post
Share on other sites

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

 

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...