Messages

1

General / Re: Dynamic linking to SFML (github master branch) under Ubuntu 16.04 fails

« on: February 17, 2017, 02:03:11 pm »

I ended up grabbing g++-6 and using it to build SFML and my test project, that seems to work.

2

General / Re: Dynamic linking to SFML (github master branch) under Ubuntu 16.04 fails

« on: February 16, 2017, 10:34:36 pm »

This is still an issue with fresh Ubuntu 16.04.4, gcc 5.4.0, fresh clone of SFML. Error I get when running compiled example now is:

/usr/bin/ld: a.out: hidden symbol `__cpu_model' in /usr/lib/gcc/x86_64-linux-gnu/5/libgcc.a(cpuinfo.o) is referenced by DSO
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status

Is there any fix for this? The CMakeLists.txt file no longer has the lines the aforementioned patch affects.

3

General / Re: Drawing Sprites to the Window

« on: May 05, 2016, 09:43:05 pm »

Thanks for the help. Where did you come up with the name Selba Ward?

4

General / Re: How can I stop my sprite from continuously to the right?

« on: May 04, 2016, 02:11:18 pm »

Do you ever reset your velocity.x to 0?

Maybe this was too subtle..  But yeah, you need to set your velocity to 0 in your main loop however you want to do it, before your isKeyPressed code.

5

General / Re: How can I stop my sprite from continuously to the right?

« on: May 03, 2016, 10:16:21 pm »

Do you ever reset your velocity.x to 0?

6

General / Drawing Sprites to the Window

« on: May 03, 2016, 10:09:28 pm »

When drawing to the window, my application runs fine (at 60fps is what I'd like) with small window/view sizes. When I increase view size to show more of the drawn map, it then starts to slow. Large window, small map size helps a little bit. I'd like to bounce my design choices off the community here, if that's OK.

Here's the flow of the program:

• Load textures that we'll need (only 6 different textures for now) into std::vector<sf::Texture>.
• Pull data from a .csv file, 0 is empty space, not 0 is a wall, where {1,2,3,...} specify texture/sprite. I'm drawing a bunch of 10x10px "blocks" on a 10x10 grid.
• Store map_data in std::vector<std::vector<int>>.
• Loop through map_data, drawing by creating a sprite for each block from the &loaded_textures, setting it's position, then drawing. Return std::vector<sf::FloatRect> of all bounding boxes.

Having run gprof, I'm seeing a lot of time spent in that final point there, mainly creating the sf::Sprite and drawing, which can be seen below. I've tried creating a std::vector<sf::Sprite> to pull from in the same manner as I'm pulling from needed_textures right now, but didn't see any speed increase. Map size is 35x29 right now, so say ~500 10x10px sprites are being drawn per frame.

sf::FloatRect drawBlock(std::vector<sf::Texture> &needed_textures, int block_type, int left, int top, sf::RenderWindow &window)
{
    sf::Sprite block_sprite;

    block_sprite.setTexture(needed_textures.at(block_type - 1));

    block_sprite.setPosition(left, top);
    window.draw(block_sprite);

    return block_sprite.getGlobalBounds();
}