| 00:45.22 | short_circuit | Funny.... I just ordered some shoes on Amazon a few minutes ago.. Come back to see this XD |
| 00:46.47 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |
| 01:05.58 | *** join/#bzflag Zehra (~Zehra@2601:58b:c600:3349:90c5:2bbe:fb16:8666) |
| 01:05.58 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |
| 07:45.58 | *** join/#bzflag bboles (~quassel@2607:fcd0:100:8301:378::86) |
| 10:10.30 | *** mode/#bzflag [+o blast007] by ChanServ |
| 10:10.47 | *** mode/#bzflag [-b *!*@47.185.225.32] by blast007 |
| 10:10.50 | *** mode/#bzflag [-o blast007] by blast007 |
| 12:13.19 | *** join/#bzflag Sgeo__ (~Sgeo@ool-18b98dd9.dyn.optonline.net) |
| 13:34.50 | *** part/#bzflag Guest62808 (~quassel@00.alucard.sujevo.io) |
| 13:38.50 | *** join/#bzflag moriah (~quassel@unaffiliated/kierra) |
| 13:45.38 | BZNotify` | 022.4 @ bzflag: 03blast007 pushed 3 commits (06https://git.io/fjmnB): |
| 13:45.39 | BZNotify` | 022.4 @ bzflag: 03blast007 14a43cef: Look up the flag hiding BZDB vars once per frame instead of once per flag per frame. (06https://git.io/fjmnR) |
| 13:45.40 | BZNotify` | 022.4 @ bzflag: 03blast007 14c559ce: Add the Open Free For All mode to the Start Server menu. (06https://git.io/fjmnE) |
| 13:45.41 | BZNotify` | 022.4 @ bzflag: 03blast007 14051f73: Sort locally discovered servers to the top of the server list. (06https://git.io/fjmnu) |
| 14:08.11 | blast007 | macsforme: for the premake5 stuff, is the idea to require premake5 to build BZFlag from source, or just to rebuild the project files? |
| 14:55.36 | *** join/#bzflag Peridot (~Peridot@47.185.225.32) |
| 14:56.41 | blast007 | wonders if Peridot's connection is working better :) |
| 14:58.35 | blast007 | I'll take that as a maybe |
| 16:12.49 | *** join/#bzflag Peridot1 (~Peridot@47.185.225.32) |
| 16:36.12 | *** join/#bzflag Peridot (~Peridot@47.185.225.32) |
| 16:45.51 | *** join/#bzflag Sgeo_ (~Sgeo@ool-18b98dd9.dyn.optonline.net) |
| 17:06.00 | *** join/#bzflag brlcad (~sean@104.225.5.10) |
| 17:06.07 | *** join/#bzflag catay (~smertens@valyria.catay.be) |
| 17:06.08 | *** join/#bzflag Swant (swant@freenode/staff/ikea) |
| 17:07.12 | *** join/#bzflag Peridot1 (~Peridot@47.185.225.32) |
| 17:11.21 | *** join/#bzflag tupone (~alfredo@gentoo/developer/tupone) |
| 17:21.45 | *** mode/#bzflag [+o blast007] by ChanServ |
| 17:21.59 | *** mode/#bzflag [+b *!*@47.185.225.32] by blast007 |
| 17:22.01 | *** mode/#bzflag [-o blast007] by blast007 |
| 17:30.36 | tupone | alpha not working and texture sometimes wrong :( (GLES1.1) |
| 18:38.28 | macsforme | blast007: I think for practical purposes, you will need premake5 at least to generate the project files the first time |
| 18:39.26 | macsforme | we could pre-generate them and include them with releases, but then it would be up to the user to make sure that the dependencies are in the right place (premake checks for that before generating projects, currently) |
| 18:40.18 | blast007 | can I generate the Xcode project files with premake5 on linux? |
| 18:41.50 | blast007 | if you want them part of the release, the Xcode projects should just be there so that 'make dist' includes them |
| 18:42.36 | macsforme | I tried generating files for one OS from a different one, and it seemed to work, but I don't know how reliable that will be |
| 18:42.55 | blast007 | if we're moving to having a dependency package for macOS as well, there's no need to use system-installed libs |
| 18:42.55 | macsforme | I think it's simpler not to include them |
| 18:43.08 | macsforme | yes |
| 18:43.36 | blast007 | simpler for who? |
| 18:43.53 | macsforme | us |
| 18:44.27 | blast007 | I don't see that |
| 18:44.47 | macsforme | buildmacos.sh in our bzflag-dependencies repository generates a working dependency package for macOS in master right now |
| 18:45.02 | blast007 | cuz now you're saying that we'd have to build the source tars by merging generated files from two different platforms |
| 18:45.15 | blast007 | currently I just run 'make dist' and I get source tars |
| 18:46.00 | macsforme | I meant that we don't include premake-generated project files in our releases, and make the user generate them |
| 18:46.35 | blast007 | I don't understand why that makes anything easier for anyone |
| 18:48.09 | macsforme | it won't be easier than what we have now, true (as far as releases are concerned) |
| 18:49.09 | macsforme | the benefit will be a near-zero maintenance burden for the macOS project files during development, when files are moved around or added/removed |
| 18:49.34 | blast007 | okay, but why not include the generated Xcode project files in Git? |
| 18:50.20 | macsforme | my main concern would be that they would become stale |
| 18:51.11 | blast007 | and that's a bigger problem then making everyone who wants to build from source download an alpha version of a build system? |
| 18:51.17 | blast007 | than* |
| 18:52.25 | macsforme | and when we add or remove a project (like a plugin), we have extra things to change so that the new project file is tracked in git |
| 18:53.38 | blast007 | if you have premake generating the project files, can't it just be run from time to time? wouldn't it generate identical output if nothing has changed? |
| 18:54.56 | blast007 | I imagine we could even set up a travis CI that would check for stale project files |
| 19:01.17 | macsforme | I think the question of which is a "bigger problem" is subject to opinion... for me, I see a lot of stale information/configuration/scripts/etc. in our repository, so I prioritize avoiding that, versus maybe the 2 - 3 people who will regularly build BZFlag on macOS, who should have premake installed anyway so they can do work on our source file layout (modifying/adding/deleting) |
| 19:02.16 | macsforme | and true, it could probably be automated, and have updated projects generated and committed when needed |
| 19:05.39 | macsforme | I think the best path forward will become clear with time, once we get people in the community building with this new method |
| 19:24.03 | tupone | macsforme: did alpha worked for you? (Mesa and openGL ES) |
| 19:28.42 | macsforme | tupone: yes, I think so... I remember some problems with GL_RGB textures not working with some implementations (everything had to be GL_RGBA), but that's the only problem I remember |
| 19:29.19 | macsforme | you can build my fork and see for yourself if you want a comparison |
| 19:29.29 | tupone | The error I get is directly from Mesa/SDL2. |
| 19:29.56 | macsforme | what's the error? |
| 19:30.13 | tupone | Window does not provide Gamma support |
| 19:30.23 | tupone | something like that |
| 19:31.43 | tupone | Everything is almost perfect only texturing is not so good. Maybe I have to use glues :) |
| 19:32.45 | tupone | Window doesn't have DirectColor visual |
| 19:32.54 | tupone | that is the exact error |
| 19:40.47 | macsforme | I do remember seeing an error about gamma not being supported... the other one, I don't recall |
| 19:41.34 | tupone | the last is from SDL2, bzflag translate as Gamma support |
| 19:42.51 | macsforme | that doesn't sound related to transparency though, does it? |
| 19:43.18 | tupone | My problem is not alpha nut gamma. Cannot set brightness |
| 19:43.26 | tupone | s/nut/but/ |
| 19:43.46 | macsforme | oh |
| 19:43.59 | macsforme | yes, I think I had that problem too |
| 19:44.51 | macsforme | I think that does not have good support in SDL with OpenGL ES contexts |
| 19:46.02 | tupone | for the texture ... do you know if some of the texture are not pot, at least in mofo ? |
| 19:46.54 | tupone | because I'm not scaling them at the moment |
| 19:47.20 | blast007 | pot = Power of Two? |
| 19:47.24 | tupone | yes |
| 22:51.03 | *** mode/#bzflag [+v spldart] by ChanServ |