-
Here is code:
/* virtual */ void Info::draw(sf::RenderTarget& target, sf::RenderStates states) const
{
SIMPLE_LOCK
if (!mVisible || !mIsInitiated)
{
return;
}
sf::View old = target.getView();
target.setView(mView);
target.draw(mDrawText, states);
target.setView(old);
}
About one hour ago text was on the screeen, after little refactoring - no text drawed. Target is active, GLstate reseted... Is there any simple reason for such behavior?
Solved: Use sf::InputStream with care!
-
It could be anything. Only you knows what you changed during that hour. It can't be that much, right? So revert your changes step by step and you should find the error ;)
-
Yes, i reverted all changes (as i think), and i left only this object in render queue... Nothing on screen. May be sf::View is wrong? It is created by this code:
void Info::RecalcView(int x, int y)
{
mScreenSize.x = (float) x;
mScreenSize.y = (float) y;
mView.reset(sf::FloatRect(0.0f, 0.0f, mScreenSize.x, mScreenSize.y));
}
All is looking good, but m_inverseTransform is equal to m_transform. They both are the identity matrixes. Is it correct?
-
Obviously, you can't have reverted everything, if it worked before and doesn't work anymore now. Don't you use a versioning system? That's one of the huge advantages: You can roll back at any time, where stuff still works.
The view looks good. You have to debug further, or if you want us to see the error, reduce the code until you have a minimal and complete example (http://en.sfml-dev.org/forums/index.php?topic=5559.msg36368#msg36368), otherwise we can only guess.
By the way, what is SIMPLE_LOCK? It looks dangerous ???
-
Are you sure your "return;" isn't executed?
-
Yes, i use Bitbucket and have Mercurial repo. This is very simple class to show debug (mostly) info without SFGUI. So i did the class, the text has been drawn. Source code was not committed to repository because of simplicity of class. =) Then i made some changes... :o
Are you sure your "return;" isn't executed?
Yes, i'm sure.
-
By the way, what is SIMPLE_LOCK? It looks dangerous ???
It is macro where can be mutex lock. It is empty now.
-
otherwise we can only guess.
Yep, i will continue to guess too. =)
-
Well, if i initialising font before main loop, and if i creating sf::Text with some text - font will be created. But only will be available letters from previously defined sf::Text.
This code is before main loop:
sf::Font* font = RES_MGR.InstantGetFont("sansation.ttf");
sf::Text text("123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ", *font);
Without both of these lines - no text displayed... :o
Font is loaded via loadFromStream function. Is this function loads entire font?
-
Well, yes, here it is:
Common mistakes
Some resource classes are not loaded completely after loadFromStream has been called. Instead, they continue to read from their data source as long as they are used. This is the case for sf::Music, which streams audio samples as they are played, and for sf::Font, which loads glyphs on the fly depending on the texts content.
I have to rewrite my resource manager... :'( He was so cute.
And now i understand why i'm taking a rare crash with one texture. =)
-
I have to rewrite my resource manager... :'( He was so cute.
You can also use an existing one, such as thor::ResourceCache (http://www.bromeon.ch/libraries/thor/v2.0/doc/classthor_1_1_resource_cache.html) ;)
-
Yes, thank you, looks almost as my manager, but i tried to not use smart pointers. Now i'm ready to think that smart pointers are the best solution for Resource Manager.
-
Note that std::shared_ptr which I use is only appropriate if you have true shared ownership, i.e. the manager/cache does not store the resources. Instead, the resources live (at least) as long as they are being referred to. Every user of a resource keeps a shared pointer to it.
For simpler cases, you might just have a centralized class that stores the resources and ensures their lifetime. You can then give away raw pointers to resources, since they are not owning.
-
For simpler cases, you might just have a centralized class that stores the resources and ensures their lifetime. You can then give away raw pointers to resources, since they are not owning.
I have the same now. Font problem was solved with a simple stream manager. By the way, how about to add sf::InputStream flag, or callback, that data was readed fully?