Sprites only drawn once

[RaptorIV]

I wrote a Render handler that draws a sf::Drawable* at certain depths. For some reason if a sprite using the same image as another sprite is in the handler only the first sprite inserted is drawn. Is there anything useful that is not common knowlegdge about sf::Image or sf::Sprite that would stop me from casting them as a Drawable that might cause this?

We have our project up at github, here is the Renderer cpp
https://github.com/b3ngr33ni3r/Magnet/blob/master/OurGame/Renderer.cpp

[Groogy]

Impossible to know. We can't read your entire code base to find the problem. But as far as I saw I couldn't see you handle anything per-image specific so don't know.

Are you sure that the next sprites are inserted? Have you even tried doing it with several different sprites that have different textures? Is it specific to a per-image basis?

Also how are they "not drawn"? Not drawn at all, or white without texture(try setting their texture rect so they don't only become a white dot)

What SFML are you running with? What card are you running it on? Do you experience the behaviour in release or debug mode?

On a side note: Your code is a bit hard to read because of the code convention your writing with and because of your love to overcomplicated solutions. My renderer that takes depth into account is much simpler. And it's even multi-threaded.

[RaptorIV]

All the objects are accounted for in the renderer, 20 objects inserted, Window()->Draw() is called 20 times. The sprites aren't even white dots some just do not appear at all.

Running SFML 1.6 on GTX 560ti in debug mode.

On a side note: Your code is a bit hard to read because of the code convention your writing with and because of your love to overcomplicated solutions. My renderer that takes depth into account is much simpler. And it's even multi-threaded.

Was this really necessary? I'm glad your renderer is superior to mine, congratulations.

Edit:

Relevant Files:
https://github.com/b3ngr33ni3r/Magnet/blob/master/OurGame/Renderer.h
https://github.com/b3ngr33ni3r/Magnet/blob/master/OurGame/Renderer.cpp
https://github.com/b3ngr33ni3r/Magnet/blob/master/OurGame/ImageHandler.h
https://github.com/b3ngr33ni3r/Magnet/blob/master/OurGame/ImageHandler.cpp

[Groogy]

Was this really necessary? I'm glad your renderer is superior to mine, congratulations.

Yes it was. And no it is not superior. There was a point behind it which you probably would have seen if you wouldn't have gone on the defensive.

If something is difficult to understand just by reading the code, then solving any problems in it will get near impossible.Especially for an outsider. My point was more or less that the code should be refactored.

Now,you are running on 1.6 and I am not aware if there are any known bugs related to this. I don't remember any.

What I would do in your case is that I would simplify the problem area till we got a failsafe base line to test against. To simplify the code just remove functionality. (layers, depth, etc)
When it works we add it all back one by one till we find what actually broke it. Do it in atomic steps. The smaller the better.

[RaptorIV]

I've stripped it down to only the object_map. I've also changed the sf::Drawable* argument to sf::Sprite. The error is still happening.

I am outputting the memory location of the image, then after I create the sprite and pass it to the Renderer I output the memory location of Sprite->GetImage();

The locations are matching for most entries but some will be 0, and I have no idea why. They are all inserted in the same manner.

Here is where the image/sprites are created (at line 30)
https://github.com/b3ngr33ni3r/Magnet/blob/master/OurGame/Main.cpp

Here is where they are added & drawn (line 120 and 92 respectively)
https://github.com/b3ngr33ni3r/Magnet/blob/master/OurGame/Renderer.cpp

[Groogy]

Hmmm it almost sounds like if the sf::Image is destroyed somehow. But that wouldn't make sense.

Can you try and track down exactly where the image "disappear" from the sprites? If your on VS10 then the debugger there is great to follow the code flow. Otherwise just put out more output sections. Also I recommend you had something like a section label(name of function or just a number) before outputting any information. It's easier then to decipher from where it came.

One last thing, can you just give a quick try without the renderer at all? Just plain old draw calls.

[RaptorIV]

So it appears that that data is lost (apparently randomly)  when I convert an &sf::Sprite to an sf::Drawable*, when I changed it to just render sf::Sprite references it works fine, but when I convert to Drawable it only draws  the Sprite once.

[nitrix]

It's generally not good practice to cast a child class to its parent class. Most of the time the child inherits of some virtual functions and overwrite them to implement them further more.

That is, your compiler will find the appropriate functions related the pointer type you're working with.

In my opinion, if you cast anything to another type, it's because you're more interested into the new type capabilities than your current ones. Why would you work with a Drawable when Sprite provides everything Drawable does + beyond?

[RaptorIV]

Hmmm it almost sounds like if the sf::Image is destroyed somehow. But that wouldn't make sense.

I rewrote much of the Renderer. I know have a LinkableObject that inherits from sf::Sprite to add layer and depth data to the sprite. The sf::Sprite.GetImage() always returns a valid memory location, but the same drawing problem is still occurring.

I am using a reinterpret_cast to cast a sf::Sprite to a LinkableObject

Here are the relevant files and locations:
Renderer.cpp line 30
https://github.com/b3ngr33ni3r/Magnet/blob/master/OurGame/Renderer.cpp
LinkableObject.h
https://github.com/b3ngr33ni3r/Magnet/blob/master/OurGame/Handler/Renderer/LinkableObject.h

One last thing, can you just give a quick try without the renderer at all? Just plain old draw calls.

[lezebulon]

i'm not sure that it's legal to downcast using reinterpret_cast, since you have no guarantee that the members of the derived class are placed at the same memory location as the members of sf::sprite, usually people use dynamic_cast on pointers to do this
I also don't really see why you need to derive SFML classes when you could just encapsulate them in your object

edit : you should check
std::cout << "In link: " << object.GetImage() << "\n";
instead of
std::cout << "In link: " << sprite.GetImage() << "\n";
the second time, it's possible that the memory location is different