| 00:03.34 | BulletCatcher | Bookmarked. Thanks. |
| 00:26.20 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 00:58.44 | *** join/#bzflag Shuist (~Shuist@ppp203-122-213-220.static.internode.on.net) |
| 01:03.32 | *** join/#bzflag macsforme (~macsforme@bzflag/developer/Constitution) |
| 01:03.32 | *** mode/#bzflag [+o macsforme] by ChanServ |
| 01:08.31 | *** join/#bzflag macsforme (~macsforme@bzflag/developer/Constitution) |
| 01:08.31 | *** mode/#bzflag [+o macsforme] by ChanServ |
| 01:11.32 | *** join/#bzflag macsforme (~macsforme@bzflag/developer/Constitution) |
| 01:11.32 | *** mode/#bzflag [+o macsforme] by ChanServ |
| 01:26.31 | *** join/#bzflag macsforme (~macsforme@bzflag/developer/Constitution) |
| 01:26.31 | *** mode/#bzflag [+o macsforme] by ChanServ |
| 01:28.32 | *** join/#bzflag macsforme (~macsforme@bzflag/developer/Constitution) |
| 01:28.32 | *** mode/#bzflag [+o macsforme] by ChanServ |
| 01:33.31 | *** join/#bzflag macsforme (~macsforme@bzflag/developer/Constitution) |
| 01:33.31 | *** mode/#bzflag [+o macsforme] by ChanServ |
| 02:10.59 | macsforme | for the curious, here's a comparison of BZFlag build times with everything enabled across three different operating systems and compilers: https://gist.github.com/macsforme/092e348f3774a54493aadca82c677d53 |
| 02:11.15 | macsforme | all performed on the same machine |
| 02:18.06 | macsforme | it seems weird to me that it takes that much longer in Visual Studio... I wonder if there are multithreaded compiling settings that I need to tweak |
| 02:20.29 | JeffM | Yes and no |
| 02:20.39 | JeffM | By default it builds one project in a thread |
| 02:20.55 | JeffM | It does not use multiple CPUs for files in a project |
| 02:21.12 | JeffM | So it's not exactly the same as GCC/llama |
| 02:21.16 | macsforme | ah |
| 02:25.02 | JeffM | So it depends on how much the code is broken into DLLs |
| 02:25.17 | JeffM | There are third party products that spread the load on a per file basis |
| 02:25.20 | JeffM | We use one at work |
| 02:28.14 | macsforme | since it was almost exactly double, I wondered if it was compiling multithreaded but not using hyperthreading |
| 02:29.58 | macsforme | so only two things at a time instead of four |
| 02:37.58 | JeffM | It may have for most of it |
| 02:38.08 | JeffM | There are settings for how many projects to do at a time |
| 03:21.55 | the_map | I like that chart, macsforme |
| 04:06.38 | *** join/#bzflag araa (~bonaque@zamok.crans.org) |
| 04:54.16 | macsforme | you like that it shows the superiority of Linux? ;) |
| 04:54.55 | the_map | nah, I already knew that ;P |
| 04:55.14 | the_map | I just really liked the chart |
| 04:55.23 | the_map | I like tables like that :) |
| 04:55.26 | allejo | hails Linux |
| 04:59.01 | macsforme | :) |
| 04:59.10 | macsforme | I wonder if Linux would be even faster with clang |
| 04:59.28 | macsforme | because actually it was fastest on macOS |
| 04:59.37 | macsforme | (which uses clang) |
| 05:00.21 | *** join/#bzflag a_meteorite (~a_meteori@unaffiliated/ameteorite/x-000000001) |
| 05:00.27 | the_map | <macsforme> it was fastest on macOS |
| 05:00.39 | the_map | and these tests were all run on your computer? |
| 05:00.58 | the_map | ;) |
| 05:04.32 | macsforme | yes, all on the same machine... otherwise it wouldn't be much of a fair test |
| 05:06.25 | allejo | triboot or vm |
| 05:07.48 | the_map | macsforme: I was making a joke about the validity of the data given your theoretical interest in it saying what you want |
| 05:09.02 | the_map | but on a similar note to what allejo is asking, would windows run better on a windows computer than on a mac computer? I could see mac software running best on a mac computer |
| 05:09.24 | the_map | out of curiosity, not out of doubting you |
| 05:09.50 | macsforme | it was all native... I triple boot my machine |
| 05:10.25 | macsforme | so it was at least as level of a playing field as I could get |
| 08:34.04 | *** join/#bzflag BZnotify (~BZnotify@192.30.252.40) |
| 08:34.04 | BZnotify | [13bzflag] 15macsforme pushed 1 new commit to 062.4: 02https://git.io/vMFFp |
| 08:34.04 | BZnotify | 13bzflag/062.4 14839026c 15Joshua Bodine: Fixed loading plugins by name straight from the .app in macOS. |
| 08:34.04 | *** part/#bzflag BZnotify (~BZnotify@192.30.252.40) |
| 11:13.24 | blast007 | the_map: modern day macs are just normal computers with a few exotic parts |
| 11:51.38 | *** join/#bzflag Shuist (~Shuist@ppp203-122-213-220.static.internode.on.net) |
| 12:34.56 | *** join/#bzflag notnadir (uid134094@gateway/web/irccloud.com/x-mwqozqydfvzfvcbv) |
| 12:49.38 | *** join/#bzflag nadir (uid134094@gateway/web/irccloud.com/x-kjcauhejboelyyry) |
| 15:38.19 | allejo | ...and are soldered together |
| 15:42.49 | blast007 | allejo: well how else would they make them super thin and upsell you on overpriced RAM upgrades? |
| 15:43.30 | allejo | :) |
| 15:47.58 | *** join/#bzflag KaadmY (uid135503@gateway/web/irccloud.com/x-yvepmjgprdxsnkuf) |
| 16:04.41 | JeffM | blast007: you can get a ram upgrade? they are soldered on |
| 16:05.27 | blast007 | JeffM: thus the upsell |
| 16:07.31 | blast007 | I'd still call it an upgrade if you're increasing the specs at the time of purchase |
| 16:07.49 | JeffM | I call that "buying a different computer" |
| 16:08.53 | JeffM | I'm asking in #freeenode for how to turn control of #bzflag-chat to you guys |
| 16:09.09 | JeffM | jeffm2501 is expired and can not affect his will over any channels |
| 16:10.25 | blast007 | that channel really isn't all that useful anyway |
| 16:10.43 | JeffM | well you can decide to delete it if you want |
| 16:10.54 | JeffM | SOMONE should have control over it |
| 16:11.34 | JeffM | you could set it to redirect here |
| 16:21.30 | JeffM | so tim has to request the transfer, I'll send him an email |
| 16:27.05 | JeffM | sent |
| 16:46.20 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |
| 19:06.25 | *** join/#bzflag a_meteorite (~a_meteori@unaffiliated/ameteorite/x-000000001) |
| 19:54.59 | *** join/#bzflag tupone (~alfredo@gentoo/developer/tupone) |
| 20:32.11 | macsforme | I'm afraid the industry in general is following Apple's lead in regards to the everything-soldered approach, at least with some of the ultra-thin portables and two-in-ones |
| 20:32.37 | macsforme | although not on desktops... I still don't understand how they get away with that |
| 21:01.53 | tupone | macsforme: hi. regarding your email, I'm afraid I cannot book any time for meeting. Maybe I can have some chat, but not regularly. I see e-mail though. Maybe as backup ? |
| 21:06.07 | macsforme | works for me, thanks |
| 21:06.36 | macsforme | or I think it will, depending on who else answers :) backup is better than nothing, though |
| 21:07.06 | tupone | Are there a list of ideas ? I have started something but lack of time |
| 21:07.29 | tupone | well, different priority :) |
| 21:07.43 | macsforme | not yet... I was going to start a document within the next few days |
| 21:08.39 | macsforme | they have to be ideas that are more tied into the main code this time |
| 21:09.18 | tupone | My idea however, was reducing the jitter/lag introduced by the screen-swap, by doing multitasking, while retaining the vsync |
| 21:10.27 | blast007 | decoupling the simulation/network code from the graphics code? |
| 21:10.49 | tupone | decoupling network-input |
| 21:10.58 | tupone | and simulation |
| 21:11.05 | macsforme | that sounds like a great idea |
| 21:13.05 | tupone | and doing network with a task, well 2, we don't need to retain the strange network code we have as this will not affect the lag anymore |
| 21:17.13 | macsforme | when I was researching physics engines, I saw that some of them can do "soft" updates that don't actually update the positions but will give you a predicted mid-update position that you can use to render a frame... if we totally de-couple the sim update from the rendering, I wonder if we can do something like that |
| 21:17.56 | macsforme | otherwise we still need at least one sim update per frame to make it smooth |
| 21:31.46 | tupone | mid position update can be also used to detect kill |
| 21:31.57 | tupone | not only for better physic |
| 21:32.26 | blast007 | wouldn't that just *be* another sim update? |
| 21:32.34 | tupone | yes |
| 21:32.35 | macsforme | yeah |
| 21:32.42 | tupone | not linked to screen refresh |
| 21:34.06 | blast007 | http://gafferongames.com/networked-physics/deterministic-lockstep/ |
| 21:41.30 | tupone | interesting |
| 21:56.08 | *** join/#bzflag KaadmY (uid135503@gateway/web/irccloud.com/x-vrageqyobkuoixgh) |
| 22:01.23 | blast007 | that's similar to how a lot of modern FPS games work |
| 22:02.26 | blast007 | they send input, not position/velocity/statuses, and the server uses that to calculate the game state |
| 22:03.49 | blast007 | the local client would also calculate it's own local game state so that there isn't horrid delays between input and the result of that input, and ideally it should remain the same as the server state. If there's ever a difference, the server state would overwrite the local client state (either immediately or gradually). |
| 22:04.44 | blast007 | that's likely our ideal path for the game |
| 22:05.02 | blast007 | then the server would have a proper state, and we could finally do death checks on the server |
| 22:11.22 | kierra | blast007: ping |
| 23:17.45 | macsforme | are our .la files generated by libtool for our plugins important? it looks like premake doesn't create them |
| 23:26.23 | BulletCatcher | Fedora doesn't install the .la files, so they probably aren't really necessary. |
| 23:26.42 | JeffM | are those link libs? |
| 23:27.39 | macsforme | they seem to be text files that describe the library |
| 23:27.51 | JeffM | ahh name unmagler |
| 23:28.13 | JeffM | yeah those would not be needed, the only thing bzfs gets from the plugin dynamic lib is the specific functions |
| 23:28.29 | macsforme | "# Please DO NOT delete this file! # It is necessary for linking the library." |
| 23:28.32 | JeffM | it's like the export lib that vc makes for dlls |
| 23:28.43 | JeffM | yeah that's linking TO the library |
| 23:28.58 | JeffM | the .so is not compile time linked to any binary |
| 23:29.05 | JeffM | it's runtime loaded |
| 23:29.17 | macsforme | okay |
| 23:29.25 | JeffM | it would be like if you wanted a compile time link to a library |
| 23:29.50 | JeffM | like if you wanted BZFS to always link to a specific plugin, in a sort of static way |
| 23:30.06 | JeffM | but still dyanmiucaly loaded, just automaticly loaded |
| 23:30.36 | JeffM | on windows, SDL is a dll, and it has an export lib. bzflag links to the export lib so that it has a hard link to the dll |
| 23:31.12 | JeffM | the export lib doesn't have the code in it, it's not a static library, it just has info about the exported functions in the DLL so the .exe can load it automaticly with out having to call LoadLibrary and GetProcAddr |
| 23:31.27 | JeffM | nobody does that TO plugins, plugins do that TO bzfs |
| 23:31.51 | BulletCatcher | Insert "In Soviet Russia" joke here. |
| 23:32.13 | JeffM | thats why on windows you need the bzfs.lib, so the plugins know how to get all the API functions with out explicity loading them by name. |
| 23:34.32 | macsforme | does anyone remember why we originally switched to compiling using libtool? |
| 23:35.04 | JeffM | I belive it did the correct stuff to make plugins work |
| 23:35.30 | JeffM | the old make file just wanted to staticly link all the plugins and didn't generate .so files |
| 23:35.40 | JeffM | IIRC that was all brlcad |
| 23:36.13 | macsforme | I've compiled 3rd-party plugins without libtool... it was just gcc file.cpp -shared -o file.so, iirc |
| 23:36.35 | JeffM | and they load into bzfs? |
| 23:36.46 | macsforme | yes |
| 23:36.56 | JeffM | then perhaps it is no longer such an issue |
| 23:37.08 | macsforme | maybe there was some other advantage, or it helped on the bzfs end, but I've always wondered |
| 23:37.12 | JeffM | this was many many moons ago |