Welcome, Guest. Please login or register. Did you miss your activation email?
Pages: 1 ... 3 4 [5] 6 7 ... 13

Author Topic: SFML 2.0  (Read 113108 times)

0 Members and 5 Guests are viewing this topic.

Ceylo

  • Hero Member
  • *****
  • Posts: 2325
    • View Profile
    • http://sfemovie.yalir.org/
    • Email
SFML 2.0
« Reply #60 on: March 26, 2009, 04:42:06 pm »
Uh... lol :mrgreen:
Logged
Want to play movies in your SFML application? Check out sfeMovie!

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6287
  • Thor Developer
    • View Profile
    • Bromeon
SFML 2.0
« 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... ;)
Logged
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
SFML 2.0
« 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. :)
Logged

Kreeg

  • Full Member
  • ***
  • Posts: 115
    • View Profile
SFML 2.0
« Reply #63 on: March 27, 2009, 06:07:56 pm »
I can't wait to use sf::RenderImages ! :p
Logged
Attention (va) aux (sur) messages (mon) subliminaux, (blog) camarade !

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
SFML 2.0
« 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.
Logged
Laurent Gomila - SFML developer

The DarK'

  • Sr. Member
  • ****
  • Posts: 255
    • View Profile
SFML 2.0
« 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 ??
Logged

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
SFML 2.0
« 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.
Logged
Laurent Gomila - SFML developer

christoph

  • Full Member
  • ***
  • Posts: 102
    • View Profile
    • http://www.christoph-egger.org
SFML 2.0
« 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 ;)
Logged

The DarK'

  • Sr. Member
  • ****
  • Posts: 255
    • View Profile
SFML 2.0
« Reply #68 on: April 14, 2009, 08:34:35 pm »
Ok, thanks for indication.  :)
Logged

nfries88

  • Newbie
  • *
  • Posts: 42
    • View Profile
SFML 2.0
« 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?
Logged

seoushi

  • Newbie
  • *
  • Posts: 15
    • View Profile
SFML 2.0
« 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.
Logged

Lokk

  • Full Member
  • ***
  • Posts: 228
    • View Profile
    • http://betadineproject.wordpress.com/
SFML 2.0
« 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.
Logged

Lokk

  • Full Member
  • ***
  • Posts: 228
    • View Profile
    • http://betadineproject.wordpress.com/
SFML 2.0
« 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
Logged

Ceylo

  • Hero Member
  • *****
  • Posts: 2325
    • View Profile
    • http://sfemovie.yalir.org/
    • Email
SFML 2.0
« 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 !
Logged
Want to play movies in your SFML application? Check out sfeMovie!

nitram_cero

  • Full Member
  • ***
  • Posts: 166
    • View Profile
SFML 2.0
« 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
Logged
Pages: 1 ... 3 4 [5] 6 7 ... 13