Author Topic: SFML 2.0 (Read 113069 times)

Ceylo · « **Reply #60 on:** March 26, 2009, 04:42:06 pm »

Uh... lol :mrgreen:

Nexus · « **Reply #61 on:** March 26, 2009, 08:44:31 pm »

Just write your own GUI or use an existing one. Then you can meet all your desires.

The probability, that an SFML-integrated GUI is not exactly as you imagined, is very big anyway...

Tank · « **Reply #62 on:** March 27, 2009, 11:34:16 am »

And since Laurent works alone, a release in version 5.0 is quite a realistic forecast.

Ceylo, you've got a cool GUI in progress, just go with it.

Kreeg · « **Reply #63 on:** March 27, 2009, 06:07:56 pm »

I can't wait to use sf::RenderImages ! :p

Laurent · « **Reply #64 on:** April 14, 2009, 09:44:41 am »

Quote

Idk if it has been discussed before, but maybe some sort of process control would be a good addition.

Being able to spawn new processes and such. Sure would be useful to me!

I think that it goes beyond the scope of SFML. And there are already good libraries for this stuff (boost::process).

Quote

Also, true static linking builds that require no DLLS to run

If you're talking about libsndfile and OpenAL DLLs, I can't link them statically because they are LGPL.

Quote

And maybe going forward Linux 64bit binaries?

Is it that hard to build SFML?

But yeah, maybe I'll provide those 64-bit binaries in the next release.

The DarK' · « **Reply #65 on:** April 14, 2009, 08:17:48 pm »

Quote from: "Laurent"

Quote
Also, true static linking builds that require no DLLS to run

If you're talking about libsndfile and OpenAL DLLs, I can't link them statically because they are LGPL.

LGPL don't provide static compilation ??

Laurent · « **Reply #66 on:** April 14, 2009, 08:24:21 pm »

Quote

LGPL don't provide static compilation ??

It does, but then your project has to be LGPL itself. And SFML is not.

christoph · « **Reply #67 on:** April 14, 2009, 08:25:03 pm »

Quote from: "The DarK'"

Quote from: "Laurent"
Quote
Also, true static linking builds that require no DLLS to run

If you're talking about libsndfile and OpenAL DLLs, I can't link them statically because they are LGPL.

LGPL don't provide static compilation ??

If SFML was statically linked against it would effectivle become LGPL Licensed itself

The DarK' · « **Reply #68 on:** April 14, 2009, 08:34:35 pm »

Ok, thanks for indication.

nfries88 · « **Reply #69 on:** April 14, 2009, 11:27:17 pm »

Quote from: "Laurent"

Quote
Idk if it has been discussed before, but maybe some sort of process control would be a good addition.

Being able to spawn new processes and such. Sure would be useful to me!

I think that it goes beyond the scope of SFML. And there are already good libraries for this stuff (boost::process).

boost::process seems pretty BA, but isn't it still in the sandbox?

seoushi · « **Reply #70 on:** April 15, 2009, 09:36:38 am »

About the gui discussion, it would fairly simple to port over guichan as it already has an opengl port but it will need a SFML for the event processing.

The framework for like the accelerometer and touches are somewhat done already on the iPhone code I've posted in the other thread so it shouldn't be too hard to clean it up and add it.

Lokk · « **Reply #71 on:** April 15, 2009, 11:14:06 am »

Quote

About the gui discussion, it would fairly simple to port over guichan as it already has an opengl port but it will need a SFML for the event processing.

Yeah, I have worked on it, the port also should include an ImageLoader class (for loading BMP fonts)
I will put it to the wiki in the future.

Lokk · « **Reply #72 on:** May 08, 2009, 06:11:12 am »

Ok, the tutorial is online, but only in French at the moment.

But there is a package (not stable yet) on the wiki page.
Requires SFML 1.4 and Guichan 0.8.1

Ceylo · « **Reply #73 on:** May 08, 2009, 02:31:26 pm »

Great !! I've recently been looking at Guichan and I was about to do the backend you've just been doing..

I'm really pleased to see it now, thank you very much !

nitram_cero · « **Reply #74 on:** May 13, 2009, 12:31:18 am »

I don't know if this was requested:

A transparent "preemptive" priority sound manager.

Because OpenAL can go from 16 to 62 sources (optimistically). Maybe more with some fat-ass sound cards, but those aren't probably owned by the common public.

Like for example, it could have this interface (it feels somewhat redundant, it could be worked out):
void Sound::SetPriority(float Priority);
void Sound::SetSeizable(bool Seizable);
void Sound::SetOwnsSource(bool OwnsSource);

priority[0..1]: default 0.5
seizable: default false
OwnsSource: default true
This default values yield a "classic" behaviour.

So if a sound is requested to play:
If there are free sources: Attach to a source and play it
If no sources are available: Seize the source of a less or equal priority sound that is seizable.

Sounds that own the source are not in the pool of non-playing sources until they are destroyed.

If the lib is meant to be easy, it should have this functionality. Everything is explained like Sound is to audio like a Sprite is to Graphics.
But Sound actually is owning a resource (AL's Source), Sprites don't.

For instance, every enemy object owns it's own sprite. But if they wanted to own their own Sound... it would fail miserably on some drivers.
On other drivers, it would just allow me to have ilimited sources but only play some and stop playing when it runs out of real internal sources (without priority).

Also, if the user wants to implement its own manager, or don't care... then it just have to leave this parameters as default.

EDIT: it could also take into account the distance to the listener to roughly degrade the priority by the distance (roughly=fast=sqrt table).

Thanks
-Martín