| 00:23.43 | *** join/#bzflag infobot (ibot@rikers.org) |
| 00:23.43 | *** topic/#bzflag is https://BZFlag.org || http://ohloh.net/p/bzflag || https://bzflag.org/help || Channel Logs: http://infobot.rikers.org/%23bzflag/ || 2.4.14 released! https://forums.bzflag.org/viewtopic.php?f=62&t=19953 |
| 00:23.43 | *** mode/#bzflag [+v infobot] by ChanServ |
| 01:09.19 | *** join/#bzflag bertman (~bert@unaffiliated/bertman) |
| 01:10.20 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 01:20.23 | macsforme | allejo: I tried every version of SDL 2 back to 2.0.3, and nothing would fix it... then I tried building bz 2.4.10 against a few of those versions, and still nothing would fix it |
| 01:22.10 | macsforme | I saw 2.4.10 was originally compiled with Xcode 7.2.1, so I booted into Yosemite and tried compiling with that... compiling bz 2.4.14 with SDL 2.0.8 (the latest) on Xcode 7.2.1 resulted in a good build without the problem |
| 01:22.40 | macsforme | so the problem appears related to compiling our code with a certain version of Xcode... |
| 01:24.34 | macsforme | at this point I guess I should just rebuild 2.4.14 with the older version of Xcode and re-upload it? |
| 01:27.05 | blast007 | you could name the file 2.4.14.1 if you want to show that it's different |
| 01:27.33 | blast007 | do you think it's a bug with SDL2 or something we're doing? |
| 01:28.36 | *** join/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-ysslwefpzwzpxpwj) |
| 01:28.36 | BZnotify | [13bzflag-dependencies] 15blast007 pushed 1 new commit to 06master: 02https://git.io/vpDTG |
| 01:28.36 | BZnotify | 13bzflag-dependencies/06master 1483c7e86 15Scott Wichser: Merge remote-tracking branch 'origin/2.4'... |
| 01:28.36 | *** part/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-ysslwefpzwzpxpwj) |
| 01:29.33 | *** join/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-woaclihmugjuiygg) |
| 01:29.33 | BZnotify | [13bzflag] 15blast007 pushed 1 new commit to 06master: 02https://git.io/vpDT0 |
| 01:29.33 | BZnotify | 13bzflag/06master 14a4f6402 15Scott Wichser: Merge remote-tracking branch 'origin/2.4' |
| 01:29.33 | *** part/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-woaclihmugjuiygg) |
| 01:31.00 | *** join/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-qmmvpymmrwdxjfsw) |
| 01:31.00 | BZnotify | [13bzflag-dependencies] 15blast007 pushed 1 new commit to 06master: 02https://git.io/vpDTS |
| 01:31.00 | BZnotify | 13bzflag-dependencies/06master 1424166b2 15Scott Wichser: Copy the libpng license file. |
| 01:31.00 | *** part/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-qmmvpymmrwdxjfsw) |
| 01:34.44 | blast007 | are we wanting GLEW for 2.4, or 2.6? |
| 01:35.20 | macsforme | I don't think it's in our code... I think it's somewhere between SDL and the platform SDK, maybe having to do with which version the library was compiled on versus our game code |
| 01:35.50 | blast007 | are you compiling SDL or using a pre-built bin? |
| 01:35.59 | macsforme | I should try compiling SDL from source on Stoned Sierra too to see if that makes any difference |
| 01:36.21 | macsforme | pre-built |
| 01:37.42 | macsforme | I think GLEW can go in 2.4 |
| 01:38.23 | blast007 | as a hard requirement this time? previously, I believe it was optional |
| 01:38.42 | macsforme | yes |
| 01:39.28 | macsforme | otherwise I don't see the point, if we're going to keep our own redundant functionality |
| 01:39.41 | blast007 | right, I agree |
| 01:45.55 | blast007 | oh, and I guess GLEW only has up through VC12 project files in the *released* version |
| 01:48.06 | macsforme | it has CMake support, right? could we build our own? |
| 01:48.23 | blast007 | yeah, but I'm gonna see if I can make it work with that quick |
| 01:48.46 | blast007 | I did some similar magic for SDL2 |
| 01:50.18 | *** join/#bzflag The_Noah (~The_Noah@cpe-97-99-253-228.tx.res.rr.com) |
| 01:50.41 | macsforme | I built SDL 2 from source on high sierra and it had the same problem we were seeing |
| 01:50.59 | blast007 | what is the issue? |
| 01:51.00 | macsforme | when I built bz on high sierra also |
| 01:51.30 | macsforme | iconify doesn't work... it keeps the window in fullscreen but just shoves it behind the dock and menu |
| 01:51.59 | blast007 | weird |
| 01:52.10 | BulletCatcher | We used GLEW as recently as version 2.4.2. It was removed 3 years ago starting with Git commit 4d0722e, so there shouldn't be any problem bringing it back to 2.4. |
| 01:52.43 | blast007 | BulletCatcher: I think a lot of distributions even still list it as a dependency :) |
| 01:59.04 | BulletCatcher | I get the same behavior from the current test program in all 4 fullscreen modes. |
| 02:00.08 | blast007 | a blank window for all 4? |
| 02:01.09 | BulletCatcher | I see the colorful triangle in window mode, and black in the 3 fullscreen modes. |
| 02:01.28 | blast007 | and nothing from stderr output? |
| 02:01.47 | BulletCatcher | Nothing. |
| 02:28.18 | blast007 | I have GLEW added to the bzflag-dependencies. I'll try the GLEW PR another night. |
| 03:25.27 | *** join/#bzflag FastLizard4 (fastlizard@wikipedia/pdpc.active.FastLizard4) |
| 03:33.41 | *** join/#bzflag Kutakizukari (~Kutakizuk@207.189.2.25) |
| 06:02.54 | tupone | maybe we can try create window single buffer just to see if is a problem on the swapbuffer |
| 06:08.16 | tupone | hmm no flag to set it :/ |
| 06:11.25 | tupone | SDL_GL_SetAttribute(SDL_GL_DOUBLEBUFFER, 0); |
| 06:20.37 | *** join/#bzflag The_Noah (~The_Noah@cpe-97-99-253-228.tx.res.rr.com) |
| 07:35.47 | *** join/#bzflag The_Noah (~The_Noah@cpe-97-99-253-228.tx.res.rr.com) |
| 08:06.31 | *** join/#bzflag Kutakizukari (~Kutakizuk@192.171.255.53) |
| 09:35.36 | *** join/#bzflag The_Noah (~The_Noah@cpe-97-99-253-228.tx.res.rr.com) |
| 10:52.05 | blast007 | is it okay if we move the glewInit from SDL2Window::makeContext to OpenGLGState::initContext (after the call to ContextInitializer::executeFreeFuncs) ? |
| 10:53.25 | *** join/#bzflag The_Noah (~The_Noah@cpe-97-99-253-228.tx.res.rr.com) |
| 11:07.53 | blast007 | (that restores anisotropic filtering on SDL1) |
| 11:51.35 | tupone | it should be after any createcontext |
| 11:53.09 | tupone | i should look into the bzflag if that place is ok. |
| 12:17.44 | *** join/#bzflag The_Noah (~The_Noah@cpe-97-99-253-228.tx.res.rr.com) |
| 15:24.53 | *** join/#bzflag nadir (uid134094@gateway/web/irccloud.com/x-enpbokljjkirdxbx) |
| 16:53.07 | tupone | yes (IMHO), for SDL2 is ok, and maybe for all |
| 17:30.56 | blast007 | does it matter where in OpenGLGState::initContext it goes? we previously had it in there before the ContextInitializer::executeFreeFuncs() call |
| 17:42.01 | tupone | I guess that it does not matter, unless they call some gl function that are invalidated by changing context. |
| 17:42.11 | tupone | I suppose this event is very rare |
| 17:42.55 | tupone | Have you tried to change the standalone program to set single buffer ? |
| 17:45.24 | blast007 | I haven't, but I'm also not having an issue with the test program (other than mode 2 not working, but that's either not supposed to work or I'm doing it wrong) |
| 18:47.12 | tupone | My guess is that the problem rely on swap buffer not working on that platform. |
| 18:47.21 | tupone | and SDL2 |
| 19:15.44 | blast007 | it works with SDL1, just not SDL2 |
| 19:16.22 | tupone | I know |
| 19:56.00 | *** join/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-igrjvzhulictjkbr) |
| 19:56.00 | BZnotify | [13bzflag] 15atupone opened pull request #111: Enable unbuffered openGL with bzflag -singlebuffer (062.4...06SingleBuffer) 02https://git.io/vpyoV |
| 19:56.00 | *** part/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-igrjvzhulictjkbr) |
| 19:57.14 | tupone | BulletCatcher: something for you to test |
| 22:08.48 | *** join/#bzflag The_Noah (~The_Noah@cpe-97-99-253-228.tx.res.rr.com) |
| 23:25.13 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |