Jump to content
The Dark Mod Forums

TDM Engine Development Page


Recommended Posts

  • Replies 1.1k
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Video #1 is up. I'll add the second one to this post in about half an hour.   http://youtu.be/iumyzCicOzM   Note to self: I really must learn to put a proper light or two in even if it's only a test m

Good news, this works out better all round.   The 2.02 release shader (that doesn't have the extra colours) uses far fewer samples than the one I was adapting above, so I've put in the extra sample to

Yes it can be fixed using currentDepth but as expected it creates a slightly calm area round the object:     Although that's probably better than the distortion.

Posted Images

I could use some advise on getting around the renderCrops problem ^_^ though fhDoom scales them in the exact same spot so i guess it wont be easy.

Not giving up i was close to having something at a point but it broke other parts of the framebuffer code like we saw with msaa etc.

 

atm i changed it to this ->

	renderCrops[0].x = 0;
	renderCrops[0].y = 0;

	FB_Resize( reinterpret_cast<GLuint *>( &windowWidth ), reinterpret_cast<GLuint *>( &windowHeight ), r_fboResolution.GetFloat() ); // duzenko #4425: allow virtual resolution
	
	renderCrops[0].width = windowWidth;
	renderCrops[0].height = windowHeight;

which works but is still located in the backend, and so is not much of an improvement.

I tried a simple solution like this

	// update screen resolution on scaling
	if ( renderSystem->GetScreenWidth() != renderWidth ) {
		glConfig.vidWidth  = renderWidth;
	}

	if ( renderSystem->GetScreenHeight() != renderHeight ) {
		glConfig.vidHeight = renderHeight;
	}

unfortunatly this crashes pbo's, so i guess ill have to isolate it.

  • Like 1
Link to post
Share on other sites

Oh spew i finally nailed it, and simple at that.

void FB_Resize( GLuint *width, GLuint *height, GLfloat scale ) {

	// make sure we can contain these resolutions
	if( *width > static_cast<GLuint>( glConfig.maxRenderbufferSize ) )	{
		common->Error( "FB_Resize: bad width %i", width );
	}

	if( *height > static_cast<GLuint>( glConfig.maxRenderbufferSize ) ) {
		common->Error( "FB_Resize: bad height %i", height );
	}

	// update screen resolution if mode changes
    if ( r_mode.IsModified() ) {
        int w, h;
        if ( R_GetModeInfo( &w, &h, r_mode.GetInteger() ) ) {
            glConfig.vidWidth = w;
            glConfig.vidHeight = h;
        }
        r_mode.ClearModified();
    }

	// copy of screen resolution
    GLuint renderWidth = *width;
    GLuint renderHeight = *height;

	// will be 1 if not scaling
	renderWidth *= scale;
	renderHeight *= scale;

	// woot i finally fixed it Oo
	renderSystem->GetCurrentRenderCropSize( reinterpret_cast<int &>( renderWidth ), reinterpret_cast<int &>( renderHeight ) );
	renderWidth = (renderWidth + 3) & ~3; //opengl wants width padded to 4x

	// uploading possibly scaled resolution
	*width = renderWidth;
	*height = renderHeight;
}

it works now with no blurring pixelation crashes burning or resizing of the viewport :)

 

ill leave the one in RenderSystem.Cpp in but commented in case something turns up.

 

unfortunatly i had to make some typecasts because it does not like GLuint, but that is a small price to pay.

  • Like 1
Link to post
Share on other sites

Hmm the blurred view at lower r_fboresolution settings might not be a bug since we basically scale viewport resolution by a fraction when doing r_fboresolution 0.1 on the other hand it allmost kills my otherwise more than capable gfx card if i go over 2 but it looks crisp.

 

pbo's do not like renderCrops at all so i basically spent the last few hours getting around that, with some success (not enough though).

I guess the code for lightgems might be why since it allready uses renderCrops to get dimensions.

Link to post
Share on other sites

A nvidia only bug ? when was the last time i heard that :blink: loooong time ago.

Would be funny though seing as nvidia allways had an edge in the opengl department , but yah in real life things like that suck :blush:.

 

Im also banging my head on how to move the FBO resize out of BeginFrame cause renderCrops are frontend only it seems, atleast the codemap tells me so.

I been trying various workarounds some work better but break other things like shadows or depth render, some worse and result in a black screen.

 

the code for pixelbuffers basically screws me over on most of it, maybe because it divides width and height by r_fboresolution so that it does not scale with the framebuffer.

The best experiment so far had the view working allright but it scaled the screen to half size :o so i tried getting around that by multiplying the values by a factor 2 and then it crashes with wrong pbo size sigh.

Link to post
Share on other sites

You should go back through the history of Duzenko's "soft shadows" work.

 

He has Intel hardware so his implementations are heavy biased towards Intel features.

Nvidia was always breaking on every clever trick he tried to improve Intel performance.

 

So it seems that this is the way of things:

 

1) If you develop for Nvidia hardware, AMD and Intel drivers appear to be buggy

2) If you develop for Intel hardware, Nvidia drivers appear to be buggy

3) If you develop for AMD? ... It used to be Nvidia would be the problem. Not sure but I think it's Nvidia and Intel these days

 

so much for "OpenGL standards that work the same way everywhere" :P

 

(Don't even ask about Linux and "free drivers" MESA, etc. :D )

  • Like 2

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to post
Share on other sites

Most of it allready was, I did keep FB_Resize, but besides guarding against insane scaling like 16x FBO resolution and updating screen res on mode change it does the same now as the original code which was more or less just setting scales directly with a cvar.But ill check against 7705 to see if i missed something from hacking about on moving r_fboresolution out of BeginFrame. Funny enough it works great on my AMD card now :wacko: but if my changes affect nvidia then im sorry. i do have a laptop with an nvidia card but the harddrive is a pretty small first gen SSD so not a lot of space but ill try and run it from usb stick.

Link to post
Share on other sites

Most of it allready was, I did keep FB_Resize, but besides guarding against insane scaling like 16x FBO resolution and updating screen res on mode change it does the same now as the original code which was more or less just setting scales directly with a cvar.But ill check against 7705 to see if i missed something from hacking about on moving r_fboresolution out of BeginFrame. Funny enough it works great on my AMD card now :wacko: but if my changes affect nvidia then im sorry. i do have a laptop with an nvidia card but the harddrive is a pretty small first gen SSD so not a lot of space but ill try and run it from usb stick.

Great, then it shouldn't be a problem reverting the rest of it

Please understand that you have been doing a lot of unrelated changes in same commits. We need to back out of it gracefully to start moving forward.

Link to post
Share on other sites

Made a local copy of my changed version and reverted the code to 7704, 7705 had my initial code to FB_Resize. I then applied all your code changes upto 7707.

And miracle of miracles... it also works on my laptop with a nvidia card wtf is going on? :huh: stalled config or something.

Oh btw my laptop runs win10 but my main PC runs win7 and it works on both machines so it does not seem to be a windows thing, unless by chance you run linux ?.

 

Ill use my local copy to do further testing, and maybe get a hint from RBDoom about framebuffer scaling. It seems it does not use BeginFrame for any of that, so i might get some ideas to point me in the right direction.

  • Like 1
Link to post
Share on other sites

Made a local copy of my changed version and reverted the code to 7704, 7705 had my initial code to FB_Resize. I then applied all your code changes upto 7707.

And miracle of miracles... it also works on my laptop with a nvidia card wtf is going on? :huh: stalled config or something.

Oh btw my laptop runs win10 but my main PC runs win7 and it works on both machines so it does not seem to be a windows thing, unless by chance you run linux ?.

 

Ill use my local copy to do further testing, and maybe get a hint from RBDoom about framebuffer scaling. It seems it does not use BeginFrame for any of that, so i might get some ideas to point me in the right direction.

Do you have an account on github? I want to add you to my experiments repo at https://github.com/duzenko/darkmod-experiments

Then we can easily branch, merge, and test without spamming the svn history.

  • Like 1
Link to post
Share on other sites

Thanks for the reverts Revelator.

 

Update 11 at Moddb now:

 

https://www.moddb.com/mods/the-dark-mod/downloads/tdm-206-vertex-buffer-beta

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to post
Share on other sites

Geforce GTX 1050.

 

Probably something to do with Maxwell+ generations having built-in tiled rendering hardware.

This has caused all sorts of mayhem with depth tested scenarios because the data isn't there to test

due to tile culling.

  • Like 1

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to post
Share on other sites

Strange one indeed ^_^ after some thought it might have been my change to hardware PCF that caused this then since it was a pretty old but by then working example.

Easy test would be to just uncomment

 

qglTexParameteri( GL_TEXTURE_CUBE_MAP, GL_TEXTURE_COMPARE_MODE, GL_COMPARE_REF_TO_TEXTURE ); in CheckCreateShadow and see if shadowmaps go bad again.

i used GL_COMPARE_R_TO_TEXTURE instead of GL_COMPARE_REF_TO_TEXTURE though since the code was set up that way in my working example.

  • Like 1
Link to post
Share on other sites

Got an old account there, probably better that way since we could provide test executables for people with different hardware to try out.

Would save us a lot of grief.

 

shall i PM you the details ?.

 

And no problem nbohr,does it work again for you now ?.

I'll need your github user name
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...