00:42.16 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
07:22.15 | macsforme | blast007: in your PR #238, is your SDL2Window::create() function intentionally designed to handle the possibility of getting back a different window size than was requested? |
07:23.55 | macsforme | and if so, have we thought through the other possible side effects of that happening? |
07:25.28 | macsforme | I'm specifically thinking of additional BzfEvent::resize events being thrown, which I don't *think* would trigger a loop necessarily, but I'm trying to trace through what would happen in that case (probably an additional call to create(), at a minimum) |
11:26.25 | *** join/#bzflag FieldSobers (~Artistics@unaffiliated/user49) |
12:17.42 | blast007 | yeah, our way of handling resizes is a bit weird |
12:17.57 | blast007 | I did certainly run into situations where it infinitely looped trying to resize |
12:18.52 | blast007 | I don't understand why our game code tells the platform code about resize events, which in turn triggers resize events... |
12:19.37 | blast007 | really, the game code should only inform the platform code about *desired* sizes when that changes (such as when changing the full-screen resolution) |
12:20.30 | blast007 | I also don't like our separate display and window classes |
22:48.00 | *** join/#bzflag infobot (ibot@c-174-52-60-165.hsd1.ut.comcast.net) |
22:48.00 | *** topic/#bzflag is BZFlag Support and Development || Latest version: 2.4.18 || https://www.bzflag.org || https://www.bzflag.org/help/ || https://www.openhub.net/p/bzflag || https://logs.bzexcess.com/freenode/%23bzflag/ || New shiny website! https://forums.bzflag.org/viewtopic.php?f=8&t=20201 |
22:48.00 | *** mode/#bzflag [+v infobot] by ChanServ |