| *** I_Died_Once <I_Died_Once!~I_Died_On@unaffiliated/idiedonce/x-1828535> has quit IRC (Ping timeout: 260 seconds) | 01:41 | |
| Zehra | Does anyone have trouble connecting to Easy Tank's super server? | 01:47 |
|---|---|---|
| blast007 | works here | 02:02 |
| blast007 | still having trouble on your end? | 02:02 |
| Zehra | Was able to successfully authenticate and connect, but not "join". | 02:04 |
| Zehra | On other servers, it seemed to have a bit of a delay in connecting, but still successfully joined. | 02:04 |
| *** SpringTank <SpringTank!~quassel@69-154-138-57.lightspeed.rcsntx.sbcglobal.net> has quit IRC (Ping timeout: 240 seconds) | 03:04 | |
| *** SpringTank <SpringTank!~quassel@69-154-138-57.lightspeed.rcsntx.sbcglobal.net> has joined #bzflag | 03:07 | |
| *** Zehra <Zehra!~Keiki_Han@unaffiliated/zehra> has quit IRC (Quit: Quit) | 03:53 | |
| *** Sgeo <Sgeo!~Sgeo@ool-18b982ad.dyn.optonline.net> has quit IRC (Read error: Connection reset by peer) | 06:25 | |
| BZNotify | bzflag: atupone synchronized pull request #259 "Buffer udp" (https://git.io/JJPKk) | 08:21 |
| *** I_Died_Once <I_Died_Once!~I_Died_On@unaffiliated/idiedonce/x-1828535> has joined #bzflag | 08:56 | |
| *** spldart <spldart!~spldart@bzflag/contributor/spldart> has quit IRC (Ping timeout: 260 seconds) | 09:27 | |
| *** spldart <spldart!~spldart@bzflag/contributor/spldart> has joined #bzflag | 09:30 | |
| *** ChanServ sets mode: +v spldart | 09:30 | |
| *** spldart <spldart!~spldart@bzflag/contributor/spldart> has quit IRC (Ping timeout: 260 seconds) | 14:46 | |
| *** spldart <spldart!~spldart@bzflag/contributor/spldart> has joined #bzflag | 14:49 | |
| *** ChanServ sets mode: +v spldart | 14:49 | |
| *** spldart <spldart!~spldart@bzflag/contributor/spldart> has quit IRC (Ping timeout: 260 seconds) | 14:54 | |
| *** spldart <spldart!~spldart@bzflag/contributor/spldart> has joined #bzflag | 15:05 | |
| *** ChanServ sets mode: +v spldart | 15:05 | |
| *** Sgeo <Sgeo!~Sgeo@ool-18b982ad.dyn.optonline.net> has joined #bzflag | 15:18 | |
| *** FieldSobers <FieldSobers!~User49@unaffiliated/user49> has joined #bzflag | 20:02 | |
| *** User49 <User49!~User49@unaffiliated/user49> has quit IRC (Ping timeout: 272 seconds) | 20:05 | |
| macsforme | as far as #267 (wrong resolution getting saved when quitting via the taskbar/dock), it looks like BzfDisplay is designed to be agnostic to the idea of a "current" resolution setting other than the literal current display mode, which leads to our problem | 20:32 |
| macsforme | I'm not sure what approach to take on that, so if anyone has ideas, please voice them | 20:34 |
| JeffM[m] | Is there any advantage to ever changing the resolution these days? | 20:36 |
| macsforme | we could blur the lines a bit between BzfDisplay and BzfWindow, then try to take the window resolution instead, but I'm afraid to mess too much with this fragile design | 20:36 |
| macsforme | that question does come up from time to time... it seems most games these days still offer the option to change the resolution, sometimes in addition to the option of a reduced render scale | 20:37 |
| JeffM[m] | Changing the display resolution on a lcd is a little silly | 20:38 |
| JeffM[m] | And with BZ’s low graphics needs it seems rare that a system will need a lower render size | 20:39 |
| macsforme | nonetheless, the performance difference is definitely there... especially on a high-DPI display | 20:39 |
| macsforme | another approach might be to write the BZDB "resolution" value, instead of the value dumped by BzfDisplay, and then just make sure the BZDB value is being updated at every resolution change | 20:41 |
| JeffM[m] | Since you are using SDL for all platforms now you can probably combine display and window into a single class. The separation was more important in the CRT era. High DPI displays with low end graphics cards would be best served by a smaller back buffer. But even in the high DPI case, you don't need arbitrary resolutions, you'd just need a flag for "cut my res in half" since you'd only want to use specific power of 2 | 20:44 |
| JeffM[m] | resolutions of the used display. You don't want the flat panel to do any odd interpolation. | 20:44 |
| *** Zehra <Zehra!~Keiki_Han@unaffiliated/zehra> has joined #bzflag | 20:55 | |
| blast007 | JeffM[m]: I do have the start of a platform code rewrite that does merge most of display/window together. | 21:01 |
| blast007 | it still has a lot of the issues we've recently worked around with PR 251, though | 21:01 |
| JeffM[m] | I think that would be best for you in the long run. | 21:02 |
| blast007 | I had initially designed it around GLFW's API, then added SDL2 support | 21:02 |
| blast007 | also mostly supports multiple window/monitors | 21:03 |
| blast007 | Wayland, at least with how we're interfacing with SDL2, also doesn't offer any resolution adjustments, so the only option is the desktop resolution | 21:04 |
| *** FieldSobers <FieldSobers!~User49@unaffiliated/user49> has quit IRC (Ping timeout: 264 seconds) | 21:04 | |
| JeffM[m] | I think more things are going to go to that method, change the render buffer and scale on swap. CRTs are long gone :) | 21:04 |
| blast007 | yeah, I think that's eventually what we'll move to - render at some resolution and scale up | 21:05 |
| blast007 | if we start requiring GL 3.2, though, that'll eliminate many of our low performance machines ;) | 21:06 |
| JeffM[m] | indeed | 21:07 |
| JeffM[m] | I still wonder if the ARM macs are going to support GL. Part of me thinks the "GL is deprecated, use metal" thing last year was to get ready for the fact that they are doing metal only on new arm based machines. | 21:08 |
| blast007 | might be that the support it for x86 apps, but not native arm apps | 21:10 |
| JeffM[m] | maybe | 21:10 |
| * JeffM[m] bets someone on his team has one | 21:12 | |
| JeffM[m] | It's weird to see help requests for "can someone reboot my PS4 Dev kit?" | 21:13 |
| blast007 | heh | 21:13 |
| blast007 | iOS supports OpenGL ES, which current macOS has not | 21:13 |
| blast007 | so I wonder if they'll support that for running some iOS apps | 21:13 |
| JeffM[m] | maybe for a bit | 21:14 |
| *** User49 <User49!~User49@unaffiliated/user49> has joined #bzflag | 21:14 | |
| JeffM[m] | it's obvious they want everything to go full metal | 21:14 |
| macsforme | someone makes GL and GLES libraries that work on top of Metal (better performance than Apple's own GL, too)... I wish Apple would just buy them and incorporate them into their SDK | 21:26 |
| blast007 | oh god no, I don't want Apple to buy them | 21:27 |
| blast007 | they'd just kill them off | 21:27 |
| JeffM[m] | Yeah apple wants ONE API for each thing | 21:28 |
| JeffM[m] | They have no incentive to be inclusive, they expect everyone to just do what they say, and be happy to pay 30% | 21:28 |
| blast007 | macsforme: are you talking about MoltenGL? | 21:28 |
| macsforme | I think so | 21:29 |
| blast007 | MoltenVK (Vulkan to Metal) is open-source https://github.com/KhronosGroup/MoltenVK | 21:29 |
| macsforme | if only that helped us :-) | 21:29 |
| JeffM[m] | write a metal backend for urho3d :) | 21:30 |
| blast007 | there's also a half dozen (at least) different graphics libraries that let you target multiple graphics APIs | 21:31 |
| *** joevano <joevano!~joevano@bzflag/developer/JoeVano> has quit IRC (*.net *.split) | 21:59 | |
| *** joevano <joevano!~joevano@bzflag/developer/JoeVano> has joined #bzflag | 21:59 | |
| *** ChanServ sets mode: +v joevano | 21:59 | |
| *** infobot <infobot!ibot@96-86-209-99-static.hfc.comcastbusiness.net> has quit IRC (Ping timeout: 246 seconds) | 22:02 | |
| *** infobot <infobot!ibot@96-86-209-99-static.hfc.comcastbusiness.net> has joined #bzflag | 22:03 | |
| *** ChanServ sets mode: +v infobot | 22:03 | |
| BulletCatcher | I run BZFlag with a 4:3 resolution on my 16:9 monitor to increase the vertical field of view. That's more important than any blurring due to interpolation. | 23:10 |
| JeffM[m] | could you not just change the FOV? | 23:11 |
| BulletCatcher | The FOV width is already maxed out. | 23:12 |
| BulletCatcher | The horizontal FOV is fixed to the edges of the window and the vertical FOV is adjusted to fit the current aspect ratio. | 23:14 |
| JeffM[m] | does your monitor black box the sides or stretch it? | 23:20 |
| BulletCatcher | It has black boxes on the sides to preserve the aspect ratio. | 23:50 |
Generated by irclog2html.py 2.17.3.dev0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!