Zehra | Arena CTF released to the public: https://forums.bzflag.org/viewtopic.php?f=79&t=20450 | 00:31 |
---|---|---|
*** User49 <User49!~User49@unaffiliated/user49> has joined #bzflag | 00:40 | |
*** FieldSobers <FieldSobers!~User49@unaffiliated/user49> has quit IRC (Read error: Connection reset by peer) | 00:41 | |
allejo | Zehra: there's bzu_getTeamFromFlag from plugin_utils.h | 00:51 |
allejo | and bz_eTeamType is an enum, so you can do comparisons like `cappedTeam >= eRedTeam && cappedTeam <= ePurpleTeam` iirc | 00:52 |
allejo | or just use an std::map<bz_eTeamType, bool> for keeping track if flags for a team have been touched | 00:54 |
allejo | then you can just do `grabStatus[eRedTeam]` | 00:54 |
Zehra | Thanks allejo. I noticed bzu_getTeamFromFlag, although requiring another header for a single function seemed a bit excessive. | 00:58 |
Zehra | (For me.) | 00:59 |
*** spldart is now known as short_circuit | 00:59 | |
*** ChanServ sets mode: -v short_circuit | 00:59 | |
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:00 |
allejo | it's a header, it'd be optimized out at compile time if that's what you're worried about but whatevs | 01:01 |
Zehra | That's good, some of the earlier compilers didn't do so well and didn't properly optimize the code as expected. :) | 01:05 |
blast007 | like.. back in the 70's? | 01:06 |
*** _I_Died_Once <_I_Died_Once!~I_Died_On@unaffiliated/idiedonce/x-1828535> has joined #bzflag | 01:06 | |
Zehra | Well, comparing binary size, a megabyte in difference for a single change based on C or C++ style is a lot. | 01:07 |
Zehra | Or included headers. | 01:08 |
*** I_Died_Once <I_Died_Once!~I_Died_On@unaffiliated/idiedonce/x-1828535> has quit IRC (Ping timeout: 244 seconds) | 01:09 | |
blast007 | your plugin is larger than 1MB? | 01:09 |
Zehra | 18 kilobytes. | 01:09 |
blast007 | what are you referring to then? | 01:10 |
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 |
Zehra | Even though the exact same thing, only difference being code style and functions used. | 01:11 |
Zehra | I'm sort of getting off topic though. | 01:12 |
JeffM[m] | That’s the runtime | 01:21 |
JeffM[m] | And did you compare release builds or debug? | 01:23 |
Zehra | I'm not sure. (In both cases.[For plugin and/or program.]) | 01:24 |
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 |
Zehra | ^ | 01:25 |
JeffM[m] | Does it have static runtimes? | 01:28 |
*** bertman <bertman!~bert@c-69-254-102-169.hsd1.tn.comcast.net> has joined #bzflag | 01:29 | |
Zehra | No clue. | 01:29 |
Zehra | Also in reference to program or SAMPLE_PLUGIN? | 01:32 |
JeffM[m] | The lib for untill | 01:32 |
JeffM[m] | Utils | 01:32 |
allejo | how'd you check that? | 01:36 |
JeffM[m] | Linker options on the lib when it’s built | 01:37 |
allejo | not seeing any flags on plugin_util's makefile other than -avoid-version | 01:42 |
JeffM[m] | Then it’ll depend on what the compiler does by default, how big is the static lib? | 01:44 |
JeffM[m] | My guess is the linker isn’t optimizing dead code | 01:44 |
JeffM[m] | Try adding the utils cpp files to the plugin directly, it’ll then optimize the entire thing | 01:45 |
JeffM[m] | There may be a “hole program optimization “ option | 01:45 |
JeffM[m] | I know how to do it in Windows, not gcc | 01:45 |
allejo | static lib would be libplugin_utils.a, right? if so, 2M | 01:47 |
JeffM[m] | Wow | 01:47 |
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:53 |
JeffM[m] | Yeah that seem big | 01:55 |
BZNotify | bzflag: allejo opened issue #263 "plugin_utils lib size seems too large" (https://git.io/JU4re) | 02:06 |
BZNotify | bzflag: allejo labeled issue #263 as needs triage | 02:06 |
BZNotify | bzflag: allejo labeled issue #263 as needs more info | 02:06 |
blast007 | 4.6M Sep 14 21:06 libplugin_utils.a | 02:08 |
blast007 | (that's a release build) | 02:08 |
JeffM[m] | Dammmmmmmmmmnnnnnn | 02:09 |
FusionDude | so ... static libs and shared libs are treated completely differently by the linker | 02:12 |
*** FusionDude is now known as Flash | 02:12 | |
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:12 |
Flash | a static lib that is 2M might contribute a tiny 1K bit to the program | 02:13 |
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:13 |
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:14 |
JeffM[m] | Yeah it should only link in what is used | 02:15 |
blast007 | should those .o files be stripped? | 02:15 |
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 |
allejo | ah yea, plugin_utils.o is coming in at ~752K for me which would explain the jump from 35K to 911K | 02:16 |
Flash | yeah, so one symbol from that .o and you get the whole thing | 02:16 |
Flash | if size is a huge concern, you can break it up into multiple compilation units | 02:17 |
blast007 | looks like none of our .o files are stripped | 02:17 |
Flash | I thought stripping happened to executables, after linking? | 02:18 |
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:18 |
blast007 | so I feel like something is just very wrong... | 02:19 |
blast007 | my bzflag binary is 91MB :) | 02:19 |
Flash | is that a release build? | 02:20 |
blast007 | all I did was ./configure, no arguments, so it *should* be | 02:20 |
Flash | hmmm | 02:20 |
blast007 | rebuilding an older version here just for a sanity check... | 02:22 |
blast007 | well what the heck... | 02:26 |
*** _I_Died_Once <_I_Died_Once!~I_Died_On@unaffiliated/idiedonce/x-1828535> has quit IRC (Ping timeout: 240 seconds) | 02:26 | |
allejo | please tell me that latest 2.4 *is* the "optimized" version and it was larger in an older build | 02:26 |
*** bboles <bboles!~quassel@2602:fe90:604:1b::52f2:f9b3> has quit IRC (Quit: No Ping reply in 180 seconds.) | 02:27 | |
blast007 | 2.4.12 is what I tried, and that also resulted in a non-stripped bzflag binary (weighing it at 77MB) | 02:27 |
*** bboles <bboles!~quassel@2602:fe90:604:1b::52f2:f9b3> has joined #bzflag | 02:29 | |
Flash | looks to me that a straight build puts "-g -O2" in the flags | 02:30 |
Flash | I have the Mac version of 2.4.20 and BZFlag is 3.7M | 02:32 |
Flash | but XCode doesn't use configure | 02:32 |
*** Zehra <Zehra!~Keiki_Han@unaffiliated/zehra> has quit IRC (Quit: Quit) | 02:33 | |
JeffM[m] | why didn't you go with premake again? | 02:33 |
blast007 | the beta version that isn't packaged in most linux distributions? | 02:34 |
JeffM[m] | so? | 02:34 |
JeffM[m] | include a premade preamake makefile :) | 02:34 |
allejo | this is the 2.4 branch. premake is used in the 2.5-dev branch, no? | 02:34 |
blast007 | premake is available in the master version and used for macOS | 02:35 |
BZNotify | bzflag: jwmelto commented on issue #263 "plugin_utils lib size seems too large" by allejo (https://git.io/JU4og): `.so` is fundamentally different from `.a`. It's generally not a go... | 03:12 |
Flash | JeffM[m]: by the way, good to see you; you haven't been around much | 03:13 |
JeffM[m] | I have had my ways of seeing what is going on | 03:14 |
Flash | lol ... lurkers-r-us | 03:14 |
JeffM[m] | the riot thing makes it easy | 03:15 |
BZNotify | bzflag: allejo closed pull request #262 "updated readme to reflect current plugin" by Zehra (https://git.io/JUCTp) | 03:52 |
BZNotify | 2.4 @ bzflag: allejo pushed 2 commits (https://git.io/JU4KR): | 03:52 |
BZNotify | 2.4 @ bzflag: Zehra bb6b7b: updated readme to reflect current plugin (https://git.io/JU4K0) | 03:52 |
BZNotify | 2.4 @ bzflag: allejo ef1c75: Merge pull request #262 from Zehra/shockwave-docs (https://git.io/JU4KE) | 03:52 |
BZNotify | bzflag: allejo edited pull request #262 "updated shockwaveDeath readme to remove nonexistent BZDB var" by Zehra (https://git.io/JUCTp) | 03:53 |
BulletCatcher | I recommend stripping a .o file once so you learn why not to do it ever again. ;-) | 04:12 |
Flash | that sounds ominous :) | 04:12 |
BulletCatcher | Hint: run "nm file.o" on it before and after stripping. | 04:13 |
Flash | as in, all symbols are gone and linking is impossible? | 04:32 |
BulletCatcher | yup | 05:08 |
*** Sgeo_ <Sgeo_!~Sgeo@ool-18b982ad.dyn.optonline.net> has joined #bzflag | 05:17 | |
*** Sgeo <Sgeo!~Sgeo@ool-18b982ad.dyn.optonline.net> has quit IRC (Ping timeout: 240 seconds) | 05:20 | |
*** Sgeo_ <Sgeo_!~Sgeo@ool-18b982ad.dyn.optonline.net> has quit IRC (Read error: Connection reset by peer) | 07:01 | |
*** bertman <bertman!~bert@c-69-254-102-169.hsd1.tn.comcast.net> has quit IRC (Quit: leaving) | 09:22 | |
*** _I_Died_Once <_I_Died_Once!~I_Died_On@unaffiliated/idiedonce/x-1828535> has joined #bzflag | 09:31 | |
*** I_Died_Once <I_Died_Once!~I_Died_On@unaffiliated/idiedonce/x-1828535> has joined #bzflag | 12:28 | |
*** _I_Died_Once <_I_Died_Once!~I_Died_On@unaffiliated/idiedonce/x-1828535> has quit IRC (Ping timeout: 244 seconds) | 12:32 | |
*** EvilJStoker <EvilJStoker!jstoker@unaffiliated/jstoker> has quit IRC (Ping timeout: 272 seconds) | 14:00 | |
*** Sgeo <Sgeo!~Sgeo@ool-18b982ad.dyn.optonline.net> has joined #bzflag | 14:00 | |
*** EvilJStoker <EvilJStoker!jstoker@unaffiliated/jstoker> has joined #bzflag | 14:07 | |
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:42 |
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:45 |
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:47 |
*** _I_Died_Once <_I_Died_Once!~I_Died_On@unaffiliated/idiedonce/x-1828535> has joined #bzflag | 14:48 | |
*** I_Died_Once <I_Died_Once!~I_Died_On@unaffiliated/idiedonce/x-1828535> has quit IRC (Ping timeout: 244 seconds) | 14:51 | |
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 |
JeffM[m] | XInput has a better interface to them. | 15:04 |
blast007 | macsforme: the Game Controller piece of SDL2 might work better for modern gamepads, since it's based around the Xbox 360 controller. | 15:08 |
blast007 | may still treat it the same way though.. I'd have to test | 15:09 |
JeffM[m] | it probably maps to XInput on the backend too | 15:09 |
JeffM[m] | I've seen a lot of APIs have seperate gamepad and joystick APIs because so many things emulate the xbox controller | 15:09 |
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 |
blast007 | I think directional force feedback is pretty much dead these days | 15:10 |
JeffM[m] | oh yeah | 15:11 |
JeffM[m] | except maybe on fancy wheels | 15:11 |
JeffM[m] | I still have one of those old sidewinder force feeback joysticks with directional feedback | 15:11 |
JeffM[m] | has it's own power plug | 15:11 |
blast007 | :) | 15:11 |
JeffM[m] | probably should get rid of it before I move | 15:12 |
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:14 |
BulletCatcher | Yes. The point of a debug version is to have those symbols available to the debugger at runtime. :-) | 15:25 |
BulletCatcher | You can strip an executable and it will still run (but the debugger won't find any symbols). | 15:26 |
JeffM[m] | would you not want to strip a release build? | 15:26 |
BulletCatcher | It depends on whether you expect end users to run a debugger on it. | 15:28 |
BulletCatcher | "strip --strip-unneeded" can be used on a .so file to remove debugging symbols while preserving those needed for runtime linking. | 15:28 |
JeffM[m] | I believe the previous discussion was about binary size, and thus assuming a minimal binary with no debug symbols. | 15:30 |
BulletCatcher | Testing reveals that "strip --strip-unneeded" strips all symbols from BZFlag plugin .so files, so don't do that. | 15:45 |
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:46 |
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. | 15:54 |
BulletCatcher | On Fedora, configuring with --enable-debug and compiling with -g adds roughly 50 megabytes of symbols to bzflag. | 16:07 |
blast007 | BulletCatcher: for me, it's adding -g when I *don't* have --enable-debug | 16:42 |
blast007 | so my release build 'bzflag' binary is like 92MB | 16:43 |
*** Agatha_ is now known as Agatha | 16:49 | |
BulletCatcher | My version of gcc is 9.3.1. What's yours? | 17:04 |
BulletCatcher | Never mind. I get a 95MB file when I use -g without --enable-debug. | 17:29 |
*** I_Died_Once <I_Died_Once!~I_Died_On@unaffiliated/idiedonce/x-1828535> has joined #bzflag | 17:29 | |
*** _I_Died_Once <_I_Died_Once!~I_Died_On@unaffiliated/idiedonce/x-1828535> has quit IRC (Ping timeout: 244 seconds) | 17:32 | |
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:29 |
*** I_Died_Once <I_Died_Once!~I_Died_On@unaffiliated/idiedonce/x-1828535> has quit IRC (Read error: Connection reset by peer) | 19:34 | |
blast007 | autoconf (GNU Autoconf) 2.69 automake (GNU automake) 1.15 gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516 | 19:39 |
blast007 | (Debian 9 system, but it was also doing the same on Debian 10) | 19:40 |
*** I_Died_Once <I_Died_Once!~I_Died_On@unaffiliated/idiedonce/x-1828535> has joined #bzflag | 20:36 | |
*** _I_Died_Once <_I_Died_Once!~I_Died_On@unaffiliated/idiedonce/x-1828535> has joined #bzflag | 21:13 | |
*** I_Died_Once <I_Died_Once!~I_Died_On@unaffiliated/idiedonce/x-1828535> has quit IRC (Ping timeout: 240 seconds) | 21:15 | |
*** Zehra <Zehra!~Keiki_Han@unaffiliated/zehra> has joined #bzflag | 21:34 | |
*** I_Died_Once <I_Died_Once!~I_Died_On@unaffiliated/idiedonce/x-1828535> has joined #bzflag | 21:50 | |
*** _I_Died_Once <_I_Died_Once!~I_Died_On@unaffiliated/idiedonce/x-1828535> has quit IRC (Ping timeout: 244 seconds) | 21:52 | |
*** _I_Died_Once <_I_Died_Once!~I_Died_On@unaffiliated/idiedonce/x-1828535> has joined #bzflag | 22:33 | |
*** I_Died_Once <I_Died_Once!~I_Died_On@unaffiliated/idiedonce/x-1828535> has quit IRC (Ping timeout: 244 seconds) | 22:36 | |
*** Juesto <Juesto!~LimeC@unaffiliated/juest> has quit IRC (Ping timeout: 264 seconds) | 22:36 | |
blast007 | Debian 10: autoconf (GNU Autoconf) 2.69 automake (GNU automake) 1.16.1 gcc (Debian 8.3.0-6) 8.3.0 | 23:16 |
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:30 |
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. | 23:32 |
Generated by irclog2html.py 2.17.3.dev0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!