Jump to content

wik

Community Members
  • Posts

    26
  • Joined

  • Last visited

1 Follower

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

wik's Achievements

Discens

Discens (2/14)

6

Reputation

  1. Thanks for pointing that out, I'll need to study it Meanwhile I've done some more experiments and noticed that if we only multiply glViewport components by scale factor, then mouse coordinates not affected. Previously I've tried to multiple ClientSize in OnResize and InitSize, but those broke mouse coordinates. void CRenderer::SetViewport(const SViewPort &vp) { m_Viewport = vp; const float scaleFactor = 2.f; glViewport((GLint)vp.m_X * scaleFactor,(GLint)vp.m_Y * scaleFactor,(GLsizei)vp.m_Width * scaleFactor,(GLsizei)vp.m_Height * scaleFactor); } Looks a bit more promising IMHO, but still need to figure out how to get content scale factor in there.
  2. I also tried SDL2-2.0.12 + flags |= SDL_WINDOW_ALLOW_HIGHDPI It enables auto-scaling to 2880 x 1800, but has the same missing text issue as in SDL2-2.0.5 m_Viewport 1440 x 900 GL_VIEWPORT 2880 x 1800
  3. I haven't tried, but there seems to be similar solution for OSX, i.e. disable high dpi capability on per application basis: https://github.com/ioquake/ioq3/issues/422#issuecomment-541193050 /Contents/Info.plist, right above the "" line: <key>NSHighResolutionCapable</key> <false/> Could be an intermediate option before transitioning to hdpi support.
  4. I've tried it with SDL2-2.0.5 (the version we currently have in trunk) https://github.com/0ad/0ad/blob/master/libraries/osx/build-osx-libs.sh#L27 And it turns out that removing explicit call to glViewport allows game to scale automatically (2880 x 1800), below some examples with and without glViewport void CRenderer::SetViewport(const SViewPort &vp) { m_Viewport = vp; //glViewport((GLint)vp.m_X,(GLint)vp.m_Y,(GLsizei)vp.m_Width,(GLsizei)vp.m_Height); } With glViewport (m_Viewport m_Width X m_Height => 1440 x 900) Without glViewport (after commenting out the line, also glGetIntegerv(GL_VIEWPORT) reports 2880 x 1800) But I've noticed that some text disappeared in "auto-scaled" version, perhaps something to do with fonts.
  5. Note, I'm using SDL2-2.0.12 and the following commit could probably explain why game, unlike editor, running in 1:1 mode: https://hg.libsdl.org/SDL/rev/46b094f7d20e i.e. SDL overrides default behavior and the application treated as non hidpi compatible and running in 1:1 mode by default. I should probably give it a go with SDL2-2.0.5
  6. I've done some more experiments with opengl examples from wxWidgets and it turns out that if we skip glViewport the system will sort it out automagically, i.e. scale factor will be applied and even mouse position will be adjusted transparently, wxWidgets will behave as it would run on any other screen // Renderer.cpp void CRenderer::SetViewport(const SViewPort &vp) { m_Viewport = vp; //glViewport((GLint)vp.m_X,(GLint)vp.m_Y,(GLsizei)vp.m_Width,(GLsizei)vp.m_Height); } I've tried to debug GL_VIEWPORT state with the following snippets int viewport[4]; glGetIntegerv(GL_VIEWPORT, viewport); std::printf("m_Viewport %d x %d\n", m_Viewport.m_Width, m_Viewport.m_Height); std::printf("GL_VIEWPORT %d x %d\n", viewport[2], viewport[3]); Here is results: Editor: m_Viewport 734 x 718 GL_VIEWPORT 1468 x 1436 Game: m_Viewport 1440 x 900 (also noticed that every 4th call to SetViewport has strange vp 2048 x 2048, i.e. something in 0ad game code tries to set this) GL_VIEWPORT 1440 x 900 (remains stable, I believe not scaled, probably because some magic in SDL update) Unfortunatelly I didn't find documentation about default behavior for glViewport and when it should or shouldn't be used explicitly.
  7. Ah, I see, thank you for clarification and sorry for the false alarm
  8. OSX Catalina, trunk@23702 Have any one experienced similar problem?
  9. This is because scale factor need to applied to wxMouseEvent::GetPosition(), I found some clarification in wxWidgets documentation https://docs.wxwidgets.org/trunk/classwx_g_l_canvas.html As an experiment I've tried to apply scale factor of 2.0 (retina) in AlterElevation tool POST_MESSAGE(BrushPreview, (true, Position(evt.GetPosition() * 2.0))); // multiplied by 2.0 (retina) Here is illustration, the mouse pointer, in both cases, in the middle (approx) of square Before: After: It feels like "Position::Position(const wxPoint& pt)" definition from ScenarioEditor.cpp might be a good place to implement this uniformly. I also need to figure out how to get scale factor from wxPoint.
  10. Thanks, I'll try With those changes applied the map fills whole canvas, but I just noticed that it still have offset between mouse pointer and place where it triggers action for some reason. On non-retina display it only happens with my changes applied, so, I probably missing something. UPDATE: it only happens on retina display, if I move window to non-retina display it back to normal after resize (I keep forgetting to resize)
  11. Looks like it also helps with altas editor, if I multiply client size by scale factor GetContentScaleFactor(): void Canvas::OnResize(wxSizeEvent&) { // Be careful not to send 'resize' messages to the game before we've // told it that this canvas exists if (! m_SuppressResize) { const wxSize ClientSize = GetClientSize() * GetContentScaleFactor(); POST_MESSAGE(ResizeScreen, (ClientSize.GetWidth(), ClientSize.GetHeight())); // TODO: fix flashing } } void Canvas::InitSize() { m_SuppressResize = false; const wxSize ClientSize = GetClientSize() * GetContentScaleFactor(); SetSize(ClientSize); }
  12. I've discovered the same problem in OpenGL samples from wxWidgets wxWidgets-3.0.5/samples/opengl/ And then I found solution here: https://github.com/wxWidgets/wxWidgets/pull/1470/files Multipluing size by scaling factor solves the problem: const wxSize ClientSize = GetClientSize() * GetContentScaleFactor();
  13. The problem Looks like something related to retina display, because if I move Editor window to 2nd monitor (not retina) and resize a bit, it shows okay: and when I move it back to retina, it changes back as per first screenshot.
  14. @wraitii, yes, can delete text too, yay Also, Alt + Enter works, and even "full screen" green button works more as expected. Yes, I can change text in the fields on the left side, also QE, WASD and other shortcuts works inside game simulation However I can't enter / change text in any text fields which appears as a part of game simulation, for example, user name in game options or message in the chat window.
  15. Thanks @Stan`, do you mean there is different solution rather than removing OSXIsGUIApplication method which I suppose is needed for the good reason?
×
×
  • Create New...