TDM Engine Development Page

[duzenko 643]

So what are your plans with r_fboResolution? Have you given up? Do you need some advice to go through?

[revelator 239]

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.

[duzenko 643]

I could use some advise on getting around the renderCrops problem

Look what render crops are used for on the front end and where they are used on the backend.

[revelator 239]

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.

[revelator 239]

Oh wait a sec, it breaks shadows guess it was not that simeple after all.

[161803398874989 81]

Oh wait a sec, it breaks shadows guess it was not that simeple after all.

When is it ever

[revelator 239]

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.

[nbohr1more 2047]

Shadow maps still fail to render as of rev 7714.

 

Do you have access to Nvidia hardware to debug?

[Bikerdude 3739]

I have some old Nvidia cards if required.

[revelator 239]

A nvidia only bug ? when was the last time i heard that 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 .

 

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 so i tried getting around that by multiplying the values by a factor 2 and then it crashes with wrong pbo size sigh.

[nbohr1more 2047]

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"

 

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

[duzenko 643]

@revelator

Do you mind reverting all your commits starting with 7705 and doing your staff in a separate branch until you sort it out?

[revelator 239]

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

[duzenko 643]

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

[revelator 239]

Ok ill look into it, but if it works on my laptop i would start to wonder

[revelator 239]

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

[duzenko 643]

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

[nbohr1more 2047]

Thanks for the reverts Revelator.

 

Update 11 at Moddb now:

 

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

[revelator 239]

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

[nbohr1more 2047]

Yes. Shadow Maps work again.

 

Thank you.

[revelator 239]

what nvidia card do you have ?, my laptop has an hybrid intel nvidia 840m and for me it worked on both my r9 390 and that one.

[nbohr1more 2047]

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.

[revelator 239]

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.

[duzenko 643]

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

[revelator 239]

PM sent