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 window handling to its own class #121

Closed
wants to merge 11 commits into
base: master
from

Conversation

Projects
None yet
3 participants
@farmboy0
Contributor

farmboy0 commented May 7, 2016

No description provided.

@farmboy0

This comment has been minimized.

Show comment
Hide comment
@farmboy0

farmboy0 May 7, 2016

Contributor

The following functionality should be tested:

  • changing FSAA level
  • switching between fullscreen and windowed and back
  • changing window size in windowed and fullscreen mode
Contributor

farmboy0 commented May 7, 2016

The following functionality should be tested:

  • changing FSAA level
  • switching between fullscreen and windowed and back
  • changing window size in windowed and fullscreen mode
Show outdated Hide outdated src/graphics/graphics.cpp
@@ -957,8 +761,8 @@ Renderable *GraphicsManager::getGUIObjectAt(float x, float y) const {
return 0;
// Map the screen coordinates to our OpenGL GUI screen coordinates
x = x - (_width / 2.0f);
y = (_height - y) - (_height / 2.0f);
x = x - (WindowMan.getWindowWidth() / 2.0f);

This comment has been minimized.

@Supermanu

Supermanu May 11, 2016

Contributor

Minor nitpick here: space alignment not needed anymore.

@Supermanu

Supermanu May 11, 2016

Contributor

Minor nitpick here: space alignment not needed anymore.

@DrMcCoy

This comment has been minimized.

Show comment
Hide comment
@DrMcCoy

DrMcCoy Oct 22, 2016

Member

Yeah, this looks good, IMHO. I like it.

I especially like the use of an enum for the renderer type; that's probably what I should have done in the first place, yes.

Two things I noticed (but are not a fault of your code, just general observations for the TODO list):

  • When changing the FSAA settings in NWN (either the main menu or the ingame options menu), the highlight bounding boxes suddenly appear offset by half an object's height. This doesn't seem to change the cursor/object interactions, though. When restarting xoreos with the new FSAA settings, they're okay again, too. Very weird.
  • The game loader progress bar looks silly in higher FSAA settings, because the bar is actually a string of Unicode box glyphs. With FSAA up, the gaps between them are visible. That really shouldn't be, but the bar should probably be drawn in a better way anyway, I guess.

Do you want this to be merged now or should this wait for after @mirv-sillyfish's stuff? #123 rebases cleanly (with an automatic 3-way merge) on top of this change, but then needs a little fix in graphics.cpp to replace _width/_height by WindowMan.getWindowWidth()/WindowMan.getWindowHeight() to make it compile again.

Member

DrMcCoy commented Oct 22, 2016

Yeah, this looks good, IMHO. I like it.

I especially like the use of an enum for the renderer type; that's probably what I should have done in the first place, yes.

Two things I noticed (but are not a fault of your code, just general observations for the TODO list):

  • When changing the FSAA settings in NWN (either the main menu or the ingame options menu), the highlight bounding boxes suddenly appear offset by half an object's height. This doesn't seem to change the cursor/object interactions, though. When restarting xoreos with the new FSAA settings, they're okay again, too. Very weird.
  • The game loader progress bar looks silly in higher FSAA settings, because the bar is actually a string of Unicode box glyphs. With FSAA up, the gaps between them are visible. That really shouldn't be, but the bar should probably be drawn in a better way anyway, I guess.

Do you want this to be merged now or should this wait for after @mirv-sillyfish's stuff? #123 rebases cleanly (with an automatic 3-way merge) on top of this change, but then needs a little fix in graphics.cpp to replace _width/_height by WindowMan.getWindowWidth()/WindowMan.getWindowHeight() to make it compile again.

@DrMcCoy

This comment has been minimized.

Show comment
Hide comment
@DrMcCoy

DrMcCoy Oct 23, 2016

Member

Merged with 287d2d8..812b1af. Thanks! :)

I did, however, remove the SDL_WINDOW_RESIZABLE flag since it's currently not working anyway. I added "Let the user resize the xoreos window" as a TODO. If you have a working implementation, please do a PR for it. I'm really not sure how well it'll work though, what with OpenGL needing to be recreated for every change, but yeah, if I see it working, sure.

Also note that Sonic, as a Nintendo DS game, is inherently fixed-size. Currently, the engine code even overrides a user config choice there. In the future, we might add something to scale the 2D images? But even that would probably work best in full integer steps. So an engine might explictly want to disable user scaling.

I also added two issues, #131 (boundbox displacement while changing FSAA) and #132 (borked fullscreen resolution change, and added the progress bar thing as another TODO.

Member

DrMcCoy commented Oct 23, 2016

Merged with 287d2d8..812b1af. Thanks! :)

I did, however, remove the SDL_WINDOW_RESIZABLE flag since it's currently not working anyway. I added "Let the user resize the xoreos window" as a TODO. If you have a working implementation, please do a PR for it. I'm really not sure how well it'll work though, what with OpenGL needing to be recreated for every change, but yeah, if I see it working, sure.

Also note that Sonic, as a Nintendo DS game, is inherently fixed-size. Currently, the engine code even overrides a user config choice there. In the future, we might add something to scale the 2D images? But even that would probably work best in full integer steps. So an engine might explictly want to disable user scaling.

I also added two issues, #131 (boundbox displacement while changing FSAA) and #132 (borked fullscreen resolution change, and added the progress bar thing as another TODO.

@DrMcCoy DrMcCoy closed this Oct 23, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment