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

Pages: 1 [2] 3 4
16
Audio / Modifying length of a sound sample?
« on: June 25, 2013, 03:00:22 am »
I am currently writing a program in which the user can play a simple virtual piano.  I load a sample representing a middle C, and I change the pitch of that sound to get the other notes the user requests.  However, I also want the player to be able to play notes of different lengths - quarter notes, half notes, etc.

Is there a way to dynamically alter the length of the sample?  I've been mucking around in Audacity trying to change the sample length to have multiple samples (I only really want five - staccato, quarter, half, three-quarter and full), but doing so makes the sample sound very scratchy.

If there is no way to do this, does anybody know what other approaches I may try?

17
Audio / Re: Sounds stop playing when other Sounds are deleted?
« on: June 07, 2013, 12:11:14 pm »
Hm, so I solved the problem by using an std::vector<sf::Sound*> as a container, so pointers instead of objects.  Otherwise everything remained the same (obviously, I delete the object before disposing of its pointer in the culling loop, too).  Not sure why that worked, but it did.

18
Audio / Sounds stop playing when other Sounds are deleted?
« on: June 06, 2013, 09:13:58 pm »
So I'm not 100% sure what is going wrong here, but the following code is not working as expected.

void Cycle(float Time, float Pitch)
{
    //Reduce the timer
    m_PlayTimer -= Time;

    //If it's zero, play the sample
    if (m_PlayTimer <= 0.0)
    {
        //Add the sound!
        m_SoundList.push_back(sf::Sound());
        unsigned short NewSound = m_SoundList.size() - 1;
        m_SoundList[NewSound].setBuffer(*SoundManager::GetSoundBuffer(1));
        m_SoundList[NewSound].setVolume(30.0);
        m_SoundList[NewSound].setPitch(Pitch);
        m_SoundList[NewSound].play();

        //Restore a positive value to the timer
        m_PlayTimer = 1.0;
    }

    //Cull finished sounds
    for (unsigned int ii = 0; ii < m_SoundList.size(); ++ii)
    {
        //Test whether the sound is finished or not; if so, remove it
        if (m_SoundList[ii].getStatus() == sf::Sound::Status::Stopped)
        {
            m_SoundList.erase(m_SoundList.begin() + ii);
            std::cout << "Sound deleted!\n";

            //If ii is the same as the size, there are no further sounds
            if (ii == m_SoundList.size())
            {
                break;
            }
            //Otherwise, there are further sounds!  Decrement ii so as not to skip any
            else
            {
                --ii;
            }
        }
    }
}

What happens is that sometimes, when one Sound finishes after another has started (I also modify the pitch of the sound, so the lengths of each sf::Sound are slightly different), both sounds are deleted in the same call, which kills the newer sound before it has had a chance to play out.  It's as though the algorithm thinks that both sf::Sound objects return Stopped upon calling getStatus().

Any idea what might be causing this, and how I can get things to work as expected?

19
Graphics / Re: Text off-center, problems getting size
« on: April 29, 2013, 09:51:52 pm »
Ah, okay.  Good to know it's expected, at least, so I'm not doing anything wrong.  Thanks!

20
General discussions / Re: SFML 2 and its new website released
« on: April 29, 2013, 09:47:35 pm »
Congratulations!

Also, Android support?  I think I'm in love, even if it's just "soon."

21
Graphics / Re: Text off-center, problems getting size
« on: April 29, 2013, 06:55:23 pm »
If I try this (which is what I assume the last message meant):

target.create(text.getGlobalBounds().left + text.getGlobalBounds().width,
              text.getGlobalBounds().top + text.getGlobalBounds().height);

then the entire text does always appear, but a large blank space also always appears above the text, about half as high as the text itself.  If I move the text up by half its own height, again, going to smaller character sizes cuts out the top of the image, and going to larger sizes creates a slightly larger gap above the text than below.


22
Graphics / Text off-center, problems getting size
« on: April 28, 2013, 08:33:21 pm »
I am trying to get images of arbitrary text, and am using this thread as a reference.  However, I am having some issues.  First, my implementation:

       
        sf::Font f;
        f.loadFromFile("courier.ttf");

        sf::Text text;
        text.setString("Test!");
        text.setFont(f);
        text.setCharacterSize(24);
        text.setColor(sf::Color::Black);

        sf::RenderTexture target;
        target.create(text.getLocalBounds().width,
                      text.getLocalBounds().height);
        target.clear(sf::Color::White);
        target.draw(text);
        target.display();

        sf::Image image = target.getTexture().copyToImage();
        image.saveToFile("text_test.png");

The problem is that if I just do this, what I get is an image wherein the top half is just white, and the bottom half of the image contains the top half of the text (with the bottom half of the text clipped out).

Adding
text.setPosition(0, -text.getLocalBounds().height / 2);

seems to mostly correct the issue... at 24 pts.  But if I change the character size to other values further from 24, such as 12 or 64, an upper or lower sliver of the text is again clipped out of view, respectively.

Am I misunderstanding something about how sf::Text objects are sized, positioned or displayed?  How can I neatly get an image that encompasses exactly all of the displayed text, and no more?

23
Graphics / Re: Problems with positioning sf::Text objects
« on: October 14, 2012, 03:27:52 pm »
Ugh, how embarrassing. 

The problem was that I was calling setCharacterSize() AFTER calculating the origin.  Doing so beforehand solves all my problems.  Of course.

Nevermind then.  Hopefully this helps someone in the future with similar inattentiveness.

24
Graphics / Problems with positioning sf::Text objects
« on: October 14, 2012, 03:17:32 pm »
So this is similar to my previous post, but the problem has become more pervasive.  I am not able to sensibly come up with a solution for properly arranging a series of sf::Text objects along the center of the screen.  The loop looks like this:

short CharSize = 16;
for (int ii = 0; ii < m_WeaponData.size(); ++ii)
{
    m_WeaponData[ii].setOrigin(...);
    m_WeaponData[ii].setCharacterSize(CharSize);
    m_WeaponData[ii].setColor(sf::Color(255, 255, 255));

    //Then, position it, making sure that each element is below the last
    m_WeaponData[ii].setPosition(m_App->getSize().x / 2, 30 + ii * (CharSize + 8));
}

My initial attempt was to put the origin of the sf::Text objects at their visual center, as such:

m_WeaponData[ii].setOrigin(m_WeaponData[ii].getLocalBounds().width / 2, 0);

But I discovered that this doesn't actually position the origin to the proper place; instead, the end of each string, more or less, is centered at the middle of the screen (though there is some slight variation).  Instead, I had to do this:

m_WeaponData[ii].setOrigin(m_WeaponData[ii].getLocalBounds().width / 4, 0);

To get the texts aligned according to their visual centers, which makes no sense since width/4 should not be the horizontal center.

Now, however, I've decided that it would be more convenient for the user if the strings were all arranged such that they are centered around the colon ':' character that appears in each of them, which would neatly put labels on one side of the screen and data on the other side.  So to do that, I tried this:

m_WeaponData[ii].setOrigin(m_WeaponData[ii].findCharacterPos(m_WeaponData[ii].getString().find(sf::String(":"))));

What I get instead is a bunch of texts that are shoved off to the left at seemingly random distances, rather than centered on the only ':' character in each string.  However, when I read the values provided by .findCharacterPos(), they seem to be more or less correct (i.e. the farther the ':' into the string, the higher the value of x).

Note that I know that findCharacterPos() returns global coordinates; the sf::Text objects all start positioned at (0,0), however, so that shouldn't matter.

I find that the only way to almost properly position the objects is to ignore setOrigin() altogether and do this instead:

m_WeaponData[ii].setPosition(m_App->getSize().x / 2 - Origin.x / 2, 30 + ii * (CharSize + 8));

But the result is only approximately lined up, not perfectly lined up, and I don't even understand why that solution is better than finding the position of the ':' character.

So something is going wrong here, and I don't know what it is.  Could somebody please offer some advice on this?

25
So I have an std::vector of sf::Text items I'd like to distribute evenly along a vertical axis in the center of the screen.  Here is what I do:

    short CharSize = 16;
    for (int ii = 0; ii < m_WeaponData.size(); ++ii)
    {
        //First, set the text object's origin
        //Use zero as the origin's Y, because if you use half the height, hanging characters such as (g,j,p,q,y) will make things uneven
        //Use 4 instead of 2 because... I have no idea.
        m_WeaponData[ii].setOrigin(m_WeaponData[ii].getLocalBounds().width / 4, 0);
        //Then, position it, making sure that each element is below the last
        m_WeaponData[ii].setPosition(m_App->getSize().x / 2,
                                     30 + ii * (CharSize + 2));
    }

Where m_App is of type sf::RenderWindow*.

My question is this: why am I dividing the local bounds by 4?  If I use 2, as would seem to make sense (that should put the origin at the halfway point of the sf::Text's X side, since the width divided by 2 is half the width...), the end of the text lines up with the center of the screen, rather than the center.  Using 4, though, does line up the X center of the sf::Text with the X center of m_App (which I assume I am obtaining correctly, right?).

I can only assume I am doing something wrong, but what?  Why does getLocalBounds().width / 2 not give me the proper results?

26
Graphics / Re: OpenGL - Screenshots always magenta
« on: May 30, 2012, 06:55:05 am »
Ahh, I see.  I changed that - thanks!

27
Graphics / Re: OpenGL - Screenshots always magenta
« on: May 29, 2012, 08:23:44 pm »
It seems like BMP export is broken, all other formats work.

I just tried with .tga, .jpg and .png.  I can't open .tga files for some reason, but yes, .jpg files work fine!  I'll use the .jpg format from now on.

Unfortunately, .png gives me a picture that is mostly transparent instead of dark grey, except for polygons that are heavily lit/shadowed (when printing a screen with models), or fully transparent (with the above example code).  Perhaps that's just me, though the code is otherwise identical.

28
Graphics / Re: Passing sf::RenderWindow to multiple .cpp files
« on: May 29, 2012, 07:06:13 pm »
I am by no means a guru, being a self-taught hobbyist myself, but it sounds like you're doing what I did back when I first learned to program using Python - arbitrarily moving functions off into other .py files to avoid clutter. 

I don't think this is generally what is done in C++.  Normally you'd have classes handling various tasks, and you could easily pass a pointer/reference to an sf::RenderWindow as a parameter to whatever function in whatever class needs it (among other possible solutions), or give the class a pointer to the sf::RenderWindow as a data member.  Better programmers than me probably know better ways of doing this.

I'd take Perde's advice, it sounds like you're not too sure how to organize C++ code.  It's not too hard, though, just takes a bit of reading and practice.

29
Graphics / UPDATE on magenta screenshots, full example code
« on: May 29, 2012, 06:58:34 pm »
So I've taken apart my code and hacked it down to the bare minimum, removing lighting, shading and all, and the screenshots are still pink.  Here is the entire code of a program that displays an empty OpenGL scene.  Perhaps you could remove even more, but I removed all the stuff that seemed superfluous.

The scene is dark grey when seen real-time, or captured with PrintScreen (with Windows, not within the program), but pressing F1 (which uses the SFML function) creates a pink/magenta image rather than a dark grey one as expected.  There are no polygons, but they aren't necessary to see the problem.

#define GLEW_STATIC
#include <GL/glew.h>
#include <SFML/Graphics.hpp>
#include <cstdlib>
#include <iostream>

int main()
{
    //WindowSize
    int WindowWidth = 800;
    int WindowHeight = 600;
    // Create the main window
    sf::RenderWindow App(sf::VideoMode(WindowWidth, WindowHeight, 32), "OpenGL Magenta Problem");

    // Set color and depth clear value
    glClearDepth(1.f);
    //Color here is in RGB, converted to a 0-1 scale.
    glClearColor(0.3f, 0.3f, 0.3f, 0.f);

    // Enable Z-buffer read and write
    glEnable(GL_DEPTH_TEST);
    glDepthMask(GL_TRUE);

    // Setup a perspective projection
    glMatrixMode(GL_PROJECTION);
    glLoadIdentity();
    gluPerspective(60.f, 1.33f, 0.1f, 512.f);

    // Start game loop
    while (App.isOpen())
    {
        sf::Event Event;
        while (App.pollEvent(Event))
        {
            // Close window : exit
            if (Event.type == sf::Event::Closed)
            {
                App.close();
            }

            // Escape key : exit
            if (Event.type == sf::Event::KeyPressed &&
                Event.key.code == sf::Keyboard::Escape)
            {
                App.close();

            }
            if (Event.type == sf::Event::KeyPressed &&
                Event.key.code == sf::Keyboard::F1)
            {
                sf::Image Screen = App.capture();
                Screen.saveToFile("screenshot.bmp");
                std::cout << "Screenshot saved!\n";
            }
        }

        //Clear color and depth buffer, and reset the screen
        glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
        glMatrixMode(GL_MODELVIEW);
        glLoadIdentity();

        //Display
        App.display();
    }

    return 0;
}
 

30
Graphics / Re: OpenGL - Screenshots always magenta
« on: May 27, 2012, 12:25:06 pm »
Okay!  So, the good news is, I've migrated to SFML 2.0 and the code all works!  Most of the changes just involved decapitalizing the initial letter of each method/function, although I did have to make an sf::Clock...

The bad news is that the screenshots are still pink.  Hm.  I'll see if I can make something small and self-contained.

Pages: 1 [2] 3 4