Little feedback about build process

[codec-abc]

Hi,

As a linux user (Ubuntu 13.10) and a "game engine hobbyist" I searched for a game engine that is fully featured and easy to use. Something like Unity3D but open sourced and linux compatible. I came across Urho3D and I decided to tried it. Once I build it (which is the main reason of my post here) I have to say that I was really impressed by the samples and the editor. Before, starting with some of the things I don't like in the build process I have two questions about Urho3D.

1-From what I saw the GUI looks similar to every others GUI written in OpenGL/DirectX. By this, I mean it is not really pretty (imho). I know this is a difficult topic and from what I know, every engine that aims to do neat things with GUIs end up to using other library to handle this. I think about scaleform, coherent ui, awesomium, librocket... So my question is : is there any plan to integrate a different UI in Urho3D ?

2-I saw that Urho3D doest not use OpenAL. So on what libraries it rely on each platform to provide sound features ?

So now, come back to the build process. Here how I processed to build it on the problem I encoutered :

I clone the github repo.
Then, I use cmake-gui on the CMakeLists.txt on the source folder. I think it's better to do this way that relying on a script as you have more control over things and it still remain user friendly. Using cmake-gui I made a build folder completey out of source. This is the problem I had :

1-a Urho3D.h was generated on my build directory (which is normal I suppose), But the folder it was in was not given to the include directories list for the compilation process and so I got compile erros (not for the engine, but for the samples). About this file, can't it be on the repository instead of being generated ? I am not such a fan of generating "source files" and that force you to have more directories to include when you compile.

2-The build parameters don't show up in the cmake-gui and they don't seem to have the default value corresponding to what is written in the wiki. It may be because I didn't use a script that call cmake with the wright options. Using the cmake syntax in the cmake's scripts: option(<option_variable> "help string describing option" [initial value]) make them visible in the gui. In my opinion, it should be better to prefix them with something like U3D_BUILD_CONF_ so they show up grouped in the cmake-gui.

3-The build process is not really out-of-the-source. For clarity let's say that my source folder (repository) is called A and I want my build to be in directory B. I expect the Urho3D library file (either static or dynamic), the samples executables, the generated documentation to be in the folder B.
With the library under B/lib, the samples in B/samples/sample_name and the documentation under B/doc. Instead, the lib an the samples ended up in A/Bin and the documentaion in A/Doc. This way, you are sure to not mix up source files and build files. Even if the .gitignore should provide protection against this it's still better to completely separe source and build.

I hope you will find my feedback usefull and if you want to see how "I fixed some of those issues" you might want to look on my repo here : https://github.com/codec-abc/Urho3D/

I am by no mean a CMake expert so don't think my modifications are well designed and robust.

codec-abc

[Lasse Öörni]

I will answer shortly about the audio & GUI.

For audio, SDL's inbuilt functionality is used. This is just a stereo output stream that is manually software mixed in the Audio subsystem. The downside is the lack of true 3D audio spatialization & filtering. If eg. OpenAL-Soft was to use MIT/BSD licensing it would be a no-brainer to use it, but to retain the engine as freely usable as possible without any restrictions on static linking we cannot accept LGPL libraries.

For GUI, the same about library licenses applies. Additionally any external GUI library should be possible to seamlessly integrate into Urho's own event system, which is easier said than done. At the moment continuing to use the "inhouse" GUI is the most straightforward option, considering also that a rather substantial application (the editor) has already been written using it.

[codec-abc]

Thanks for the answer. Indeed, LGPL brings many limitations

[weitjong]

And allow me to answer on the build process. BTW, I am also a Linux user. I am actually surprised you prefers GUI over CLI. Our recent success in setting up Travis CI to perform the continuous integration build in the Ubuntu 12.04 LTS headless virtual machine is only made possible because our build process relies on CLI scripts than cmake-gui.

1. This header file is added quite recently to export Urho3D library symbols when building the library and to import the symbols when using it. The file is generated on the fly because different platforms (especially on Windows/MSVC) have different ways of exporting and importing symbols. We have two choices to solve this issue, use the CMake provided macro to generate a platform-specific header file for us; or write and maintain one big file with numerous #ifdef ourselves to cater for all the platforms. We chose the former approach. Granted that source file generation on the fly has brought its own complexity to the build process, but fortunately we can easily configure all our targets (including sample targets) to automagically find those generated source files. Incidentally, the Lua to C++ binding and LuaJIT VM cross-platform build are only possible with generating new source file on the fly.

I am also new to CMake when I started to work with Urho3D project. So, I am not sure why the same CMakeLists.txt works in CLI, but not in cmake-gui. I seldom use the latter. All I can say is, the CMakeLists.txt for sample targets uses a custom module "FindUrho3D.cmake" which is responsible to setup the header include directory and library search path for the compiler and linker, respectively. This module (and in fact all the build scripts currently available) has to make certain assumption on where the build directory and output directory is (as per our documentation). If you set those directories arbitrarily yourself via cmake-gui then the module and the build would surely fail.

2. This is a good idea if there is a plan to add 'cmake-gui' as one of the supported build process.

3. As explained in 1, currently the out-of-source build is setup with certain assumption on where the source, the build, the output, the documentation directories are located relative to project root directory. You are welcome to contribute to remove those assumption, please keep in mind that new build solution must work in all the platforms supported by Urho3D.

[codec-abc]

Well in generally, I don't prefer CLI over GUI or the contrary, it just depend on the case. For CMake the GUI is quite usefull as it shows you what you can configure and is very easy to use for those with little experience in complex build system (like myself for example). You should note that cmake-gui and the "regular" cmake do the same things so if the CMake scripts provided are well written it should not make any differences for the user if he/she use one or the other.

1-I agree with you that with the constraints you explained the generated file is the best solution. But then, you might want to check if its include path is correctly provided by CMake to the build system. I think it's not when you do not use the default location but I may be wrong.

2- For example, this is a thing that I found confusing. in the wiki it is written :

|-DENABLE_ANGELSCRIPT=0|to disable AngelScript scripting support   

Apart that from not being very clear if AngelScript would be activate at 1 or 0 value, you don' t see it using cmake-gui while you can still modify "blindly". I didn't neither see any default value in the CMake scripts so it is hard to figure what will happen if you don't provide this argument to cmake (cli or not).

From the very few changes I made I believe I fix problem 1, 2 (without names changing) and 3 (partially, the Urho3D library is now build to correct location specified but the documentation and the samples are still in the wrong places) But I am not an experienced CMake script writer and I don't have all that is needed to test that it will work on every platform. But if someone want to help me tweak the script to make a more flexible build system I will happily accept his/her help.

[Chris Friesen]

As for the UI. A simple change to a modern sans serif font and increased layout borders would make the ui feel more modern.  A couple tweaks to the scrollbars/check boxes might help.  I do think we are like 80-90% there.  Keep chipping away.  If we get the spritesheet work Aster is working on, relative ui motion, and a few bits and bobs; it inches us closer.  Incremental progress \m/  

After using Urho for quite a while you really start to appreciate the frameworks design and the way the design affects your own code in a positive way.  It's hard to notice at first glace but at every corner performance, memory, draw calls etc are considered.  Grep Batch and you start to see how it pervades the design.  It doesn't get in your way but it has some very nice conventions.  I'm telling you... Urho is like that band you like before they make it big.  Soon everyone is sing their song and then they sell out.  I can say these things without being too egotistical since I had virtually no hand in it.

[weitjong]

I think the key question is, do we want to add cmake-gui as one of the supported build process? CMake-gui allows user to arbitrarily specify where the build directory is. If we decide to support that then we will have to review all the CMake modules and scripts to remove any assumption that build directory is always PROJECT_ROOT_DIR/Build (on native build).

[weitjong]

I have done a quick scan anyway on the modules and scripts, and found only one place where the build directory was being assumed which I have now fixed. I do not test it myself personally with cmake-gui but I hope this should solve your issue of not finding the Urho3D.h file. The output directory (Bin and Lib) and document directory (Doc/html) location are still being assumed or, should I say, predefined.

[codec-abc]

@Chris Friesen : Sure a nice theme for the GUI can play a big role here. Anyway while looking at possible ways to make a UI in other ways I found that using CEF can be quite nice too. For example, there is a demo with Ogre3D. Imo, that is quite impressive and has a huge potential.
http://www.youtube.com/watch?v=MVvHmxHpf-Y

@weitjong : thanks for the build update, I will test it and try to make the build fully out of source as possible. As a side node you can provide  a different build location with the --build <dir> command argument to cmake.

@all : I want to come back on the license issue. Does the staticaly linking nature of the Urho3D library make it totally incompatible with libraries release under LGPL and similar license ? Because looking at wikipedia it seems you can use LPGL statically if you provided the source code which is the case because Urho3D is open source. This seems important to me because without some libraries you can' t have the feature you might expect from a modern game engine. The most visible case is audio. There is no library in MIT/Zlib/Apache (or similar) license that provide true 3D audio. So if you want that Urho3D could have true 3D audio someday you either have to :
-Build your own 3D audio library under permissive license and then use it in the engine. Probably the hardest way of achieving it,
-Find a way to use a LGPL (so you can use OpenAL) library statically linked. Maybe this is already possible.
-Make the default build of Urho3D using dynamically linking (for each third-party library) instead of static linking. Then you could use OpenAL too. Surely manageable but it would need to change the build system once more.

PS: sorry for the double topic that I created but I don't find that google group interface really convenient.

[Lasse Öörni]

The problem with LGPL is not in the build system, it would be relatively easy to include DLL's of thirdparty libraries with the engine. The problem is platforms where you can't reasonably comply with LGPL's requirement of being able to replace the thirdparty DLL, namely Android & iOS. In your own builds and projects based on Urho3D you're naturally free to use LGPL as you wish but we don't want to drag the default Urho3D distribution itself into any kind of a grey zone, so that it remains as generally usable as possible.

[codec-abc]

Thanks for the explanation but then I know there are people who use OpenAL (for example) on iOS and Android. So how do you think they handle the requirement of LGPL in such cases ?

[Lasse Öörni]

On iOS the native OpenAL implementation can be used. On Android there is an equivalent OpenSL API.

[codec-abc]

How you qualify the ease of integrating a library such as OpenGL in Urho3D ? Looking at the Audio part of the engine I think it will be difficult since the concept for treating sound seems quite different between the SDL and OpenAL. The only way I can imagine to do it is to get rid of the audio part in the engine and then rewrite it for for OpenAL. But then I doubt that the editor and other things would works seamlessly as the class and methods would surely differ. Is there any better way to do this without breaking all the engine apart ?

[Lasse Öörni]

The SoundSource components have basically been modelled on a low-enough common denominator feature set so that it actually wouldn't be that hard and likely wouldn't break much. Alex Fuller has already been testing an OpenAL implementation on iOS. Basically the stream output model would be discarded and the SoundSources would talk directly to OpenAL.

However, there are some possible issues, like how to do pure 2D panning with the 3D sound model. On desktops it would likely to be necessary to use OpenAL-Soft to not trip over poor or old implementations. OpenAL produces sound on its own so strict control over the audio stream (and the possibility to add custom processing) would be lost.

It would also be worth investigating whether there's a permissively-licensed implementation of the 3D positional audio filtering algorithms.

EDIT: contributor name corrected.

[codec-abc]

Thanks for the explanation. I might give it a shot in the next days. Does the code of the iOS implementation of Urho3D with OpenAL (made by Alex) is available somewhere? It might save me a lot of time if he has already done that.

As for a permissive library that could handle 3D sound in more realistic fashion that SDL does, I found nothing after googling the web for a few hours. IrrKlang, FMod, OpenAL (and derivates), Bass are excluded because of licences issues (they may have portability issues too). SDL and portAudio don't have such capabilities. It does not leave you with may others options I believe. I hope I am wrong.

[Alex Fuller]

Hi codec-abc,

I've still got the modified code for OpenAL support. It is based off an old version of Urho3D svn from December 2012 and I didn't quite get ogg-vorbis streaming to work so it is currently limited to wav files. It loosely matches to AL's equivalents when it comes to positional or doppler mixers from memory but it wasn't tested too much, all I wanted was audio for performance reasons on iOS and an easy way to use the microphone.

There is a library which does support 3D audio which had a liberal license but it was a bit high-level. https://github.com/stuffmatic/kowalski but I'm not sure of the state of it, but it does look interesting.

How should I share it? I haven't used github or git too much other than clones and doing pushes to my own private branch. I guess I just clone it to my github account and make a branch or something?

[Alex Fuller]

Hi codec-abc,

I've just pushed a branch on my own github mirror of Urho3D here:

https://github.com/boberfly/Urho3D/tree/openal

All I did was do a preliminary scan and merged the newest diffs since December 2012 but pretty much left all the #ifdef USE_OPENAL that I made originally in there. You may hit a few compile snags as I haven't dared to try and compile this. You may also want to link the OpenAL or AL lib into one of the CMake files too. There's also a way to capture the microphone in there for iOS only, the android one I didn't end up finishing, as I'm hoping a later SDL version will eventually support capturing audio...

Cheers!

[codec-abc]

That's really nice of you. Thanks. I will try out soon.

[codec-abc]

Hi again, 

Like I said in my previous message I am trying to make the build a bit more flexible.

Basically I want to :

1-make the build completely out of source

2-be able to easily build each third-party library as a shared one.

By modifying the CMake's scripts I think I am 50% done.

So far I have 2 questions :

1-I discovered travis-ci with weitjong's message. This seems nice and I plan to use it more for my next project. On the travis.yml of the repository there is a line secure: ST80PPq8cTIZ5WRgX4..... In the documentation it is written that it is environment variable that are encrypted. Is possible to know what that variable is ? Is it mandatory for the build system ?

2-What are your positions on pull request ? I mean  if I succeed on doing what I plan to do, will you accept a pull request ?

Thanks, again

[Lasse Öörni]

If things don't break (for any platform) then I don't see problem accepting build improvements.

[codec-abc]

@Lasse Öörni 
Thanks. And What about if I can only test it for some platform ? I have not a Apple computer nor a iPhone. At best I could test the Linux and Windows builds. Would it be enough ?

About pull requests :  I have done modifications in multiple commits so far. Would this cause some problem of merging with the official repository ?

Anyway I still got time for that since I successfully set up a travis build system but only 2 of 4 build happen correctly so far. I'm still pretty happy with that. I thought tweaking CMake scripts would be far more difficult.

@weitjong : Sorry for the previous bad information. In fact in you want to build a cmake version of Urho3D out of source from command line you have to call cmake from the build directory. the --build parameter is for something else.

For example, if you have this in your file system:

/~

 -> /Urho3D (the github clone repo)

 -> /build

and you want the build to be in the directory "build" (sometimes I just feel like I am captain obvious) you just have to do :  cd ~/build && cmake ../Urho3D/Source.

Basically my travis script is something like : mkdir ../build && cd ../build && cmake (lots of options here) ../Urho3D/Source && make all && make test

[weitjong]

@weitjong : Sorry for the previous bad information. In fact in you want to build a cmake version of Urho3D out of source from command line you have to call cmake from the build directory. the --build parameter is for something else.

For example, if you have this in your file system:

/~

 -> /Urho3D (the github clone repo)

 -> /build

I hope this is not the direction you are heading in case that is what you mean by "completely out of source". If you dig the commit logs long enough (I think around mid last year), you will find that this was actually what we had before. At that time all the source codes were scattered in the project root directory and the only way to setup the out-of-source build directory was to have it outside of the project root directory. Now, we have created a subdir called "Source" in the project root directory where all the source codes are grouped in one place and so the build directory can be simply setup to be out of this "Source" directory but keep inside the same project root directory for a good reason. Some developers (at least myself) have multiple Urho3D clone repos in a same parent directory, having build directory outside of project root directory (repo) could be confusing, IMHO.

  

and you want the build to be in the directory "build" (sometimes I just feel like I am captain obvious) you just have to do :  cd ~/build && cmake ../Urho3D/Source.

Basically my travis script is something like : mkdir ../build && cd ../build && cmake (lots of options here) ../Urho3D/Source && make all && make test

In our current build script we use: cmake -E chdir $BUILD cmake $SOURCE. Basically it instructs CMake to perform a change directory first to achieve the same result as above. Note that a few platform-specific build scripts have what I called post-cmake step to supplement and/or correct mistakes due to known bug from CMake generator. Calling CMake directly instead of our build scripts loses those post-cmake fixes.

[weitjong]

So far I have 2 questions :

1-I discovered travis-ci with weitjong's message. This seems nice and I plan to use it more for my next project. On the travis.yml of the repository there is a line secure: ST80PPq8cTIZ5WRgX4..... In the documentation it is written that it is environment variable that are encrypted. Is possible to know what that variable is ? Is it mandatory for the build system ?

2-What are your positions on pull request ? I mean  if I succeed on doing what I plan to do, will you accept a pull request ?

Allow me to answer the first question. You are correct, the secret key encrypts these environment variables: GIT_NAME=... GIT_EMAIL=... GH_TOKEN=... I could not give you the exact value for security reason. Those variables are not mandatory for the build (make or make test) itself. They are there only to provide GitHub account credential to allow Travis to git commit and push to our repository. If your project does not have that need, you can safely remove this secret key in .travis.yml and remove the last two lines in the Rakefile. In fact the whole instructions in the Rakefile are Urho3D project specific, so you may just remove below line in .travis.yml all together.

after_success: rake travis

[codec-abc]

Thanks for the tip about travis. That was I thought. I will remove the unnecessary line from my travis script.

About the directory structure I am thinking about something like this.

/~

 -> /Urho3D (the github clone repo)

    ->Bin

    ->Docs

    ->Source

    ->SourceAssets

 -> /build

    ->Bin

    ->Docs

    ->Libs

So basically I left the source untouched and I do not plane to move them. But the libraries (either static or dynamic), the documentation and the binary executable goes into the build directory.

For me it kept all the advantages to have the source in the same directory but it add those:

1-Completely out of source build. You do not mess with the source directory by building Urho3D. This way, you have less chance to bring back build file to the github repo by an accidental commit.

2-You can do different build for different options. For example, instead of a unique build dir, you can go for a buildDebug/ and a buildRelease/ with those two being completely independent. With the current build system I don't think it is possible.

3-It is more modular and should be easier to use 3rd party dll. In my case, I see the integration of OpenAL a bit easier with such system.

Please feel free to correct me if I'm wrong or if you see room for improvements in what I am doing. Thanks again for the time you put in answering me.

[weitjong]

I think I understand better where you are heading now. However, I have a few comments with your plan, although I could be wrong.
1. The content of Bin dir must contain CoreData and Data subdirs or the executable won't run. That is, you can't have executable in the Build/Bin while Data folders in Urho3D/Bin, unless you explicitly tell the engine where to look for assets in that other dir that is different than the dir where executable resides. Or you have to setup some symlinks one way or the other.
2. Only CMake/Makefile generator produces a single build configuration project file (e.g. Makefile for Debug or Makefile for Release). Other CMake generators, however, can produces multi build configuration project file (e.g. CMake/VS generator produces a solution file that could be in any of build configuration with a click of a button; same applies for CMake/Xcode generator). In short, you are solving a problem that does not exist in other platforms.

But you are welcome to prove me wrong. If it improves our current build process then for sure it will be accepted and merged.

[codec-abc]

You are correct on those two points and I already thank about them but I am not to the point where I decided for a solution.

1.For the data needed by the engine it can be copied over each build directory. Or I could try to generate a file by CMake that set a list of hint for the binaries.

2.I am sure it is true for Release/Debug configuration (since I already experienced it) but I doubt that it can handle going from static to dynamic linking (or the other way) in the same configuration. Even, if it is the case you can save some time if you have separate configuration by avoiding rebuilding the entire engine and its dependencies at each change.

[codec-abc]

Hi again,

I have work more on the build system and I made progress. Now the build is completely out of source and works on Linux and Windows. I could not check on others platform.

Still I have a bit of trouble when trying to make the 3rd party dependencies as dynamic. In my Linux build everything happen well until I try to build the player. Then I get this error :

[ 75%] Building CXX object Tools/Urho3DPlayer/CMakeFiles/Urho3DPlayer.dir/Urho3DPlayer.cpp.o
Linking CXX executable ../../Bin/Urho3DPlayer
../../Lib/libLuaScript.so: undefined reference to `Urho3D::HttpRequest::GetState() const'
../../Lib/libLuaScript.so: undefined reference to `Urho3D::HttpRequest::GetAvailableSize() const'
../../Lib/libLuaScript.so: undefined reference to `Urho3D::HttpRequest::GetError() const'
../../Lib/libLuaScript.so: undefined reference to `Urho3D::LOGIC_CATEGORY'
collect2: ld returned 1 exit status
make[2]: *** [Bin/Urho3DPlayer] Error 1
make[1]: *** [Tools/Urho3DPlayer/CMakeFiles/Urho3DPlayer.dir/all] Error 2
make: *** [all] Error 2

If I check with nm is symbol are in the dll (so in this case) I found them which is why I get a hard time finding where the problem come from. Anyone has a clue ?

[Mike]

Did you check if your libraries are linked in the correct order (from right to left) in your script?
Look at http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html for reference.

[codec-abc]

I thank about that and I read on stackoverflow that gcc link order is irrelevant for dynamic libraries but I might have interpreted an answer in a wrong way.

Technically I did not write the script (makefile) because it is generated by CMake. Still, I will give it another look when I will have a bit more free time. But I believe that the problem is related to the Lua Stuff since it build nicely on Linux and Windows without Lua. 

I have other weirdness too. On Windows Strange things happen. All sample run fine if they find Urho3D.dll and SDL.dll and a few system dlls. I can remove all others (Bullet.dll, ...)  it does not matter. This is very strange...

Anyway if someone want a deeper look you can grab my repository at : https://github.com/codec-abc/Urho3D

For building the engine and dependencies as dynamic libs you need to provide those arguments to CMake : -DURHO3D_LIB_TYPE=SHARED -DENABLE_LIBS_AS_STATIC=0. On windows you may just want to add d dll export to this function HWND WIN_GetWindowHandle(SDL_Window* window) in the SDL_windowswindow.c file. 

[Lasse Öörni]

I would guess the third-party libs are still being appended to the Urho3D library (there's extensive CMake magic for that in the Urho3D library CMakeLists.txt) if they can be removed and the application still works. Check the actual DLL dependencies of the application with Dependency Walker ( http://www.dependencywalker.com/ )

As for the SDL function, you should make it work out of the box, ie. modify that part to take the Urho build mode into account.

[codec-abc]

It's strange since on my linux computer if I delete the shared object it doesn't work anymore which is supposed to happen. Plus the dll and so files are roughly the same size.

I'm bit clueless for now but I hope I will find some idea soon.

For the SDL function I will patch it.

[codec-abc]

I will answer myself. The reason that Windows does not need the dll in my executables is that if no function is declared with the dll_export "tag"inside a library it will then put the entire library in the import library file and the dll file will still be created but is useless. In short, the library is build as a static one even if the project is configured to create a shared one. Moreover some libraries, like bullet for instance, are not designed to be compiled as a dynamic library. 

The conclusion is that it is pointless to try to build Urho3D with 3rd party dependencies as shared libraries. At least with those provided. If only I could have known those fact before starting this. At least, I learn something in the process. I just hope I can reuse some of my CMake script to ease the integration of other dynamic library especially OpenAL for example.

[weitjong]

In a way I am glad that now I have someone else that could see the similar problems that I have to deal with while designing and developing the Urho3D library build. When the library build just works on all the supported platforms and use cases and even on a range of CMake versions, most just take it as a matter of course.

About the problem you face with LuaScript, I have encountered it too during the development process. The LuaScript is one of Urho3D "sub-library", similar to Graphics or Audio or Script sub-library. It is not a third-party library per se, so it should not be made into a shared library by itself. The LuaScript's CMakeLists.txt is being structured differently than the rest of Urho3D sub-libraries due to CMake own technical limitation. If I remember correctly CMake only allows custom command to generate output source files on the fly for a valid CMake target in the same scope as current CMakeLists.txt. We are forced to keep LuaScript as a (static) library target to workaround that limitation. Note that the rest of Urho3D "sub-libraries" are not valid CMake targets (anymore). Still being a sub-library, LuaScript has too much dependencies to the rest of the sub-libraries, so it can only be linked against with special care as it is now.

When you are ready, perhaps you can create a pull request. It is easier for us to review the changes that way.

[codec-abc]

Thanks for the answer. I think I made what I wanted. The build is completely out of source and I made some simple script to allow linking (either static or dynamic) with other libraries.  I am testing that right now with OpenAL and the code kindly provided by Alex. Plus some build are running with travis. Hopefully, they should build nicely. 

About the pull request : How do you want to do that ? I am not a git expert and I don't know how to pull all my commits in a single request. Moreover it may be safer to create a branch for now as it may mess around. Plus I cannot guarantee that the build still work on Mac, iOS and Android. Can you test all these platforms ?

[codec-abc]

I was able to compile and link the OpenAL code provided by Alex almost with no trouble. The only thing I had to do is to disable all the Lua stuff as the linker complains that methods are found when building a Lua library. Probably the interface has changed a bit and so the lua stuff expect to find some function that are not here.

if Alex come by again to this thread I have a question for him  : Have you implemented 3d audio positioning with OpenAL ? So far I got sound but it don't seems that 3D audio positioning is working. Plus, strange things happens but nothing too critical.

[Lasse Öörni]

The pull request basically is a branch from your repository, so yes, it's better to create a branch than eg. offer your "master" branch for pulling.

However I see that there's some back-and-forth commits in your repository, where the commit messages show that you're unsure what you're doing and reverting things etc. It would be preferable to flatten (rebase) your work so that there's no sign of experimentation and unsureness, only the changes you want to happen. If you don't know how to do that with git commands you can also do that manually ie. start from our master branch as a base again and reintroduce the changes with new commits.

I can understand that you can't test on Mac & iOS. However the Android SDK (which contains a device simulator) & NDK should be available for no charge on all OSes so you should test on that one rather than require us to test for you.

[Alex Fuller]

Hi codec-abc,

From memory the positioning was just 'guessing' how it should go by setting the position vector from the attributes to OpenAL in the loop for all the audio buffers as well as setting the listener position vector. I didn't test this by ear as my purpose was to just get any sound working (OpenAL seemed to work better on older iOS devices at the time compared to the default Urho3D mixer via SDL where I had some playback issues), plus it was easier to get the microphone to work. It might be that you just need to set the distance model that I think I mapped to an attribute so there is any falloff. By default I may have hard-coded this to just have no distance model so there won't be any 3D positioning at all.

From looking at the code, open up SoundSource3D.cpp line 168:

alSourcei(alSource_, AL_SOURCE_RELATIVE, AL_FALSE); // Disable this to get 3D spacial back

Make that AL_TRUE or remove the line entirely as I think it is true by default... :)

For reference look here:

https://source.tizen.org/sites/default/files/page/openal_1.1_specification.pdf

I noticed some attributes have been added and removed since I last did the code so maybe some map more logically to OpenAL so when switching back-ends it's more consistent.

Hope this helps!

-Alex

[codec-abc]

@Lasse Öörni : Yeah it's true there is some back-and-forth in my commits. I will dig on the rebase git command soon. 

About the Android thing, I will not test it but it should work as expected since I did not touch anything related to android. 

Take no offence, but I think that mobile platforms are awful for development. Because of different processor architecture the device emulator rely on emulation instead of virtualization which make it extremely slow. Moreover the only available ide for android is eclipse which i dislike. 

Plus, they are few more reason why I don't like these but I don't intend to start a war about mobile platforms here. 

Anyway, I have no interest in mobile platform and so I won't look at these. I totally understand that it surely is a problem for you since you probably won't take modifications that could break.

@Alex Fuller : Thanks for the tips. It surely help. I will try new things soon.

[codec-abc]

Just for update sake : I have successfully used OpenAL to provide 3D sound positioning. Indeed you were right Alex : it was necessary to comment the line. I needed to add a listener to my scene too. It take me some time to find that if there isn't one there was no warning and the sound were playing but only in mono. This let me think that your line :

alSourcef(alSource_, AL_MAX_DISTANCE, 0); // I think this would kill off sound...? (~ 185 in SoundSource3D.cpp) does not work as you expected. So, it seems that alSourcef(alSource_, AL_MAX_DISTANCE, 0) does not kill the sound.

About the result were not awesome but still quite good. Anyway, thanks for the help. I greatly appreciated it.