-
Notifications
You must be signed in to change notification settings - Fork 552
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
Conversation
<child> | ||
<object class="GtkComboBoxText" id="gpuscale"> | ||
<items> | ||
<item translatable="yes">×1</item> |
There was a problem hiding this comment.
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 ?
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. |
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. |
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. |
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. |
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. |
Ok, for now I think it's finished. If anyone has other suggestions, I'll be glad to hear them. |
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).
|
* [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
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.
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.
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.