| 00:31.38 | Zehra | Arena CTF released to the public: https://forums.bzflag.org/viewtopic.php?f=79&t=20450 |
| 00:40.22 | *** join/#bzflag User49 (~User49@unaffiliated/user49) |
| 00:51.37 | allejo | Zehra: there's bzu_getTeamFromFlag from plugin_utils.h |
| 00:52.28 | allejo | and bz_eTeamType is an enum, so you can do comparisons like `cappedTeam >= eRedTeam && cappedTeam <= ePurpleTeam` iirc |
| 00:54.18 | allejo | or just use an std::map<bz_eTeamType, bool> for keeping track if flags for a team have been touched |
| 00:54.41 | allejo | then you can just do `grabStatus[eRedTeam]` |
| 00:58.45 | Zehra | Thanks allejo. I noticed bzu_getTeamFromFlag, although requiring another header for a single function seemed a bit excessive. |
| 00:59.04 | Zehra | (For me.) |
| 00:59.19 | *** mode/#bzflag [-v short_circuit] by ChanServ |
| 01:00.19 | Zehra | I also forget that bz_eTeamType is an enumeration. (And RogueTeam being at zero would have affected calculations by being off by 1.) |
| 01:01.55 | allejo | it's a header, it'd be optimized out at compile time if that's what you're worried about but whatevs |
| 01:05.18 | Zehra | That's good, some of the earlier compilers didn't do so well and didn't properly optimize the code as expected. :) |
| 01:06.06 | blast007 | like.. back in the 70's? |
| 01:06.33 | *** join/#bzflag _I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 01:07.49 | Zehra | Well, comparing binary size, a megabyte in difference for a single change based on C or C++ style is a lot. |
| 01:08.02 | Zehra | Or included headers. |
| 01:09.14 | blast007 | your plugin is larger than 1MB? |
| 01:09.49 | Zehra | 18 kilobytes. |
| 01:10.13 | blast007 | what are you referring to then? |
| 01:11.11 | Zehra | Same output programs, but one in C and the other in C++, binary size of compile being over a megabyte in difference. |
| 01:11.41 | Zehra | Even though the exact same thing, only difference being code style and functions used. |
| 01:12.46 | Zehra | I'm sort of getting off topic though. |
| 01:21.15 | JeffM[m] | Thatâs the runtime |
| 01:23.00 | JeffM[m] | And did you compare release builds or debug? |
| 01:24.57 | Zehra | I'm not sure. (In both cases.[For plugin and/or program.]) |
| 01:25.08 | allejo | hmm with SAMPLE_PLUGIN, including the header file makes no difference. however linking to plugin_utils is 911K. w/o linking plugin_utils 35K |
| 01:25.40 | Zehra | ^ |
| 01:28.30 | JeffM[m] | Does it have static runtimes? |
| 01:29.31 | *** join/#bzflag bertman (~bert@c-69-254-102-169.hsd1.tn.comcast.net) |
| 01:29.52 | Zehra | No clue. |
| 01:32.11 | Zehra | Also in reference to program or SAMPLE_PLUGIN? |
| 01:32.33 | JeffM[m] | The lib for untill |
| 01:32.42 | JeffM[m] | Utils |
| 01:36.43 | allejo | how'd you check that? |
| 01:37.05 | JeffM[m] | Linker options on the lib when itâs built |
| 01:42.19 | allejo | not seeing any flags on plugin_util's makefile other than -avoid-version |
| 01:44.03 | JeffM[m] | Then itâll depend on what the compiler does by default, how big is the static lib? |
| 01:44.42 | JeffM[m] | My guess is the linker isnât optimizing dead code |
| 01:45.23 | JeffM[m] | Try adding the utils cpp files to the plugin directly, itâll then optimize the entire thing |
| 01:45.45 | JeffM[m] | There may be a âhole program optimization â option |
| 01:45.58 | JeffM[m] | I know how to do it in Windows, not gcc |
| 01:47.00 | allejo | static lib would be libplugin_utils.a, right? if so, 2M |
| 01:47.56 | JeffM[m] | Wow |
| 01:53.11 | allejo | I genuinely thought plugin_utils was including curl for the URL encoding/decoding functionality, however it's not being used there. so not sure where that size is coming from |
| 01:55.06 | JeffM[m] | Yeah that seem big |
| 02:06.22 | BZNotify | bzflag: 03allejo 03opened issue #263 "plugin_utils lib size seems too large" (06https://git.io/JU4re) |
| 02:06.23 | BZNotify | bzflag: 03allejo 11labeled issue #263 as 15needs triage |
| 02:06.24 | BZNotify | bzflag: 03allejo 11labeled issue #263 as 15needs more info |
| 02:08.06 | blast007 | 4.6M Sep 14 21:06 libplugin_utils.a |
| 02:08.12 | blast007 | (that's a release build) |
| 02:09.29 | JeffM[m] | Dammmmmmmmmmnnnnnn |
| 02:12.21 | FusionDude | so ... static libs and shared libs are treated completely differently by the linker |
| 02:12.52 | blast007 | the .a is an ar archive, which contains the four plugin_*.o files, which seem to not be stripped and have debug info, even though I'm not building debug |
| 02:13.07 | Flash | a static lib that is 2M might contribute a tiny 1K bit to the program |
| 02:13.58 | Flash | yes; think of a .a as like a zipped file of .o files. Only the .o files that are needed are pulled out of the library at link time |
| 02:14.23 | Flash | compared to a shared library, where the entire library is mmap'd into memory at run time (but only 1 copy for all users of the lib) |
| 02:15.11 | JeffM[m] | Yeah it should only link in what is used |
| 02:15.22 | blast007 | should those .o files be stripped? |
| 02:16.09 | Flash | that's a good question; I don't know. I know it needs enough symbol information to resolve link dependencies at runtime, but I haven't really dealt with stripping |
| 02:16.24 | allejo | ah yea, plugin_utils.o is coming in at ~752K for me which would explain the jump from 35K to 911K |
| 02:16.55 | Flash | yeah, so one symbol from that .o and you get the whole thing |
| 02:17.10 | Flash | if size is a huge concern, you can break it up into multiple compilation units |
| 02:17.27 | blast007 | looks like none of our .o files are stripped |
| 02:18.04 | Flash | I thought stripping happened to executables, after linking? |
| 02:18.39 | blast007 | bzflag: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=cccc5e925229de1eadd5221153e44ab9727bc397, with debug_info, not stripped |
| 02:19.27 | blast007 | so I feel like something is just very wrong... |
| 02:19.36 | blast007 | my bzflag binary is 91MB :) |
| 02:20.25 | Flash | is that a release build? |
| 02:20.42 | blast007 | all I did was ./configure, no arguments, so it *should* be |
| 02:20.54 | Flash | hmmm |
| 02:22.09 | blast007 | rebuilding an older version here just for a sanity check... |
| 02:26.03 | blast007 | well what the heck... |
| 02:26.55 | allejo | please tell me that latest 2.4 *is* the "optimized" version and it was larger in an older build |
| 02:27.56 | blast007 | 2.4.12 is what I tried, and that also resulted in a non-stripped bzflag binary (weighing it at 77MB) |
| 02:29.33 | *** join/#bzflag bboles (~quassel@2602:fe90:604:1b::52f2:f9b3) |
| 02:30.25 | Flash | looks to me that a straight build puts "-g -O2" in the flags |
| 02:32.35 | Flash | I have the Mac version of 2.4.20 and BZFlag is 3.7M |
| 02:32.54 | Flash | but XCode doesn't use configure |
| 02:33.25 | JeffM[m] | why didn't you go with premake again? |
| 02:34.02 | blast007 | the beta version that isn't packaged in most linux distributions? |
| 02:34.12 | JeffM[m] | so? |
| 02:34.41 | JeffM[m] | include a premade preamake makefile :) |
| 02:34.42 | allejo | this is the 2.4 branch. premake is used in the 2.5-dev branch, no? |
| 02:35.04 | blast007 | premake is available in the master version and used for macOS |
| 03:12.34 | BZNotify | bzflag: 03jwmelto commented on issue #263 "plugin_utils lib size seems too large" by 03allejo (06https://git.io/JU4og): `.so` is fundamentally different from `.a`. It's generally not a go... |
| 03:13.56 | Flash | JeffM[m]: by the way, good to see you; you haven't been around much |
| 03:14.23 | JeffM[m] | I have had my ways of seeing what is going on |
| 03:14.34 | Flash | lol ... lurkers-r-us |
| 03:15.29 | JeffM[m] | the riot thing makes it easy |
| 03:52.48 | BZNotify | bzflag: 03allejo 04closed pull request #262 "updated readme to reflect current plugin" by 03Zehra (06https://git.io/JUCTp) |
| 03:52.49 | BZNotify | 022.4 @ bzflag: 03allejo pushed 2 commits (06https://git.io/JU4KR): |
| 03:52.50 | BZNotify | 022.4 @ bzflag: 03Zehra 14bb6b7b: updated readme to reflect current plugin (06https://git.io/JU4K0) |
| 03:52.51 | BZNotify | 022.4 @ bzflag: 03allejo 14ef1c75: Merge pull request #262 from Zehra/shockwave-docs (06https://git.io/JU4KE) |
| 03:53.41 | BZNotify | bzflag: 03allejo edited pull request #262 "updated shockwaveDeath readme to remove nonexistent BZDB var" by 03Zehra (06https://git.io/JUCTp) |
| 04:12.03 | BulletCatcher | I recommend stripping a .o file once so you learn why not to do it ever again. ;-) |
| 04:12.30 | Flash | that sounds ominous :) |
| 04:13.21 | BulletCatcher | Hint: run "nm file.o" on it before and after stripping. |
| 04:32.08 | Flash | as in, all symbols are gone and linking is impossible? |
| 05:08.37 | BulletCatcher | yup |
| 05:17.43 | *** join/#bzflag Sgeo_ (~Sgeo@ool-18b982ad.dyn.optonline.net) |
| 09:31.16 | *** join/#bzflag _I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 12:28.50 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 14:03.28 | *** join/#bzflag Sgeo (~Sgeo@ool-18b982ad.dyn.optonline.net) |
| 14:07.27 | *** join/#bzflag EvilJStoker (jstoker@unaffiliated/jstoker) |
| 14:42.01 | macsforme | I was able to fix DXJoystick on my joystick improvements branch so that it works on Windows now... still have to fix it on Linux |
| 14:45.15 | macsforme | although I also discovered that on the Xbox One bluetooth controller (what may be the device that players are most likely to have and to use), the two triggers are actually treated as part of the Z axis, rather than as buttons... Iâm not sure what to do with that |
| 14:47.30 | macsforme | it does work out of the box on other games... I wonder if they just set a certain actuation point on the axis that counts as a press... or if they use a different API entirely, that does generate button events for them |
| 14:48.22 | *** join/#bzflag _I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 15:04.18 | JeffM[m] | Yeah the triggers are used as analog controlls for racing games, so they have to have more than "on and off". |
| 15:04.38 | JeffM[m] | XInput has a better interface to them. |
| 15:08.09 | blast007 | macsforme: the Game Controller piece of SDL2 might work better for modern gamepads, since it's based around the Xbox 360 controller. |
| 15:09.01 | blast007 | may still treat it the same way though.. I'd have to test |
| 15:09.04 | JeffM[m] | it probably maps to XInput on the backend too |
| 15:09.38 | JeffM[m] | I've seen a lot of APIs have seperate gamepad and joystick APIs because so many things emulate the xbox controller |
| 15:10.31 | blast007 | we might not need the DXJoystick stuff anymore either. I do have some changes somewhere that adds rumble/haptic feedback to SDLJoystick when using SDL2 |
| 15:10.55 | blast007 | I think directional force feedback is pretty much dead these days |
| 15:11.04 | JeffM[m] | oh yeah |
| 15:11.19 | JeffM[m] | except maybe on fancy wheels |
| 15:11.48 | JeffM[m] | I still have one of those old sidewinder force feeback joysticks with directional feedback |
| 15:11.51 | JeffM[m] | has it's own power plug |
| 15:11.54 | blast007 | :) |
| 15:12.18 | JeffM[m] | probably should get rid of it before I move |
| 15:14.57 | blast007 | BulletCatcher: do you know if it's normal for automake/autoconf to keep debug symbols in the final .so files and executable binaries? I do see that there's an 'install-strip' make target. |
| 15:25.24 | BulletCatcher | Yes. The point of a debug version is to have those symbols available to the debugger at runtime. :-) |
| 15:26.05 | BulletCatcher | You can strip an executable and it will still run (but the debugger won't find any symbols). |
| 15:26.26 | JeffM[m] | would you not want to strip a release build? |
| 15:28.12 | BulletCatcher | It depends on whether you expect end users to run a debugger on it. |
| 15:28.52 | BulletCatcher | "strip --strip-unneeded" can be used on a .so file to remove debugging symbols while preserving those needed for runtime linking. |
| 15:30.16 | JeffM[m] | I believe the previous discussion was about binary size, and thus assuming a minimal binary with no debug symbols. |
| 15:45.38 | BulletCatcher | Testing reveals that "strip --strip-unneeded" strips all symbols from BZFlag plugin .so files, so don't do that. |
| 15:46.37 | BulletCatcher | It seems that the most reliable way to not have debug symbols in .so files is to not generate them in the first place. |
| 15:54.00 | BulletCatcher | I do that with "env ac_cv_prog_cc_g=no ac_cv_prog_cxx_g=no ./configure" to make configure think that the -g option is unsupported by the compiler. |
| 16:07.04 | BulletCatcher | On Fedora, configuring with --enable-debug and compiling with -g adds roughly 50 megabytes of symbols to bzflag. |
| 16:42.53 | blast007 | BulletCatcher: for me, it's adding -g when I *don't* have --enable-debug |
| 16:43.23 | blast007 | so my release build 'bzflag' binary is like 92MB |
| 17:04.00 | BulletCatcher | My version of gcc is 9.3.1. What's yours? |
| 17:29.14 | BulletCatcher | Never mind. I get a 95MB file when I use -g without --enable-debug. |
| 17:29.37 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 19:29.53 | blast007 | BulletCatcher: when you say "when I use -g", do you mean you're manually adding it? I'm just doing ./autogen.sh && ./configure && make -j8 |
| 19:39.52 | blast007 | autoconf (GNU Autoconf) 2.69 automake (GNU automake) 1.15 gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516 |
| 19:40.03 | blast007 | (Debian 9 system, but it was also doing the same on Debian 10) |
| 20:36.14 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 21:13.10 | *** join/#bzflag _I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 21:34.47 | *** join/#bzflag Zehra (~Keiki_Han@unaffiliated/zehra) |
| 21:50.37 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 22:33.08 | *** join/#bzflag _I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 23:16.31 | blast007 | Debian 10: autoconf (GNU Autoconf) 2.69 automake (GNU automake) 1.16.1 gcc (Debian 8.3.0-6) 8.3.0 |
| 23:30.54 | BulletCatcher | Normally when I build BZflag I don't compile with -g (using the technique described above) and it produces about a 3 MB bzflag executable. |
| 23:32.08 | BulletCatcher | When I do ./autogen.sh && ./configure && make like any sensible person it gives me a 95 MB bzflag executable, roughly the same size as yours. |