Jump to content
The Dark Mod Forums

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.

Link to post
Share on other sites
  • Replies 538
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

As part of my work on a VR port, I have been spending some time looking at the Doom3 BFG edition code for opportunities to improve performance. A core concept in BFG is a vastly different vertex cache

Nothing significant. I cleaned up a few things in code, but apart from that the latest executable is still state-of-the-art   Far as I can tell, it runs pretty stable now, so from my side it could be

Update 11 is up at Moddb:   https://www.moddb.com/mods/the-dark-mod/downloads/tdm-206-vertex-buffer-beta       (Too changes many to remember!)   Grayman fixed a few AI pathfinding issues and door hand

Posted Images

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

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?

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.

Link to post
Share on other sites
  • 1 month later...

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.

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.

Link to post
Share on other sites
  • 2 weeks later...

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

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.

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 😞

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


×
×
  • Create New...