Hey, folks! I just migrated my personal project to FmodEx in 2 hours (from OpenAL). 😀
I don’t intend to charge for my project, so I can use Fmod for free according to your licence, which is simply awesome considering how much Fmod provides. Thanks a lot for that.
I have a few notes, though.
Documentation that comes with Fmod is OK (almost 700 pages of API in a pdf file, geeze). However the tutorials in it are quite weak. For example, the code there uses ERRCHECK( FMOD_RESULT & ); but such method or define does not exist in API, and is not described either. Same goes for FMOD_ErrorString(). How do I get error description by its number from FMOD_RESULT?
So, it would be nice to have a set of complete tutorials, however small and simple they are. It would be very helpful to see a complete code with init and shutdown.
In documentation, it is mentioned that FmodEx is more OOP. Maybe, but I find it hard to believe, there are so many defines it seems to me, such as FMOD_RESULT returning from each method. Personally I would prefer std::exception or similar. I suppose you could have reasons for this if you want to have less pain making C interface available, but it is really painful to use for me as I got used to OOP. No big deal there, I just made pretty wrapper around Fmod, so I don’t have to use its interface everythere in my code.
Overall, I am pleased. Thumbs up! 😀
OOP is object oriented programming. FMOD uses objects. That is object oriented programming. Just because you can go nuts and use everything C++ has to offer (which i prefer to stay away from), doesn’t mean its not object oriented. OOP is an idea not a feature of C++. You can do OOP in assembler language if you want to.[/quote:3g8j6hiv]
Personally, I like them very much since this is the ONLY possibility to write one API and use a “OOP”-like interface in other languages without breaking ABI’s (Application Binary Interfaces).
If you did develop a real OOP C++ Class, export it through a DLL it is impossible to use it in … for example C# or even in Borland C++. Object based systems don’t have this drawback since they can work on top of “__stdcall” … that means native “C” interfaces 😉 That’s conform over languages, plafforms or even operating systems.
The best capability of object based systems is that I as the API designer have complete control over the created objects. That means with one small call to “API_close()” it’s possible to destroy all objects That sound to me like very good API usability … and FMODEx does a real good job in offering API usability!
- slajar answered 11 years ago
[quote="Olex":2i4tk1cd]Personally I would prefer std::exception or similar.[/quote:2i4tk1cd]
Personally I would vote against that. We are using FMOD to develop console games, and we don’t have exceptions enabled in our projects at all. Why? Well, because that’s generating more code (we use gcc, msvc, and i guess soon metrowerks), and eventually messing the things up.
I guess if you would like std::exceptions so hard, there could be done a wrapper over FMOD, called FMODEx, opss. sorry FMODEx_WithExceptions, which is the same API, that for each function throws an exception if the returned result was failure. You can do that with any API, and you can even automate that job (some script, which goes through the functions and do it for you).
Thanks for ideas, but I don’t need total OOP from FMODEx that much. I think my goal was to get a clearer picture. Exceptions handling isn’t that important for me nor removal of C-like objects in C++ interface of FmodEx.
FmodEx gets the job done. Its “face” is not what I would prefer, but I can handle this easily with wrappers, which I have already done for myself. This is just a small matter of tastes. 😀
Thanks for quick answers.
Please login first to submit.