1
General / Re: RenderWindow in Win32 app problem with resizing
« on: February 15, 2023, 10:08:30 pm »
After few more days of playing around I think I've found a solution.
I'll present some more explanation of what I found/tested in hope it trun out useful to anyone.
Using SetWindowPos or MoveWindow function works well for resizing the static control that's the "base" of sf::RenderWindow, but for some reason that change isn't propagated to SFML internals, so the RenderWindow doesn't change it's size. That cuases symptomps I described before, as any function calling getSize() on the RenderWindow gets the starting dimensions. When you change the view to adjust the drawing after resizing, you set it properly, but since the size of the RenderWindow isn't updated, you end up drawing to a rectangle of starting dimensions, so the scaling is reversed. And when you don't change the view, scaling doesn't occur, but nothing is drawn outside that starting rectangle.
The reason of unusual behaviour along the vertical axis - that the drawing follows to the bottom border, is caused by glViewport taking the bottom left pixel as the viewport's origin. That's also the reason why applyCurrentView function of RenderTarget (called internally when drawing) calculates the top variable. Connecting this with the fact that the RenderWindow's size isn't updated explains that phenomenon we observe.
And I think that'd be it for now. I'll be playing more with that app so maybe I'll find out more in the future. Hopefully that "more" won't be "more issues".
Code: [Select]
LRESULT Application::onSize(UINT width, UINT height)
{
main_window.width = width;
main_window.height = height;
renderer.setSize(sf::Vector2u(width, height));
renderer.setView(sf::View(sf::FloatRect(0.f, 0.f, width, height)));
return 0;
}
The "trick" is to set the size of sf::RenderWindow explicitly with setSize() method. You should pass it the size of client area, which is convieniently available from the WM_SIZE message, as the setSize function calculates the dimensions of the window (including borders and title bar) and calls SetWindowPos. And for that to work one doesn't need to recompile SFML (I did that to test things and find the solution).I'll present some more explanation of what I found/tested in hope it trun out useful to anyone.
Using SetWindowPos or MoveWindow function works well for resizing the static control that's the "base" of sf::RenderWindow, but for some reason that change isn't propagated to SFML internals, so the RenderWindow doesn't change it's size. That cuases symptomps I described before, as any function calling getSize() on the RenderWindow gets the starting dimensions. When you change the view to adjust the drawing after resizing, you set it properly, but since the size of the RenderWindow isn't updated, you end up drawing to a rectangle of starting dimensions, so the scaling is reversed. And when you don't change the view, scaling doesn't occur, but nothing is drawn outside that starting rectangle.
The reason of unusual behaviour along the vertical axis - that the drawing follows to the bottom border, is caused by glViewport taking the bottom left pixel as the viewport's origin. That's also the reason why applyCurrentView function of RenderTarget (called internally when drawing) calculates the top variable. Connecting this with the fact that the RenderWindow's size isn't updated explains that phenomenon we observe.
And I think that'd be it for now. I'll be playing more with that app so maybe I'll find out more in the future. Hopefully that "more" won't be "more issues".