Is there a reason to have everything so "private:"

[nitram_cero]

I mean, having a bunch of "protected:"s wouldn't kill anyone, and would make the library much more expandable, without having to hack and compile SFML for custom needs.

In my case I could use it to get the OpenAL source id ("source name") from a derived sf::Sound and implement a buffer queue for seamless uninterrupted playing of non-music non-streamed sounds.

For others, it could be a way to export the HWND from a sf::Window.

To avoid having to change and maintain all the hacks in SFML lib code when updating revisions.



I just want to know the reasons, which probably are important, and learn something new.


Regards
-Martín

[Laurent]

The reasons are that you don't have to play with these variables .
I could as well make everything public so that everyone can do everything with every single part of SFML

In my case I could use it to get the OpenAL source id ("source name") from a derived sf::Sound and implement a buffer queue for seamless uninterrupted playing of non-music non-streamed sounds

This is clearly a bug, I'd better fix it myself. Can you tell me more about it?

[nitram_cero]

The reasons are that you don't have to play with these variables .

But that's what protected is for. The regular John Doe won't be deriving from SFML classes as this  (exept for sf::Thread) is not SFML's schema of proper use.

It's a great lib, but far from complete.
And because it's so tight in functionality and "keeping it minimal", it's a pity that it lacks the ability to add functionality program-side without touching the library code itself.

Making everything public is absurd because it kills OOP paradigms. But protected is the key to allow extention of classes.
I would like to know what people think about this, thou not a whole lot extend or even touches the lib's source.




Another example, getting the 4x4 opengl-friendly projection matrix from a sf::RenderWindow's current view is IMPOSSIBLE.
I'm using mixed SFML/OpenGL code (for a background moving texture, to simulate depth), and wanted to get the exact same projection matrix that SFML's drawables get (to avoid Preservation of GL states, which is slow)
Instead I had to do something like:
App.Draw(Shape());
(draw a bogus shape in order to load the projection matrix.)

This is clearly a bug, I'd better fix it myself. Can you tell me more about it?

I don't think it's a bug. Maybe I wrote it badly (I'm not so good at english).

I wanted to do a sound queue, that would derive from Sound (because of the OpenAL Source), keeping all Sound's functionality: volume, pitch, position... and to take as many buffers as wanted, and just do what Music class does for music streaming, but without the streaming part, and having more control over what's played and how.

e.g.:

Code: [Select]

SoundQueue q;
q.AddBuffer(soundBuffer1);
q.StartLoop();
q.AddBuffer(soundBuffer2);
q.AddBuffer(soundBuffer3);
q.EndLoop();
q.AddBuffer(soundBuffer4);


q.Play(); //if currently stopped, plays buf1 thru 3, and then loops indefinetly between buf2 and 3.

q.Stop(); //stop looping, so when the queue reaches the buffer3, continue with buffer 4 until there are no more.

q.HardStop(); // Kill the sound, shut it up.



[Laurent]

I would like to know what people think about this, thou not a whole lot extend or even touches the lib's source.

Me too

Another example, getting the 4x4 opengl-friendly projection matrix from a sf::RenderWindow's current view is IMPOSSIBLE.
I'm using mixed SFML/OpenGL code (for a background moving texture, to simulate depth), and wanted to get the exact same projection matrix that SFML's drawables get (to avoid Preservation of GL states, which is slow)
Instead I had to do something like:
App.Draw(Shape());
(draw a bogus shape in order to load the projection matrix.)

You see, that's what I want to avoid. If I allow advanced users to hack everywhere, then they will always find a workaround to their problems and never report them to me

I wanted to do a sound queue, that would derive from Sound (because of the OpenAL Source), keeping all Sound's functionality: volume, pitch, position... and to take as many buffers as wanted, and just do what Music class does for music streaming, but without the streaming part, and having more control over what's played and how.

Ok I see. But can't you do that with one sf::Sound and multiple sf::SoundBuffer? Which part needs to be done directly with OpenAL?

[Jesper Juhl]

Yes, I know this is an ancient thread, but I just want to leave these links here for other people who read it (Herb Sutter has some great points sometimes and these articles are highly relevant in the context of this thread):

 Virtuality
 Virtually Yours