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

gtk: implement GPU scale factor feature #764

Merged
merged 4 commits into from
Jan 25, 2024
Merged

gtk: implement GPU scale factor feature #764

merged 4 commits into from
Jan 25, 2024

Conversation

thesourcehim
Copy link
Contributor

WIP implementation of GPU scale factor for linux GTK3 frontend. Currently UI is changed to properly set new option, however scaling itself does not fully work yet: rendered image seems to be scaled but put incorrectly to the window, parts of the image are mixed, like origin point is set somewhere in the middle. Still trying to figure this out, hints are appreciated.

<child>
<object class="GtkComboBoxText" id="gpuscale">
<items>
<item translatable="yes">×1</item>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wouldn't it be better to make the scale factor a float, like in cli, and use some sort of editbox with a knob for the selection, instead of hardcoding a few ints in a combobox ?

@thesourcehim
Copy link
Contributor Author

thesourcehim commented Jan 21, 2024

Replaced combobox with spin button and fixed screenshot crash. Did some tests to check if incorrect image comes from GPU or VideoFilter and it looks like it comes from GPU. Maybe, OGL renderer bug? I'll continue digging.

Update: no, it's not OGL, with software rasterizer same distortion occurs.

@rofl0r
Copy link
Collaborator

rofl0r commented Jan 21, 2024

can't help with your rendering issues, as i dont quite understand what you're doing there, but i can tell you what i did in 90326ea : basically all the rendering happens in 1x scale, and the scalefactor is only taken into account when creating the window and when passing the images to SDL2's renderer, using an SDLRect to tell it to scale up.
that's a simple and cheap way to do it, but what you have in mind might be what @rogerman did in the cocoa port where the 3d textures are actually rendered in the up-scaled resolution for smoother visuals.

@thesourcehim
Copy link
Contributor Author

Yes, I understood what you did in cli, but I'm trying to render at higher resolution using large buffer like windows frontend does. Simply scaling rendered image to window is already supported.

@thesourcehim
Copy link
Contributor Author

Finally fixed incorrect image, turns out, I was using wrong pointer to access the buffer. Also added some sanity checks for scale factor value. For now I changed graphics dialog so only integer values are allowed: testing revealed that non-integer values tend to cause random crashes.

Here's the screenshot rendered at 5x:
desmume-screenshot-0

@thesourcehim
Copy link
Contributor Author

Small fix for OSD when scale factor is > 1. Makes OSD elements at least visible, but unfortunately not scaled. As far as I can see, reworking of AGG OSD code is required since native screen size is hardcoded there in a lot of places. Probably should be done in different PR.

@thesourcehim thesourcehim changed the title [WIP] gtk: implement GPU scale factor feature gtk: implement GPU scale factor feature Jan 23, 2024
@thesourcehim
Copy link
Contributor Author

Ok, for now I think it's finished. If anyone has other suggestions, I'll be glad to hear them.

@rofl0r
Copy link
Collaborator

rofl0r commented Jan 24, 2024

cool. are you prepared to do some follow-up work in case a bug in this code gets detected ? i haven't seen the maintainer of the gtk+3 port for quite some time.
oh, and please provide a screenshot of where you placed the button in the gui, so i can try to port this over to gtk+2.

@thesourcehim
Copy link
Contributor Author

cool. are you prepared to do some follow-up work in case a bug in this code gets detected ? i haven't seen the maintainer of the gtk+3 port for quite some time.

Sure. I also have a couple more ideas for GTK3 frontend for the future. AGG OSD needs some touch and I want to implement hybrid layout (similar to melonDS, but with different size preferences).

oh, and please provide a screenshot of where you placed the button in the gui, so i can try to port this over to gtk+2.

Screenshot_20240125_093908

@rofl0r rofl0r merged commit f2cfd23 into TASEmulators:master Jan 25, 2024
9 checks passed
getItemFromBlock pushed a commit to getItemFromBlock/AM64DS_DeSmuME that referenced this pull request Feb 28, 2024
* [WIP] gtk: implement GPU scale factor feature

* Replace combobox with spin button, fix taking screenshot

* Fix distorted image, add some checks for scale factor value

* Make OSD at least properly visible
rofl0r added a commit to rofl0r/desmume-gtk2 that referenced this pull request Oct 28, 2024
feature was originally added via PR TASEmulators#764 to the gtk3 frontend.

this makes it possible to run the scaling on the GPU, avoiding the
incredibly slow software scaling that's otherwise done via cairo
when view->window size is set to anything > 1.0.
note that the window size "scale" needs to be identical to the
chosen GPU scale factor, otherwise software scaling kicks in again.

unlike the scale setting in the CLI port, which simply upscales the
native NDS framebuffer in hardware, this setting scales up even
the actual 3D textures, resulting in a sharper image, at the cost
of higher CPU/GPU usage. a game using demanding 3D scenes, like
zelda phantom hourglass' intro scene, may be able to still trash
the FPS.

the original PR also reported issues when setting the GPU scale to
a fraction, therefore the increments are currently locked to 1.0.
rofl0r added a commit that referenced this pull request Oct 28, 2024
feature was originally added via PR #764 to the gtk3 frontend.

this makes it possible to run the scaling on the GPU, avoiding the
incredibly slow software scaling that's otherwise done via cairo
when view->window size is set to anything > 1.0.
note that the window size "scale" needs to be identical to the
chosen GPU scale factor, otherwise software scaling kicks in again.

unlike the scale setting in the CLI port, which simply upscales the
native NDS framebuffer in hardware, this setting scales up even
the actual 3D textures, resulting in a sharper image, at the cost
of higher CPU/GPU usage. a game using demanding 3D scenes, like
zelda phantom hourglass' intro scene, may be able to still trash
the FPS.

the original PR also reported issues when setting the GPU scale to
a fraction, therefore the increments are currently locked to 1.0.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants