Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Qt: Always apply SmoothPixMapTransform to the background logo #1886

Closed
wants to merge 1 commit into from

Conversation

@lotharsm
Copy link
Member

@lotharsm lotharsm commented Sep 12, 2020

Currently, the background logo of the Qt application looks not very nice if the bilinear filter is disabled in the mGBA settings and tends to be pretty blurry.
mgba-no-antialias

This simple patch always enables the SmoothPixmapTransform rendering hint for drawing the background logo, so the hinting filter will always be applied, resulting in a much cleaner image of the background logo regardless of the bilinear filter for the emulation being enabled or disabled.
mgba-with-antialias

Any chance to get this merged or am I breaking something here? :-)

@endrift
Copy link
Member

@endrift endrift commented Sep 12, 2020

This breaks the still image used when the game is paused or behind the savestate select, see Window::updateFrame. The correct thing to do would be to call m_screenWidget->filter(false) in the constructor and Window::gameStopped. That said, that code should also be refactored out because it's common between the two functions. You'll also need to gate the m_screenWidget->filter(value.toBool()); line in setupMenu behind an if (m_controller) check like the ones above it.

@lotharsm
Copy link
Member Author

@lotharsm lotharsm commented Sep 12, 2020

Ah, thanks! Would have been too easy :D

EDIT: I tried to find out what exactly breaks so I have something to compare. At least the still image on pausing seems to work fine - could you give me another hint what's broken in this case?

@endrift
Copy link
Member

@endrift endrift commented Sep 12, 2020

Anything that calls Window::updateFrame expects that code you changed to have the same filtering as the game. It might only be noticeable if you use the Software display driver. Not sure.

@endrift
Copy link
Member

@endrift endrift commented Sep 18, 2020

Are you still looking into this? I can probably fix it myself if you're having trouble reproducing the case I described.

@lotharsm
Copy link
Member Author

@lotharsm lotharsm commented Sep 18, 2020

I was pretty busy in the past days, so this issue was a bit 'on hold' - however, I'd like to look at it in the next couple of days, so I can start gaining some experience :-)

@endrift
Copy link
Member

@endrift endrift commented Oct 13, 2020

Any update?

@lotharsm
Copy link
Member Author

@lotharsm lotharsm commented Oct 14, 2020

Sorry, I'm afraid I won't be able to take a look at this issue soon :/

@endrift
Copy link
Member

@endrift endrift commented Oct 14, 2020

Do you mind if I just fix it on my end then? I'd like to include a fix for this in 0.8.4, since it should be a safe fix, and I'd like to release that soon.

@lotharsm
Copy link
Member Author

@lotharsm lotharsm commented Oct 14, 2020

It wouldn't make any sense to hold back a release just waiting for me trying to fix stuff while it seems that you already know the solution to the problem, so please, go ahead 😃

@endrift
Copy link
Member

@endrift endrift commented Oct 14, 2020

It wouldn't be holding back the release, it would be skipping fixing it for the release, but yeah I'll go ahead and do that soon then. Thanks.

@endrift endrift closed this in 6ffa43d Oct 15, 2020
endrift added a commit that referenced this pull request Oct 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

2 participants
You can’t perform that action at this time.