Messages

46

General discussions / Re: Replacement for OpenAL

« on: September 18, 2014, 08:10:03 am »

System Requirements slab3d runs under Windows 2000 and higher. For low-latency audio output, slab3d supports ASIO and DirectSound sound device drivers. See your sound device documentation for information on obtaining and installing these drivers. slab3d is developed using the ASIO SDK and the DirectSound SDK. To obtain the ASIO SDK, see www.steinberg.net under Support | 3rd Party Developers. For DirectX information, see www.microsoft.com/directx and msdn.microsoft.com/directx. If executing a slab3d application reports a missing DLL, you most likely require a more thorough version of the "DirectX End-User Runtime" (see the Microsoft Download Center at www.microsoft.com/downloads). The XScape application requires the "Microsoft XNA Framework Redistributable 4.0".

It's Windows only (DirectSound), thus doesn't fit the requirements. Besides OpenAL is the "standard". It's used in thousands of applications and supported on all kinds of platforms, thus it's guaranteed to run stable nearly everywhere.

I know that, but I am considering the alternatives (also there might be a platform that doesn't support it, who knows). Anyway, I believe that the ideal would be to have all the general processing done on platform-less code (with optional hardware acceleration on supported platforms), and depend on the platform only for the most low level features: in this case, I believe it would be to control audio input/output devices and to input/output samples from/to them. Any platform must have a way to provide that if it has sound, so a simple porting would always be possible.

About the DirectSound issue, slab3d also supports memory buffer input/output. I believe it should be possible to strip all platform code from it and keep it working, but it seems a bit overcomplicated for SFML anyway. What I am curious about is the NASA license, that I've never seen before. Does any of you know how it works and if I understood it right?

47

General discussions / Re: Replacement for OpenAL

« on: September 18, 2014, 04:53:44 am »

Huh? What does this have to do with SFML? What would it be used for? Why in the world should it be part of the core of SFML?

It does sound spatialization, and I believe that sound spatialization is the main feature that is tying SFML to OpenAL. I am not saying that it should be a part of SFML, my question was only about the NASA license.

48

General discussions / Replacement for OpenAL

« on: September 17, 2014, 07:41:54 pm »

Yeah, I've searched for a while, but I am surprised I didn't find any cross-platform library to compute spatial audio. It shouldn't be so hard, right? The actual audio output could be provided by multiple libraries, but spatial audio calculations seems to be exclusive to OpenAL and FMOD (proprietary).

There are some obscure libraries able to compute HRTF audio (which uses a "model" of the ear to make realistic sounds for each channel, at least on headphones), but I also couldn't find a cross-platform library for that. The closest I got was the slab3d library (http://slab3d.sonisphere.com/), that is licensed on the NASA Open Source Agreement, but it is said on the site that it is made for Windows, so I am not sure if it would work on other platforms. It also has a lot of features that are not neccessary for SFML.
There is a demo that someone made using it here (watch it with headphones):


By the way, if I understood the NASA license correctly, we could use the library (even with static linking) as long as the library's code and eventual modifications we do are released, and we can keep our own code closed. Would that license be acceptable to use on SFML?

49

General discussions / Re: AW: Re: SFML 3 - What is your vision?

« on: September 15, 2014, 06:38:00 am »

I don't know, it seems to me that any code that isn't ANSI C/C++ is to be considered a platform specific code, even if it has ports on multiple platforms. But if you preffer, you could interpret my posts as referring to backends then.

Not really. If you use library X one OS K, the library API doesn't become "platform code", the API itself has nothing to do with OS K, it's just an API on it's own. The issue that library X isn't supported on OS J still doesn't make the library API platform specific/platform code.
I can write a library just using standard C++ (it's probably better to use ISO than ANSI, even if ISO stuff is automatically ANSI), like my library has a public function test() which prints out "Hello World". By your definition my standard C++ library would now turn into platform code, since my function test() isn't part of the standard C++. However since my code is written in standard C++, it will work on any platform, thus my API (the test() function) isn't platform code.

OpenGL is also "just" an API (okay it's a bit more tricky than that), it's not platform code, but the API isn't available on all platforms.

I might have expressed myself poorly, but that was not what I meant. Your library (with the test() function) would not be platform dependent, since it would work on any platform. I would tell your library is platform independent, since it only deppends on ANSI C++ to work.

On the other hand, if your library required some Windows API (for example) to work properly, I would consider it platform dependent. It is the same for OpenGL: as far as I know, OpenGL is an API that requires an implementation interfacing directly with the platform functions, so it is platform dependent. Any code that uses OpenGL would also be platform-dependent, since it would require the platform's implementation and support for the OpenGL API.

In other words, I consider a code platform independent if and only if it works on any platform that has an ANSI (or ISO, don't realy know the difference) C/C++ compiler, without requiring anything else. My suggestion would be to separate this kind of code from the platform dependent code on SFML, so it would be easier to port it to whatever platform.

50

General discussions / Re: AW: Re: SFML 3 - What is your vision?

« on: September 14, 2014, 10:50:40 pm »

I see... There was talk some time ago about asking for permition to static link OpenAL from the developers, or something like that. Did it go through?

You probably confuse this with libsndfile. I asked again and there wasn't any progress after 8+ month - still hasn't. As such the decision was made to drop libsndfile.
OpenAL itself is well supported on all platforms, so there's currently no issue (iOS comes with its own version).

I've already answered that to zsbzsb...

Lets say I want to port my SFML game to Xbox360, for example. As far as I know, Xbox360 has no OpenGL support, only DirectX. With the platform code (in this case, OpenGL) in its separated classes, all I would need to do would be to reimplement the platform classes using DirectX (I would imagine classes like Texture, Polygon, Display, or something like this, very low level), while maintaining the same interfaces, recompile SFML with those new implementations, then SFML would work with DirectX instead of OpenGL. The same if I would want to port my game to a platform that doesn't support OpenAL, for example.

You're misusing the word "platform"; OpenGL isn't "platform code". SFML could currently potentially be ported to any platform supporting OpenGL 2.x-ish or with the upcoming Android port also OpenGL ES 1.something. The fact that Xbox360 doesn't support OpenGL, doesn't make the OpenGL code "platform code", but Xbox360 simply doesn't provide the nessecary dependency.
However there are discussions going on, on how to refactor the graphics code to make it possible, to implement different rendering back-ends, such as DirectX. How and if this will be done, is still in discussion.

Edit: Hrmpf zsbzsb

I don't know, it seems to me that any code that isn't ANSI C/C++ is to be considered a platform specific code, even if it has ports on multiple platforms. But if you preffer, you could interpret my posts as referring to backends then.

51

General discussions / Re: SFML 3 - What is your vision?

« on: September 14, 2014, 09:53:47 pm »

I see... There was talk some time ago about asking for permition to static link OpenAL from the developers, or something like that. Did it go through?

It was permission to statically link libsndfile, however we did not get permission to do so. AFAIK dropping libsndfile as a dependency is what we are going to do about that.

Ok, I stand corrected. I will be on the lookout for potential OpenAL replacements but, if I understood correctly, SFML 3 would only need 1 dll for OpenAL. Is that right?

Lets say I want to port my SFML game to Xbox360, for example.

Porting SFML's rendering to DirectX is not really porting to another platform, its just changing the backend. So if you want XBox support you need platform specific code for the XBox and you need to change the rendering backend. That said, allowing multiple backends is unlikely to happen anytime soon. If you want to mess around with porting SFML's rendering to DirectX have fun. It won't be as easy as you make it out to be

I am not saying it is that easy now, but I am asking if it could be, and how hard would it be to redesign SFML to work with platform (or backend, whatever) interfaces instead of directly to facilitate such ports. We are on the SFML 3 vision thread, after all.

52

General discussions / Re: AW: Re: SFML 3 - What is your vision?

« on: September 14, 2014, 09:21:07 pm »

Laurent, is it possible (and are you planning) to remove all of the dynamic dependencies of SFML?

Not really. The main problem is, that there's nothing compareable out there to OpenAL. Some similar libraries are even less permissive and others don't support iOS and Android..

I see... There was talk some time ago about asking for permition to static link OpenAL from the developers, or something like that. Did it go through?

Another question: Would it be possible to separate all of the platform specific code from the SFML logic code on different files? Like, the OpenGL code separated from the Drawable/Window/Whatever code, in a way that the platform specific code could be easily ported without messing with SFML's logic?

I'm not sure what you're asking. All platform specific code is usually in separated class (see all the XYZImpl.hpp/cpp files).
As for the rendering/OpenGL code, we might investigate a more detached approach.

Lets say I want to port my SFML game to Xbox360, for example. As far as I know, Xbox360 has no OpenGL support, only DirectX. With the platform code (in this case, OpenGL) in its separated classes, all I would need to do would be to reimplement the platform classes using DirectX (I would imagine classes like Texture, Polygon, Display, or something like this, very low level), while maintaining the same interfaces, recompile SFML with those new implementations, then SFML would work with DirectX instead of OpenGL. The same if I would want to port my game to a platform that doesn't support OpenAL, for example.

53

General discussions / Re: SFML 3 - What is your vision?

« on: September 14, 2014, 06:05:22 am »

Laurent, is it possible (and are you planning) to remove all of the dynamic dependencies of SFML?

Another question: Would it be possible to separate all of the platform specific code from the SFML logic code on different files? Like, the OpenGL code separated from the Drawable/Window/Whatever code, in a way that the platform specific code could be easily ported without messing with SFML's logic?

54

SFML projects / Re: Node 54

« on: September 03, 2014, 08:25:22 am »

@Tex Killer:
Thanks for the feedback! I saw your comment already but I haven't got enough time yet to play your game. But I will for sure, I promise! I am aware of many mistakes that I made. More on this topic here in this blog post: http://www.ludumdare.com/compo/2014/08/30/node54-final-thoughts/

I've read your post, and it was like that for me on my first Ludum Dare, except that I couldn't produce a playable game at the end, and you could. This time the game worked very much better than my first try, but it is my third Ludum Dare with my own engine, so that was to be expected. Good luck on your future developments!

55

SFML projects / Re: Morpheus - Ludum Dare Jam #30 Entry

« on: September 03, 2014, 08:12:30 am »

It's a shame this game didn't develop a little more; it seems a little cut short.

I completed it first time without ever being hit. I wasn't even sure at which point I would be hit so I just (easily) avoided each one completely. I even forgot to try to jump; I didn't need it! I tried it again to see what happens when you get hit and ended up running through to the 19th (I think) room without being touched. If you continue with the development of this, you may want to limit the progress speed e.g. maybe open a door every few seconds, start with a few open etc..

Thank you for playing and for the tips! I didn't have any time at all to do the second dream at the time of the competition, I've finished the first dream and the cutscenes just minutes before the time limit was over. On the second dream you would have to jump between platforms, but that unfortunately didn't make it out of the concepts.

On relation to the music looping discussion, the music when you complete the game loops with very noticable delays between each loop. Also, SFML's music has a loop option. I'm not sure how long it's had one, though, so you may need a new version to use it. It seems to do so well though (tested using a 3.5 minutes .wav file and an .ogg file).

The music at the end is like that because I only had half an hour to find music loops on the internet and insert them on the game, so I got the first free ones that could fit on those three places and sent it in like that. The last one ended up not looping well, but it was the sound's fault, not my modification's.

If you mean "loop points", where the music will stop some time before the end and restart some time after the beginning (so as to avoid that annoying quiet period while it fades out and in), then there is an oustanding pull request which implements that, so you could always try merging that into your copy of SFML.

I've also made a "public version" of my modification. You can check it out here: http://en.sfml-dev.org/forums/index.php?topic=6213
That pull request seems a bit too limited to me, only allowing one loop per music file. Mine allows any amount of looping you want with any sound files and any positions.

P.S.: There might be some memory leaking on my public version. I've found a few memory problems recently on my private version, but I don't know if they also affect the public version. I've tested it and it works, though.

56

SFML projects / Re: Node 54

« on: September 02, 2014, 04:48:34 am »

Nice, another LD #30 contestant

I've played and rated your entry. The connection with the theme is kind of weak, but it is funny and the pixel art is good. Congratulations!

You check my entry out, if you want to (although mine is for the Jam compo): http://en.sfml-dev.org/forums/index.php?topic=16248.0

57

SFML projects / Re: Morpheus - Ludum Dare Jam #30 Entry

« on: September 02, 2014, 04:32:10 am »

Congratulations on finishing a playable game.

Thank you!

My engine uses a 2013 snapshot version of SFML with changes to the audio module to allow for music loops.

There's no need to modify SFML for that. See, for example, my Jukebox class.

From what I understood from your code, you are checking the status of the current sound every frame and starting the next when it stops. Is that how you did it?
If it is, then it will create gaps in between sounds (between when the sound ends and when you check), and that sounds just awful for a background music loop. I've already tried that before resorting to modifying SFML.

My modification is for playing linked portions of sound without ever stoping. The only way that could be achieved (at least on the 2013 snapshot that I used) was by using a private class (I think it is called SoundFile), so it had to be a modification of SFML itself. Laurent said that class would be made public on the next version of SFML, but I don't know if it is public already on the SVN.

58

SFML projects / Morpheus - Ludum Dare Jam #30 Entry

« on: September 01, 2014, 07:10:31 am »

Hey guys!

We've finally managed to create a "playable" game for a Ludum Dare with our own engine!

Here is the link: http://www.ludumdare.com/compo/ludum-dare-30/?action=preview&uid=7901

The concept (as always) was bigger, but at least it is playable.

My engine uses a 2013 snapshot version of SFML with changes to the audio module to allow for music loops. It uses a modified version of Bullet Physics for the physics simulation.

Hope you guys like it!

59

General discussions / Re: SFML 3 - What is your vision?

« on: June 30, 2014, 10:55:45 pm »

My understanding is that https://github.com/SFML/SFML/pull/629 is not integrated on SFML, right?

If it is just one implementation made by users, I've already coded one for my engine and have been using it for a while. I've made a version of it avaliable here: http://en.sfml-dev.org/forums/index.php?topic=6213

Laurent, how will it be done without hacking into SFML sources? Are you going to make SoundFile public?

60

General discussions / Re: SFML 3 - What is your vision?

« on: June 30, 2014, 09:20:56 pm »

Hey guys...

I've been away from the forum for a long time, so I'm sorry if these issues were already taken care of.

The issues I wish were addressed by SFML3 (if not already) would be:

1) Clipping masks, or some way of having polygon-shaped views (http://en.sfml-dev.org/forums/index.php?topic=9877.msg67745#msg67745)
2) Audio listener rotation support (http://en.sfml-dev.org/forums/index.php?topic=7995.0)
3) Optional MIDI support as add-on of instrument banks, that could be plugged to SFML if there was need for it (http://en.sfml-dev.org/forums/index.php?topic=7079.msg46850#msg46850)
4) Support for custom loop points for the audio module, or a way to achieve it without having to hack SFML's sources (https://github.com/SFML/SFML/issues/177 and http://en.sfml-dev.org/forums/index.php?topic=6213)

Thanks