Messages

1

General / Re: When creating a tile map, sprites do not always texture properly

« on: May 09, 2013, 08:32:27 pm »

The same as operator<, it is used to compare different values. The priority queue must reorder the elements according to their priority values. See here for example.

By the way, there is no need for a full quote if the text is just above

Understood. Thanks.

2

General / Re: When creating a tile map, sprites do not always texture properly

« on: May 09, 2013, 08:02:54 pm »

Why does overriding the () operator work?

Because the C++ standard allows it

Overriding the function call operator is the basic idea of functors (function objects). This allows very powerful constructs like std::function in C++11.

No, I mean, what does the () operator do in the std::priority_queue? I'm learning something new here.

3

General / Re: When creating a tile map, sprites do not always texture properly

« on: May 09, 2013, 07:57:08 pm »

In general, declare binary operators as non-member functions. This treats the two operands symmetrically and allows implicit conversions of both.

bool operator< (const TileSet& lhs, const TileSet& rhs)
{
    return lhs.gid < rhs.gid;
}

If the operator< is not meaningful in other contexts, you can also define a predicate functor:

struct CompareTileSet
{
    bool operator() (const TileSet& lhs, const TileSet& rhs)
    {
        return lhs.gid < rhs.gid;
    }
};

std::priority_queue<TileSet, std::vector<TileSet>, CompareTileSet> queue;

Why does overriding the () operator work?

4

General / Re: When creating a tile map, sprites do not always texture properly

« on: May 09, 2013, 12:12:07 am »

What was the problem in the end?

Loading TMX requires that you provide information for the tiles, provided in the tilesets in the .tmx file. I was loading the tileset information into a priority queue, which held a custom Object::TileSet class, and had overrode the < operator to compare gid's. However, I put pointers of the Object::TileSet into priority queue, so it was comparing the memory of the pointers, not the gid.

To solve the problem, I just stored references to the Object::TileSet's in the queue and continued on my merry way.

Like I said, not a SFML problem, and probably not helpful to anybody in the future, so this thread can be deleted.

This is what the TileSet looks like now, I changed the operator override from

bool operator<(const TileSet &b)

to

bool operator<(const TileSet &b) const

        namespace Object
        {
                struct TileSet
                {
                        // ctor, dtor...

                        virtual ~TileSet(){}

                        bool operator<(const TileSet &b) const
                        {
                                return this->gid > b.gid;
                        }

                        sf::Texture* texture;
                        int gid, spacing, height, width;
                };
        }
 

Then I changed the priority queue from

std::priority_queue<Object::TileSet*> tileset_queue;

to

std::priority_queue<Object::TileSet> tileset_queue;

5

General / Re: When creating a tile map, sprites do not always texture properly

« on: May 08, 2013, 12:59:58 am »

Found the problem. It is of no importance to SFML, and I would request that this thread be removed.

6

General / Re: AW: When creating a tile map, sprites do not always texture properly

« on: May 07, 2013, 07:36:35 pm »

We won't dig in your code and debug it for you, so at best you should do it on your own.
If manage it to narrow down to a minimal and complete example, we might look into it.

Understood. I'm looking into it.

7

General / When creating a tile map, sprites do not always texture properly

« on: May 07, 2013, 03:28:33 pm »

So, as the title says, I'm making a tile map loader (using the Tiled format).





The images show 2 instances of the program loading the map. One, the tiles are fine. Another, the tiles are blacked out, but only on one layer. I first thought that this was a problem with the vector in which I store my tiles, but its not. The hex values are pointers to the sf::Textures that I have loaded in my texture manager. You're wondering, well if it works in one instance, then why are you here? The images are the same program. I was stress testing my program; loading the map over and over and noticed this problem. Sometimes it works, sometimes it doesn't. I'm baffled. The textures are fine, cuz the memory is the same. The vector should be reserved correctly, but I'm not sure. The tile id's are the same every single time I load. I'm trusting that SFML is fine, unless I discovered some issue.

Here is my map parsing code. I use RapidXML to parse the .tmx file.

      bool MapManager::parseData(const std::string& src)
      {
         try
         {
            rapidxml::xml_node<> *node_root = m_document->first_node("map"), *node_layer = node_root->first_node("layer"),
               *node_data = 0;

            std::string encoding = "", compression = "";

            for(; node_layer; node_layer = node_layer->next_sibling("layer"))
            {
               std::deque<unsigned> split;
               node_data = node_layer->first_node("data");

               if(node_data->first_attribute("encoding"))
               {
                  encoding = node_data->first_attribute("encoding")->value();
                  if(encoding == "csv")
                  {
                     split = m_parse_csv(node_data->value());
                  }
                  else if(encoding == "base64")
                  {
                     if(node_data->first_attribute("compression"))
                     {
                        if((compression = node_data->first_attribute("compression")->value()) == "zlib")
                        {
                           split = m_parse_zb64(node_data->value());
                        }
                        else
                        {
                           split = m_parse_b64(node_data->value());
                        }
                     }
                  }
                  else
                  {
                     return false;
                  }

                  for(int y = 0; y < m_height; y++)
                  {
                     for(int x = 0; x < m_width; x++)
                     {
                        int id = split.front();
                        be::Object::TileSet* t = m_decide_tileset(id);

                        if(id != 0 && t && !split.empty())
                        {
                           sf::Vector2i pos(x, y), size(t->width, t->height);
                           sf::IntRect text_split = m_decide_texture_split(id, t);

                           m_tile_map.push_back(new be::Object::Tile(id, pos, size, text_split, t->texture));
                        }

                        split.pop_front();
                     }
                  }
               }
            }
         }
         catch(const rapidxml::parse_error &e)
         {
            return false;
         }

         return true;
      }

Here is what I use to load textures.

      sf::Texture* TextureManager::getTexture(const std::string& src)
      {
         for(auto i = m_textures.begin(); i != m_textures.end(); i++)
         {
            if(i->first == src)
            {
               std::cout << i->second << std::endl;
               return i->second;
            }
         }

         sf::Texture* t = new sf::Texture;

         if(t->loadFromFile(src))
         {
            std::cout << "Loading a new texture: " << src << std::endl;
            m_textures[src] = t;
            return t;
         }
         else
         {
            delete t;
            return 0;
         }
      }

I won't post more code unless needed to save everyone a headache. I got an itch that this is where the issue lies.

Tiled documentation: https://github.com/bjorn/tiled/wiki/TMX-Map-Format

8

General / Re: Why can't I use static libs for SFML on Linux?

« on: April 07, 2013, 11:22:42 pm »

Okay, thank you! Btw statically linking isn't useful in my situation, I was just curious as to why it wasn't working. 

9

General / Why can't I use static libs for SFML on Linux?

« on: April 07, 2013, 11:00:04 pm »

When trying to link the SFML libraries statically on Ubuntu, I get the following errors:

/home/wuser/Development/SFML/lib/libsfml-graphics-s-d.a(RenderWindow.cpp.o)||In function `sf::RenderWindow::capture() const':|
/home/wuser/Development/SFML/src/SFML/Graphics/RenderWindow.cpp|92|undefined reference to `glReadPixels'|
/home/wuser/Development/SFML/lib/libsfml-graphics-s-d.a(GLCheck.cpp.o)||In function `sf::priv::glCheckError(char const*, unsigned int)':|
/home/wuser/Development/SFML/src/SFML/Graphics/GLCheck.cpp|40|undefined reference to `glGetError'|
/home/wuser/Development/SFML/lib/libsfml-graphics-s-d.a(GLCheck.cpp.o)||In function `sf::priv::ensureGlewInit()':|
/home/wuser/Development/SFML/src/SFML/Graphics/GLCheck.cpp|116|undefined reference to `glewInit'|
/home/wuser/Development/SFML/src/SFML/Graphics/GLCheck.cpp|123|undefined reference to `glewGetErrorString'|
/home/wuser/Development/SFML/lib/libsfml-graphics-s-d.a(ImageLoader.cpp.o)||In function `sf::priv::ImageLoader::writeJpg(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::vector<unsigned char, std::allocator<unsigned char> > const&, unsigned int, unsigned int)':|
/home/wuser/Development/SFML/src/SFML/Graphics/ImageLoader.cpp|274|undefined reference to `jpeg_std_error'|
/home/wuser/Development/SFML/src/SFML/Graphics/ImageLoader.cpp|277|undefined reference to `jpeg_CreateCompress'|
/home/wuser/Development/SFML/src/SFML/Graphics/ImageLoader.cpp|282|undefined reference to `jpeg_stdio_dest'|
/home/wuser/Development/SFML/src/SFML/Graphics/ImageLoader.cpp|283|undefined reference to `jpeg_set_defaults'|
/home/wuser/Development/SFML/src/SFML/Graphics/ImageLoader.cpp|284|undefined reference to `jpeg_set_quality'|
/home/wuser/Development/SFML/src/SFML/Graphics/ImageLoader.cpp|297|undefined reference to `jpeg_start_compress'|
/home/wuser/Development/SFML/src/SFML/Graphics/ImageLoader.cpp|303|undefined reference to `jpeg_write_scanlines'|
/home/wuser/Development/SFML/src/SFML/Graphics/ImageLoader.cpp|307|undefined reference to `jpeg_finish_compress'|
/home/wuser/Development/SFML/src/SFML/Graphics/ImageLoader.cpp|308|undefined reference to `jpeg_destroy_compress'|
/home/wuser/Development/SFML/lib/libsfml-graphics-s-d.a(RenderTarget.cpp.o)||In function `sf::RenderTarget::clear(sf::Color const&)':|
/home/wuser/Development/SFML/src/SFML/Graphics/RenderTarget.cpp|60|undefined reference to `glClearColor'|
/home/wuser/Development/SFML/src/SFML/Graphics/RenderTarget.cpp|61|undefined reference to `glClear'|
/home/wuser/Development/SFML/lib/libsfml-graphics-s-d.a(RenderTarget.cpp.o)||In function `sf::RenderTarget::draw(sf::Vertex const*, unsigned int, sf::PrimitiveType, sf::RenderStates const&)':|
/home/wuser/Development/SFML/src/SFML/Graphics/RenderTarget.cpp|217|undefined reference to `glVertexPointer'|
/home/wuser/Development/SFML/src/SFML/Graphics/RenderTarget.cpp|218|undefined reference to `glColorPointer'|
/home/wuser/Development/SFML/src/SFML/Graphics/RenderTarget.cpp|219|undefined reference to `glTexCoordPointer'|
/home/wuser/Development/SFML/src/SFML/Graphics/RenderTarget.cpp|228|undefined reference to `glDrawArrays'|
/home/wuser/Development/SFML/lib/libsfml-graphics-s-d.a(RenderTarget.cpp.o)||In function `sf::RenderTarget::pushGLStates()':|
/home/wuser/Development/SFML/src/SFML/Graphics/RenderTarget.cpp|245|undefined reference to `glPushClientAttrib'|
/home/wuser/Development/SFML/src/SFML/Graphics/RenderTarget.cpp|246|undefined reference to `glPushAttrib'|
/home/wuser/Development/SFML/src/SFML/Graphics/RenderTarget.cpp|247|undefined reference to `glMatrixMode'|
/home/wuser/Development/SFML/src/SFML/Graphics/RenderTarget.cpp|248|undefined reference to `glPushMatrix'|
/home/wuser/Development/SFML/src/SFML/Graphics/RenderTarget.cpp|249|undefined reference to `glMatrixMode'|
/home/wuser/Development/SFML/src/SFML/Graphics/RenderTarget.cpp|250|undefined reference to `glPushMatrix'|
/home/wuser/Development/SFML/src/SFML/Graphics/RenderTarget.cpp|251|undefined reference to `glMatrixMode'|
/home/wuser/Development/SFML/src/SFML/Graphics/RenderTarget.cpp|252|undefined reference to `glPushMatrix'|
/home/wuser/Development/SFML/lib/libsfml-graphics-s-d.a(RenderTarget.cpp.o)||In function `sf::RenderTarget::popGLStates()':|
/home/wuser/Development/SFML/src/SFML/Graphics/RenderTarget.cpp|264|undefined reference to `glMatrixMode'|
/home/wuser/Development/SFML/src/SFML/Graphics/RenderTarget.cpp|265|undefined reference to `glPopMatrix'|
/home/wuser/Development/SFML/src/SFML/Graphics/RenderTarget.cpp|266|undefined reference to `glMatrixMode'|
/home/wuser/Development/SFML/src/SFML/Graphics/RenderTarget.cpp|267|undefined reference to `glPopMatrix'|
/home/wuser/Development/SFML/src/SFML/Graphics/RenderTarget.cpp|268|undefined reference to `glMatrixMode'|
/home/wuser/Development/SFML/src/SFML/Graphics/RenderTarget.cpp|269|undefined reference to `glPopMatrix'|
/home/wuser/Development/SFML/src/SFML/Graphics/RenderTarget.cpp|270|undefined reference to `glPopClientAttrib'|
/home/wuser/Development/SFML/src/SFML/Graphics/RenderTarget.cpp|271|undefined reference to `glPopAttrib'|
/home/wuser/Development/SFML/lib/libsfml-graphics-s-d.a(RenderTarget.cpp.o)||In function `sf::RenderTarget::resetGLStates()':|
/home/wuser/Development/SFML/src/SFML/Graphics/RenderTarget.cpp|285|undefined reference to `glDisable'|
/home/wuser/Development/SFML/src/SFML/Graphics/RenderTarget.cpp|286|undefined reference to `glDisable'|
/home/wuser/Development/SFML/src/SFML/Graphics/RenderTarget.cpp|287|undefined reference to `glDisable'|
/home/wuser/Development/SFML/src/SFML/Graphics/RenderTarget.cpp|288|undefined reference to `glDisable'|
/home/wuser/Development/SFML/src/SFML/Graphics/RenderTarget.cpp|289|undefined reference to `glEnable'|
/home/wuser/Development/SFML/src/SFML/Graphics/RenderTarget.cpp|290|undefined reference to `glEnable'|
/home/wuser/Development/SFML/src/SFML/Graphics/RenderTarget.cpp|291|undefined reference to `glMatrixMode'|
/home/wuser/Development/SFML/src/SFML/Graphics/RenderTarget.cpp|292|undefined reference to `glEnableClientState'|
/home/wuser/Development/SFML/src/SFML/Graphics/RenderTarget.cpp|293|undefined reference to `glEnableClientState'|
/home/wuser/Development/SFML/src/SFML/Graphics/RenderTarget.cpp|294|undefined reference to `glEnableClientState'|
/home/wuser/Development/SFML/lib/libsfml-graphics-s-d.a(RenderTarget.cpp.o)||In function `sf::RenderTarget::applyCurrentView()':|
/home/wuser/Development/SFML/src/SFML/Graphics/RenderTarget.cpp|329|undefined reference to `glViewport'|
/home/wuser/Development/SFML/src/SFML/Graphics/RenderTarget.cpp|332|undefined reference to `glMatrixMode'|
/home/wuser/Development/SFML/src/SFML/Graphics/RenderTarget.cpp|333|undefined reference to `glLoadMatrixf'|
/home/wuser/Development/SFML/src/SFML/Graphics/RenderTarget.cpp|336|undefined reference to `glMatrixMode'|
/home/wuser/Development/SFML/lib/libsfml-graphics-s-d.a(RenderTarget.cpp.o)||In function `sf::RenderTarget::applyBlendMode(sf::BlendMode)':|
/home/wuser/Development/SFML/src/SFML/Graphics/RenderTarget.cpp|353|undefined reference to `__GLEW_EXT_blend_func_separate'|
||More errors follow but not being shown.|
||Edit the max errors limit in compiler options...|
||=== Build finished: 50 errors, 0 warnings ===|

This is not a problem, as I can link dynamically, but why can't I link statically? It looks like a problem with OpenGL.

10

General discussions / Just wanted to say

« on: February 28, 2013, 08:23:50 pm »

Thanks, Laurent! SFML is a great library and we all appreciate the work you do! 

11

Window / Way to check for window focus?

« on: November 14, 2012, 03:37:08 pm »

I currently use the sf::Keyboard::isKeyPressed() function to check for input, because if I use window events, I can't handle multiple key presses.

However, using this makes it so input is recognized, even if I don't have window focus. Is there a way to check if my window has focus?