optimized builds for you

hi guys yesterday I came here to give you this:
* dedicated, API-specific DLLs
* full global compiler optimizations, including LTO
* ASMlib by Agner Fog: hand-written assembly common standard library functions replacement
up to 10 times faster than microsoft compiler, significantly faster than even intel's C++ compiler
* increased security: all builds use /SDL and /Guard compiler flags
* CPU instruction-set specific DLLs
* around half of external DLL dependencies gone (wininet, ws32, gdi32, shell32...the list goes on)
* added experimental untested Windows XP builds (for One-Core-API + WineD3D)
* engine-only without GUI builds included
www.mediafire.com/folder/0k6sx3irz86xr,9ghrbrj98r6hx/shared

but my account was disabled and post removed, twice, wtf ?!

This was flagged multiple times by the anti-spam system.

If you feel like there is something that should be optimized, feel free to make a pull request. Putting up links to unknown DLLs is not coming along as trustworthy.

that's not going to be a problem, I can give the source to all the modifications
hang on I am uploading the source to the mediafire
there are no real code modifications, I leave that to you
it's just properly compiled versions
p.s. might not be the best idea to let a computer bot decide for you what is and is not trust-worthy

As someone who used to fiddle with compiler flags on various programs under Linux (particularly encoding tools), and for which significant performance improvements could sometimes be achieved depending on what the program was doing, this is certainly interesting

@dod -- thanks for doing this but Crosire is right, it will be hard for people to trust these from a third party source. However, it might be good if you listed the compiler options or flags you used so Crosire can test for himself. Also -- it's just me -- but I actually prefer one DLL for all APIs, as it makes it easier to install for games without fart-arsing round with different DLLs (if you feel like making one for all APIs).

@crosire -- could these make a difference for Reshade, or is it all depending on the GPU executing shaders? These specifically:

• full global compiler optimizations, including LTO
• ASMlib by Agner Fog: hand-written assembly common standard library functions replacement
  up to 10 times faster than microsoft compiler, significantly faster than even intel's C++ compiler
• increased security: all builds use /SDL and /Guard compiler flags
• CPU instruction-set specific DLLs

Sound promising? (although the instruction-set DLLs, unless it makes a noticeable difference, would be a hassle to manage and educate people on which ones could be used).

I don't want to discourage anybody from experimenting with ReShade. So please don't misinterpret my quick answers as being meant in a negative way (they are not). Anyway, my opinion on a few of these points:

* dedicated, API-specific DLLs

This should have no performance impact apart from some initial disk activity for loading a larger DLL and the set up for the hooks (all payed once on startup).

* full global compiler optimizations, including LTO

This is already done for the published release builds.

* ASMlib by Agner Fog: hand-written assembly common standard library functions replacementup to 10 times faster than microsoft compiler, significantly faster than even intel's C++ compiler

I don't doubt this can help a little, but ReShade calls almost none of the C STD library functions, so I'm not convinced this is noticable.

* increased security: all builds use /SDL and /Guard compiler flags

ReShade is compiled with /sdl. ReShade is not compiled with /guard, since there is no reason to pay for additional security checks (no important data goes through ReShade).

* CPU instruction-set specific DLLs

There is little SSE in ReShade, which is the primary reason you'd want this. I don't think this will make a difference.

* around half of external DLL dependencies gone (wininet, ws32, gdi32, shell32...the list goes on)

The linker will automatically remove dependencies that are not referenced (You can verify this with Dependency Walker)
ReShade currently makes explicit use of wininet.dll and gdi32.dll though, so I'm curious on how you got rid of those.

* added experimental untested Windows XP builds (for One-Core-API + WineD3D)

ReShade doesn't support Windows XP for reasons other than it was build without those build options in MSVC. It uses Win32 API features that were introduced in Windows Vista, so it will simply fail to launch on Windows XP regardless.

* engine-only without GUI builds included

I see somebody found the "RESHADE_GUI" preprocessor definition I added as an experiment not long ago

crosire wrote: This was flagged multiple times by the anti-spam system.

Also, sorry about that. But you wouldn't believe how much spam this site gets every day. So I'm very happy to have most of it rejected automatically without having to go through every post. Sometimes it has false positives, sometimes it has false negatives, but it's better than nothing.

the source is up on the mediafire take a look
it the true: performance is not really increased over the original from the statistics tab shows that it's actually slower (on Intel by less than on AMD), maybe the security reduce so many performance ? on my phenom 2 it slower by 0.03 ms from the original, on my haswell it's slower by 0.01, it should be much faster than original considering all the optimizations used