| 01:20.10 | BulletCatcher | blast007, if the purpose of bz_ApiString is to safely pass dynamic strings across the DLL boundary, then that seems like a fine solution. |
| 01:21.44 | blast007 | "that" referring to the patch, or to the "maybe if we returned a std::string from CallKey and added a std::string casting operator to bz_ApiString"? |
| 01:23.12 | BulletCatcher | I tried the patch. |
| 01:23.13 | BulletCatcher | It compiles on Linux, but I haven't actually run the plugin yet. |
| 01:24.14 | BulletCatcher | So at this point, "whatever works" is about the best I can do. :-p |
| 01:24.18 | blast007 | with the patch I'm wondering if I'm creating a memory leak by my use of strdup, though |
| 01:24.57 | BulletCatcher | Ah. You proabably are since it doesn't get freed. |
| 01:25.56 | BulletCatcher | Anyway, if bz_ApiString is what we're supposed to use (and it actually works) then let's use that. |
| 01:27.16 | blast007 | that part I'm okay with, it was more about the best way to handle that situation outside of the plugin, since memory was still being freed outside of the plugin when dealing with a char* |
| 01:35.40 | BulletCatcher | It seems like having CallKey return a std::string ought to make it unnecessary to use strdup(). |
| 01:36.16 | blast007 | yeah |
| 01:36.53 | BulletCatcher | And then we shouldn't have to worry about creating a memory leak. |
| 01:37.30 | *** join/#bzflag Pimpi_ (~frank@pD9E11F39.dip0.t-ipconnect.de) |
| 01:39.12 | BulletCatcher | That assumes that assigning the GetTemplateKey() result to a std::string will actually make a copy of the string. |
| 01:39.36 | BulletCatcher | If not, we may have to make GetTemplateKey() return a bz_ApiString. |
| 02:04.12 | BulletCatcher | If we have a std::string variable sss, then ("" + sss) is a distinct copy of the underlying memory with gcc. |
| 02:04.43 | BulletCatcher | But I can imagine a clever optimizier just using the original storage. |
| 02:09.44 | BulletCatcher | The only approach that I am confident would work in all cases is to allocate memory in the main program, pass a pointer to it to the plugin, have the plugin put data into it, and return any helpful size info. |
| 02:10.05 | BulletCatcher | There should be no possibility of confusion about scope in that case. |
| 05:07.00 | *** join/#bzflag BZnotify (~BZnotify@192.30.252.45) |
| 05:07.00 | BZnotify | [13bzflag] 15JMakey pushed 1 new commit to 062.4: 02http://git.io/vY0Tv |
| 05:07.00 | BZnotify | 13bzflag/062.4 143f92b7b 15Jeff Makey: Provide a working Makefile.am for the webStats plugin. |
| 05:07.00 | *** part/#bzflag BZnotify (~BZnotify@192.30.252.45) |
| 05:59.20 | *** join/#bzflag zuii (~akos@BC06BF93.catv.pool.telekom.hu) |
| 06:21.43 | *** join/#bzflag khonkhortisan (~Kyle@c-24-16-240-200.hsd1.wa.comcast.net) |
| 06:37.28 | DTRemenak|RDP | there are two rules to observe: first, deallocation must occur on the same side of a DLL boundary as allocation; second, STL containers (including strings) must not be passed across DLL boundaries. I believe bz_ApiString handles both those conditions correctly. |
| 06:41.29 | DTRemenak|RDP | breaking the first rule will generally result in a crash on windows (and possibly other platforms, though IIRC linux+glibc is OK with it). breaking the second will result in wildly unpredictable behavior if the library is built with a different STL implementation than the executable. |
| 07:00.14 | BulletCatcher | Can we define bz_ApiString variables where it is convenient to do so, and pass them in and out of plugins without fear of unwanted effects? |
| 07:00.15 | BulletCatcher | If they aren't that flexible, it should be sufficient if we can instantiate them in the main program and pass them by reference to a plugin, which can then safely modify them. |
| 07:01.45 | DTRemenak | I believe they are safe to pass both directions |
| 07:01.56 | DTRemenak | but I could be wrong |
| 07:02.05 | DTRemenak | haven't looked at the code in a long time |
| 07:02.17 | DTRemenak | pass by reference is definitely safe |
| 07:02.38 | DTRemenak | as long as they don't go out of scope in the meantime |
| 07:04.03 | BulletCatcher | It sounds like the "sufficient" case I described above is covered. |
| 07:04.52 | BulletCatcher | Since Windows is more picky than Linux maybe blast007 will do some science to test the more general case. |
| 07:05.14 | BulletCatcher | Thanks for th info, DTRemenak. |
| 07:08.47 | DTRemenak | probably won't link correctly if you try to instantiate one from a plugin. If it links, it should run. |
| 07:09.07 | DTRemenak | all the alloc/dealloc code is safely on the bzfs side |
| 07:39.25 | *** join/#bzflag mdskpr (~quassel@209.222.8.90) |
| 07:47.19 | khonkhortisan | In playing.cxx:5309 setupNearPlace(), if I replace NearPlane = NearPlaneNormal with NearPlane = NearPlaneClose; return; this moves the near plane of the view frustum backward from 1.0 units away from the camera to 0.25 units away from the camera. This is normally used to draw the player´s tank from first-person view, but it also fixes being able to see through walls while holding the Wide Angle bad flag (120FOV) with a building imm |
| 07:47.19 | khonkhortisan | Is there any reason to use the further-away near plane? |
| 07:47.19 | khonkhortisan | On a 1600x900 screen (I don´t know how much resolution and aspect ratio matter), with NearPlaneNormal, I can see through walls at FOVs 110 or higher, with NearPlaneClose I can see through the tank at FOV145 and through walls at FOVs over 160. At NearPlane = 0.01f; return; I can go to 178 without seeing through the tank, and 179 without seeing through walls, even though I can´t understand much of what I see. At NearPlane = FLT_MIN |
| 08:27.24 | *** join/#bzflag khonkhortisan (~Kyle@c-24-16-240-200.hsd1.wa.comcast.net) |
| 09:52.50 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 10:08.13 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 10:39.34 | *** join/#bzflag Pimpi (~frank@p4FF43D1F.dip0.t-ipconnect.de) |
| 10:44.31 | *** join/#bzflag ruskie (ruskie@sourcemage/mage/ruskie) |
| 15:08.22 | *** join/#bzflag nitroxis (n@nxs.re) |
| 16:07.23 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 16:38.27 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 17:35.42 | *** join/#bzflag disco- (~disco@unaffiliated/disco-) |
| 17:45.32 | *** join/#bzflag khonkhortisan (~Kyle@184-78-135-131.war.clearwire-wmx.net) |
| 17:46.05 | *** join/#bzflag khonkhortisan1 (~Kyle@50-46-141-48.evrt.wa.frontiernet.net) |
| 18:05.50 | *** join/#bzflag khonkhortisan (~Kyle@50-46-141-48.evrt.wa.frontiernet.net) |
| 22:42.30 | *** join/#bzflag Shuist (~Shuist@ppp203-122-213-220.static.internode.on.net) |
| 23:13.07 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 23:30.53 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 23:46.25 | *** join/#bzflag khonkhortisan (~Kyle@c-24-16-240-200.hsd1.wa.comcast.net) |
| 23:47.42 | *** join/#bzflag khonkhortisan (~Kyle@c-24-16-240-200.hsd1.wa.comcast.net) |