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

Move "Display Rotation" and stretching options to display layout editor. #8182

Merged
merged 9 commits into from
Jan 17, 2016

Conversation

LunaMoo
Copy link
Collaborator

@LunaMoo LunaMoo commented Nov 7, 2015

Seems fitting since it's not really a performance setting where it is now, also makes one option less in graphics setting menu.
Also fix portrait rotation representation in the editor with auto setting and minor cleanup.

Edit: this kind of goes along the recent cleaning spirit:P, but if the main change is not ok let me know so I can revert it and just leave the minor fix and cleaning.

@daniel229
Copy link
Collaborator

Can you add "Display Rotation" to the windows menu bar under the "Emulation".

@LunaMoo
Copy link
Collaborator Author

LunaMoo commented Nov 7, 2015

Ok, not sure if that's the right place, but I guess it can be treated same as umd switch also something we can't physicaly do(well rotating TV for example;p).

@CarlKenner
Copy link
Contributor

Sounds like a bad idea to me. It's not really a performance setting, but it is really a game specific graphics hack.

@daniel229
Copy link
Collaborator

@LunaMoo Thanks.

@LunaMoo
Copy link
Collaborator Author

LunaMoo commented Nov 7, 2015

@CarlKenner it's not really a graphics hack since it doesn't affect game rendering, it's more of a feature that on desktop can't be physically done, so just like UMD switch which already is under emulation settings it seems to fit there. Either way that was only about creating new option in windows menu bar and that's divided differently from main menus on simply emulation, debug and game settings.

Being or not being performance settings I mentioned in context of where the option is placed now in ppsspp GUI, since along #8171 we want to clear as much clutter as we can from the main menus and graphics setting is really tragic with that. The display layout editor screen seems much better place for it since it's already centered around moving and resizing display. It will still be in the graphics section, just one screen deeper.

@daniel229 you're welcome, through it will not depend on me if that get's there or not;3.

@hrydgard
Copy link
Owner

This has some odd issues:

  • The rotation picker drifts upwards and disappears of the screen as you resize the window
  • The screen overlaps the blue borders when switching to landscape

capture

(oops, semitranslated Swedish, heh)

A little bit more polish and I'll merge, it's pretty neat :)

@LunaMoo
Copy link
Collaborator Author

LunaMoo commented Nov 13, 2015

Thanks for finding that out, appears touch control layout screen was affected by that as well so I fixed both.
Also added some other cases to display representation on auto to match functionality in cases other than common widescreen resolution since that was also missing.

Edit: pushed it again since I forgot to remove one unnecessary variable;3

@LunaMoo
Copy link
Collaborator Author

LunaMoo commented Nov 13, 2015

@hrydgard what do you think about also moving "Stretch to display" checkbox inside display layout editor screen? I could change it to be always accessible, just disable zoom options when stretched instead. I don't think that option is often used either and also fits meaning another -1 to graphics settings screen.

@hrydgard
Copy link
Owner

Yeah, that would be great.

@LunaMoo
Copy link
Collaborator Author

LunaMoo commented Nov 13, 2015

Instead of separate option, I renamed zoom settings to more general "Options"(and reused translation for it from cheat menu) and included both stretching options there. They can't be enabled with other options anyway, so might as well be one.
Also when stretching is used it'll replace the screen representation to reflect that.

@LunaMoo LunaMoo changed the title Move "Display Rotation" to display layout editor. Move "Display Rotation" and stretching options to display layout editor. Nov 14, 2015
@@ -281,6 +283,10 @@ namespace MainWindow
NativeMessageReceived("gpu resized", "");
}

if (screenManager) {
screenManager->RecreateAllViews();
Copy link
Collaborator

Choose a reason for hiding this comment

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

Is this the correct thread to do this from? Shouldn't this happen via an event?

-[Unknown]

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Well that's a fix for the issue which messes up both this and touch control layout screens since they aren't recreated whenever you resize window as on Henrik's screenshot above. Not really sure how to deal with it differently.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Hmm. Maybe we should recreate views when the resized event comes through to the DisplayLayoutEditor? I mean via void DisplayLayoutScreen::sendMessage(const char *message, const char *value) {.

-[Unknown]

@LunaMoo
Copy link
Collaborator Author

LunaMoo commented Dec 21, 2015

Changes:
Re-added blackberry partial stretch check that was setting default, but since it really only checks for resolution proportions, I made it for all devices.
Divided zoom type from level also limited all display representation scaling(*/ 8) to display layout screen and added an extra slider to set zoom level accurately aside to mouse/touch resize.
Got rid of the lenghty and potentially confusing submenu and replaced it with direct link to the screen.

Pretty much that's how it looks now:
displaylayout
Extra options are hidden when stretching or automatic scaling is used, also rotation is grayed out and visual representation looses potential rotation when non-buffered rendering is being used.

@unknownbrackets
Copy link
Collaborator

I use a 4:3 screen and would not want partial stretch on my desktop. I would prefer the black bars. I'm not sure making it the default for everyone makes sense, it makes more sense for small screens.

-[Unknown]

@LunaMoo
Copy link
Collaborator Author

LunaMoo commented Dec 21, 2015

Ok then, changed it your way. Althrough imo the same way someone could not like it on smaller device as well since it's a matter of proportions not size really, just like emulating older consoles on psp, small wide screen, but it's not like everyone stretched old games just to get a bit less black bars.
Either way it's just defaults anyway so anyone wanting to change it will be able.

@unknownbrackets
Copy link
Collaborator

Hey, it's been a while, I think some change has conflicted. Pretty sure it's my fault - I changed this line if (g_Config.iGPUBackend == GPU_BACKEND_OPENGL) { offsetY = offsetY * -1.0f; } to fix a backend thing.

Could you rebase? I haven't looked carefully at all the UI code, but it looks like this is ready to go, right?

-[Unknown]

@LunaMoo
Copy link
Collaborator Author

LunaMoo commented Jan 17, 2016

Sorry kind of forgot about it, but yeah should be ready / rebased.

->addEventChecked(&g_Config.bStretchToDisplay);
MenuTree* displayLayoutMenu = new MenuTree(this, videoMenu, QT_TR_NOOP("&Display Layout Options"));
displayLayoutGroup = new MenuActionGroup(this, displayLayoutMenu, SLOT(displayLayoutGroup_triggered(QAction *)),
QStringList() << "Stretched" << "Partialy stretched" << "Auto Scaling" << "Manual Scaling",
Copy link
Collaborator

Choose a reason for hiding this comment

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

*Partially.... does this get translated?

-[Unknown]

@LunaMoo
Copy link
Collaborator Author

LunaMoo commented Jan 17, 2016

Fixed all of that not counting Qt, no clue what to do with it, I recall I initially just fixed the build trying to maintain existing functionality, but I had to do it blindly, I don't even know how Qt menu looks(well I imagine it is a drop down menu, but that's it), looking at other options as I based that code on existing stuff I saw there it doesn't seem to have translations.(?)
Also would be best to just link it to display layout editor menu like on windows, but I don't know if it's even possible for it.

//Edit: oh and the land of spaces had suprising amount of aliens;p.

@unknownbrackets
Copy link
Collaborator

//Edit: oh and the land of spaces had suprising amount of aliens;p.

Hahahaha... sorry. Thanks.

In the interface, "Stretching" and "Auto Scaling" look different, and "Stretching" reacts to clicks but doesn't do anything. Is that intentional?

Also, I think it's an improvement as is, but if you click not in the center, and then move, the frame jumps to center on your cursor. Usually I prefer to save the initial click offset somewhere, and apply that every time so that the drag is fluid.

It'd be cool if you could focus that particular view, and press X, and then use the arrow keys to move it, and then press X again or O to release.

Anyway, those don't seem necessary. LGTM, what do you think @hrydgard?

-[Unknown]

@LunaMoo
Copy link
Collaborator Author

LunaMoo commented Jan 17, 2016

Don't know about controls, but the moving part was easy and seems nice change, thanks for that idea.

Also minor changes - displayed zoom value should now update instantly when resizing and disabled that click you catched as that "choice" is there just a visualization.

if ((touch.flags & TOUCH_MOVE) && picked_ != 0) {
int touchX = touch.x - offsetTouchX;
int touchY = touch.y - offsetTouchY;
if (mode == 0) {
const Bounds &bounds = picked_->GetBounds();

int mintouchX = screen_bounds.w / 4;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Oh, sorry for the nitpick - minTouchX right?

-[Unknown]

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Nah minTouchX is not offset it sets bounds of the movement on the screen, I reused it in maxTouchX because it was same equation, ~ simplified, but that's not offset:).

Copy link
Collaborator

Choose a reason for hiding this comment

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

I just meant touch vs Touch, your change is good I'm just being the camel case police, sorry.

-[Unknown]

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Aaahh I see now, I looked at the changed code instead of the line you mentioned ~ attention colors heh;p. Will rename that.

@unknownbrackets
Copy link
Collaborator

Nice.

-[Unknown]

@LunaMoo
Copy link
Collaborator Author

LunaMoo commented Jan 17, 2016

Pushed it again with a fix for resize I updated incorrectly(could get to 0;p), either way moving and resizing does work much smoother with the offset now.

@hrydgard
Copy link
Owner

Alright, let's merge when the buildbot is happy :)

unknownbrackets added a commit that referenced this pull request Jan 17, 2016
Move "Display Rotation" and stretching options to display layout editor.
@unknownbrackets unknownbrackets merged commit 5161476 into hrydgard:master Jan 17, 2016
@LunaMoo LunaMoo deleted the minor_cleaning branch January 24, 2016 05:21
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.

6 participants