December 3, 2014 
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >
December 3, 2014 [00:22:30] *** zeroclouds has joined #openal[00:22:30] *** ChanServ sets mode: +v zeroclouds[01:54:01] <KittyCat> the new alure api is probably in a state now where it's functionally usable for large(ish) projects[01:54:44] <KittyCat> though I only know of two open source projects that put openal through its paces, and that I know the code well enough to change it[01:57:52] <caedes__> daikatana 1.3 for linux uses alure.. but I'm not sure I wanna touch that code again to upgrade to the new API ;)[02:48:06] <KittyCat> does -fno-rtti cause issues with inherited classes?[02:48:57] <KittyCat> for example, will deleting a base class (with an appropriate virtual destructor) properly call the child class destructor?[02:49:43] <caedes__> I think it works[02:50:02] <caedes__> the destructor should just be an entry in the vtable that is generated nevertheless, shouldn't it?[02:50:40] <caedes__> (that's why you're supposed to make destructors in virtual classes virtual, compilers warn about that)[02:51:14] <KittyCat> yeah, I'd think so[02:52:42] <caedes__> hmm I somehow thought that rtti was opt-in not opt-out in gcc[02:53:47] <KittyCat> I think rtti is automatically added for a type when GCC detects it will be needed[02:54:14] <caedes__> at least for exceptions it's done anyway, even if -fno-rtti is used[02:54:46] <KittyCat> but if you make a simple struct like struct Foo { int a; }; it doesn't add rtti info for it[02:55:35] <KittyCat> you need to add a virtual destructor to tell GCC to add it[02:56:28] <caedes__> hmm are you sure this isn't needed for non-virtual classes?[02:57:57] <caedes__> or does dynamic_cast and typeid() not work for non-virtual classes (or classes derived from them)?[02:58:11] <KittyCat> I remember having issues using dynamic_cast when the base class didn't have any virtual methods[02:58:38] <KittyCat> typeid() would (I believe) be resolved at compile time[03:00:07] <KittyCat> so if you did const foo &obj typeid would give info for 'foo' even if the object's actually referencing a derived class[03:00:28] <caedes__> typeid is also runtime, according to http://en.cppreference.com/w/cpp/language/typeid[03:00:46] <KittyCat> it can be runtime, yeah[03:00:55] <caedes__> but only works for "polymorphic types" which seem to be virtual classes[03:01:48] <caedes__> (i.e. on non-virtual classes it returns the type of the pointer, on virtual classes the type of the object)[03:02:04] <caedes__> which matches your observations about dynamic_cast[03:02:39] <caedes__> dynamic_cast doesn't make sense with non-virtual classes anyway, I think[03:03:24] <caedes__> hmm or actually.. it would, because then you can cast to the derived class and have the right methods called even though they're not virtual[03:03:46] <KittyCat> well it can, since you can derive from non-virtual classes. but the compiler won't generate rtti for them, so dynamic_cast doesn't have anything to check[03:04:10] <KittyCat> static_cast will work, but obviously that doesn't do any runtime checks[03:04:42] <caedes__> I think in gamedev rtti is avoided.. I think console SDKs don't (or at least didn't) support it[03:05:00] <caedes__> and there is some overhead (not sure how much really)[03:05:22] <caedes__> and games try to avoid overhead[03:06:37] <caedes__> e.g. the C4 engine has its own manual rtti-like mechanism (classes have a GetType() method that returns an enum value.. or actually some kind of type hierarchy, with additional getters for subtypes)[03:07:55] <caedes__> so you frequently see stuff like "if(node->GetType() == kNodeMarker && static_cast<Marker*>(node)->GetMarkerType() == kMarkerFoo) { FooMarker* fm = static_cast<FooMarker*>(node); ... }"[03:08:35] <caedes__> not sure if all those tests with the implied branching have less overhead than doing an rtti check, but at least it works if the platform doesn't support rtti[03:09:46] <KittyCat> by default, C++ checks an entire hierarchy[03:10:26] <KittyCat> so if you have an object of type C, and try to dynamic)cast from A* to B*, it will still work if C derives from B, which derives from A[03:13:58] <KittyCat> I had someone negatively comment about alure using rtti/dynamic_cast, since it uses pure-virtual interfaces to hide implementation details[03:15:29] <KittyCat> the dynamic_cast being a safety net in case someone stupidly decides to inherit from one of alure's classes themselves and pass an object in where it otherwise wants one of its own[03:18:04] <KittyCat> so I just added an option to build with -fno-rtti and use static_cast, instead of dynamic_cast[03:18:44] <KittyCat> not sure what MSVC switch disables rtti[03:20:57] <caedes__> /GR- http://msdn.microsoft.com/en-us/library/we6hfdy0.aspx[03:25:26] <caedes__> wow, doom3 has its own typeinfo stuff, seems quite sophisticated: https://github.com/RobertBeckebans/RBDOOM-3-BFG/blob/master/neo/d3xp/gamesys/Class.h#L333[03:27:17] <caedes__> (IsType() probably doesn't support multiple inheritance, though)[04:10:32] *** joelt has joined #openal[04:10:32] *** ChanServ sets mode: +v joelt[04:11:19] <joelt> newbie here> is OpenAL relatively ideal for capturing audio cross-platform?[04:11:51] <KittyCat> it's a decent way to do it, yeah[04:12:05] <KittyCat> it's more designed for mixing and playback, though[04:12:22] <joelt> is there something more appropriate for simple capture?[04:12:36] <joelt> i tried fmod and at least on OSX had issues getting the latency down.[04:14:23] <KittyCat> hmm, does SDL do audio capture?[04:16:05] <joelt> i just see playing: http://www.libsdl.org/release/SDL-1.2.15/docs/html/guideaudioexamples.html[04:18:22] <joelt> i'm confused though, platforms already support OpenAL? so nothing needs to be statically linked?[04:19:25] <joelt> KittyCat: question i guess for you :)[04:19:29] <KittyCat> you'll need to provide DLLs for Windows. OSX has it built-in, and most Linux systems have it easy enough[04:19:41] <joelt> android/ios?[04:20:40] <KittyCat> ios has it built-in I believe. you'll probably need to include it with your app for android[04:25:25] <joelt> KittyCat: you wouldn't know anything about NACL would you?[04:26:52] <KittyCat> unfortunately no[04:26:53] <joelt> actually i see there is something: http://stackoverflow.com/questions/13570739/nacl-openal-example-doesnt-work-on-windows[05:07:51] *** neXyon has quit IRC[06:34:32] *** joelt has quit IRC[06:43:34] *** lritter has quit IRC[06:54:56] <KittyCat> https://github.com/ducakar/openzone/blob/master/etc/patches/openal-soft-1.16.0.patch hmm, this patch doesn't look too difficult to fix up properly and apply[06:55:33] <KittyCat> is there some sdk or something to build nacl stuff on linux? and how about running?[07:02:32] *** mat^2 has quit IRC[07:46:55] *** tristanseifert has quit IRC[09:27:22] *** prophile has joined #openal[09:27:22] *** ChanServ sets mode: +v prophile[09:30:58] *** tristanseifert has joined #openal[09:30:58] *** ChanServ sets mode: +v tristanseifert[09:35:56] *** tristanseifert has quit IRC[09:44:52] *** bjz has joined #openal[09:44:52] *** ChanServ sets mode: +v bjz[09:54:13] *** bjz_ has joined #openal[09:54:13] *** ChanServ sets mode: +v bjz_[09:54:46] *** bjz has quit IRC[09:54:57] *** bjz_ has quit IRC[09:55:49] *** bjz has joined #openal[09:55:50] *** ChanServ sets mode: +v bjz[10:04:32] *** bjz has quit IRC[10:04:37] *** bjz_ has joined #openal[10:04:38] *** ChanServ sets mode: +v bjz_[10:04:40] *** mat^2 has joined #openal[10:04:40] *** ChanServ sets mode: +v mat^2[10:36:38] *** zeroclouds has quit IRC[10:41:13] *** Smirftsch has joined #openal[10:41:13] *** ChanServ sets mode: +v Smirftsch[10:41:41] <Smirftsch> hey all[10:42:19] <Smirftsch> does anyone know where I can get docs and explanations about :"Implemented EFX Chorus, Flanger, Distortion, Equalizer, and Compressor effects."[10:43:08] <Smirftsch> and things like the difference between f.e. AL_EFFECT_REVERB and AL_EFFECT_EAXREVERB[10:44:23] <KittyCat> Creative's OpenAL SDK contains information about EFX[10:44:38] <Smirftsch> yes, but not about the newer additions in openalsoft[10:45:20] <KittyCat> the basic difference between AL_EFFECT_REVERB and AL_EFFECT_EAXREVERB is that EAXREVERB is more flexible (contains echo, modulation, panning, and high-pass filter parameters)[10:46:29] <Smirftsch> which makes an explanation in detail even more interesting :)[10:48:37] <Smirftsch> but I see the differences in efx.h, guess can test it out- although I really miss an updated doc file like it is in the sdk[10:49:24] <KittyCat> the recent additions in openal soft are those things described in the EFX doc[10:50:45] <KittyCat> they weren't all implemented before (and there are still a few things missing))[10:54:03] *** bjz_ has quit IRC[10:54:27] *** bjz has joined #openal[10:54:27] *** ChanServ sets mode: +v bjz[10:59:03] <Smirftsch> oh....you mean in the...ah yes, indeed! Cool. thanks, didnt even think about the possibility that the new things could be mentioned there :)[10:59:14] <Smirftsch> its been years I looked into it[11:05:12] *** mat^2 has quit IRC[11:09:13] *** mat^2 has joined #openal[11:09:13] *** ChanServ sets mode: +v mat^2[11:11:17] <Smirftsch> this pdf file should be really included in the openalsoft package (if possible), it's definitely a bit confusing the way it is[11:12:21] <KittyCat> unfortunately I'm not very clear on the redistribution rights Creative has on it[11:13:34] <Smirftsch> and probably no one there willing to answer such a question? :)[11:14:59] <KittyCat> creative's been very silent with openal-related matters lately, for some reason[11:16:28] <Smirftsch> well, can't say that I am surprised, they dropped openal itself years ago anyway, if not for openalsoft it would have been pretty much dead since then anyway[11:17:32] <Smirftsch> the recent openal implementations are only included within the hardware drivers of some soundcards and only of very limited use for other cards[11:18:00] <Smirftsch> very disappointing[11:19:49] *** tristanseifert has joined #openal[11:19:49] *** ChanServ sets mode: +v tristanseifert[11:24:27] *** tristanseifert has quit IRC[11:25:26] <Smirftsch> didn't check it very frequently, but I think openal.org is also down for months[11:28:09] <KittyCat> it's had problems yeah, and creative let the domain lapse. luckilly though icculus managed to snag it and get something there (minimal as it is)[11:29:20] <Smirftsch> yeah, minimal but at least there, but it should be redirected or better, given to openal-soft[11:29:40] <Smirftsch> in the last years they forgot about the "open" in openal[11:31:50] <Smirftsch> icculus? Ryan?[11:32:32] <KittyCat> Ryan Gordon, yeah[11:34:57] <Smirftsch> yes, a commited coder, I "know" him from UTPG[11:35:24] <Smirftsch> somehow its always the same few people[11:46:14] *** bjz has quit IRC[11:46:33] *** bjz has joined #openal[11:46:42] *** ChanServ sets mode: +v bjz[11:53:18] *** mat^2 has quit IRC[12:03:01] *** mat^2 has joined #openal[12:03:01] *** ChanServ sets mode: +v mat^2[12:10:38] *** mat^2 has quit IRC[12:11:14] *** mat^2 has joined #openal[12:11:14] *** ChanServ sets mode: +v mat^2[12:53:07] <Smirftsch> I take it that ALC_HRTF_SOFT is not in latest git yet?[12:58:52] <KittyCat> not officially, no[12:59:09] <KittyCat> it is technically, but it's considered incomplete and subject to change[13:04:09] *** mat^2 has quit IRC[13:08:39] *** tristanseifert has joined #openal[13:08:39] *** ChanServ sets mode: +v tristanseifert[13:10:01] *** mat^2 has joined #openal[13:10:01] *** ChanServ sets mode: +v mat^2[13:13:17] *** tristanseifert has quit IRC[14:44:31] *** tristanseifert has joined #openal[14:44:31] *** ChanServ sets mode: +v tristanseifert[14:59:18] *** tristanseifert has quit IRC[15:04:57] *** mat^2 has quit IRC[16:07:28] *** kornerr1 has joined #openal[16:07:28] *** ChanServ sets mode: +v kornerr1[17:08:36] *** kornerr1 has quit IRC[19:10:06] *** lritter has joined #openal[19:10:06] *** ChanServ sets mode: +v lritter[19:15:47] *** mat^2 has joined #openal[19:15:47] *** ChanServ sets mode: +v mat^2[20:10:20] *** BrainDamage has quit IRC[20:15:29] *** BrainDamage has joined #openal[20:15:30] *** ChanServ sets mode: +v BrainDamage[20:50:24] *** freeedrich| has quit IRC[21:18:45] *** neXyon has joined #openal[21:18:45] *** ChanServ sets mode: +v neXyon[23:32:45] *** tristanseifert has joined #openal[23:32:45] *** ChanServ sets mode: +v tristanseifert