Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Overriding sf::Drawable::draw  (Read 17191 times)

0 Members and 2 Guests are viewing this topic.

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6287
  • Thor Developer
    • View Profile
    • Bromeon
Re: Overriding sf::Drawable::draw
« Reply #30 on: October 27, 2015, 11:03:24 pm »
Strange. I did it like I said, first made everything up, then called spr.setTexture(); and from then on never touched any vector or whole object. Still didn't worked.
You could use a debugger to check whether the addresses of the sf::Texture objects change, and if they do, where this happens.

You could also declare a vector of non-copyable but movable objects (e.g. std::vector<std::unique_ptr<int>>) in the same place, and see whether a compiler error resulting from a copy attempt occurs.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Skorpion

  • Newbie
  • *
  • Posts: 28
    • View Profile
Re: Overriding sf::Drawable::draw
« Reply #31 on: October 28, 2015, 09:12:22 pm »
Now I'm like John Snow; I know nothing.

I was tired of keeping trying to make that code work. As I wrote yesterday, I've made some changes and compiled the project. Once again I saw white squares and as I had a hard day I haven't time to write code. Today I entered the forum, saw your post and tought "Great idea, let's see how it works!". So I, making no changes from yesterday, debugged code and started a "new game". Everything was set up in it's place, displayed fullly properly. I have no idea why it didn't worked yesterday  :o

All in all thank you all for your time you spended here reading my sh*tty code and trying to help me. Now I know more about SFML and object oriented programing in C++. Thakns to you I started reading some more materials about both and I find it really helpful so far.

The solution to the problem for all that could look for this in the future:
1. Ensure that you don't move your Texture objects in memory after calling sprite.setTexture(texture);.
2. If you do you can do two things:
    a) change the code to don't move the Texture
    b) change the code to call sprite.setTexture(texture); always right after moving the Texture

In my opinion the case is closed, if I had some problems with it in the future I'll probably be able to handle with it on my own (thanks to you ofc ;)).

You guys are awesome! Thank you once again for what you did for me, for your patience and nerves :)

Best regards,
Skorpion

 

anything