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

Pages: [1]
1
Audio / Re: Static/popping noises on Raspberry Pi 3
« on: October 25, 2018, 05:45:35 am »
Wow, thanks for the quick response!  I will try to answer your questions:

1. I installed SFML from the package manager ("sudo apt-get blah blah blah" lol).  I only did this a couple days ago, so I'm pretty sure it's the current version (though again, I'm not sure how to stick an exact number on it).

2. I will see if I can get it off the Pi and send it to you; but unfortunately, there is no way to send the version with the noises (it would just be the original one I downloaded).

3. I just tested it with a ".ogg" file and had the same problem.  So I think we can rule out the wav bug.

4. The noises happen during playback at seemingly random intervals (not just at the end).  The only thing I can compare it to is the sound you would hear if you unplugged the headphones.

By the way, I also found some text being printed to stdout that I wasn't seeing before, that might be useful:
Setting vertical sync not supported
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::JackShmReadWritePtr - init not done for -1, skipping unlock
JackShmReadWritePtr::JackShmReadWritePtr - init not done for -1, skipping unlock

This of course means nothing to me, apart from random things I can guess from the text (obviously, some component is trying to connect to some other component, with a client/server model, and some pointer for reading and writing something has some other mysterious problem.  I'm sure the SFML dev team would understand it, whatever it means. :)

2
Audio / Static/popping noises on Raspberry Pi 3
« on: October 25, 2018, 05:11:59 am »
Hey guys, what's up? :)

I've been messing with the Raspberry Pi a lot lately, and I found it supports SFML, so I've been having a lot of fun with that (lol).  Anyway, I notice when I use the audio API, there is a sort of static / popping type noise in the background when sound is playing.

Here are some details on my system: it's a Raspberry Pi 3, purchased in March/April of this year (so it's running a relatively new version of Raspbian, though I'm not sure how to get an exact version number).  I'm also using a USB headset, and I haven't connected an HDMI monitor (getting sound to play on HDMI was another rabbit-hole of obscure config files and random forum posts, lol - I did eventually crack it, so chances are there's some related setting in some equally obscure config file, but for now that should not be a factor since I'm not using HDMI at the moment).
And here's an example of my code:
sf::SoundBuffer buff;
buff.loadFromFile("/home/my_username/Desktop/test.wav");
sf::Sound test(buff);

// Then in my event loop, on key press
test.play();
What's interesting is if I just do
system("play /home/my_username/Desktop/test.wav");
the sound plays with no popping/staticky sounds.  So I know it's not my headset or the Pi.  Maybe it does ".ogg" or some other format better?  idk... anyway, I've Googled myself stupid and created several useless config files, and nothing seems to work.  Has anyone else hear dealt with this?  Thanks in advance.

3
Hey guys,

I've been on a roll with SFML, creating a simple scrolling shooter, but so far the only way I've been able to keep references to graphics available long enough to be used is by storing them in fixed-size arrays or class properties for every instance.  Initially I thought it was possible to use vectors, maps, etc. but quickly found out that the way those classes work internally is to make copies, so anything I create is destroyed the second it goes out of scope.  Sounds don't play, and graphics get the white square bug, if I use anything out of the STL.

But then again, I'm thinking that might not actually be the case.  I've only been doing C++ for about 6 months, and it's the first language I've learned where memory management is an issue.  So odds are that there's some other way I just haven't learned yet.  Take for example these 2 versions of the same class:

// This is the version that works, using a class property for every instance
#ifndef SOUND_PLAYER_H
#define SOUND_PLAYER_H
#include <map>
#include <SFML/Audio.hpp>

class SoundPlayer
{
public:
    static SoundPlayer * Get();
    void PlayerLaser();
private:
    static SoundPlayer * Instance;
    SoundPlayer();
    sf::SoundBuffer player_laser, enemy1_explode;
    sf::Sound sound;
};

SoundPlayer * SoundPlayer::Instance = NULL;

SoundPlayer * SoundPlayer::Get()
{
    if (Instance == NULL)
        Instance = new SoundPlayer();
    return Instance;
}
SoundPlayer::SoundPlayer()
{
    if (!player_laser.loadFromFile("bin\\debug\\sounds\\player_laser.wav"))
        throw "Error loading the player laser sound";
    if (!enemy1_explode.loadFromFile("bin\\debug\\sounds\\enemy1_explode.wav"))
        throw "Error loading the enemy 1 explosion sound";
}
void SoundPlayer::PlayerLaser()
{
    sound.setBuffer(player_laser);
    sound.play();
}

#endif
 
// And this is the one that doesn't work, using maps
// I've tried maps of objects, and maps of pointers (which is what's shown here)
// and both don't seem to have what it takes to work in SFML - but they've been around for decades so it's obviously just me being a noob :)
#ifndef SOUND_PLAYER_H
#define SOUND_PLAYER_H
#include <map>
#include <SFML/Audio.hpp>

class SoundPlayer
{
public:
    static SoundPlayer * Get();
    void PlayerLaser();
private:
    static SoundPlayer * Instance;
    SoundPlayer();
    std::map<std::string, sf::SoundBuffer*> buffers;
    std::map<std::string, sf::Sound*> sounds;
};

SoundPlayer * SoundPlayer::Instance = NULL;

SoundPlayer * SoundPlayer::Get()
{
    if (Instance == NULL)
        Instance = new SoundPlayer();
    return Instance;
}
SoundPlayer::SoundPlayer()
{
    sf::SoundBuffer b1;
    if (!b1.loadFromFile("bin\\debug\\sounds\\player_laser.wav"))
        throw "Error loading the player laser sound";
    buffers.insert(std::make_pair("player_laser", &b1));

    sf::Sound s1;
    s1.setBuffer(b1);
    sounds.insert(std::make_pair("player_laser", &s1));
}
void SoundPlayer::PlayerLaser()
{
    sounds["player_laser"]->play();
}

#endif
 

Both compile fine, and both "look" like they should work, but because of however these STL classes work "under the hood" they just don't seem to work well with SFML, making the idea little more than wishful thinking.  From what I've read (including another question on this forum) the way they work is to make copies of the objects, and I haven't been able to figure out a way around that obstacle yet.  I've tried vectors/maps of objects, and also pointers (shown above), and none of it seems to work... so it's gotta be me just being a noob (lol).

But it's no biggy if it actually can't be done.  Fixed arrays and class properties per object are working reliably, and I've got a pretty cool little game going using them as my go-to for everything SFML-related.  Heck, even the NES could only have up to 64 objects on the screen at once, so my player object only being able to use up to 5 laser instances or there only being up to 16 enemies is not an issue.  But there's a reason the STL was created, problems with the fixed-size way of doing things that it was meant to solve, and I bet there's a better way to use it that I just haven't figured out yet.

So how do you guys handle textures, sprites, sound buffers, sounds, and other stuff like that?  I'm sure I'm not the first guy who's ever had this question (and since the white square issue is brought up in the documentation it must be super-common) but so far I haven't managed to fish up any answers on Google, so I figured I'd ask the pros. :)

Thanks in advance. :)

4
Audio / Re: Playing audio
« on: June 21, 2017, 01:10:48 pm »
And I agree I have a lot to learn; I've done plenty of work in C++, but the more I learn, the more I realize I still need to discover.  I understand the concept of scope, but had no idea it played such a critical role (apparently more than any of the other languages I know) in tools like SFML.

But anyway, your idea of making the sf::sound a class property did the trick.  Thanks!  Now one last dumb question: How do I mark this topic as solved?  :)

5
Audio / Re: Playing audio
« on: June 21, 2017, 09:36:30 am »
Code: [Select]
Okay, so how do I "keep it alive"?  I know it plays sounds in its own thread - is that what needs to be "kept alive" or "closed" afterward?

And as for the pointer thing, I only said that because so far that has been my experience - I've never had this kind of trouble managing objects or pointers before, but as soon as I dove into SFML, it seems nothing sticks around long enough to be used.  But I also said I was sure SFML isn't the only framework that does this, and it was probably a mistake on my end.  Sorry if I wasn't clear about that.

So now that I've stomped everyone's toes to oblivion (lol sorry, totally didn't mean it) how do you guys handle the "keeping sounds alive" problem?  I just tried getting rid of the SoundPlayer class altogether and just calling it like this:

[code lang="cpp"}sf::SoundBuffer b;
    if (!b.loadFromFile("bin\\debug\\sounds\\player_laser.wav"))
        throw "Error loading the player laser sound";
    sf::Sound sound;
    sound.setBuffer(b);
    sound.play();

This of course got the same result.  And every reference I've been able to find to playing sounds with SFML says to do pretty much exactly what I've got here (the only differences being variable names and the sound file path).  There is no mention of closing anything or "keeping it alive" anywhere... sf::sleep maybe?  If that's the case I guess I'll stick with IrrKlang, since sf::sleep stops the game while the sounds play.

6
Audio / Playing audio
« on: June 21, 2017, 04:19:53 am »
Hey guys, what's up,

So I've been following the tutorials on playing sounds, and I've run into a kind of weird issue that doesn't seem to be mentioned anywhere: The sound doesn't play, and when the program ends I get this error: "AL lib: (EE) alc_cleanup: 1 device not closed".  So after a bit of Googlefishing, I found a few sites where people have asked about it, and even one guy who filed a bug about it - but since I'm new to SFML I'm assuming it's something I've done wrong. :D

So here's my code:


#ifndef SOUND_PLAYER_H
#define SOUND_PLAYER_H
#include <map>
#include <SFML/Audio.hpp>

class SoundPlayer
{
public:
    static SoundPlayer * Get();
    void PlayerLaser();
private:
    static SoundPlayer * Instance;
    SoundPlayer();
    sf::SoundBuffer player_laser;
};

SoundPlayer * SoundPlayer::Instance = NULL;

SoundPlayer * SoundPlayer::Get()
{
    if (Instance == NULL)
        Instance = new SoundPlayer();
    return Instance;
}
SoundPlayer::SoundPlayer()
{
    if (!player_laser.loadFromFile("bin\\debug\\sounds\\player_laser.wav"))
        throw "Error loading the player laser sound";
}
void SoundPlayer::PlayerLaser()
{
    sf::Sound sound;
    sound.setBuffer(player_laser);
    sound.play();
}

#endif

// And here is how it's used:
SoundPlayer * sp = SoundPlayer::Get();
sp->PlayerLaser();
The SoundPlayer class is mostly an attempt to keep the sound-related objects in scope (since stuff seems to go out of scope and get destroyed super-easy/almost instantly with SFML), but originally it was the constructor and PlayerLaser methods as one function.  I figured that was not efficient (cuz it would have to re-load-from-file every time the sound is played), but I figured I'd share it anyway.

But this error seems to suggest that something needs closing?  I didn't see anything in the tutorial about that (apart from if you have too many sounds, but I can't get it to play just one).  I haven't managed to find any clear answer on Google or in the API docs, but then again I only spent like half an hour fighting with it.  Has anyone here dealt with this cryptic error before?  No big deal (I can always use IrrKlang for sounds if I can't get past it) but I'm guessing it's another newbie mistake on my part and a common pitfall everybody fights with at some point.

Also, if there is a better way to make references to SFML objects permanent, or at least exist a little longer, I'm all ears.  I recently had a similar struggle with textures, and learned the hard way that storing them in a vector was a dumb idea.  I know others have found or built workarounds, but if it's basic C++ stuff it really is something I should learn.  I know what a pointer is, but I've never had as many issues with pointers being destroyed as I have with SFML; but I'm sure SFML isn't the only framework to auto-destroy pointers, so I "better figger it out fast" tyvm

7
Graphics / Re: Trying to solve the white square riddle
« on: June 21, 2017, 01:48:18 am »
Gotcha.  That particular tidbit was knowledge that this C++ developer didn't know... until now.  :)

Seriously though, you're absolutely right that there is a deeper understanding of C++ that is necessary if you're going to be any good, and at times it seems to be infinitely deeper than any other language I know, so I appreciate your bearing with me.

So in the short-term, I've deleted the vector from the code and just have 5 instances of the laser object that can be visible at any given time, and pressing the shoot button just uses the first one that's off the screen.  But in the long-term I'd be interested to find out a more reliable storage method than vectors, or maybe a way to prevent the accidental destruction of that texture pointer - but for now I got a workaround that gets the job done.  Thanks. :)

8
Graphics / Re: Trying to solve the white square riddle
« on: June 20, 2017, 01:53:55 pm »
Well first off, I apologize for all the toe-stomping I seem to have done.
  • I didn't see an icon for the code thing, but figured there must be some text-based syntax to set up a code block as code.  I will make sure to do it from here on out.
  • I didn't think I was asking to be taught C++; sorry if I was.  I thought the white square thing was specific to SFML.  But anyway it won't happen again.
Now getting back to the problem at hand, the laser class is nearly identical to the player class, except for the vector and player movement, which is why I didn't include it (but I will if you really want it).  And every class (background, player, and even laser) works if I create them before the while loop in main.

So the problem definitely seems to be with the vector.  I'm still not sure what is causing that pointer to go out of scope; the objects' constructors set it, and in theory the object is still in scope because the vector hasn't gone out of scope, but obviously I'm wrong there (and apparently it's something so super-basic that I cam across as being asked to learn C++).  I've tried using a vector of pointers to laser objects, but pressing Space in that scenario crashed the program; maybe I just need to fight with doing things that way and see if that could potentially lead to any change.

But until then, it sounds like the only way to keep textures permanent is some kind of resource manager class like the one you suggested.  Just the fact that someone felt the need to create a tool like that kinda tells me I'm not the first SFML noob to get whammied with this problem.  ;D

9
Graphics / Trying to solve the white square riddle
« on: June 20, 2017, 04:44:23 am »
Hey, what's up,

I've recently started with SFML, and I've run into the infamous "white square problem".  The documentation explains the problem, but doesn't give any hints at solutions.  I get that under the hood, it uses a pointer to a texture, but that doesn't explain what "breaks" this pointer or what can be done to keep it "intact" (lol).

So I'm writing this simple 2D shooter, and I have a player class and a laser class.  The player class has a vector of lasers, and draws them all in its "update" method.  The objects are created and added to the vector, but this is where I'm hitting the white square bug.  Here's some code:

// Player class

#include <vector>
#include <SFML/Audio.hpp>
#include <SFML/Graphics.hpp>
#include "PlayerLaser.h"

class Player
{
public:

    /**
     * Constructor - initialize instance variables
     */

    Player();

    /**
     * Updates the player's position based on keyboard input
     * @param[in] Pointer to the keyboard event
     */

    void HandleEvents(sf::Event * event);

    /**
     * Update and draw the object to the screen
     * @param[in] Pointer to the window to draw to
     * @param[in] The player's speed
     */

    void Update(sf::RenderWindow * window, float speed);
private:
    sf::Texture texture;
    sf::Sprite sprite;
    bool MovingLeft, MovingRight, MovingUp, MovingDown;
    int index;
    std::vector<PlayerLaser> Lasers;
};

Player::Player()
{
    // Set up the sprite
    if (!texture.loadFromFile("bin\\debug\\graphics\\player.png"))
        throw "Failed to load player texture.";
    sprite.setTexture(texture);
    sprite.setTextureRect(sf::IntRect(0, 0, 64, 32));
    sprite.setPosition(320, 320);

    // Init other variables
    MovingUp = false;
    MovingDown = false;
    MovingLeft = false;
    MovingRight = false;
    index = 0;
}
void Player::HandleEvents(sf::Event * event)
{
    if (event->type == sf::Event::KeyPressed)
    {
        if (event->key.code == sf::Keyboard::Left)
            MovingLeft = true;
        else if (event->key.code == sf::Keyboard::Right)
            MovingRight = true;
        else if (event->key.code == sf::Keyboard::Up)
            MovingUp = true;
        else if (event->key.code == sf::Keyboard::Down)
            MovingDown = true;
        else if (event->key.code == sf::Keyboard::Space)
        {
            PlayerLaser pl(sprite.getPosition().x, sprite.getPosition().y);
            Lasers.push_back(pl);
        }
    }
    else if (event->type == sf::Event::KeyReleased)
    {
        if (event->key.code == sf::Keyboard::Left)
            MovingLeft = false;
        else if (event->key.code == sf::Keyboard::Right)
            MovingRight = false;
        else if (event->key.code == sf::Keyboard::Up)
            MovingUp = false;
        else if (event->key.code == sf::Keyboard::Down)
            MovingDown = false;
    }
}
void Player::Update(sf::RenderWindow * window, float speed)
{
    // Update the player's animation
    index++;
    if (index == 1000)
        sprite.setTextureRect(sf::IntRect(0, 32, 64, 32));
    if (index == 2000)
    {
        sprite.setTextureRect(sf::IntRect(0, 0, 64, 32));
        index = 0;
    }

    // Update the player's position
    if (MovingLeft && sprite.getPosition().x > 0)
        sprite.move(speed * -1, 0);
    else if (MovingRight && sprite.getPosition().x < 640 - 64)
        sprite.move(speed, 0);
    if (MovingUp && sprite.getPosition().y > 0)
        sprite.move(0, speed * -1);
    if (MovingDown && sprite.getPosition().y < 480 - 32)
        sprite.move(0, speed);

    // Draw the player
    window->draw(sprite);

    // Draw the lasers
    for (PlayerLaser pl : Lasers)
        pl.Update(window, speed + (speed / 2));
}

// Main
#include <SFML/Audio.hpp>
#include <SFML/Graphics.hpp>
#include "Background.h"
#include "Player.h"
#include "PlayerLaser.h"

int main()
{
    // Create the main window
    sf::RenderWindow window(sf::VideoMode(640, 480), "3017");

    // Create the background and player objects
    Background background;
    Player player;

    // Test
    PlayerLaser pl(32, 32);

    /*
    // Create a graphical text to display
    sf::Font font;
    if (!font.loadFromFile("arial.ttf"))
        return EXIT_FAILURE;
    sf::Text text("Hello SFML", font, 50);

    // Load music to play
    sf::Music music;
    if (!music.openFromFile("nice_music.ogg"))
        return EXIT_FAILURE;

    // Play the music
    music.play();
    */


    // Start the game loop
    while (window.isOpen())
    {
        // Process events
        sf::Event event;
        while (window.pollEvent(event))
        {
            // Close window: exit
            if (event.type == sf::Event::Closed)
                window.close();
            else if (event.type == sf::Event::KeyPressed && event.key.code == sf::Keyboard::Escape)
                window.close();
            else
                player.HandleEvents(&event);
        }
        // Clear screen
        window.clear();

        // Draw the background
        background.Update(&window, 0.025);
        player.Update(&window, 0.1);

        // test - no white square for this instance
        pl.Update(&window, 0.2);

        // Update the window
        window.display();
    }
    return EXIT_SUCCESS;
}
 

So the laser object works, if it's created at compile time, before the while loop.  But if it's created by the player object pressing space, it gets whitesquared.  So are objects not allowed to be created at runtime or something?  I suppose if I create every single instance at compile time it'll avoid the problem, but I'd really like to know if there's an actual solution available.  Unfortunately my knowledge of SFML's internals, vector's internals and whatever else the heck could be causing this to even come up with a logical theory; so for now I'm left Googling and guessing. (hair--;) lol

Any clues would be greatly appreciated.

Pages: [1]