Pcsx2: Regression after build 2795: Visual C++ Runtime error when choosing DX11

[auranticus]

PCSX2 version:
v1.5.0-dev-3121

PCSX2 options:
Default

Plugins used:
Default, GSdx: DirectX 11 renderer

Description of the issue:

Using DirectX renderer causes Visual C++ Runtime error, OpenGL is fine

Edit: installing Windows on drive other than C:\ caused this error

How to reproduce the issue:

1. Choose DirectX 11 renderer in GSdx plugin menu  
2. Boot game/BIOS  
3. Voila! C++ Runtime error!

Last known version to work:
v1.5.0-dev-2795

PC specifications:

Windows 10  
Intel i5-7200U  
Intel HD Graphics 620 version 26.20.100.6709 (4/18/2019)

Note: I installed Microsoft Visual C++ Redistributable 2015 - 2019, latest DirectX version.
DirectX dialog:

[lightningterror]

This shouldn't be an issue if the redistributables are installed, can you confirm that 2807 is broken and 2795 fine?

[auranticus]

This shouldn't be an issue if the redistributables are installed, can you confirm that 2807 is broken and 2795 fine?

Yes, I'm sure. GSdx32 dlls in dev-2795 works, while newer ones cause this error, starting from 2807 (2796-2806 is unavailable to download)

Edit title: oops, wrong version

[lightningterror]

Ok few things to try, see if you can narrow down which dll works from these and which is broken.

2806
GSdx32-AVX2.zip

2803
GSdx32-AVX2.zip

2802
GSdx32-AVX2.zip

2801
GSdx32-AVX2.zip

2800
GSdx32-AVX2.zip

2799
GSdx32-AVX2.zip

2798
GSdx32-AVX2.zip

2797
GSdx32-AVX2.zip

2796
GSdx32-AVX2.zip

[gregory38]

Seem like an uncatched exception

[auranticus]

Hey @lightningterror is SSE4 the same as AVX2?

[tadanokojin]

Not exactly the same but your CPU supports AVX2 so you should prefer to use it over SSE4.

[auranticus]

OK. From what I heard that AVX2 performs better for Software, but I prefer Hardware. Well, never mind.

I have tried and it's 2799 that caused the problem. AVX2 and SSE4 both produced the same error FYI.

[tadanokojin]

https://github.com/PCSX2/pcsx2/commit/5e75a66f82b828595c65b0a51bdce5e83f6e7374

Unfortunately nothing sticks out to me. I have HD 630 and Win10 and no issues here.
Could be an Intel bug maybe?

@gregory38 yes, uncaught exception I think, maybe from DX api. Any thoughts?

[gregory38]

There is an error of freetype face in log. Is it related to gl only or did you use it for dx ?

[tadanokojin]

We use it in DX, hmm. Maybe GL handle it a bit more gracefully.

@windyboy1704 curious did you use a clean GSdx ini for each test? it sounds like you override the font face with a font that doesn't exist or your system misses C:\\Windows\\Fonts\\tahoma.ttf

[gregory38]

I'm not sure dx can throw. Could be from new but unlikely. Ormaybe us if we can't create texture

[auranticus]

@gregory38

There is an error of freetype face in log. Is it related to gl only or did you use it for dx ?

You mean "Failed to init the freetype face"? It's happen on both renderers, but OpenGL is fine.

@tadanokojin

We use it in DX, hmm. Maybe GL handle it a bit more gracefully.

@windyboy1704 curious did you use a clean GSdx ini for each test? it sounds like you override the font face with a font that doesn't exist or your system misses C:\\Windows\\Fonts\\tahoma.ttf

I tried clean install of it, same error on latest dev version. C:\\Windows\\Fonts\\tahoma.ttf where do I suppose to put this in the ini? And by the way I installed my Windows on drive E:\ - is this the factor (guess not since build dev-2795 works fine)?

[tadanokojin]

And by the way I installed my Windows on drive E:\

This is why
add a line in your gsdx.ini

osd_fontname=E:\\Windows\\Fonts\\tahoma.ttf (assuming it's installed E:\Windows
should stop the crash

[auranticus]

@tadanokojin oh wow, it worked! So that means "Failed to init the freetype face" will cause C++ runtime error when using DirectX, but not OpenGL. Thank you.
And I wonder why this error happens when I don't put osd_fontname=E:\\Windows\\Fonts\\tahoma.ttf in the ini? Is it trying to look that font in default drive C:\? Can you guys think a workaround for this (because just like me some people don't install Windows on C:\)

[tadanokojin]

Yeah we default check to C:\. We should really use a Windows system call to find the windows drive. Thankfully @gregory38 suggested to me I keep the override in the ini.

[auranticus]

So instead of using C:\, why not use %systemroot%\Fonts? (is using %systemroot% possible)

[tadanokojin]

No I don't think so. %systemroot% would just be taken literally by the library we use.
needs something like
https://docs.microsoft.com/en-us/windows/desktop/api/sysinfoapi/nf-sysinfoapi-getwindowsdirectorya

And maybe more graceful handling if a font isn't found.

[KrossX]

It could be set differently than its default %windir%\Fonts location. You use SHGetFolderPath with CSIDL_FONTS parameter to get it. MSDN SHGetFolderPath

Another option is to ditch all that and just embed some nice awesome font. For example: The Ultimate Oldschool PC Font Pack

[tadanokojin]

Ah yes, that seems more proper.

To be honest embedded font seems like a nice idea. Consistent across platforms and we will avoid this mess on Linux too (donno if current hard coded font path can be relied on).

[gregory38]

Yes embedded is nice (can't change the font) but avoid a bad path