Jump to content

revelator

Development Role
 View Profile  See their activity

  • Posts

    1529

  • Joined

  • Last visited

  • Days Won

    26

 Content Type 

Posts posted by revelator

  1. TDM Engine Development Page

    in The Dark Mod

    Posted

    Changes with no use would be counter productive i agree on that :) the goal was not so much speeding anything up, but rather to compartialize the code making it easier for other devs with no previous history coding in C to just jump in and make fixes. Im sorry if im not allways clear, english is not my main language.

     

    What i wanted to achive was something similar to cabalistics plans for gl3/4, i just started in the framebuffer code because it was allmost pure C, but eventually i want to make the entire renderer class based like he would.

     

    So it seems we had the same idea, i just came in a bit to late. But when the time comes then i would not mind in helping getting it together :).

     

    So what are the most WIP problems atm ?, please nothing in regards to shaders, im not profient enough with those yet.

  3. TDM Engine Development Page

    in The Dark Mod

    Posted

    Rewriting the entire renderer with classes might be next step, but it will be a big ammount of work.

    The goal for me was simplifying the code a bit, i did not expect any gains speedwise at all, but strangely that was what i got. Need to investigate that one.

     

    Reducing the state changes would have been a more likely candidate for a speedup, but that part was not even in when i tested it the first time around.

  6. TDM Engine Development Page

    in The Dark Mod

    Posted

    So the AA problems have been fixed ?, ok thats nice :)

     

    Tested my version of the class based FBO code, it works just like the unmodified version, no visible change besides faster loading.

    I made some of the functions private because they are not used outside the FBO code.

    I also moved the static initializers to a constructor but kept the destructor as a seperate function for now.

     

    So far i tried 10 maps with different shadow options and i see no visible difference, from the unmodified one.

    I dont mind posting a test executable you can try if you want.

  7. TDM Engine Development Page

    in The Dark Mod

    Posted

    I made an experiment and converted the fbo code to C++ classes.

    I have not upped this experiment to svn so no worries i wanted to discuss it first.

     

    Theres a good reason why we might want this, for one automatic constructors / destructors, and we could simplify the code a good deal.

     

    Speedwise i had not anticipated any gain but strangely enough it actually loads faster now, go figure... :huh:

     

    I can upload the changed code somewhere if you want to toy with it before deciding.

  8. TDM Engine Development Page

    in The Dark Mod

    Posted

    FXAA can be used from the old ARB shaders also, so that would not be a problem.

    Speedwise its not noticable atleast for me with sikkmod, but less capable gfx cards might take a bigger hit.

     

    seems AA and FBO does not play super well together from what i can gather around the net, though it should be possible to fix it.

    All comes down to the ammount of code needed to get there :)

  10. TDM Engine Development Page

    in The Dark Mod

    Posted

    Hmm strange that the bugged models only seem to affect one type of model :huh: 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 :laugh: and while that might look funny im certain that was not the intention.

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

    • Like 1

  12. TDM Engine Development Page

    in The Dark Mod

    Posted 

    /*
================
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.

    • Like 1

  19. TDM Engine Development Page

    in The Dark Mod

    Posted

    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.

  23. TDM Engine Development Page

    in The Dark Mod

    Posted

    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.

  24. TDM Engine Development Page

    in The Dark Mod

    Posted

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

×
×
  • Create New...