Switch from FMOD Ex to OpenAL-Soft #10
Comments
|
You can use libogg (or another library) to stream it to openal-soft. Here is an article about setting it up (ogg/openal): If you need help... stop by OpenMW's forum or IRC channel and talk with Chris/Kcat who is our resident OpenAL expert (and lead developer of OpenAL-Soft itself). We use FFmpeg to support every fileformat under the sun and stream it to OpenAL to do the rest. I don't think you need FFmpeg if you only support OGG, that is why I recommended libogg. |
|
BTW... OpenMW wishes you success on the project! :D |
|
Thanks! Yes, this is my first real project, and as such I expect to make a lot of naive mistakes along the way. It's great having such open access to experts on subjects like audio and cross-platform issues. I'm more oriented towards graphics programming; hence the plan to make my own ray tracer. It just seemed like a good idea since Arena has so little geometry to render and I know more about OpenCL than OpenGL. I am glad I decided to go with C++ instead of C#, since I have a feeling it would've been harder to keep things compatible between Visual Studio and Mono than between Visual Studio and GCC. |
|
Once you feel you are ready... I can help get opentesarea into Debian/Ubuntu and help with porting to other platforms as well. :) Congratulations and good luck on the project by the way! |
|
Mono implements the standard .NET libraries and for game specific routines, MonoGame runs on Windows as well and is at least partially API compatible with XNA. Both I know is true from first hand experience of experimentally porting an old XNA project of mine from .NET to Linux via Mono without actually changing a single line of code. Where I'd see you having problems with .NET would be the cross-platform OpenCL components, I can't really come up with any .NET OpenCL libraries off the top of my head but I have no real reason to expect they don't exist. That, and the Mono requirement would probably be annoying to people on Linux (myself included) and .NET being more personally more annoying for me to program in than C++. That former bit there might make it harder to get it into official repositories anyway. |
|
I used OpenCL.Net with C# for one small practice program before and it worked as intended. It doesn't look like it will be updated past OpenCL 1.2, though. Anyway, it seems that C++ was the right choice for this project. I've been using a lot of the convenience features of C++11 like unique_ptrs and bounds-checking, so I rarely have to worry about manual memory management or going outside of an array. With working on a growing code-base like this one, it makes development less of a headache. |
|
👍 C++11 and C++14 are great! |
|
It has been making hell in debugging, though. At least here, (it became prevalent in debugging issue #5 ) where it seems Code::Blocks's GDB invocation can't properly deal with the pointer wrapper types. (It just shows as a unique_ptr containing 0xwhatver and I can't view members or anything). If anyone has a suggestion of an IDE that works on Linux and can properly deal with them (I sure am not invoking gdb manually if I don't have to), I'd gladly try. It preferably should also be targetable by CMake. There's a handful I can pull out of the CMake help, though I'm not sure which one I should try first. |
|
Before, I used QtCreator for C++ then I fell in love CLion by JetBrains (makers of PyCharm). I <3 CLion. JetBrains loves OpenSource as well. So go download CLion and give it a try and then ask JetBrain for a free license to work on OpenTESArena. :) CLion is heavily geared towards CMake, so it is a perfect fit here. Don't get me wrong, QtCreator is great too, you can do more than just write Qt applications. So perhaps give both a spin and see which one you prefer. Open Source Support Program:
|
|
For debugging my projects, I always use the combination of gdb and valgrind. valgrind is great! |
|
Just as long as the autocomplete isn't terrible, the jump-to-declaration (and implementation) actually works and the visual debugger works with the pointer wrapper types in use here. None of those have ever really worked reliably for me in Code::Blocks as I'm usually in at least a minor state of perpetual annoyance. The visual debugging is pretty critical and is why I used Code::Blocks for so long, there is plenty of straight text editors I could just use but I don't really want to deal with using the GDB CLI when I don't have to (why should I have to? It's a pretty standard thing for projects like these. It's only a necessity when you're doing kernel debugging and other low level debugging). Looks like CLion might already be what I want, I just need to try it against OpenTESArena with its usage of the pointer wrappers. I just can't actually link the game right now due to OpenCL 2.0 issues with NVidia, but it hopefully should work. By the way, I'd say OpenTESArena currently doesn't fit their criteria for a free license as per https://www.jetbrains.com/buy/opensource/?product=clion But that really only depends on how rigidly they enforce these rules. Like this one: "Your OS project has a website including either a regularly updated News section or links to social network account(s) where project updates are posted" Github in many ways can qualify, especially with GH's inbuilt web hosting (which is currently unused), but it may not qualify for reasons of it not being your own hosted domain. I'd also have to question them about if the IDE should then only be used for the project I registered it for or if I can use it for whatever else and how active I need to be with the project and so on. It's a little messy. But I am pretty enthused about the IDE's capabilities thus far and I only messed with it briefly, but I am a bit put off by the having to renew licenses every year but it's not a terrible pricing either. |
|
All you have to do is ask for two licenses for the project. The worst they can say is no. ;) If you need it, you can have github host a 'webpage' for you via pages. I've done this for my other project: I have two licenses, one FOSS license for my work on OpenMW/WildMIDI/WorldEngine/others and another paid for by my work. Obviously I switch between my work and home machines quite a bit and still work on the same projects. I wouldn't worry about it too much. They aren't going to disqualify you for working on hobbies, they see it as another way to eventually get your work to buy licenses because their employees like the product. I won't get into the merits of gdb, suffice it to say... visual debugger will only get you so far before you have to dig deeper and sometimes you don't have the luxury of an IDE at all! ;) |
|
Visual debuggers are well more enough in pretty much all regular applications (those running in userspace) to view, alter and understand the program state. It becomes less of an option for lower level things like debugging kernels, like I said. At that point you're not working within the IDE anyway. If you're not working with a visual debugger and you're trying to debug a userspace process on the system, then you probably should look a little closer at your IDE's debugging systems. I wouldn't be horridly surprised if you can just attach to arbitrary processes (as you can with GDB). MSVS at the least can do it. I mentioned the GH pages in the post you responded to. I talked about them rigidly enforcing rules -- which I don't see them doing, but I don't hold much trust until proven otherwise for things like that. |
|
Just trying to help. :) I'm not saying which one is better, that is just silly... learn and use all the tools at your disposal. I mentioned GDB because the chances are 9 out of 10 that it will already be installed on non-Windows platforms. From clued-in users who want to give a stack-trace when OpenMW dies to integration testing where you can jump right into a machine to debug why your application failed their tests or segfaulted. Anyway, that is why I don't dismiss GDB out of hand. It has its uses, but you're right that a proper IDE is wonderful in development. I wish you guys luck. :) I've been using JB products for about five years now, with FOSS licenses... they've never revoked them and have been really easy going about things. That has been my experience anyway. |
|
You just need the dump file that the test created when it died to debug those sorts of situations. It'd be pretty weird if the IDE didn't know how to load that up into GDB. Seems like Clion might not support it, but there is tools like VisualGDB that can do it. Supposedly Eclipse can do it too. I just avoid it when I can because it just feels awkward in my opinion to debug the program state in a console. So far Clion has been pretty nice, it's supporting those pointer wrappers that Code::Block's choked on but so far it doesn't seem to deal with lambdas in a way I wanted it to (I can break in lambdas, step through, but dealing with variables in it is pretty weird), but it at least is capable of showing lambda-local variables. |
|
I know what you mean, I've used Eclipse for a few years before stepping over to QtCreator (C and C++) and PyCharm (Python). I'll be honest, I've not had a chance to evaluate Code::Block but people seem to like it. Please note, I don't develop on nor for Windows. I've been in the *Nix world since the 90s, so many of the really nifty things that MSVC provides and tools like ReSharper I don't have much experience with. This last bit might be something Windows devs here are interested in. The extend of my involvement in Windows is via VirtualBox and community editions of MSVC to make sure things compile and run. In addition to that, I use AppVeyor for continuous integration. This might be helpful for CI in addition to Travis-CI: I can help with this if there is any interest. (Build matrix of GCC and Clang).. |
|
I don't really develop much for Windows myself. :) Code::Blocks works pretty well except for the issues I mentioned, which can be pretty infuriating. As a thing aside, @afritz1 sorry for slightly hijacking this thread! |
|
It's okay. @kcat has sufficiently implemented OpenAL Soft and WildMIDI now, so I might as well close this issue. The project still needs WildMIDI 0.4 though, which can be built straight from its repository instead of using one of the releases. |
|
Yes, sorry for the hijack! Man pages need to be updated, then we can make a formal release and I can start pushing downstream. @Ragora and @afritz1 : would you like me to create an ITP for Debian (Ubuntu) to get OpenTESArena into downstream as well? I can push it to experimental so that those adventurous enough can test and send feedback to here. If not, no worries, we can wait. :) |
|
I'm not familiar with what ITP (Intent-to-Package?) is for. Does it just package up this project so others on Debian and Ubuntu can work with it more easily? I don't think we need lots of people testing the project just yet. What's your opinion? |
|
You guessed it right. ITP means that I (or someone else) intends to create a package of OpenTESArena for Debian inclusion. It will go on to the mailing list, be talked about and then someone has to actually create the package. Once this is done, then it is again talked about and hopefully a sponsor (Debian Developer with more rights than I) will help champion the package for inclusion. Once this has happened, the first release is uploaded to the Debian Lawyers so they can look it over to make sure it fits DFSG (Debian Free Software Guidelines)[1]. Should they OK it and it meets quality control standards, it is uploaded first to 'experimental' release. All brand new packages go there. When you feel that OTESA is 'ready', we can then re-upload to 'testing' which eventually makes it into a proper Debian release that gets picked up by Ubuntu. I'm guessing the process can take anywhere from a month to 6 months depending on the queue size. Once it is accepted by Debian, it is then trivial for me (or others) to make updates every release. This can be anywhere between a day to a week typically. In my opinion, having more eyes on the project is always good. It brings in more developers and testers... you can never have enough of those. Its good PR! [1] https://en.wikipedia.org/wiki/Debian_Free_Software_Guidelines |
Wow, that sounds pretty nifty! I guess my project might end up going farther than I had anticipated. So other open-source projects do this too, like OpenMW? If my current MIT license causes any road bumps, I can change it to GPL, but I would like a good reason to do it first. I like the idea of more testers, but I'm also a bit anxious about all of the questions I'd be answering for people instead of doing coding! |
|
I've done this with multiple projects already (including OpenMW): MIT is fine! It is a more liberal/open license than the GPL. You can't just arbitrarily change a license however, you would need the permission of everyone on your team to make the switch but that isn't necessary, MIT is good if that is what you really want. |
|
Okay. Well, I think we should wait a bit longer until the project is free of any Arena resources being used from extracted/converted files (namely, those in my Dropbox link). Once we start using the virtual file system exclusively to read in the floppy disk version's files, then I think there would be no legal issues at all. What would you say the limit is on using extracted files for Arena? @kcat already mentioned this topic here, and how it is "legally dubious". For example, I used a tool to extract the original font files and I assembled them into new image files. Is this something we would have to leave up to mods? I just wanted to avoid doing some things in the program that could be done outside beforehand. |
|
He's right about that, it is best to read the files in natively and convert on-the-fly to PCM and let OpenAL handle the rest. The same should be done with all other assets as well. Best leave it up to modders for creating new content or remixing the old content. I would focus on supporting the original formats natively first. Bethesda/Zenimax are still the owner of the Arena IP, even if they allow you download it for free, we still don't know under what kind of license which makes it legally dubious/ambiguous to redistribute/remix. Best just to stay at arm's length. :) |
|
It's even more dubious if they legitimately released it with no sort of licensing terms at all (packaged with it). You'd have to contact them, for which there shouldn't be a loss at doing so as the worst they can say is "You can't do that" but they can't stop you from doing the above as you're not redistributing the assets. OpenMW would've been hammered absolutely forever ago if this weren't the case. |
|
I imagine this also affects text, like character classes and locations in the game (since text is still data), so I can't use my |
|
I'm going to have to pull an 'arm-chair' lawyer moment here, so please, IANAL: Individual words and phrases can't be copyrighted. Non-generic names can be trademarked however. Copying sentences (full text) on the other hand is something Bethesda can go after the project for, if they wanted, and make your life difficult. These things are best read in at runtime. It is more work, but then you don't have to worry about Bethesda sending in guys like Matt Grandstaff to ask people to stop developing. |
|
I read through most of those emails, and wow, it's pretty involved. So OpenMW has to "primarily" be on PC platforms, but it can also be on Linux, Mac, etc., as long as you don't parade around exclaiming it to everyone. It seems like having it run on Android was a big concern of theirs, too. I originally thought it didn't matter where Morrowind was played as long as the user purchased a copy legally. I don't think I'll freak out if I'm contacted by Bethesda, because from what you showed me, there is certainly the opportunity to talk it over with them first before making any decisions about stopping development. Also, I wonder how they treat the "intended platform" topic with DOS... if it's now DOSBox with Arena and Daggerfall... |
|
PC == Personal Computer, which includes Windows, Linux and OSX. <-- This they have no problems with. They took exception with Morrowind running on Android (Mobile/Tablet). Maybe they want to release their own version in the future? Who knows. They technically don't have a legal leg to stand on, but we worked around it. We "OpenMW Team" won't display screenshots or films of Morrowind running on Android (or Mobile Device). It doesn't prevent others from doing so however. :) |
|
Edit The included PDF simply says they own the IP but mention nothing about how they want it restricted to only them distributing the content (despite it being a free release). I'm at a point of screw it, may as well just disregard everything above. |
From their official download: But regardless of the EULA, I know the moderators over at the BethSoft forums are diligent about removing download links for ArenaSetup since it contains the CD version of the game, while Bethesda released the floppy disk version for free. Unfortunately I can't seem to find any info on UESP about what the exact differences are between the floppy disk and CD versions (some voice and video files I think, though I'm not sure which ones), but that's going to be a limiting factor for pre-converted asset distribution even if it was allowed of their free release. |
|
That is the download I checked indeed. |
|
@Ragora the email exchange was to demonstrate that bethesda does actively go out looking for these things. The point is, don't redistribute someone else's IP. :) |
|
Of course they are, why would I think otherwise? They need to defend their IP to really retain it. The problem is literally everything else not-that above, though. And it's also why I keep saying in every other post that there isn't anything lost in clarifying with them. |
|
Agreed. :) Thread hijack complete! :P BTW: I'm making a new release of WildMIDI today. This includes the XMI support so you guys don't have to compile from scratch anymore. The follow up release (0.4.1) will have SF2 (soundfont) support. |
|
That's good news! (To be honest, I've just been using 0.3.9 in the meantime.) |
|
I could grab that and see what happens. |
I found that Debian and Ubuntu don't include FMOD as it is actually a closed-source library, so I will be moving in the direction of OpenAL-Soft soon instead.
For MIDI support, I'll use either WildMIDI or FluidSynth. I don't know if there will be any significant changes to the project's Ogg support when using OpenAL-Soft. In the worst case, all of the .ogg sound files would be converted to another (hopefully lossless) format.
The text was updated successfully, but these errors were encountered: