Screen rendered with offset on Intel HD Graphics Cards

[PabloNeirotti]

Hi there!

I know this project is meant to work with nVidia Graphics Cards. Still, many users have integrated cards and I get tons of reports regarding this, so hopefully anyone here may have a clue on how to deal with this.

Basically, all Intel HD Graphics card users have the whole game viewport drawn 50% up to the top, when scaling higher than 1x (on the lowest window size, it looks just fine).

Here is a picture that illustrates this better: http://www.pic-upload.de/view-29015216/NeueBitmap.jpg.html

Any thoughts?

Thank you!

[Ancurio]

I know this project is meant to work with nVidia Graphics Cards.

I don't know why you say this. The engine requires a working OpenGL driver. Often, Intel on Windows is simply not able to satisfy this condition. I myself use a mobile-class AMD card.

First, tell them to make absolutely sure that they have the newest driver version installed for their system.

Next, they should try and rename mkxp.exe to doom3.exe.

If that doesn't work, running the game under Linux might be another option (the Intel drivers are a lot better there), but honestly I'm not sure what else can be done. I don't have such a Windows system with broken Intel drivers to debug the problem on.

For reference, I have a cheap Lenovo Laptop with an Intel Bay Trail chip, and mkxp runs just fine on it (on Linux though, no idea about Windows).

[PabloNeirotti]

Hey there!

Sorry, don't take it the wrong way. I remember you saying that Nvidia is the only one that has proper OpenGL drivers, and that's where that came from.

I understand. It's probably a Intel + Windows + OpenGL issue then. Is there any way to hardcode-patch this? (I know it's not the the best angle). Like, would shifting the viewport downwards IF it's a Windows, Intel Graphics setup, make the trick?

Again, I know it sounds dirty, but if there is nothing else that can be done to it, maybe something like that would work.

Indeed, all of them told me they have the latest drivers, so it's probably just the way OpenGL + Intel is on Windows :/.

Thank you so much for your time.

[Ancurio]

Is there any way to hardcode-patch this? (I know it's not the the best angle). Like, would shifting the viewport downwards IF it's a Windows, Intel Graphics setup, make the trick?

If you can determine whether you're on windows intel, then sure, you could try to offset the blit rectangle downward to "correct" the bad driver behavior, although there is no guarantee that this will work (the rectangle might go upward instead, or something else might happen).

The code that does the scaled blit is here.

Then you'd have to strstr through GL_VENDOR or GL_RENDERER (not sure which), and for Windows detection you can use one of SDL's platform defs.

Note that this will screw up the game for anyone on Windows Intel not having the problem (and therefore very likely not having even reported that it works for them, remember only people with problems complain). A better solution IMO would be to create a config entry like the subImageFix one I made, and tell people to manually toggle it on via their launch parameters if they're experiencing this problem.

Of course, all this assumes that everyone's viewport is wrongly shifted by the exact same amount, but from what you wrote, that seems to be the case.

[PabloNeirotti]

Hi there!

Yes, the shifting seems to be consistent, although you made a good point, I can't be certain that all Intel HD Graphics users experiment this issue.

I'll take a shot at it using the config file. Thank you so much for your time!

Sent from my iPhone

On Dec 4, 2015, at 6:06 AM, Jonas Kulla notifications@github.com wrote:

Is there any way to hardcode-patch this? (I know it's not the the best angle). Like, would shifting the viewport downwards IF it's a Windows, Intel Graphics setup, make the trick?

If you can determine whether you're on windows intel, then sure, you could try to offset the blit rectangle downward to "correct" the bad driver behavior, although there is no guarantee that this will work (the rectangle might go upward instead, or something else might happen).

The code that does the scaled blit is here.

Then you'd have to strstr through GL_VENDOR or GL_RENDERER (not sure which), and for Windows detection you can use one of SDL's platform defs.

Note that this will screw up the game for anyone on Windows Intel not having the problem (and therefore very likely not having even reported that it works for them, remember only people with problems complain). A better solution IMO would be to create a config entry like the subImageFix one I made, and tell people to manually toggle it on via their launch parameters if they're experiencing this problem.

Of course, all this assumes that everyone's viewport is wrongly shifted by the exact same amount, but from what you wrote, that seems to be the case.

― Reply to this email directly or view it on GitHub.

[Ancurio]

I've just thought of something, have you considered using Google's ANGLE project to run mkxp via Direct3D9? I'm not sure where to get compiled binaries for it, and I don't have Visual Studio so I can't build it from source, but it shouldn't be too hard to make SDL use it.

[PabloNeirotti]

Hey! Thanks for returning to this :D

Didn't know about that. I'll check out if it is something I can implement. I only know Ruby and HTML5. C++ and compiling are still dark arts to me.

But I'll investigate and let you know. It's be great if this also could potentially fix all the other graphic issues I get reported, as I feel bad I can't really help them from my end.

Thanks a lot man!

Sent from my iPhone

On Mar 5, 2016, at 2:15 PM, Jonas Kulla notifications@github.com wrote:

I've just thought of something, have you considered using Google's ANGLE project to run mkxp via Direct3D9? I'm not sure where to get compiled binaries for it, and I don't have Visual Studio so I can't build it from source, but it shouldn't be too hard to make SDL use it.

― Reply to this email directly or view it on GitHub.

[PabloNeirotti]

Okay, so I took a look at it. Yea, that exceeds my scripting knowledge by a lot. I will bear this in mind but clearly not a solution I can provide for the time being. Specially given this would be a "try and see what gets fixed" scenario, as opposed to, knowing for sure it will address all their issues.

Still, I really appreciate the suggestion. Maybe I will be able to make use of this in the future, who knows. Thank you a lot!