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 - Marukyu

Pages: [1] 2 3
Audio / Re: sf::Music fails to loop after seeking
« on: April 25, 2019, 01:21:11 pm »
My suggestion would be to round the sample index to a multiple of the channel count when seeking an sf::InputSoundFile, in order to avoid ending up "between" multi-channel samples in m_sampleOffset:


I haven't gotten around to testing the fix too extensively yet (e.g. sound file types other than Ogg/Vorbis, channel counts other than stereo), but it appeared to work for my use case without any obvious adverse effects.

Audio / sf::Music fails to loop after seeking
« on: April 19, 2019, 07:55:46 pm »
When seeking an sf::Music object to certain playback offsets, it will not loop at the end despite setLoop having been called on it.

The following example reproduces this issue on Linux Mint 18.3 (the example requires testsound.ogg, found in the attachments, to be present in the working directory, though any stereo Ogg sound should work):
#include <SFML/Audio/Music.hpp>
#include <SFML/System/Sleep.hpp>
#include <SFML/System/Time.hpp>
#include <iostream>
#include <fstream>
#include <memory>
#include <string>
#include <vector>

std::vector<char> readFile(std::string fileName)
        std::ifstream f(fileName);
        std::vector<char> data;
        f.seekg(0, std::ios::end);
        f.seekg(0, std::ios::beg);
        f.read(data.data(), data.size());
        return data;

std::unique_ptr<sf::Music> play(const std::vector<char> & buffer, sf::Time offset)
        std::unique_ptr<sf::Music> music = std::make_unique<sf::Music>();
        music->openFromMemory(buffer.data(), buffer.size());


        if (offset != sf::Time::Zero)
                std::cout << "Playing at " << offset.asMicroseconds() << " us" << std::endl;
                std::cout << "Playing from start" << std::endl;

        return std::move(music);

int main()
        auto buffer = readFile("testsound.ogg");

        std::unique_ptr<sf::Music> music;

        music = play(buffer, sf::Time::Zero);       // Playing from the start: sound loops correctly
        music = play(buffer, sf::microseconds(20)); // Issue occurs here: sound does not loop
        music = play(buffer, sf::microseconds(25)); // No issue here, sound loops properly

        return 0;

Playing the example sound from the start or seeking to 25 microseconds loops the sound just fine, but seeking to 20 microseconds causes the sound to stop at the end instead.

Through debugging, I found that in the erroneous case, when reaching the end of the sound, SoundStream::fillAndPushBuffer exceeds the retry limit and requests a stop.

This is due to neither of the two conditions in Music::onLoop being met: the current sample position is just one sample short of the music's ending, but no more full multi-channel samples can be read, therefore never allowing the loop condition to trigger.

This playback offset misalignment was caused by InputSoundFile::seek(Uint64), which accepts offsets that end up between full multi-channel samples. I fixed this issue locally by dividing/multiplying the offset by the channel count, changing InputSoundFile::seek(Uint64)'s function body to the following:
void InputSoundFile::seek(Uint64 sampleOffset)
    if (m_reader && m_channelCount != 0)
        // The reader handles an overrun gracefully, but we
        // pre-check to keep our known position consistent
        m_sampleOffset = std::min(sampleOffset / m_channelCount * m_channelCount, m_sampleCount);

I haven't familiarized myself too deeply with SFML's sound streaming classes and audio streaming in general, so I might be completely mistaken about most or all of what I've written above. It could also be a completely unrelated issue instead, as the phenomenon has proven rather difficult to reproduce reliably. :)

SFML projects / Re: FM Composer - A sound & music creation tool
« on: May 21, 2018, 12:26:03 am »
It's very nice to hear that my modifications are appreciated! Feel free to link the forked repository anywhere you'd like, I'd be honored to be mentioned on your website. ^^

The reason I used templates for min/max is because defining macros with those names can break standard library headers that are included afterwards, which is what happened while I was compiling the project. Performance-wise, they should be identical on most modern compilers. I also added explicit min/max macros in fmlib.c to work around a linker issue (undefined references to "min" and "max"), but this might be solvable with a better CMake configuration.

As for _control87, I spent a while looking for a drop-in replacement for Linux, but couldn't find one, so I "temporarily" ifdef'd out the line to see if the program still behaves properly. It appeared to work just fine for me without audio or performance issues, but I'm not enough of a floating point optimization wizard to understand the exact effects this function has on subsequent operations. I'll be sure to let you know and/or update my fork if I stumble upon a cross-platform alternative to this function!

Providing Linux builds that work everywhere is somewhat tricky. Binaries will depend on the exact versions and compiler settings of all dynamically linked libraries (so, to answer your question, yes, Ubuntu builds will pretty much only work on Ubuntu). As a result, applications are usually distributed as packages in an environment where the library versions are predictable (this is what package managers and software repositories do).

There are some ways to work around this issue by bundling binaries and libraries into self-contained packages with tools like AppImage or Snappy, which can be used for universal software distribution on Linux, but my experience with these tools is rather limited. Personally, I'd say that providing source code that compiles successfully on Linux, along with some build instructions, is already a good starting point. :)

SFML projects / Re: FM Composer - A sound & music creation tool
« on: May 15, 2018, 08:21:58 pm »
Submitting a pull request sounds good! I think I should first clean up the hacks I introduced though, and verify that I didn't break anything on the Windows build. I wouldn't want to cause the developer too much additional work, after all.

SFML projects / Re: FM Composer - A sound & music creation tool
« on: May 15, 2018, 07:37:45 pm »
Upon reading the title, this project immediately caught my interest. It looks (and sounds) amazing!

I made a set of modifications to get FM Composer to compile on Linux using CMake (thanks to Phanoo's great efforts for cross-platform compatibility, few changes were needed to port the program!). Feel free to check it out if you're interested: https://github.com/Marukyu/fmcomposer

My fork is still somewhat "quick-and-dirty", being essentially the minimal set of changes to get the program to compile successfully on my machine (possibly even breaking the Windows build in the process), but I hope that some of you will find a use for it anyway. ^^

General discussions / Re: Multi Monitor Setup
« on: August 01, 2014, 04:39:10 pm »
It is difficult to use SFML's current fullscreen functionality with TwinView on Linux. The resolutions detected by SFML apply to the virtual screen that spans both physical screens. Switching that virtual screen's resolution often yields incorrect results:
On my system, with 1920x1080 (primary) and 1280x1024 monitors, fullscreening a 1920x1080 SFML window causes the 1280x1024 monitor to display the SFML window content stretched, and the 1920x1080 screen gets turned off entirely. Because the 1280x1024 monitor has a lower internal ID (0), it gets picked as the monitor to display the image on, even if the resolution does not match.

I am in support of adding multi monitor handling (or at least multi monitor awareness) to make SFML fullscreen work on TwinView setups without turning off the other screen or even using invalid resolutions. I've been hoping there would be some interest or progress with this issue, but I'm rather terrible at working with C code like X11's.
SDL2 handles this well, but then again, the relevant code is quite long... maybe there's room for simplification?
By the looks of it, querying/using Xinerama is sufficient to support TwinView on non-outdated Nvidia drivers.

General discussions / Re: Future release of SFML 2.2 (feedback needed)
« on: April 01, 2014, 01:25:32 pm »
Hayo! I'm looking forward to the release of 2.2! It's going to be interesting to play around with the mobile ports.

One of the oldest active issues on the tracker, and in my opinion the greatest shortcoming of SFML, is the lack of proper handling for international keyboard layouts. Nearly every special key on my QWERTZ keyboard is reported as "sf::Keyboard::Unknown", without any way to distinguish what key was actually pressed. Games with rebindable inputs are pretty much restricted to the alphanumeric/modifier keys on non-QWERTY keyboards.

A possible (and previously suggested) solution is to provide direct scancode/VK/KeySym values in sf::Event and allow optionally passing them to a function like sf::Keyboard::isKeyPressed(), as this would at least allow keys to be distinguished locally. An API addition like this shouldn't break any existing code.

The issue is marked as "Milestone: 2.2", but unfortunately, there don't seem to be any pull requests to improve this behavior. I've made a personal workaround/hack that simply adds a systemCode member to the keyboard (and mouse) event struct, but it's undocumented/ugly, slightly buggy on Linux when modifiers are involved, and completely untested on Windows. Still, I'll try my best to contribute if I can.

Anyway, the issue may not exactly be critical, but it is bothering me quite a bit because I'm particularly affected by it.

Text-only clipboard support built into SFML would be extremely useful, right now I have to rely on popen() with xclip on Linux because I can't access X11 events without having to modify SFML's source code, which would force me to readd my changes everytime I update to a newer SFML version (which is currently quite often, due to SFML's frequent feature, bugfix and optimization progression right now, particularly for Linux).

Also, clipboard handling on Linux is generally quite a complicated matter (compared to a trivial single function call on Windows) and appears to require a good understanding of X11.

Regarding usefulness within a multimedia library, I'd say almost every major SFML app uses some kind of widget toolkit, usually written in SFML itself. Most of those involve text input fields, of which Ctrl-V functionality should be expected.
One argument that seems to be brought up often in this context is Qt's clipboard functionality, but there doesn't appear to be a way to use the clipboard functions from the rest of the Qt library without linking the a large part of the library, adding a significant amount of overhead, particularly if you're using a pure SFML GUI system.

"Open with default application"-type functionality support is much easier to implement without having to modify SFML, all it requires is a call to ShellExecute() on Windows and a script such as xdg-open on Linux, and it's not needed quite as often as the clipboard, so it's probably not all that necessary to be added to SFML.

Graphics / Re: RenderTexture, compile fail on linux gcc
« on: October 27, 2012, 12:57:57 pm »
sf::RenderTexture cannot be copied, so classes that use it as a member cannot be used within containers such as std::vector directly. A vector of pointers to said class will work, though.

SFML projects / Re: [Bullet Hell-Game] Still Unnamed Project
« on: September 14, 2012, 12:13:53 pm »
Sounds very nice, looking forward to seeing progress on this project.
I wish you the best of luck, and may the ⑨ be with you! :3

Graphics / Re: Color transmission is not smooth
« on: September 12, 2012, 10:39:01 am »
Make sure CLAMP() returns a float, not an int.

Graphics / Re: Image not drawn on render window
« on: September 01, 2012, 02:16:41 pm »
How do I cut the extra background pixels from the image? What I want is a clean circle/bullet and the white background behind it is annoying. Would doing it with SFML be better than doing it with another software?

It is possible to do this in SFML by loading to an sf::Image first, applying createMaskFromColor() with the specific background color that you want removed, and then creating an sf::Texture from the image.
If you're working with white-transparent-looking images that have a black background, then they're likely supposed to be additively blended by the application. You can do this by setting the "blendMode" parameter of the sf::RenderStates you're using to "sf::BlendAdd".

Also, yay for Touhou! n_n

Window / Re: SFML 2.0 mouse position
« on: July 25, 2012, 12:13:16 pm »
Well, it's not easy to tell you what is going wrong if the only thing provided is a part of the main loop. It's likely related to the way you structured the rest of your code. Could you elaborate on "the code does not work"? What exactly does not work?

Window / Re: SFML 2.0 mouse position
« on: July 25, 2012, 12:00:33 pm »

I'm not entirely sure what exactly you're trying to make your function do here, but you cannot chain return calls like this. If you want your function to return the position at which the mouse button was clicked according to some sf::Event, return it as a vector, like this:
return sf::Vector2i(menuEvent.mouseButton.x, menuEvent.mouseButton.y);

Also, not sure if this is just stripped down code or an extract of what you're actually using, but if the latter is the case, you might have to change it use window.pollEvent(menuEvent) in a while()-loop to catch all events from an sf::Window (unless menuEvent is being passed as a parameter to the function, or something).

About the "::" vs "." question: accessing static class members or namespaces requires "::" to be used. The "." operator is for accessing members and functions of class instances / objects.

~ def8x

ninja edit: fixed a stupid mistake I made with the vector code

General discussions / Re: SFML 2.0 RC
« on: July 10, 2012, 12:13:21 am »
Thank you very much for the fix! Glad I could help. :3

Pages: [1] 2 3