Messages

1

General discussions / Re: Using SFML 2.1 for Window, Input, ... with Ogre3D Example(Working)

« on: December 01, 2013, 02:24:32 pm »

The example was quite useful to me, thanks.

Unfortunately the code you presented didn't work on Windows. The "currentGLContext" option seems to be ignored. This can be fixed by retrieving the context manually and set options accordingly. The code below works for me on Windows.

        Ogre::NameValuePairList misc;
#ifdef _WIN32
        unsigned long winHandle = reinterpret_cast<unsigned long>(window.getSystemHandle());
        unsigned long winGlContext = reinterpret_cast<unsigned long>(wglGetCurrentContext());

        misc["externalWindowHandle"] = StringConverter::toString(winHandle);
        misc["externalGLContext"] = StringConverter::toString(winGlContext);
        misc["externalGLControl"] = String("True");
#else
        misc["currentGLContext"] = String("True");
#endif

        Ogre::RenderWindow* ogreWindow = ogreRoot->createRenderWindow("Ogre Window", 800, 600, false, &misc);
 

Also, I found out how to handle the resize events correctly.

if (event.type == sf::Event::Resized) {
    ogreWindow->windowMovedOrResized();
    ogreCamera->setAspectRatio(Ogre::Real(event.size.width) / Ogre::Real(event.size.height));
}
 

2

Feature requests / Re: Sound and Music common interface (SFML2)

« on: February 05, 2013, 03:47:48 pm »

Public inheritance (and everything that goes with it) is a powerful tool, one of the most important in C++. But it doesn't mean that every C++ library has to use it. It introduces strong design dependencies in user code, so it's perfect for frameworks or final application code, but not for a lightweight tool box like SFML. Moreover, don't forget that SFML may be mixed with other libraries in user code; imagine if they all impose interfaces that have to be inherited etc., what a mess! I want users to have their own design, and only use SFML in their implementation part. I don't want SFML to drive their public API.

That is an admissible design choice. I've considered SFML a slightly more high level framework than the simple toolbox that should just provide a simple abstraction of openAL and sound file handling in case of the audio module. From that point of view the interface I proposed might not fit well into SFML.

However I'd still appreciate if it would be introduced to the api in the future. 

3

Feature requests / Re: Sound and Music common interface (SFML2)

« on: February 05, 2013, 03:18:09 pm »

Well, what you described is how to handle the current SFML 2 classes. Although I'd introduce an abstract class AudioSceneNode from which the concrete classes derive. However if they had a common interface I'd only need one, non abstract, AudioSceneNode that references a sf::Sound or sf::Music through a reference of the common type. A builder then would provide a method to create an AudioSceneNode via either opening a stream or loading/reusing a sound buffer.

About your plan to remove hierarchies, virtual functions and polymorphism: From what I learned about object orientation that would mean removing object orientation. When removing runtime polymorphism and interfaces we're left with c-style structures using the c++ method call syntax. Or am I misunderstanding you?

4

Feature requests / Re: Sound and Music common interface (SFML2)

« on: February 05, 2013, 01:24:23 pm »

My use case is a game environment. Some environment sounds like e.g. a radio or rattling machines are very long running loops that are to expensive to be held in memory and thus are implemented as sf::Music. Other sounds like e.g. a bell or footsteps have less memory consumption and are needed repeatedly so they are implemented as sf::Sound that references a sf::SoundBuffer. Clearly the difference between sf::Music and sf::Sound is very important here. Once they are just "scene objects", the differences get unimportant. Both sound types may be bound to a scene node, both may be triggered by certain events etc.

To speak in terms of graphic objects, I think of something like the sf::Drawable and/or sf::Transformable class. A sprite, a circle and a text are at least as different as sound and music are. However they are all drawable and transformable objects. Likewise sf::Sound and sf::Music are both "spatialisable" and "playbackable" objects.

5

Feature requests / Sound and Music common interface (SFML2)

« on: February 04, 2013, 10:31:50 pm »

Hi,

I think a common base class for Music and Sound, providing public access to all SoundSource methods plus the playback methods could be handy in many cases.

In SFML 1.6 the class Music derived from Sound, but in 2.0 they have SoundSource as common base class. With that change it is now one has to provide two pieces of code, even if one only wants to play, pause and stop them. A candidate to reimplement that functionality is SoundSource. In this thread Laurent argued that SoundSource doesn't provide this functionality because it's purpose is to bundle common code. I understand that you don't want to pollute that class with abstract playback methods. Another, abstract class as interface that is implemented by Music and Sound would circumvent that problem.