FS hack fixes for Descent 3

[Frogging101]

A couple of fixes which allow Descent 3's OpenGL renderer to work with the fullscreen hack.

    fshack: Always allocate a depth buffer
    
    Some applications use depth testing but leave the image format depth
    component set to 0. OpenGL drivers always provide a depth buffer for
    framebuffers regardless of whether the image format specifies one, so the
    FS hack texture should too, otherwise such applications will render
    incorrectly.

    fshack: Use texture name hack for Descent 3
    
    Descent 3's OpenGL renderer will use a texture conflicting with the FS
    hack texture, and only a small rectangle in the bottom left corner will
    be rendered.

[Frogging101]

@gofman Gentle ping

[gofman]

Some applications use depth testing but leave the image format depth component set to 0. OpenGL drivers always provide a depth buffer for framebuffers regardless of whether the image format specifies one, so the FS hack texture should too, otherwise such applications will render incorrectly.

Are you sure about that? There are certainly GLX visuals without depth buffers. Why do we get 0 GLX_DEPTH_SIZE then? I suspect that maybe something else is wrong, just e. g., the game does something which we do not handle in fshack or maybe wrong GL format is chosen at once. Does it work with Wine without fshack?

Then, skipping pglFramebufferTexture2D( GL_DRAW_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, GL_TEXTURE_2D, ctx->fs_hack_ds_texture, 0 ); if we have a stencil looks suspicious, but for now this is secondary, so far I am not yet convinced that the change is correct in general.

[gofman]

So I took a look at the second issue with depth buffer. On an AMD machine I could see rendering glitches related to Z testing in the first (Pilot Training) mission when moving left from initial position. That is not related to fshack, the game works with upstream Wine and shows the same. Indeed, the game calls ChoosePixelFormat() without explicitly requesting depth bits in PIXELFORMATDESCRIPTOR. That happens to have depth on one Nvidia machine with Wine / Proton here, but not on AMD. On the same AMD machine the same ChoosePixelFormat ends up with 32 / 8 depth / stencil on Windows 11. Frankly I am not sure that with every possible GPU and driver it will get a depth buffer (and the game warns about "buggy drivers" when selecting OpenGL option which suggests that it doesn't necessarily work very well on arbitrary instance). I suppose it is nothing wrong in matching current Windows / AMD behaviour here instead of depending on unspecified format order. But that should be done in opengl32/wglChoosePixelFormat, not by adding some depth buffers in fshack.

So I pulled the first patch from this PR ("fshack: Use texture name hack for Descent 3 ") and made another patch for depth issue (also sent upstream: https://gitlab.winehq.org/wine/wine/-/merge_requests/5636

Those are in the just updated Proton Experimental ([bleeding-edge] branch): https://github.com/ValveSoftware/wine/commits/experimental-wine-bleeding-edge-9.0-96562-20240514-p230721-we36c29-d6259e8-vf6d390/

Does that fix the issues?