TDM Engine Development Page

[revelator]

Neato

[duzenko]

@revelator
1. Can you tell me about your problem 7641 was supposed to fix?
2. Do you understand that unnecessary, meaningless changes cause a lot of extra work for other people when it comes to branch merging? I'm talking about explicit variable initializtion here

GLuint fboPrimary = 0, fboResolve = 0, fboShadow = 0, fboPostProcess = 0, fboCurrent = 0, pbo = 0;
GLuint renderBufferColor = 0, renderBufferDepthStencil = 0, renderBufferPostProcess = 0;

I have been trying to keep my multi-light project out of trunk but with this daily re-formatting, reverting, re-reverting craze it's just not practical any more.

I'm going to fix the merges myself and commit everything back to trunk.

[revelator]

It was an attempt to fix softshadows because i misunderstood your intention with r_softshadowsquality,

i had the impression that the negative values mentioned might have been accidentally fed to the scissor and or viewport,

so i made sure that this could not happen. Then you fixed it yourself and i noticed i was on the wrong track.

 

The explicit variable initialization started as an attempt at getting rid of the ? vid_restart if mapping failed, guess i went a little overboard on that one sorry.

 

multi-light ? sounds interresting, what is the effect ?.

[revelator]

And it was not my intention to make your lifes harder, just with the initial problems with code that went poof, formatting problems and me trying to revert everything back,

i probably ended up changing more than was nessesary.

Appologies for that, guess with me being away for so long i had a hard time catching up to all the changes.

[duzenko]

Sorry if I sounded too harsh. Don't want to offend fellow coders or cause any tension.

It's just that I have received tons of explicit and implicit suggestions not to commit unfinished stuff to trunk. The first time I try to work in a branch, it's starting to merge conflict on the daily basis because of formatting changes or initialization of variables that make no difference at all.

 

The negative scissor check is absolutely not related to the negative SS quality cvar. It's a bug in front renderer. It's making no sense to change sign of negative scissor width/height once they already come negative from the front end. I think you should revert that and ask in the PM next time.

[duzenko]

 

multi-light ? sounds interresting, what is the effect ?.

http://forums.thedarkmod.com/topic/19594-multi-light-interaction-shader/

[revelator]

No worries im just a bit old school, eg. not used to working in a multi dev environment, and i understand those gripes completely.

And aye the SS bug had nothing to do with that as i found out after your update, ill revert the commit in a minute.

[revelator]

Ok done.

And that multilight idea sounds pretty good fillrate could indeed use some help.

[nbohr1more]

? why does lighting only work with shadow mapping enabled (r_shadows 2) now??

[revelator]

works with both values here, but i need to do a vid_restart after changing r_shadows.

[duzenko]

? why does lighting only work with shadow mapping enabled (r_shadows 2) now??

Sorry, my bad.

7647 should fix that.

[nbohr1more]

Thank you.

[revelator]

The idea with avoiding negative values in scissor atleast was not totally far fetched, fhdoom does something similar, but i also went a bit overboard on that one cause i assumed no value there could be negative.

but as i found out x and y can actually be negative, but width and height must not be.

Question would then be should we care ? because if that happens we would allready have other problems down the line.

[duzenko]

The idea with avoiding negative values in scissor atleast was not totally far fetched, fhdoom does something similar, but i also went a bit overboard on that one cause i assumed no value there could be negative.

but as i found out x and y can actually be negative, but width and height must not be.

Question would then be should we care ? because if that happens we would allready have other problems down the line.

Yes we should care because it's a bug and it must be fixed

[revelator]

Ok then, should i make the nessesary changes ?

[revelator]

Had to ask because id did not check for it originally, but better safe than sorry.

[duzenko]

Ok then, should i make the nessesary changes ?

First you need to find a scene where you reliably repeat negative scissorRect

[revelator]

Hopefully there should be none, so it will be quite a chase to get one if that is the case ,

i guess one way of going about that would be to insert an assert checking for negative scissorRect and then running the debug executable to see where it happened ?.

[revelator]

Well that was fast Oo, first map i ran triggered it (crucible of omens) just after exiting the room you start in.

[revelator]

Hmm interresting effect if we prevent negative width and height from entering scissorRect it works but if doing the same for viewport some models get there parts cut off, undead revenants for one looses half their head lol.

[revelator]

Hmm spoke to soon, this seems to be a bug in the map i was playing, it also does it without preventing passing negative values to either scissorRect or viewRect (alberics curse).

[revelator]

/*
================
Sys_SetHighDPIMode

code that tells windows we're High DPI aware so it doesn't scale our windows
================
*/
typedef enum D3_PROCESS_DPI_AWARENESS {
	D3_PROCESS_DPI_UNAWARE = 0,
	D3_PROCESS_SYSTEM_DPI_AWARE = 1,
	D3_PROCESS_PER_MONITOR_DPI_AWARE = 2
} YD3_PROCESS_DPI_AWARENESS;

static void Sys_SetHighDPIMode( void ) {
	/* For Vista, Win7 and Win8 */
	BOOL( WINAPI * SetProcessDPIAware )( void ) = NULL;
	/* Win8.1 and later */
	HRESULT( WINAPI * SetProcessDpiAwareness )( D3_PROCESS_DPI_AWARENESS dpiAwareness ) = NULL;
	HINSTANCE userDLL = LoadLibrary( "USER32.DLL" );
	if ( userDLL ) {
		SetProcessDPIAware = ( BOOL( WINAPI * )( void ) ) GetProcAddress( userDLL, "SetProcessDPIAware" );
	}
	HINSTANCE shcoreDLL = LoadLibrary( "SHCORE.DLL" );
	if ( shcoreDLL ) {
		SetProcessDpiAwareness = ( HRESULT( WINAPI * )( YD3_PROCESS_DPI_AWARENESS ) )
			GetProcAddress( shcoreDLL, "SetProcessDpiAwareness" );
	}
	if ( SetProcessDpiAwareness ) {
		SetProcessDpiAwareness( D3_PROCESS_PER_MONITOR_DPI_AWARE );
	} else if ( SetProcessDPIAware ) {
		SetProcessDPIAware();
	}
}

Btw found this in a recent dhewm3 commit, might be of use to us also ?, it tells windows to avoid applying scaling on high dpi panels.

 

call in WinMain just before Sys_SetPhysicalWorkMemory.

[duzenko]

/*
================
Sys_SetHighDPIMode

code that tells windows we're High DPI aware so it doesn't scale our windows
================
*/
typedef enum D3_PROCESS_DPI_AWARENESS {
	D3_PROCESS_DPI_UNAWARE = 0,
	D3_PROCESS_SYSTEM_DPI_AWARE = 1,
	D3_PROCESS_PER_MONITOR_DPI_AWARE = 2
} YD3_PROCESS_DPI_AWARENESS;

static void Sys_SetHighDPIMode( void ) {
	/* For Vista, Win7 and Win8 */
	BOOL( WINAPI * SetProcessDPIAware )( void ) = NULL;
	/* Win8.1 and later */
	HRESULT( WINAPI * SetProcessDpiAwareness )( D3_PROCESS_DPI_AWARENESS dpiAwareness ) = NULL;
	HINSTANCE userDLL = LoadLibrary( "USER32.DLL" );
	if ( userDLL ) {
		SetProcessDPIAware = ( BOOL( WINAPI * )( void ) ) GetProcAddress( userDLL, "SetProcessDPIAware" );
	}
	HINSTANCE shcoreDLL = LoadLibrary( "SHCORE.DLL" );
	if ( shcoreDLL ) {
		SetProcessDpiAwareness = ( HRESULT( WINAPI * )( YD3_PROCESS_DPI_AWARENESS ) )
			GetProcAddress( shcoreDLL, "SetProcessDpiAwareness" );
	}
	if ( SetProcessDpiAwareness ) {
		SetProcessDpiAwareness( D3_PROCESS_PER_MONITOR_DPI_AWARE );
	} else if ( SetProcessDPIAware ) {
		SetProcessDPIAware();
	}
}

Btw found this in a recent dhewm3 commit, might be of use to us also ?, it tells windows to avoid applying scaling on high dpi panels.

 

call in WinMain just before Sys_SetPhysicalWorkMemory.

 

Done 2 years ago

[revelator]

Oh had not noticed, ok then this is moot.

[revelator]

Hmm strange that the bugged models only seem to affect one type of model kinda looks like a failed depthhack gets applied, weird though this is the only mod where i noticed this behaviour.

if looking up the undead revenants get there heads cut off and while that might look funny im certain that was not the intention.

Strangely the ghost models in the same place are not affected.