Messages

1

Feature requests / Re: Enhanced Music Control

« on: November 23, 2014, 12:20:16 am »

Wouldn't implementing loops with manual definition be an acceptable solution for you?

Grah, yeah that would work just fine.  I guess I just had a one-track mind where I was trying to get my previous solution to work in the new setup.

Can this be done with the no_libsndfile branch as it is now?  It doesn't look like it to me.  I see a looping option in SoundStream, but it always loops from the start of the file.  I guess we could add a new 'setLoopPoint' function or something to SoundStream.

2

Feature requests / Re: Enhanced Music Control

« on: November 22, 2014, 09:46:45 pm »

Hrm... without libsndfile this becomes a lot trickier... since metadata now has to be read from each file type individually.  Which means creating a private interface for reading metadata.

Still no way to do this without modifying SFML that I can see.  To ensure music can be looped properly without breaks in the audio, the change has to be made where the audio data is supplied.

In this branch the most logical place for the change seems to be in Music::onGetData, with a pure virtual addition to SoundFileReader to obtain metadata.  How that metadata function would look is a mystery to me, though.  I'm not familiar enough with the specifics of each individual file format to build a common interface.

Guess I'll stick with my custom 2.0 build for now, and possibly will look into this in the future.

3

Feature requests / Re: Enhanced Music Control

« on: November 22, 2014, 07:24:21 pm »

This has been a long-time issue for me with SFML and I always seem to have to create my own workaround for it.

As Ryan Bram previously mentioned, this problem can be resolved with zero interface changes merely by pulling the loop information out of the audio file metadata.

libsndfile already provides the ability to extract some metadata.  While I was unable to extract the exact "LOOPSTART" and "LOOPLENGTH" metadata fields that he mentioned using libsndfile, I was able to extract similar strings by putting them in the "comments" field of the audio file.

Personally, I think a LOOPLENGTH identifier is pointless, since it just adds more complication when you can just use EOF.  All we really need is a LOOPSTART.

The key for the change is in the SoundFile class.  All this class has to do is:

1)  In SoundFile::initialize:  Extract a loop start point from the sound file metadata (start point should be a sample offset for maximum precision and not a time offset)
2)  In SoundFile::read: Once EOF is reached, merely seek the file back to the loop point (if specified)


Both of these steps require minimal code changes (maybe 10-15 lines), do not really impact larger design issues, and do not require any interface changes.  The only externally visible change you'd need is to the documentation to make note of the feature.


I've made a similar change in my local copy of SFML 2.0 and it works great.  I'd be okay with applying the change (after cleaning it up) to the latest SFML bulid... but only if it's going to be welcome.



So what do you guys think?



EDIT:

Laurent mentioned this on the first page:

Using specific metadata is not an option, since SFML supports many standard audio formats.

This is why I suggest extracting text from the 'comments' field.  This is generic enough to be common across all audio formats.  And the functionality for reading this metadata is already in libsndfile.

4

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?

5

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.

6

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

« on: January 20, 2013, 04:25:55 am »

SOLVED:

Looks like this was a problem with my video drivers.  I updated for an unrelated reason, but the update seems to have fixed this issue as well.

Nice.

7

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.

8

General discussions / have fast moving sprites without distortion?

« on: October 28, 2011, 02:47:10 am »

They are not clear, as if there was not time to clear the old position of the sprite on the screen before drawing the new position. it makes you see multiple sprites at the same time especially when the ball is moving vertically. When it is moving horizontally it looks blurred.

I suppose it's a possibility that the monitor might leave "trails", but it would have to be really old and worn.  Besides, you probably would have noticed it earlier.

A more likely explanation is that it's your eyes.  Maybe you need glasses?

9

General discussions / have fast moving sprites without distortion?

« on: October 26, 2011, 04:28:10 pm »

I think it's a hardware limitation, the monitor may simply not fast enough.

I wouldn't say this this to your boss.  It doesn't really make any sense.

The monitor is fast enough.  It consistently redraws at whatever refresh rate it is set to redraw at (and based on what you said, it is set to redraw at 60Hz).

Attempting to draw faster than the refresh rate is pointless, because whatever you draw won't be visible until the next time the monitor refreshes.  So you can draw a scene at 1000 FPS, but if the monitor is refreshing at 60Hz, the end user will only see 60 FPS.  All those additional frames that you draw in between will never be seen (or will only be partially seen in the form of "tearing", an ugly video effect that distorts the image)


The only other thing I can think of is the way you're doing the timing:

Code: [Select]


      x += force_x * mainRenderWindow.GetFrameTime();
      y += force_y * mainRenderWindow.GetFrameTime();


While this is a commonly used technique because it's simple, it's actually kind of wrong.  You're drawing the next scene based on how long the previous frame was.

If, for example, you get a slow frame (40 ms) mixed in with your normal frames (let's say 20 ms to keep the math simple).  What will happen is the slow frame will draw normally, and the following frame will skip way ahead because the previous frame was slow.  This will result in a "jump" that will be especially noticable on things that are moving high speed.

The only way to solve this is to VSync, since that's the only way you can be "sure" that every frame will be the same length.  Otherwise you're at the mercy of the scheduler.

If you VSync, though, the above code should work fine and there shouldn't be any jumping.

10

General discussions / have fast moving sprites without distortion?

« on: October 21, 2011, 04:33:07 pm »

The kind of distortion you're talking about could be tearing or an instable framerate.  The best solution for both is to vsync.

Code: [Select]


yourwindow.EnableVerticalSync(true);


11

SFML projects / Yellow Snake - w/Source (Updated 10/21)

« on: October 18, 2011, 04:50:00 pm »

So it's really a toss up between which takes longer, construction/destruction, or assignments. Seeing as sf::Event is a POD type, it'll be faster to use the second option,

I fail to see how it could be faster.  I'm pretty sure they'd both compile to practically the exact same thing.

12

SFML projects / Airport

« on: October 15, 2011, 01:15:03 am »

Another option:

The first time the program is launched (no saved file or whatever), run a very small window and have the user pick their desired res.  Then switch to that res and save it to the saved file so it can be auto-started in that res the next time the game is run.

Or try to autodetect based on the user's current screen resolution (does SFML have a way to check the current res?)

13

General / Keep seeing: error: expected ')' before '&' token ?

« on: October 11, 2011, 10:25:15 pm »

Glad to help.

14

General / Keep seeing: error: expected ')' before '&' token ?

« on: October 11, 2011, 08:37:05 pm »

Circular dependency.

Game.h is including Snake.h
Snake.h is including Game.h

Read section 4 (for how to fix/avoid) and 6 (for explanation of why it's happening) of this article:

http://www.cplusplus.com/forum/articles/10627/#msg49679

Long story short, you need to break the circular dependency by removing one of the includes and replacing them with a forward declaration.

15

General / Possible Bug in RenderWindow Destructor (SFML 2.0)

« on: October 10, 2011, 06:17:26 pm »

I must admit I'm pretty curious as to why globals are impossible to remove.  Not that I dont' believe you... it's just I find it intriguing.