| *** Sgeo <Sgeo!~Sgeo@ool-18b98455.dyn.optonline.net> has quit IRC (Ping timeout: 244 seconds) | 00:00 | |
| BZNotify | bzflag: macsforme commented on pull request #53 "-view three for greater or fewer than three monitors" by khonkhortisan (https://git.io/fjyoC): Anyone have thoughts on what to do with this?... | 00:05 |
|---|---|---|
| *** infobot <infobot!ibot@c-174-52-60-165.hsd1.ut.comcast.net> has quit IRC (Ping timeout: 246 seconds) | 00:07 | |
| blast007 | macsforme: I lean more towards removing the -view option completely | 00:07 |
| macsforme | I'd go along with that | 00:08 |
| blast007 | the majority of the modes are for very specific setups or old school HMDs | 00:09 |
| macsforme | I'd like to eventually support multiple monitors as far as being able to move the radar to a second screen (for example), and maybe multiple 3D views assuming there isn't a significant advantage with that | 00:15 |
| short_circuit | 8~D | 00:16 |
| *** Zehra <Zehra!~Zehra@unaffiliated/zehra> has joined #bzflag | 00:36 | |
| BZNotify | bzflag: macsforme opened pull request #206 "Symbols hidden by default (and manually exported) when compiling with clang" (https://git.io/fjyoE) | 00:37 |
| BZNotify | bzflag: macsforme review_requested pull request #206 "Symbols hidden by default (and manually exported) when compiling with clang" (https://git.io/fjyoE) | 00:37 |
| *** BZNotify <BZNotify!BZNotify@2600:3c00::f03c:91ff:fe1f:d52a> has joined #bzflag | 00:43 | |
| BZNotify | bzflag: macsforme opened pull request #207 "Symbols hidden by default (and manually exported) when compiling with macOS using clang on master" (https://git.io/fjyoK) | 00:56 |
| BZNotify | bzflag: macsforme review_requested pull request #207 | 00:56 |
| macsforme | we can probably merge a lot of our PRs... the TimeKeeper refactor to std::chrono, the radar/console height controlled by BZDB, the simplified singleton pattern, and the clang visibility fixes | 01:20 |
| *** FusionDude <FusionDude!~flash@2601:280:c200:4e39:24d6:3d50:dcf:a9f7> has quit IRC (Ping timeout: 250 seconds) | 01:24 | |
| blast007 | the timekeeper one needs some cleanup. it wasn't made in a branch, so it has a unrelated commits now, including adding a CONTRIBUTING.md file. | 01:31 |
| macsforme | okay | 01:31 |
| macsforme | perhaps tupone can tell us about the status of his PRs so we can evaluate those too | 01:31 |
| blast007 | do we want GL2.0 to get merged into 2.4 or master? | 01:31 |
| blast007 | (just planning ahead) | 01:32 |
| *** Flash <Flash!~flash@2601:280:c200:4e39:b946:6a76:7859:7237> has joined #bzflag | 01:34 | |
| *** ChanServ sets mode: +v Flash | 01:34 | |
| macsforme | I think probably master | 01:36 |
| macsforme | reading through the changes, it looks like tupone's PRs (and other branches he's mentioned that don't have PRs yet) have dependencies on other branches/PRs | 01:44 |
| macsforme | before we consider any of those, I would like to understand what depends on what, and some of the PRs need a better summary of the changes and/or a rationale for the changes | 01:52 |
| macsforme | the idea of using glm is growing on me... I am open to doing it in master, so we can more easily add it to the dependencies package on macOS | 01:54 |
| blast007 | yeah, I'm fine with glm. just wan't sure if we wanted to switch to it in 2.4 as it *could* potentially alter our simulation math causing a mismatch between client versions. | 02:08 |
| macsforme | the GM math PR has a good summary/rationale, but it will be easier to read after the glm changes are merged (so we can see what changes are specific to that PR) | 02:09 |
| macsforme | yeah, I think all of this needs to go into master | 02:10 |
| macsforme | the VBO PR I don't understand... it has no summary, it seems to have unrelated changes, it seems to depend on the glm PR, and it seems to be largely a duplication of my own effort porting immediate mode drawing to vertex arrays in the embedded branch | 02:21 |
| macsforme | I don't see the point of a PR saying "Do not merge now"... I think you make a PR when it's ready... we should probably just close that one | 02:25 |
| BZNotify | bzflag: macsforme commented on pull request #175 "refactor TimeKeeper to use std::chrono" by jwmelto (https://git.io/fjyK4): Per @blast007, prior to merging, this needs to be cleaned up to rem... | 02:30 |
| BZNotify | bzflag: blast007 commented on pull request #175 "refactor TimeKeeper to use std::chrono" by jwmelto (https://git.io/fjyKB): Using a separate branch for each PR will help keep the changes clea... | 02:39 |
| *** short_circuit <short_circuit!~james@2601:2c5:c600:2365:23dc:3205:2d10:9731> has quit IRC (Ping timeout: 276 seconds) | 02:54 | |
| *** Sgeo__ <Sgeo__!~Sgeo@ool-18b98455.dyn.optonline.net> has joined #bzflag | 03:10 | |
| *** Sgeo_ <Sgeo_!~Sgeo@ool-18b98455.dyn.optonline.net> has quit IRC (Ping timeout: 245 seconds) | 03:13 | |
| *** Zehra <Zehra!~Zehra@unaffiliated/zehra> has quit IRC (Quit: Gone for now.) | 03:25 | |
| BZNotify | bzflag: jwmelto commented on pull request #175 "refactor TimeKeeper to use std::chrono" (https://git.io/fjyiW): What did I do? ... | 06:37 |
| BZNotify | bzflag: jwmelto closed pull request #175 | 06:37 |
| *** Sgeo__ <Sgeo__!~Sgeo@ool-18b98455.dyn.optonline.net> has quit IRC (Read error: Connection reset by peer) | 13:19 | |
| *** Sgeo__ <Sgeo__!~Sgeo@ool-18b98455.dyn.optonline.net> has joined #bzflag | 13:19 | |
| *** short_circuit <short_circuit!~james@2601:2c5:c600:2365::494a> has joined #bzflag | 13:37 | |
| *** Zehra <Zehra!~Zehra@unaffiliated/zehra> has joined #bzflag | 14:56 | |
| *** Sgeo__ <Sgeo__!~Sgeo@ool-18b98455.dyn.optonline.net> has quit IRC (Ping timeout: 245 seconds) | 15:45 | |
| *** Sgeo <Sgeo!~Sgeo@ool-18b98455.dyn.optonline.net> has joined #bzflag | 16:54 | |
| BZNotify | bzflag: Zehra opened pull request #208 "Cleanup for consistency with mesh rendering" (https://git.io/fjy7Q) | 17:18 |
| blast007 | Zehra: for a moment, I thought you had written some code. | 17:23 |
| Zehra | Hence the usage of the term "cleanup", as it implies removal of code and not the writing of it. | 17:26 |
| Zehra | Still, I am checking through previous works/projects..etc, so likely sooner or later I will follow with some PRs of my own code. | 17:27 |
| blast007 | cleanup does not imply only removal. when you clean up your room, do you just throw everything away? | 17:29 |
| Zehra | Nope, although I perhaps should have simply used "removal" instead. | 17:34 |
| *** Foo_man_choo <Foo_man_choo!~james@2601:2c5:c600:2365::494a> has joined #bzflag | 18:04 | |
| *** short_circuit <short_circuit!~james@2601:2c5:c600:2365::494a> has quit IRC (Read error: Connection reset by peer) | 18:04 | |
| BZNotify | bzflag: atupone edited pull request #148 "Use of Vertex Buffer Objects instead of Client Arrays" (https://git.io/vhCKr) | 19:15 |
| BZNotify | bzflag: atupone edited pull request #148 "Use of Vertex Buffer Objects instead of Client Arrays" (https://git.io/vhCKr) | 19:17 |
| tupone | the GL2.0 branch is based on the VBO pull request | 19:18 |
| tupone | only 4 commits more | 19:23 |
| Flash | anyone ever used ZeroMQ ? | 19:33 |
| Flash | http://zeromq.org/intro:read-the-manual | 19:36 |
| Flash | while it isn't necessarily appropriate for client/server communication, it could be an interesting choice for intra-server, cross-thread communication | 19:36 |
| Flash | potentially making the plugin API more isolated | 19:37 |
| Flash | of course, we do have a lot of TCP traffic from client to server | 19:38 |
| blast007 | having plugins run as a separate process you mean? | 19:39 |
| Flash | not required, but it would be possible | 19:39 |
| Flash | one of the uses of ZMQ replaces message queues with a lock-free paradigm | 19:40 |
| Flash | our current API is direct message call, which has argument-passing concerns | 19:40 |
| Flash | things like "don't let templates cross the API boundary" that most developers are unaware of | 19:40 |
| Flash | I don't have a full-fledged proposal, just wondering if anyone else has ever used it | 19:41 |
| blast007 | I messed with it a very tiny bit years ago | 19:42 |
| Flash | what was your application? | 19:42 |
| blast007 | think I was trying to use it with PHP and didn't get real far | 19:42 |
| blast007 | "getting it to work" | 19:42 |
| Flash | ah. | 19:42 |
| Flash | I'm using it for distributed messaging, but I got a python client to talk to my C++ components trivially | 19:43 |
| Flash | we have an engineering tool (web server) written in Python that stimulates the C2 interface of our components via web page | 19:43 |
| Flash | only using PUB/SUB and REQ/REP right now | 19:44 |
| blast007 | I can't even recall what I was planning to use it for. | 19:44 |
| Flash | what are we using UDP for now? server to clients or clients to server? | 19:45 |
| blast007 | yes :) | 19:48 |
| blast007 | UDP is used for things we can miss some of (well, and shots.. so shots can sometimes go missing, or the shot end of a GM can so the GM never ends until it hits something) | 19:49 |
| blast007 | for plugins, I've considering using a scripting language instead of the C/C++ API | 19:50 |
| blast007 | for networking, I've considered something like ENet, RakNet (or SLikeNet, a fork), or yojimbo | 19:53 |
| Flash | I think Jeff had mentioned RakNet to me before | 19:54 |
| blast007 | RakNet proper has seen no changes since OculusVR/Facebook open-sourced it | 19:55 |
| blast007 | the fork I mentioned is probably one of the most active/supported forks | 19:55 |
| Flash | the problem with open source projects is that they seem to have short life spans | 19:55 |
| blast007 | RakNet was originally a commercial library | 19:57 |
| *** Sgeo_ <Sgeo_!~Sgeo@ool-18b98455.dyn.optonline.net> has joined #bzflag | 21:02 | |
| *** Sgeo <Sgeo!~Sgeo@ool-18b98455.dyn.optonline.net> has quit IRC (Ping timeout: 245 seconds) | 21:05 | |
| macsforme | tupone: thanks for your improved documentation | 21:09 |
| macsforme | so it sounds like the merge order needs to be glm first, then the missile math, then GL 2.0 | 21:11 |
| macsforme | are you okay with closing the VBO PR and then just merging those changes in with GL2.0 when it's ready? | 21:14 |
| *** Sgeo__ <Sgeo__!~Sgeo@ool-18b98455.dyn.optonline.net> has joined #bzflag | 21:36 | |
| *** Sgeo_ <Sgeo_!~Sgeo@ool-18b98455.dyn.optonline.net> has quit IRC (Ping timeout: 268 seconds) | 21:39 | |
Generated by irclog2html.py 2.17.3.dev0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!