Topics

1

Audio / sf::Sound consumes OpenAL resources

« on: March 01, 2013, 06:51:15 am »

I just discovered some craziness today and thought it would be nice if the documentation gave some kind of warning.

I had assumed that sf::Sound was a lightweight class similar to sf::Sprite -- where you can "carelessly" create instances and all you have to worry about is a little extra memory usage.  With this in mind... in a game I'm working on, we would assign sf::Sounds to objects similar to how we'd assign sf::Sprites.

That is... if an object draws a quad, it owns a sf::Sprite.  If it plays a sound, it owns a sf::Sound.   Makes sense, right?


I was in for a rude awakening when all of the sudden I discovered stderr flooded with OpenAL failures and various crashes when I'd try to play sound effects (and on shutdown).

As I looked closer at the error message and did some debugging and examination of sf::Sound... I came to a startling realization:

sf::Sound allocates OpenAL resources and reserves them throughout its lifetime.  OpenAL resources are limited... so this makes sf::Sound a heavy resource class that should be used with care.  Instances should not be frivolously created/destroyed.

In my case, what was happening was that each object owned 4 Sounds, and there were 100 objects.  At some point (I didn't figure out exactly when), I had consumed all the available OpenAL resources, and additional calls to alGenSources (in the sf::SoundSource default ctor) were failing.  This led to a chain of errors (and ultimately crashes) due to the m_source member being uninitialized and passed to various AL functions.



Just to clarify.... I do not think this is a design issue with SFML.  It makes perfect sense for sf::Sound to behave this way.  I just wanted to throw this out there as a consideration.

I would like to see:

1)  Some kind of warning in the docs for sf::Sound (or really, sf::SoundSource and all derived classes) that these classes are resource heavy and should be used with care.

2)  SFML should not crash under any circumstances, even if initialization fails.  In this case... SoundSource::m_source should probably be initialized with 0 or some other value if the call to alGenSources fails.  I would even be okay with an exception being thrown.


Thanks.

-Disch


EDIT:  I should clarify I'm using SFML 2.0 ... I think rc 146 but am not 100% sure.  Is there a way to easily check?

2

General / Catching error messages

« on: February 11, 2013, 06:02:11 am »

Most SFML routines return a boolean to indicate success/failure, but in the event of a failure, how can we get more information about it?  Does SFML log the error message anywhere?

Is there any way to programmatically get a string explaining what went wrong with the operation?


EDIT:  I should try reading the docs more closely.  Looks like it goes to sf::err().

OK.  Thanks.

3

Graphics / SOLVED: CRASH: Sharing GL context in multiple windows

« on: January 20, 2013, 02:08:25 am »

Hi all:

I'm using SFML 2.0 rc 118 on Win7 with VS2012 express.

I'm attempting to toggle fullscreen by creating a new sf::RenderWindow.  After the new window is created, I destroy the previous one.  This is working fine up until I shut down, when textures are free'd.  I'm getting an "Access violation" error, similar to the kind of error you see when you attempt to destroy a texture after the GL context has been destroyed.

Here's a small program to reproduce the issue:

#include <memory>
#include <SFML/Graphics.hpp>
#include <SFML/Window.hpp>


///////////////////////////////////
typedef std::unique_ptr<sf::RenderWindow>       WindowPtr;
WindowPtr                   wnd;

void makeItCrash()
{
    // toggle from windowed to fullscreen
    WindowPtr next( new sf::RenderWindow( sf::VideoMode::getDesktopMode(), "Test", sf::Style::Fullscreen ) );

    // reassign the 'next' window, so the previous windowed window is destroyed
    //   and is replaced with the new fullscreen window
    wnd = std::move(next);
}

int main()
{
    // Create a windowed window
    wnd = WindowPtr( new sf::RenderWindow( sf::VideoMode(400,400), "Test" ) );

    {
        // all resources in local scope, to ensure they are destroyed before the final window is destroyed

        // load up a texture.
        std::unique_ptr<sf::Texture> atexture( new sf::Texture );
        atexture->loadFromFile("image.png");

        // if I comment out this call, it works fine
        //   this call basically replaces 'wnd' so that it points to a fullscreen window
        //   instead of a windowed window.
        makeItCrash();

    }       // texture destroyed here.      !!! This is where the crash actually happens !!!
      // !!! when the texture is destroyed !!!!


    // manually destroying the window here
    wnd.reset();

    return 0;
}
 

The best guess I can make of the problem is that the GL context is being destroyed when I destroy the original window.  Then, when I try to destroy the texture, it craps out because the context it was created in no longer exists.

This is baffling though because drawing works just fine in the new window.  So the context must still exist, right?


What am I doing wrong here?  I know SFML is capable of sharing a context between multiple windows, so it shouldn't matter when I destroy the first window, as long as any window is still in play.

Any help appreciated.  Thanks.

4

Feature requests / sf::String removal

« on: August 15, 2011, 10:18:41 pm »

sf::String suffers from "another string class" syndrome.

It's true that it adds handy conversion and locale functionality, but when it comes to other fundamental features of a typical string class (like std::string), it falls short.

I don't think increasing sf::String functionality is the solution.  I think that would only serve to be extra work and write code that already exists in the standard library.

Instead, I think sf::String should be removed entirely.  And instead, all the conversion and locale functionality it offers should be placed in a separate series of global utility functions that operate on external objects (rather than trying to manage the string data themselves).

With such conversion functions in place, instances of sf::String could be replaced with std::basic_string<sf::Uint32>.

5

Feature requests / sf::Thread::GetThreadID + Wait Events

« on: July 16, 2011, 04:15:46 am »

I'm a little surprised that sf::Thread doesn't have static GetThreadID or similar function which returns a thread-unique identifier for the current thread.

Can we get this added?


EDIT:

Also WinAPI has a threading feature that I just realized I need if I want to implement this thing I have in mind.

WinAPI has these "Event Objects" which are used for inter-thread communication.  The idea is, the event has a boolean state (set or unset).  Threads can then "wait" for the event until it has been set.

As soon as the event has been set, all threads waiting for it are resumed.

Any thread can set/unset the event state.

Of course, since SFML uses "Event" for something completely different, it would have to be renamed.  But I think it would be a great addition.

EDIT2:  More reading:

http://msdn.microsoft.com/en-us/library/ms686915%28v=VS.85%29.aspx

6

SFML projects / SFSL - SFML File System Library

« on: June 13, 2011, 05:07:49 am »

I figured I would mention this now that I'm more or less done with my other SFML related project.

I'm starting work on an add-on library to SFML... SFSL (SFML File System Library).

As the name implies, one of the primary goals is to provide cross-platform way to interact with the file system.

It'll have the expected goodies:
- File I/O
- File/Folder creation, renaming, deletion
- Directory scanning (iterating over files/folders)

Plus some perks.  The biggest one being .zip file reading/writing in a sane manner (most libs I've seen/used expect you to bend over backwards to use zips)

Benefits over stdio/iostream for normal files
- 64-bit offsets
- Ability to truncate/shorten files without having to completely wipe them
- Unicode filenames (windows' standard libs choke on this hard)
- Utility functions for endian-safe read/write of integral types

Benefits over boost::filesystem
- Seamlessly integrates with SFML
- Abstracted interface.  Not strictly a singleton.

Use it to...
- Manage user profiles
- Manipulate easily distributable "packages" to allow for additional/customized levels
- ...and more!


Imagine if i/o with files in .zips were as simple as i/o with normal files.  There's no reason it can't be!


I did something similar to this with another lib I wrote a long while back.  Some of the code should be adaptable, but most will need to be rewritten to make it thread safe and exception safe.

7

Graphics / Does anyone have a .pic file?

« on: June 11, 2011, 11:37:24 pm »

I'm trying to test the .pic file support in stb_image to make sure I didn't screw it up, but for the life of me I can't find a .pic file anywhere on the internet.  Nor can I find any free program that will allow me to convert to it.

Does this format even exist!?!??!?!!

If someone could post a pic file I'd appreciate it.  I don't care what the image is.

EDIT:  doh, probably should've put this in the general board.

8

Feature requests / ResourceStream class for custom resource loading

« on: June 08, 2011, 05:29:22 am »

For previous discussion on this topic, see this thread:

http://www.sfml-dev.org/forum/viewtopic.php?p=32631#32631

Specifically, I'm interested in custom file/stream I/O support for resource loading in SFML.  Mainly because I have interest in using zip file "packages" for game modules in my projects, and I want to be able to load resources directly from those packages without having to dump the file into memory first.

The current LoadFromFile and LoadFromMemory options available in SFML are unsuitable for this goal, so I suggest the below abstract class as well as "LoadFromStream" functions added to any and all resource loading classes.

As mentioned in the above thread, I am entirely willing to work towards wrapping existing libs (like libsndfile, etc) to use the below class.

Code: [Select]


namespace sf
{

class ResourceStream : public NonCopyable
{
public:
    //=============================================
    // enums and typedefs
    typedef Int64  Offset;

    enum Mode
    {
        SeekOrigin,
        SeekOffset,
        SeekEnd
    };

    //=============================================
    // construction / destruction
    virtual ~ResourceStream() { }

    //=============================================
    // stream I/O
    virtual Offset      Read(void* data, Offset size) = 0;          // returns bytes read
    virtual Offset      Write(const void* data, Offset size) = 0;   // returns bytes written
    virtual Offset      Seek(Offset pos,Mode = SeekOrigin) = 0;     // returns position seeked to (-1 on error)
    virtual Offset      Tell() = 0;                                 // returns -1 on error
    virtual Offset      GetSize() = 0;                              // returns total file size (-1 on error)
};

} // namespace sf


Not very complicated.  KISS.

Design decisions:

1) no const functions.  (precedent:  STL).  You typically don't have const streams anyway.  Additionally, even tasks that seem const may not be. (GetSize for example, may involve seeking, violating const rules)

2) no error reporting.  (precedent:  SFML).  Getting bogged down with error reporting would make the class complicated and the minimal requirements for deriving your own class more difficult.  As it stands now, implementing the above is very straightforward and simple.

And considering this class is designed to be used in SFML resource loading classes, and those classes don't have detailed error reporting anyway, the information would likely be lost.

3) I did my best to mimic SFML naming conventions.  I'm not sure about the enum, though.  Maybe that could be better.

4) typedeffing Offset seemed to add clarity.  It also allows for the possibility of support for future platforms which may not have 64-bit capabilities (maybe some hand-held devices?)

5)  I didn't make Doxygen style comments because I'm lazy.  That wasn't really a design decision

6)  I was torn as to whether or not GetSize should be included.  I also considered giving it a body that did the Seek/Tell/Seek approach instead of making it pure virtual.  However Seek/Tell/Seek leaves room for problems (what if the 2nd seek fails?).

Plus at least one lib needs such a function.  And it shouldn't be hard to implement in derived classes anyway.




Overall I think the simplicity says it all.

Laurent:  I hope you give this your consideration, and I am eager to hear your thoughts / feedback.


EDIT:

so I took a look at stb_image.c to see how much work will need to be put into it.  Looks like it is going to take a pretty decent chunk of effort in some areas, but in other areas, maybe not so much.  He seems to have compartmentalized file I/O (which is good), but the thing that's tripping me up is that there's #ifdef blocks everywhere and seemingly no indication of exactly what the defines are supposed to do.

It's definitely doable, though.

If he had used a callback mechanism from day 1 of this, he would have saved himself lots of duplicate code.  I see 2 sets of functions for pretty much everything -- one for memory loads and one for stdio loads.  He could have just implemented one callback set, and then employed it to implement the memory/stdio sets.

Though I suppose that would have an ever-so-slight performance hit.

But whatever.  I won't get started on this until I hear back from Laurent anyway.  No sense in doing all that work if it will be for naught.

9

General / UseVerticalSync not working

« on: October 30, 2010, 10:48:37 pm »

Hey everyone.

I recently got a new computer with Windows 7.  I'm trying to get some of my old projects (originally built on Ubuntu) to compile and run on my new machine.

So far so good, except now my program isn't vsyncing!

I tried checking all my display settings in the control panel.  I even switched my graphic device's VSync option to "On".  But I also tried "Application Settings".  Neither seem to work (I have a sneaking suspicion that option only applies to DirectX and not to OpenGL).

I have some crappy Intel integrated graphics thing.  No actual video card.

I've tried updating drivers but to no avail.

Does anyone have any advise how I can solve this?  Am I just SOL here?

Thanks.

10

General / sf::Clock problems

« on: September 27, 2010, 06:10:30 am »

Hey all.  I'm working on the timing for my game and I have a problem with sf::Clock.

My goal is to have a game-wide clock drive the logic so that I update logic every 10 milliseconds.  However I want precision to 1 millisecond so that I can render between updates for smooth movement at any framerate.

Now I could very well use sf::Clock for this, but it has one major problem:  it returns a float.

floats only have 23 bits of mantissa, so by my math, that gives me a little over 2 hours before it starts losing precision and my game starts behaving very strangely as a result.  (2^23 / 1000 / 60 / 60 = ~2.33 hours)

It's not unreasonable to expect someone to play a game for 2 hours straight.  Especially if they pause in the middle and take a break while leaving the game running in the background.  So this is a serious concern of mine.


Because of this, using sf::Clock by itself is unacceptable for my needs.  So what about solutions?

My first thought was to hide sf::Clock behind my own class.  Something like this:

Code: [Select]


class Clock
{
private:
  unsigned tick;
  sf::Clock clk;

public:
  Clock() : tick(0) { }

  unsigned GetTick()
  {
    float f = clk.GetElapsedTime();
    clk.Reset();

    tick += static_cast<unsigned>( f * 1000 );
    return tick;
  }
};



While this isn't an ideal solution, it's the best one I have so far.

Is there any way I can just get a millisecond "tick count" from SFML?  One that wraps at 32 bits?  Wrapping isn't a problem -- it's loss of precision that's a problem.

11

General / Statically linking to SFML on Ubuntu

« on: May 02, 2010, 07:30:52 pm »

Hello all.

I'm trying to statically link to SFML 1.6 on Ubuntu.  I'm using GCC with the Code::Blocks IDE.

I have built both static and dynamic builds of SFML.  Linking with the dynamic version works fine, but linking with the static version brings up all sorts of linker errors... as if I were failing to link to some other necessary libraries.

Some friends of mine on IRC were giving me some help.  One of them gave me to a link to a blog which seemed to suggest that I would have to find and dynamically link to all of sfml's dependencies.

Here is the link they gave me:
http://indicium.us/site_blog/2010/03/gccg-mixed-static-and-dynamic-linking.html

Obviously this is not ideal.

Is that really necessary?  Can't I just statically link to SFML, but still have SFML dynamically link to all its dependencies?  Surely something so basic can't be all that complicated (then again... this is Linux so you never know)

12

Feature requests / Ctor to handle implicit casting between Vector2<T> typ

« on: April 19, 2010, 12:09:54 am »

I use sf::Vector2<double> in calculations for extra precision, but pretty much everything in SFML takes sf::Vector2<float>.

It would be nice if sf::Vector2 had a ctor that could convert between different types so that these could be implicitly cast.

13

Graphics / SOLVED: Shape::SetColor doesn't work as expected

« on: April 18, 2010, 11:46:11 pm »

So I tried the below code and was in for a nasty surprise:

Code: [Select]


#include <SFML/Graphics.hpp>

int main()
{
    // A rectangle
    sf::Shape rect = sf::Shape::Rectangle(100,100,200,200,sf::Color(255,255,255));

    sf::RenderWindow wnd(sf::VideoMode(640,480),"Test");

    while(wnd.IsOpened())
    {
        sf::Event evt;
        while(wnd.GetEvent(evt))
        {
            if(evt.Type == sf::Event::Closed)
                wnd.Close();
        }

        wnd.Clear( sf::Color(96,96,96) );

        rect.SetColor( sf::Color(180,0,0) );  // this should make the rectangle red, right?

        wnd.Draw( rect );  // but here, it's drawing as black!

        wnd.Display();
    }
    return 0;
}


After digging through the documentation and tearing apart my code, I finally decided to check SFML source.

It looks like Drawable::SetColor has no effect (or some kind of ill effect?) on the actual color of Shapes.

In order to get the actual desired effect, I would need to step through all the points in my Shape and change each of those colors.  EDIT:  Actually... can this even be done?  I don't see how to do it from the docs.  /Edit

Shouldn't SetColor have the expected behavior here?

I'm also curious as to why it's drawing as black on my machine... I mean if SetColor has no effect it should be drawing white since that was the constructed color.


EDIT2:  I should mention... this is SFML 1.6 on Ubuntu

14

General / Custom file interface

« on: April 17, 2010, 02:28:52 pm »

Hello again!

I've been looking into a few areas of SFML and seeing if it fullfills all my needs.  So far it's looking like it will fit the bill beautifully!

I do have one more question about it, though...

It looks like the interfaces for loading files (ie:  sf::Image::LoadFromFile, sf::Music::LoadFromFile, sf::SoundBuffer::LoadFromFile, sf::Font::LoadFromFile, etc) all just take either a string filename or a pointer to a memory buffer.

Is there any way to load an audio/image file via a callback system so that I can use a different file system?

For example, let's say I want my game to have "packages" that can be user defined and could contain things like custom sound effects, images, different game levels, etc.  For ease of distribution and installation, I'd want the packages to be individual .zip files.

So... assuming I have my own method to read .zip files, how could I load audio/image files from a zip, without reading the entire file into memory and using LoadFromMemory (which is particularly impractical for fonts and large audio files that are to be streamed)

Libraries like libpng have a callback system where you can supply your own read/seek/tell/etc functions, but I don't see anything like this in the documentation for SFML.

Is it possible?  Or is LoadFromMemory my only option?

Thanks!

15

Graphics / 3D / 2.5D interface?

« on: April 17, 2010, 01:58:23 pm »

Is there any way to render 3D textured polygons through SFML?  Or is it strictly 2D only?

What about other 3D effects like lights, bump-mapping, etc?

If not, is there a way to use sf::Image for loading textures, but then interface with OpenGL directly for rendering instead of using SFML's rendering classes?  (Similar to how you can use SDL to set up a window, but then can use OpenGL directly and never have to touch SDL's blitting functions).

Thanks!