Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Ceylo

Pages: 1 ... 7 8 [9] 10 11 ... 69
121
Audio / Very simple sf::Music test crashes
« on: January 04, 2015, 09:00:22 pm »
On OS X 10.10, with both SFML 2.2 and Git head, running the following piece of code causes a Bus error:
int main()
{
        sf::Music music;

        if (! music.openFromFile("test.wav"))
                return 1;

        return 0;
}

The file "test.wav" does not exists, so failure is ok but it should not crash. LLDB backtrace is as follow:
Code: [Select]
* thread #1: tid = 0x1096d8, 0x00007fff951b3fcf libsystem_platform.dylib`OSSpinLockLock + 7, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x100000f74)
  * frame #0: 0x00007fff951b3fcf libsystem_platform.dylib`OSSpinLockLock + 7
    frame #1: 0x00007fff8b70477d libsystem_pthread.dylib`pthread_mutex_destroy + 25
    frame #2: 0x000000010001a497 sfml-system`sf::Mutex::~Mutex() + 23
    frame #3: 0x0000000100006b31 sfml-audio`sf::Music::~Music() + 65
    frame #4: 0x0000000100000dfb a.out`main + 347
    frame #5: 0x00007fff8da4c5c9 libdyld.dylib`start + 1
    frame #6: 0x00007fff8da4c5c9 libdyld.dylib`start + 1

122
Audio / Re: sf::Music play() and pause() bug?
« on: December 26, 2014, 01:37:58 am »
As Ixrec points out, the whole point is that this behaviour was not expected. Although when you explain why it happens it makes sense.

This also look specific to be implementation detail, although the end-user doesn't really care if SFML uses OpenAL (which is asynchronous and operation queue-oriented) or something else (which could be fully synchronous and block the execution until the wanted state is reached). This is just so weird to find out that the music is still playing even if stop was requested! :D (at least from the program execution pipeline point of view)

Even if the reality of the sound produced by the hardware would say that there is still sound coming out, I would expect the state of the SoundStream to reflect the request (as long as you can guarantee that reality will catch up with the software state).

As for the constraint on my side, there isn't really any. I just had a sanity check in my code to make sure the stream was not playing while I was doing some operations on the data that would be fed to the SoundStream. The point being that I don't want SFML to fetch data while I'm doing these operations. Here it looks like I can either wait a bit or not care about the result of the sanity check (but I like sanity checks :( ).

P.S.: thanks for all the work on SFML :)

123
Audio / Re: sf::Music play() and pause() bug?
« on: December 25, 2014, 11:12:46 pm »
I'd read this topic but… there the issue looks to be getStatus() taking too long, but not giving inaccurate result. Did I miss something?

I also tried binary1248 soundstream_contention branch where he has done some changes but it doesn't fix the current assertion failure.

124
Audio / sf::Music play() and pause() bug?
« on: December 25, 2014, 10:52:56 pm »
Hello,

Just encountered an issue that I reproduced with this sample code:

#include <SFML/Audio.hpp>
#include <cassert>
#include "ResourcePath.hpp"

int main(int, char const**)
{
    sf::Music music;
    if (!music.openFromFile(resourcePath() + "nice_music.ogg")) {
        return EXIT_FAILURE;
    }
   
    music.play();
   
    sf::sleep(sf::seconds(2));
   
    while (true)
    {
        assert(music.getStatus() == sf::Music::Playing);    // (1)
        music.pause();
        assert(music.getStatus() == sf::Music::Paused);     // (2)
        music.play();
        assert(music.getStatus() == sf::Music::Playing);    // (3)
    }

    return EXIT_SUCCESS;
}
 

This code crashes most of the time on the assert (3), sometimes on the (2), and even some times on the (1) !!! I'm using the latest sources from Git (freshly built right now) on OS X 10.10.

I thought pause() and play() would be synchronous but… is this expected? ;D

125
The packaged FFmpeg has been updated to version 2.4.3. Among the changes this makes the Opus audio decoder available natively!

More details here

126
On Windows, it's now possible to create a static version of the library!

More details here

127
More news:
Provided binaries now include all the decoders natively supported by FFmpeg!

More details here

128
I'm pleased to announce the support of bitmap subtitles!
In addition to stream selection, this is one of the first new major features since v1.0. It is also the first major feature brought thanks to the contributions of feliwir.

More details here.

129
Good to here from you :) After two months I thought you got lost into the limbo ;D

And of course personal stuff first!

130
Feature requests / Re: Why not set sf::Window style at runtime?
« on: November 11, 2014, 11:54:29 pm »
To get a confirmation and to support this feature:

I'm in the case where the user can toggle the main window to be fullscreen or windowed. When doing so, I re-create the window and properties such as whether VSync is enabled or whether mouse cursor is hidden are lost. So when I want to switch to fullscreen, I have to re-set all the window properties. This is especially annoying considering that some of these properties cannot be "get" from the window object, so if it was modified externally (ie. by the user of your library) you can't do anything.

Am I missing some obvious easy way to handle the case?
If not, I guess not having to re-create the window to switch to fullscreen mode would solve my issue.

131
More news here: it's now (at last!) possible to build build sfeMovie against your own FFmpeg installation :)
More details here

132
Hey good news on the project! :)

- Its website has moved to http://sfemovie.yalir.org/
- There is also now a freshly created forum hosted on it, at http://sfemovie.yalir.org/forum for any question, suggestion or debate you may have
- The website now provides automatically updated binaries for the latest version from Git, so if you want to use the latest version of sfeMovie without the annoyance of compiling it, whatever your OS, there is it ! http://sfemovie.yalir.org/latest/downloads.php

A few words on features too:
- FFmpeg has been updated to version 2.2.2
- In case of media files with several audio streams, it's now possible to select the one that you want to use
- apart from that it's mainly (a huge) internal cleaning and bug fixes

Recently 2 developers (namely feliwir and bluekirby0) have been participating and working on subtitles support and native build of FFmpeg on Windows through Visual Studio (yes get rid of MinGW!). These are huge improvements that may come into sfeMovie and I invite you to join me in cheering them up because these are really hard tasks :)

On my side I've been mainly working on getting continuous integration working, which will help us at finding bugs faster, and which now gives you the up-to-date prebuilt binaries :) Next weeks will be dedicated to seeking support.

As always, if you're willing to help in any way, you're welcome, be it for development, testing or encouraging the current developers!

133
Ok… then the only solution I'm aware of is doing a clean install of MinGW bundled with MSYS.

134
Do you have only one "make" or "make.exe" executable reachable from your PATH?

135
Well at least this means you're still in the build script, which is good :)

But what's happening is really odd. I remember having a similar issue a long long time ago though. I'm not sure about how I had fixed this, the only bits of memories I still have about this is I had to reinstall MSYS properly… it's really a guess but it could mean that the execution of the program by sh.exe failed in some way. What happen if you use the "exit" comment at this point? Does it continue one step forward, does it go back to MSYS or does it close the window?

Pages: 1 ... 7 8 [9] 10 11 ... 69