[00:00:42] <wjp> heh, ffmpeg's binkaudio produces horrible noise when mmx, sse and the like are disabled
[00:01:10] <wjp> and the crackling is definitely a lack of clamping in the conversion code
[00:01:29] <wjp> I'm guessing it only accidentally works in ffmpeg because one of the SIMD converters clamps automatically
[00:01:48] <wjp> (the SSE ones do, from memory)
[00:02:33] <fuzzie> *nod*
[00:26:57] <-- Maighstir has left #gemrb ()
[08:02:31] --> Gekz has joined #GemRB
[09:13:47] --> lynxlynxlynx has joined #gemrb
[09:13:47] --- ChanServ gives channel operator status to lynxlynxlynx
[09:30:46] --> Gekz_ has joined #GemRB
[09:31:24] <-- Gekz has left IRC (Read error: 110 (Connection timed out))
[10:46:25] <Gekz_> UNIVERSE IN A BALL THERE'S A UNIVERSE IN US ALL
[11:59:40] --> Maighstir has joined #gemrb
[12:57:04] <fuzzie> wjp: you reproduced the crackling in ffmpeg's binkaudio w/o clamping?
[13:17:05] <wjp> not as such
[13:18:38] <wjp> but I did output the buffer pre and post conversion and the values were clamped with the default converter (whichever SIMD version that was)
[13:19:16] <fuzzie> ok.
[13:19:33] <wjp> ok, now I did reproduce it
[13:19:54] <wjp> I disabled all SIMD, replaced the C version with a straight cast, and it sounds identical to Avenger's version
[13:19:57] <fuzzie> heh :)
[13:20:14] <fuzzie> okay, i was just wondering if you'd tried clamping in gemrb's code
[13:20:25] <wjp> yes
[13:20:50] <wjp> that removes the crackling
[13:21:36] <wjp> simply with two if statements in the float_to_int16_one code; I haven't thought about efficiency at all yet
[13:22:47] <lynxlynxlynx> cool
[13:23:46] <fuzzie> commit that? :p
[13:29:53] <CIA-28> gemrb: 03wjpalenstijn * r7455 10/gemrb/trunk/gemrb/plugins/BIKPlayer/BIKPlay.cpp: Clamp binkaudio output to int16 range
[13:31:24] <fuzzie> thanks
[13:38:08] <-- tombhadAC has left IRC (Read error: 131 (Connection reset by peer))
[13:48:47] <lynxlynxlynx> wotc plays almost perfectly here
[13:49:02] <lynxlynxlynx> the intro is much worse
[13:52:49] <wjp> hm, some kind of clicking?
[13:53:09] <wjp> at maybe 5Hz or something?
[13:53:44] <lynxlynxlynx> at which one?
[13:53:51] <wjp> intro
[13:54:13] <lynxlynxlynx> intro sounded like it was lagging (think of the flash plugin)
[13:54:57] <lynxlynxlynx> intro just crashes actually
[13:55:05] <fuzzie> did the sleeps get fixed?
[13:55:07] <lynxlynxlynx> it was probably the black isle one
[13:55:22] <fuzzie> when i heard it, it was throwing openal errors because it wasn't sleeping for long enough (and so queueing audio too early)
[13:55:35] <wjp> the intro plays if you remove the 'return false;' if DecodeBlock returns flase
[13:55:43] <lynxlynxlynx> also some screeching and scratching unrelated to the storm is heard at one point
[13:57:33] <wjp> hm, that weird clicking-like noise in the intro is also in ffmpeg's output
[13:57:44] <Gekz_> maybe the plugin is shit
[14:55:18] --> tombhadAC has joined #gemrb
[15:20:54] <fuzzie> ieDword audframesize = *(ieDword *) inbuff; <- meh :p
[15:21:06] <Gekz_> lol
[15:21:07] <Gekz_> naughty
[15:24:52] <fuzzie> if i fix that it still doesn't work for me, though..
[15:36:03] <fuzzie> oh, and now i didn't change anything and it works.
[15:39:14] <CIA-28> gemrb: 03fuzzie * r7456 10/gemrb/trunk/gemrb/plugins/BIKPlayer/BIKPlay.cpp: fix BIKPlayer to always use ReadDword
[15:39:54] <Gekz_> lol
[15:40:10] <fuzzie> Avenger used it *almost* everywhere and then ruined it in that one bit :)
[15:40:31] <Gekz_> haha
[15:40:37] <fuzzie> i'm impressed that it works now, i thought get_bits would be a disaster, but it actually uses an endian-safe macro
[16:25:35] <-- tombhadAC has left IRC (kornbluth.freenode.net irc.freenode.net)
[16:25:35] <-- Maighstir has left IRC (kornbluth.freenode.net irc.freenode.net)
[16:33:53] <-- Gekz_ has left IRC (Read error: 113 (No route to host))
[16:34:35] --> Gekz` has joined #GemRB
[16:39:09] --> tombhadAC has joined #gemrb
[18:38:52] <tomprince> I managed to get py++ and boost::python to compile under mingw/wine.
[18:39:39] <tomprince> It seems to run. But I am getting a OverflowError during chargen.
[19:16:02] <tomprince> And I noticed that GEM_BUILD_DLL is actually never set.
[19:16:52] <fuzzie> by what?
[19:17:04] <tomprince> By anything.
[19:17:18] <fuzzie> you checked the vc++ projects?
[19:18:13] <tomprince> I don't have VC.
[19:18:20] <fuzzie> the gemrb vc++ projects.
[19:18:35] <fuzzie> nm, let me pull them and look.
[19:20:21] <fuzzie> fuzzie@aspire:/tmp/gemrb-win32$ grep GEM_BUILD_DLL -r * | wc -l
[19:20:21] <fuzzie> 20
[19:20:52] <fuzzie> in the vc6, vc7 and vc8+ project files, it seems.
[19:20:56] <tomprince> That would explain it.
[19:22:13] <tomprince> I was getting failure on mingw, because boost::python declared a function with __declspec(dllexport). And since nothing else in the plugin had that set, nothing else was exported, and so the plugin wouldn't load.
[19:22:41] <fuzzie> if you haven't seen these then you perhaps haven't discovered the rest of the gemrb svn repos; see http://gemrb.svn.sourceforge.net/viewvc/gemrb/ - none of it is particularly relevant but there's the (very, very vc6-only) DLTCEP source in chitem/, Avenger's 'canonical' file dumper in ielister/, Ed's python modules in ie_shell/, etc.
[19:23:15] <fuzzie> and, *nod*. wrap it in a msvc check, maybe?
[19:23:18] <tomprince> I was aware of them. I had just assumed that cmake was used to generate project files for VC.
[19:23:51] <tomprince> No need for that. I was compiling under mingw/g++.
[19:24:21] <tomprince> We already check everywhere for WIN32 before doing anything with GEM_BUILD_DLL.
[19:24:45] <tomprince> I think that it should probably be set in Core, and in */*Importer.cpp and nowhere else.
[19:25:06] <fuzzie> I think that no-one except Gekz has really bothered with mingw builds.
[19:25:28] <tomprince> The point of the plugin system is that we only need the 3 entry points to use plugin, so everything else can be private.
[19:25:32] <fuzzie> So I would guess it hasn't really had anyone think about the possibility.
[19:26:30] <fuzzie> And I think you might miss the point of the declspecs..
[19:26:47] <fuzzie> Without them, any calls you make into the functions in the vtable will crash.
[19:27:21] <fuzzie> Well, that is not true. I think the default is "be paranoid", actually.
[19:29:52] <fuzzie> Dum de dum. I forget how this works. But it's not being used here solely for the avoid-.def-file functionality, it's for the noting-this-is-dll-call stuff.
[19:32:40] <fuzzie> unrelated, but while I am googling this I found: http://chadaustin.me/cppinterface.html has someone else implementing that 'operator delete' idea to replace release(), so i guess it must work
[19:33:17] <fuzzie> I'm not sure why they're doing it in such an indirect way.
[19:34:42] <tomprince> Well, they are not overriding new, so everything is being allocated in the DLL, not in the main program, so they need to deallocate there too.
[19:34:58] <tomprince> The way I did it is to allocate in the main program.
[19:35:40] <fuzzie> Does that new operator get called even for subclasses of Plugin?
[19:35:51] <tomprince> Yes.
[19:35:51] <fuzzie> Sorry, I know this is kind of changing the subject a little.
[19:35:55] <tomprince> At least, it should
[19:38:55] <fuzzie> it is a rather nice fix, design-wise..
[19:42:27] <fuzzie> i am trying to work out if the lack of a __declspec(dllexport) matters at all for modern compilers
[19:43:17] <fuzzie> from what I can tell, no modern compiler does optimisation on virtual functions any more, so as you say, it doesn't matter..
[19:45:16] <tomprince> What kind of optimization?
[19:46:43] <fuzzie> assuming that the C library data on both sides is the same
[19:47:10] <fuzzie> (for non-virtual functions compilers will obviously simply drop whole functions..)
[19:49:31] <tomprince> C library data?
[19:51:29] <fuzzie> apparently memory allocation breaks; i can only guess that it must store things at some global location, or in the TLS, or similar?
[19:51:58] <fuzzie> but this is pre-vc6, even
[20:01:26] <tomprince> Well, on mingw, changing GEM_EXPORT_DLL to 'extern "C" __declspec(dllexport)' seems to work with any issues.
[20:02:26] <fuzzie> mingw doesn't care about the dll boundaries at all, does it?
[20:02:33] <fuzzie> you can do allocation wherever you want, etc
[20:03:23] <fuzzie> but if you can wrap it in a define or check on vc++..
[20:03:52] <tomprince> I don't know, I haven't tested it. But the __declspec stuff is orthogonal to the memory allocation as far as I am aware.
[20:04:05] <fuzzie> well, they're both about problems caused by DLL boundaries.
[20:04:35] <tomprince> Yes. But still separate problems.
[20:05:01] <fuzzie> yes, but i mean: testing in mingw is not very helpful because it doesn't care about DLL boundaries, whether it's memory allocation or __declspec or whatever.
[20:05:02] <tomprince> I was actually reading that for vc++, if you set the C runtime to be dynamically linked there is no problem with cross-module allocation.
[20:05:09] <fuzzie> well, that is not our experience :-)
[20:05:22] <fuzzie> it does work fine in vc++6, but it doesn't seem happy in later versions.
[20:05:50] <tomprince> The cross-module allocation?
[20:05:53] <fuzzie> yes
[20:06:00] <fuzzie> it just crashes on delete.
[20:06:20] <fuzzie> quite possible that people are using the wrong option or something, i don't think anyone trying it has been a vc++ expert.
[20:06:42] <fuzzie> the people trying to build gemrb don't tend to stay around very long.. they wander in, report problems, get it fixed, disappear forever :/
[20:35:11] <tomprince> Strange, everything that I can find on the web seems to indicate that the VC settings used for GemRB shouldn't have any problems with cross DLL alloc/dealloc. :(
[20:35:32] <tomprince> Anyway, we have a solution. It just needs to be more thouroughly implemented.
[20:52:50] <-- tombhadAC has left IRC (Read error: 128 (Network is unreachable))
[21:02:38] --> tombhadAC has joined #gemrb
[21:14:03] --> Avenger has joined #gemrb
[21:14:07] --- ChanServ gives channel operator status to Avenger
[21:14:11] <Avenger> hello everyone
[21:17:10] <fuzzie> hi, Avenger
[21:18:01] <fuzzie> you saw commits?
[21:18:31] <Avenger> i'm just going to eat something then i'm here, i looked at the log. i said that clamping is needed :)
[21:18:48] <Avenger> i just guess it is slower than the original
[21:19:29] <Avenger> the original with the magic number, but i think that magic number works only on x86, and not even THAT magic number but the one tom found yesterday
[21:20:05] <fuzzie> well, the IEEE representation for floats is fairly universal I think, maybe we should try it sometime
[21:20:18] <fuzzie> i'm just not sure how it works with emulated floats
[21:20:42] <fuzzie> but i guess softfloat uses the same representation
[21:22:05] <fuzzie> i was more wondering what you wanted to do about my change
[21:22:11] <fuzzie> but i'm not really very around
[21:33:47] <Avenger> i will reboot to linux and look at the changes
[21:33:49] <-- Avenger has left IRC ("ChatZilla 0.9.85 [Firefox 3.5.5/20091102152451]")
[21:41:13] <CIA-28> gemrb: 03avenger_teambg * r7457 10/Win32/trunk/MSVC6/GemRB/ (6 files in 3 dirs): updated msvc6 project files with BIKPlayer
[21:44:06] --> Avenger has joined #gemrb
[21:44:09] --- ChanServ gives channel operator status to Avenger
[21:45:23] <Avenger> about the readdword change, i would have used the endian safe macro if i had to change this, but it is good either way
[21:47:32] <Avenger> about the keyimp changes, well, i hope it works, it seems like a huge change
[21:48:58] <tomprince> I tried to keep the logic essentially the same, just clean it up and make all the bits behave the wrt things like ResolvePath
[21:49:12] <tomprince> I think that is probably the largest change.
[21:49:40] <tomprince> There may be some corner cases where this breaks, but I think that it is probably easier to fix now.
[21:49:56] <Avenger> the cd paths to array is a good one, i wanted that too
[21:50:43] <Avenger> tom: i saw some comment there 'if you change this, try to move to ar9700
[21:50:44] <tomprince> Get the impression that the code has mostly just grown over time, with code added as need, and special cases all over the place.
[21:51:06] <tomprince> Which is resonable, since it is important that everything works.
[21:51:38] <tomprince> I didn't test that, since I don't have a working IWD install, but I didn't touch that specific bit.
[21:52:52] <fuzzie> yes, that bit is still good
[21:53:38] <tomprince> At some point, I'll probably change ResolvePath to strip multiple consecutive pathdelimiters, and that special case hack can go away.
[21:53:40] <fuzzie> i've been testing the changes with every game before i commit, which is why i am not applying them very quickly..
[21:54:03] <Avenger> that's good :)
[21:54:14] <tomprince> That is good. Since I don't seem to have working chitin.key for iwd+how+tolm and iwd2.
[21:54:36] <Avenger> so, back to the bink player, the wobbly sound is not fixed by wjp's patch, i guess?
[21:55:14] <fuzzie> it is difficult to see if there are any errors, due to all the debug output
[21:55:14] <Avenger> meh, i should comment out the video decoder
[21:55:44] <Avenger> well you can comment them out :)
[22:00:02] <Avenger> odd, it doesn't play intro.mve
[22:00:08] <Avenger> it did before
[22:00:22] <tomprince> Avenger: I was wondering if you have had a chance to test out the memory allocation patch I posted against VC
[22:00:27] <Avenger> but it sounds definitely better
[22:01:12] <Avenger> i didn't want to mess with it, i will see it when it is comitted anyway
[22:01:22] <tomprince> Also, whether it would be possible to change GEM_EXPORT_DLL to 'export "C" __declspec(dllexport) in globals.h.
[22:01:22] <fuzzie> i found a third-party source talking about it working
[22:01:43] <fuzzie> so i expect it is worth applying, since it can be trivially reverted
[22:02:04] <tomprince> Well, I don't think it should be commited if it won't work on VC, and I am not sure if that *exact* patch should go in. But simply wether the idea works.
[22:02:08] <Avenger> huh
[22:03:04] <Avenger> why would you need that?
[22:03:33] <Avenger> for some other compiler?
[22:03:42] <tomprince> Don't need that. It would just be cleaner, since the only thing we refer to symbolicly in the DLLs are those exports.
[22:04:26] <tomprince> I was testing some generated code tht added its own __declspec to some other functions, and then, since it was the only function that had a __declspec, the ones we needed weren't exported.
[22:04:31] <tomprince> Thus the plugin didn't work.
[22:05:01] <tomprince> This was under mingw, but I would guess the problem would show up under VC with the same code.
[22:05:09] <Avenger> i definitely don't understand
[22:05:44] <tomprince> Well, I was playing around with generating python bindings. And one package had the module init function declared __declspec(dllexport).
[22:05:47] <Avenger> the functions work now, so how did they 'vanish'
[22:06:06] <fuzzie> we have some specific hacks for this already, no?
[22:06:10] <Avenger> if you added one declspec, the others without it vanished?
[22:06:13] <fuzzie> oh, no, they are commented out.
[22:06:19] <tomprince> At least gcc, defaults to exporting everything, but if anything is marked dllexport, only those things marked dllexport gets exported.
[22:06:44] <tomprince> Yes.
[22:06:56] <Avenger> compilers are odd
[22:07:03] <fuzzie> huh, why are they commented out.
[22:07:27] <tomprince> Well, if you take the time to mark things as dllexport, it assumes that you know what you are doing and only exports what you tell it to.
[22:07:48] <tomprince> I a DLL that didn't export anything is rather useless, so it defaults to exporting everything in that case.
[22:09:16] <fuzzie> so, the __declspec(dllexport) was originally the case, and it was removed
[22:09:56] <fuzzie> i expect i will wait 10 minutes before sf's svn server tells me any more, though
[22:10:19] <Avenger> we have GEM_EXPORT and GEM_EXPORT_DLL
[22:10:25] <Avenger> what's the difference
[22:10:52] <fuzzie> one of them exports/imports depending on flags set in the vc++ project files
[22:11:12] <Avenger> i have *.def files for every plugin
[22:11:34] <fuzzie> yes, i guess the problem here is that .def files are not much use for non-vc+
[22:12:04] <tomprince> The difference is that GEM_EXPORT is used (effectively) in Core, and is set to __declspec(dllexport) __declspec(dllimport) depending on whether we are compiling Core or not.
[22:12:06] <fuzzie> ok, so i don't see why __declspec(dllexport) was removed
[22:12:27] <fuzzie> the commit adds the extern "C" to avoid importing decorated names, which is fair enough
[22:12:36] <Avenger> who did it, when, and what is in the commit note
[22:12:37] <tomprince> GEM_EXPORT_DLL is used only in the plugins, for the DLL entry points.
[22:12:40] <fuzzie> Avenger: you did it :)
[22:12:49] <fuzzie> and in 2006, and it was *very broken* before
[22:13:18] <fuzzie> basically, someone removed "#define GEM_EXPORT_DLL __declspec(dllexport)" from every C++ file and put "#define GEM_EXPORT_DLL extern "C"" into the globals.h..
[22:13:53] <fuzzie> it was a mistake, i think, the patch was from a linux user
[22:14:08] <tomprince> And, I think it would make sense to change that to add declspec on WIN32.
[22:14:18] <fuzzie> hm, no
[22:14:19] <fuzzie> it was Avenger
[22:14:25] <fuzzie> he rewrote the patch and removed that at the same time
[22:14:46] <fuzzie> so i agree, adding the declspec would make sense
[22:15:13] <Avenger> no commit note?
[22:15:20] <fuzzie> the commit note is "moved dll interface to "C" style bindings based on patch #1525536"
[22:15:39] <fuzzie> but patch #1525536 doesn't break the declspec
[22:16:02] <Avenger> well, i guess it didn't work for me on either msvc6 or 7
[22:16:09] <fuzzie> i think you just rewrote it
[22:16:14] <fuzzie> your patch is much tidier, it just leaves this bit out
[22:16:43] <Avenger> i'm pretty sure it caused some problem
[22:16:52] <fuzzie> well, i don't see what it could be :)
[22:17:09] <fuzzie> before the patch it must have worked with declspec
[22:17:12] <tomprince> Seems like it would be easy enough to test.
[22:17:15] <Avenger> i guess, one function had no declspec, and thus it 'vanished' from the dll interface
[22:17:38] <Avenger> since i didn't know that, i just removed it, and it 'miraculously' fixed
[22:17:45] <fuzzie> i don't think you removed it deliberately
[22:17:57] <Avenger> well, put it back and we'll see
[22:18:06] <Avenger> if it breaks something, then i did it deliberately
[22:18:22] <fuzzie> if it breaks something, we just wrap it in a gcc check too, i guess
[22:18:51] <Avenger> just give it a meaningful commit note :)
[22:19:44] <fuzzie> tomprince: '#ifdef WIN32' works for you?
[22:19:53] <tomprince> Just a second.
[22:20:09] <Avenger> i still don't know what broke intro.mve on iwd2
[22:20:18] <tomprince> Just key it off GEM_EXPORT. I posting a patch.
[22:20:26] <tomprince> http://pastebin.ca/1712583
[22:21:08] <tomprince> Wait, that doesn't work. :(
[22:21:20] <Avenger> oh i know
[22:21:21] <tomprince> Yes, the #ifdef works for me.
[22:21:24] <fuzzie> ye,s that's not going to work for you without the relevant GEM_BUILD_DLL bits
[22:21:37] <tomprince> I realized that just after i posted. :)
[22:22:14] <tomprince> But it would make sense to drop it in the same WIN32 #ifdef
[22:22:19] <Avenger> wobbly sound is still here
[22:22:52] <Avenger> the return near 'buggy audio frame, stop immediately' needs to be removed
[22:23:19] <Avenger> the reported size of the unpacked frame differs from the real size
[22:24:16] <Avenger> i guess it needs some investigation if the ffmpeg code, our code, or the data file is buggy
[22:24:34] <fuzzie> wjp talked about the ffmpeg code having clicking in the intro?
[22:25:33] <Avenger> hmm, i guess they use the original reported_size, while i use min(reported, unpacked)
[22:25:40] <Avenger> maybe that's why it is wobbly
[22:25:48] <Avenger> it is cut short
[22:26:16] <Avenger> so, the decoder has some bug, i guess
[22:28:23] <CIA-28> gemrb: 03fuzzie * r7458 10/gemrb/trunk/gemrb/includes/globals.h: restore the dllexport decorator we lost in r4009, to try and make sure the correct symbols get exported under mingw
[22:28:35] <Avenger> i'll try with the reported size now
[22:28:43] <tomprince> GEM_BUILD_DLL would be more descriptive named GEM_BUILD_CORE or something, and same with GEM_EXPORT to GEM_EXPORT_CORE?
[22:28:58] <fuzzie> tomprince: .. do you think so?
[22:29:18] <fuzzie> they're a bit confusing as they are, but i think the _CORE variants make less sense
[22:29:35] <tomprince> Well, they are for exporting stuff from Core to the plugins.
[22:29:38] <Avenger> uh, much worse
[22:30:05] <Avenger> but now this gives me a hint
[22:30:18] <fuzzie> tomprince: surely GEM_BUILD_DLL is exporting things from the plugins to a consumer
[22:30:20] <Avenger> i guess i screw the channel count in some way
[22:30:28] <tomprince> No.
[22:30:34] <fuzzie> you changed this?
[22:31:10] <tomprince> Well, Core really isn't a plugin. I am not entirely sure why it is under plugin. Core is the program, and is exporting stuff to the DLLs.
[22:31:24] <fuzzie> where is Core exporting anything to a DLL using GEM_BUILD_DLL?
[22:31:31] <fuzzie> oh, i see, i am getting defines mixed up!
[22:31:48] <fuzzie> i guess that makes the point for them being annoying as they are
[22:31:57] <tomprince> GEM_BUILD_DLL is set in Core. Actaully, I found that it is set in Core/CMakeList.txt. Plus the vcprojs.
[22:32:24] <tomprince> It was just lost in the noise of all the headers in Core doing the ifdef off of it.
[22:32:37] <fuzzie> but still, GEM_BUILD_DLL and GEM_BUILD_CORE would both be an either/or thing
[22:32:38] <tomprince> Rather than importing "globals.h", or a new header file for it.
[22:33:00] <tomprince> Either/or?
[22:33:08] <tomprince> Set it in Core, and nowhere else.
[22:33:28] <fuzzie> but that seems a rather personal style thing vs having it as it is :)
[22:33:45] <tomprince> Don't even need to conditonalize it off of WIN32. We can actually do the symbol hiding on linux too, with newer GCC.
[22:34:48] <fuzzie> presumably symbol hiding is going to be a horrible toolchain-specific thing
[22:35:04] <fuzzie> can you do it without adding a long list of supported-platform ifdefs?
[22:35:31] <Avenger> woo, the ffmpeg code is wobbly too
[22:35:32] <tomprince> Well, I don't see a reason for doing on anything other than GCC and WIN32.
[22:35:51] <Avenger> so we cannot fix it easily
[22:36:13] <fuzzie> tomprince: well, i am thinking of gcc on other platforms.
[22:37:08] <fuzzie> and so i wonder if __GNUC__ >= 4 is sufficient
[22:38:29] <fuzzie> yes, it seems to be; gcc will just drop the data on the floor if it can't do anything with it, and Mach-O supports it anyway
[22:38:53] <tomprince> Well, the boost python headers say (__GNUC__ >= 3) && (__GNUC_MINOR__ >=5 || __GNUC__ > 3)
[22:39:30] <tomprince> So yes __GNUC__ >= 4 should be enough.
[22:39:34] <fuzzie> although i find other documentation implying that making classes invisible is not good
[22:40:01] <fuzzie> very uninformative documentation, as usual
[22:42:56] <-- tombhadAC has left IRC (Read error: 54 (Connection reset by peer))
[22:43:11] --> tombhadAC has joined #gemrb
[22:43:54] <fuzzie> doesn't seem to be a problem for us, though
[22:44:01] <fuzzie> although i would never have guessed the crazy exception rules
[22:45:03] <tomprince> I think it is probably because the exceptions use some rtti or something, and the visibility affects the typeinfo objects, so that they are not shared.
[22:45:33] <fuzzie> yes, exactly that
[23:35:42] --> Maighstir has joined #gemrb
[23:36:11] <Avenger> bye
[23:36:13] <-- Avenger has left IRC ("bye!")