Steam Overlay & VirtualResolution Issue

BlitzMax Forums/BlitzMax Programming/Steam Overlay & VirtualResolution Issue

therevills(Posted 2016) [#1]
Hi All,

When running the following code as a non-Steam game with the Steam Overlay I get graphics issues:



Does anyone know why or suggest a fix?

I can fix it by overloading the Cls call, but this hurts performance:


If I use the DX11 driver I get a slightly different issue, the "cropped" section goes blue instead of black and if I go between the drivers I lose the oval which is following the mouse:



Thanks,
Steve


col(Posted 2016) [#2]
Hiya Steve,

I've corrected a bug in the d3d11 code thats related to the blue oval issue. I'll look into the borders over the weekend.

There appears to be some minor bugs in the NG version when using this test code. It'll help me track those down too.

Whats the graphics issue that you're getting with the other drivers? I don't see anything obvious here.


therevills(Posted 2016) [#3]
Thanks for looking :)

Whats the graphics issue that you're getting with the other drivers? I don't see anything obvious here.


Did you add the exe to Steam? When showing/hiding the Steam Overlay, the OpenGL driver has graphics corruption and the DX9/DX11 has similar border issues. With DX9 the images outside the virtual res are still displayed.

OpenGL just after hiding Steam Overlay:


DX9 before Steam Overlay:

DX9 after Steam Overlay (notice you can see the full oval even thought its at zero):



dw817(Posted 2016) [#4]
Therevills, don't forget everyone is using a different resolution. If you are writing absolute pixel coordinates and elements to hide the background of ads for whatever reason, it may not work - or even get worse results on some platforms.

As for me in my 1024x768 screen, ran just fine. :)


therevills(Posted 2016) [#5]
don't forget everyone is using a different resolution


That's why I use a virtual resolution and it works perfect, but for Steam I have this small issue with the Steam Overlay.


grable(Posted 2016) [#6]
You can sortof detect the overlay by loading GameOverlayRenderer.dll and calling some of the functions in it.
And through that know when to overload Cls. Its more of a quick fix though, as it should work.


Doing this will also load the steam overlay without having to run it through steam, as the dll does the hooking when its loaded.
It doesnt work with D3D9 unless running it through steam for some reason.

EDIT:
Even though it loads the overlay this way, it will not notify steam about it. But the overlay is still usable.
And using the SteamOverlayIsUsingXXX() isnt perfect, my tests show it doesnt work correctly with OpenGL as they allways return True.

Its too bad they havent added more functions to control the overlay really, like an IsOverlayActive() or ShowOverlay().
One has to resort to reversing it and hooking huge and confusing object hierarchies to able to do anything like that, and they have a tendency to change things in updates and then having to re-reverse everything :(


col(Posted 2016) [#7]
If I use the DX11 driver I get a slightly different issue, the "cropped" section goes blue instead of black and if I go between the drivers I lose the oval which is following the mouse:


The oval and alt-tab issues were bugs and should now be fixed.
The cropped vertical bars... hmm... MSDN states the full size of the back buffer will be cleared to the colour specified, ie the ClsColor and the viewport/scissor settings for the rasterizer will be ignored. Why that did that I shall never know. Dx9 and OpenGL take those viewport and scissor settings into consideration. I have a possible solution for this.

The Steam overlay is another issue.


col(Posted 2016) [#8]
Does anyone know why?

Steam is changing the scissor rectangle settings for the gpu, and not resetting them to what they were before it changed them. I guess you could blame Steam for this.

In your example that includes Dx11 if you replace from Line 461 with these couple of lines you can see it changing for Dx9 when the Steam overlays come in.

[edit]use this example[/edit]


For me pressing Enter to invoke the ratio change fixes it. Now to find a sensible solution...


therevills(Posted 2016) [#9]
@grable - thanks for trying :)

Nice find and I would love to blame Steam, but need to find a better fix than my overloaded CLS :)

In your code what is "g"? I tried Local g:TGraphicsDriver = GetGraphicsDriver(), but it still didnt compile.

Cheers,
Steve

[edit: found it... g is Global g:TGraphics :) ]


col(Posted 2016) [#10]
I just thought of 'g' and no one would know so I've changed the code in my post to the complete working example :D


therevills(Posted 2016) [#11]
Thanks Dave - okay on my machine before Steam Overlay is displayed:

Viewport X: 69
Viewport Y: 0
Viewport W: 569
Viewport H: 400

After Steam Overlay:

Viewport X: 0
Viewport Y: 0
Viewport W: 640
Viewport H: 400

Do you know what the equivalent for DX11 and OpenGL for IDirect3DDevice9?
	Local gd3d:TD3D11Graphics = TD3D11Graphics(TMax2dGraphics(g)._graphics)
	Local d3ddev:IDirect3DDevice11 = gd3d.GetDirect3DDevice()


Cheers,
Steve


therevills(Posted 2016) [#12]
Just thought of a really simple (hack) solution for DX9 and DX11... draw black rects outside the virtual resolution, not perfect but should be faster than my overloaded CLS.

Doesnt work for OpenGL though...


col(Posted 2016) [#13]
D3D11 would be

Local gd3d:TD3D11Graphics = TD3D11Graphics(TMax2dGraphics(g)._graphics)
		Local d3ddev:ID3D11DeviceContext = gd3d.GetDirect3DDeviceContext()
		Local rect:Int[4]
		Local count:Int
		d3ddev.RSGetScissorRects(count,Null)
		d3ddev.RSGetScissorRects(count,rect)

		DrawText "Viewport X: " + rect[0],20,300
		DrawText "Viewport Y: " + rect[1],20,340
		DrawText "Viewport W: " + rect[2],20,380
		DrawText "Viewport H: " + rect[3],20,420


Just thought of a really simple (hack)

Do you have that working already?


therevills(Posted 2016) [#14]
D3D11 would be


Ah, quite different... Ta :)

DX11 without Steam:

Viewport X: 0
Viewport Y: 0
Viewport W: 640
Viewport H: 400

Do you have that working already?

Not yet, been out shopping ;)


therevills(Posted 2016) [#15]
Been testing with DX7 as well, it has the same issue as OpenGL, so I draw black rects for DX9 and DX11, but still do my CLS overload for OpenGL and DX7. Which means slow downs for OpenGL and DX7 :(



Also found out that DX7 seems to be locked at 30FPS in fullscreen mode!? (On Windows 8.1 at least...)

Cheers,
Steve


col(Posted 2016) [#16]
Hey Steve,

On Windows 7 and 10 I'm getting the correct black vertical borders for all the drivers before and after showing the Steam overlay [edit]but then I would as you have put a 'fix' in there :D I get the same as you for Dx7 and Ogl[/edit].

All are @60fps.

Window7 pro GTX750
Window10 home GT650m

Both systems have the latest drivers.


therevills(Posted 2016) [#17]
Thanks for testing Dave :)

Any idea what is going on with DX7 and OGL?

Cheers,
Steve


col(Posted 2016) [#18]
I guess you could comment out the code in the SetViewport methods for the OpenGL and D3D7 Max2DDrivers. You'll need to keep the method just comment out the code. In the D3D7Max2DDriver.SetViewport method I think you'll need to keep the vp_rect=[x,y,x+width,y+height] line as it's used elsewhere, then you will need to use your 'blackbar' function.

I'm not sure if this would break other peoples code though.

The fix I had in mind was to setup some black bar parameters when you setup the viewport via SetViewport. Then in the Flip method call some code to actually draw the black bars if they are needed. You may be able to use your existing code in the SetViewport methods? I've not written or tested any of this - just ideas.


therevills(Posted 2016) [#19]
Thanks again Dave - I'll have a go at removing the code out of SetViewport tonight :)

(Any ETA regarding the Alt-Tab bug for DX11?)

Cheers,
Steve


therevills(Posted 2016) [#20]
Sorry for the late reply, RL got in the way...

Just tested commenting out the code in OpenGL and D3D7, looks good in the test app, of course I need to draw the black border now for all drivers but I can live with that :)

Now just that alt-tab issue for DX11...