SFML community forums

Help => Graphics => Topic started by: Reborn121 on December 09, 2014, 02:45:39 am

Title: Window.draw() no longer working after SFML Update
Post by: Reborn121 on December 09, 2014, 02:45:39 am
So I was, in another thread told to update my SFML to the source version. Upon doing so it fixed my problem, but now most of my classes that use SFML are broken. Here is one of the classes that is not working, I'm getting an
Code: [Select]
Unhandled exception at 0x00000000 in SFML2D.exe: 0xC0000005: Access violation reading location 0x00000000. on the
Code: [Select]
window.draw(m_Sprite);
Here is the section containing the code:
                        case Animation::FadeIn:
                                m_Alpha = 0;
                                m_Sprite.setColor(sf::Color(255, 255, 255, m_Alpha));
                                while (isAnimating)
                                {
                                        window.clear();
                                        window.draw(m_Sprite);
                                        window.display();
                                        if (loopIndex == 1)
                                        {
                                                if (m_Clock.getElapsedTime() > sf::seconds(m_InitTime))
                                                {
                                                        ++i;
                                                        m_Sprite.setColor(sf::Color(255, 255, 255, m_Alpha));
                                                        window.draw(m_Sprite);
                                                        ++loopIndex;
                                                        !isAnimating;
                                                        return;
                                                }
                                        }
                                        else if (loopIndex == 0)
                                        {
                                                if (m_Clock.getElapsedTime() > sf::milliseconds(i*m_Time))
                                                {
                                                        ++i;
                                                        m_Sprite.setColor(sf::Color(255, 255, 255, m_Alpha));
                                                        window.draw(m_Sprite);
                                                        ++m_Alpha;
                                                        if (m_Alpha > 255)
                                                        {
                                                                ++loopIndex;
                                                        }
                                                }
                                        }
                                }
                        break;
 

and this following part is my constructor (I do have a default constructor, but it does nothing and requires a create() or setSomeAttr() call, which basicly does what the following constructor does.):

        Splash::Splash(sf::Texture Texture, int InitTime, int Time)
        {
                m_Texture = Texture;
                m_Sprite.setTexture(m_Texture);
                m_InitTime = InitTime;
                m_Time = Time;
        }
 

EDIT::
I didn't change anything, but it seems that the problem is now the
virtual void draw(sf::RenderTarget &target, sf::RenderStates states) const
function, that makes something drawable in sfml. This is the only line I have in there:
target.draw(m_Sprite, states);

Helpful Info:
- OS: Windows XP 32-bit
- Compiler: Visual C++ 2010 Express
- SFML Version: Built from latest source as of December 9th.
- SFML Link Type: Dynamic
Title: Re: Window.draw() no longer working after SFML Update
Post by: Hiura on December 09, 2014, 11:22:14 am
Please consider this message ( http://en.sfml-dev.org/forums/index.php?topic=5559.msg36368#msg36368 ) if you want a proper help.
Title: Re: Window.draw() no longer working after SFML Update
Post by: Hapax on December 09, 2014, 12:39:57 pm
Although I cannot answer your question, I am curious as to what this line of code is supposed to do:
                                                        !isAnimating;
Title: Re: Window.draw() no longer working after SFML Update
Post by: Stauricus on December 09, 2014, 12:52:46 pm
which are the versions you moved from e to?
and did you completely rebuild your code?
Title: Re: Window.draw() no longer working after SFML Update
Post by: Reborn121 on December 09, 2014, 01:45:02 pm
Please consider this message ( http://en.sfml-dev.org/forums/index.php?topic=5559.msg36368#msg36368 ) if you want a proper help.

Okay, thank you, I will update the post when I have time.

Although I cannot answer your question, I am curious as to what this line of code is supposed to do:
                                                        !isAnimating;

It actually does nothing, this project is more so on the old side, I was misinformed and told that that line should change the boolean value to whatever it isn't i.e. if it is true, make it false. I forgot to change that line when updating the code.

which are the versions you moved from e to?
and did you completely rebuild your code?

Sorry, I moved from the latest stable build, not sure the version number, to the latest source code update. Git says it was updated about 21 days ago, so whatever version that is. Yes I completely rebuilt the project, I did change it from linking statically to dynamically after the update though.

Other stuff that might help:
- OS: Windows XP 32-bit
- Compiler: Visual C++ 2010 32-bit
- SFML was built from latest source.
Title: Re: Window.draw() no longer working after SFML Update
Post by: eXpl0it3r on December 09, 2014, 01:58:43 pm
Did you update your DLLs as well?

I was misinformed and told that that line should change the boolean value to whatever it isn't i.e. if it is true, make it false. I forgot to change that line when updating the code.
That would work like this:
isAnimating = !isAnimating;
Title: Re: Window.draw() no longer working after SFML Update
Post by: Reborn121 on December 09, 2014, 02:02:09 pm
Did you update your DLLs as well?

If you mean did I put the sfml-graphics-2.dll and the rest of those from the cmake build into my project folder, yes.
Title: Re: Window.draw() no longer working after SFML Update
Post by: Reborn121 on December 09, 2014, 07:29:24 pm
Okay, I've decided to look at this from a different perspective. I tried to statically link, I linked to all SFML libs, and all it's included dependencies. Everything seems to be working except I'm getting errors saying there are things defined in two or more different libs, below is the actual full build output. It's pretty repetitive though.

Code: [Select]
msvcprt.lib(MSVCP100.dll) : error LNK2005: "public: void __thiscall std::_Container_base0::_Orphan_all(void)" (?_Orphan_all@_Container_base0@std@@QAEXXZ) already defined in sfml-graphics-s.lib(RenderWindow.obj)
msvcprt.lib(MSVCP100.dll) : error LNK2005: "public: class std::locale::facet * __thiscall std::locale::facet::_Decref(void)" (?_Decref@facet@locale@std@@QAEPAV123@XZ) already defined in sfml-graphics-s.lib(Texture.obj)
msvcprt.lib(MSVCP100.dll) : error LNK2005: "public: void __thiscall std::locale::facet::_Incref(void)" (?_Incref@facet@locale@std@@QAEXXZ) already defined in sfml-graphics-s.lib(Texture.obj)
libcpmt.lib(locale0.obj) : error LNK2005: "private: static void __cdecl std::locale::facet::_Facet_Register(class std::locale::facet *)" (?_Facet_Register@facet@locale@std@@CAXPAV123@@Z) already defined in msvcprt.lib(locale0_implib.obj)
libcpmt.lib(locale0.obj) : error LNK2005: "private: static class std::locale::_Locimp * __cdecl std::locale::_Getgloballocale(void)" (?_Getgloballocale@locale@std@@CAPAV_Locimp@12@XZ) already defined in msvcprt.lib(MSVCP100.dll)
libcpmt.lib(locale0.obj) : error LNK2005: "public: static void __cdecl std::_Locinfo::_Locinfo_dtor(class std::_Locinfo *)" (?_Locinfo_dtor@_Locinfo@std@@SAXPAV12@@Z) already defined in msvcprt.lib(MSVCP100.dll)
libcpmt.lib(locale0.obj) : error LNK2005: "public: static void __cdecl std::_Locinfo::_Locinfo_ctor(class std::_Locinfo *,char const *)" (?_Locinfo_ctor@_Locinfo@std@@SAXPAV12@PBD@Z) already defined in msvcprt.lib(MSVCP100.dll)
libcpmt.lib(locale0.obj) : error LNK2005: "private: static class std::locale::_Locimp * __cdecl std::locale::_Init(void)" (?_Init@locale@std@@CAPAV_Locimp@12@XZ) already defined in msvcprt.lib(MSVCP100.dll)
libcpmt.lib(ios.obj) : error LNK2005: "public: static void __cdecl std::ios_base::_Addstd(class std::ios_base *)" (?_Addstd@ios_base@std@@SAXPAV12@@Z) already defined in msvcprt.lib(MSVCP100.dll)
libcpmt.lib(ios.obj) : error LNK2005: "private: static void __cdecl std::ios_base::_Ios_base_dtor(class std::ios_base *)" (?_Ios_base_dtor@ios_base@std@@CAXPAV12@@Z) already defined in msvcprt.lib(MSVCP100.dll)
libcpmt.lib(xlock.obj) : error LNK2005: "public: __thiscall std::_Lockit::_Lockit(int)" (??0_Lockit@std@@QAE@H@Z) already defined in msvcprt.lib(MSVCP100.dll)
libcpmt.lib(xlock.obj) : error LNK2005: "public: __thiscall std::_Lockit::~_Lockit(void)" (??1_Lockit@std@@QAE@XZ) already defined in msvcprt.lib(MSVCP100.dll)
LIBCMT.lib(setlocal.obj) : error LNK2005: __configthreadlocale already defined in MSVCRT.lib(MSVCR100.dll)
LIBCMT.lib(invarg.obj) : error LNK2005: __invoke_watson already defined in MSVCRT.lib(MSVCR100.dll)
LIBCMT.lib(lconv.obj) : error LNK2005: _localeconv already defined in MSVCRT.lib(MSVCR100.dll)
LIBCMT.lib(mlock.obj) : error LNK2005: __unlock already defined in MSVCRT.lib(MSVCR100.dll)
LIBCMT.lib(mlock.obj) : error LNK2005: __lock already defined in MSVCRT.lib(MSVCR100.dll)
LIBCMT.lib(winxfltr.obj) : error LNK2005: __XcptFilter already defined in MSVCRT.lib(MSVCR100.dll)
LIBCMT.lib(crt0dat.obj) : error LNK2005: __initterm_e already defined in MSVCRT.lib(MSVCR100.dll)
LIBCMT.lib(crt0dat.obj) : error LNK2005: _exit already defined in MSVCRT.lib(MSVCR100.dll)
LIBCMT.lib(crt0dat.obj) : error LNK2005: __exit already defined in MSVCRT.lib(MSVCR100.dll)
LIBCMT.lib(crt0dat.obj) : error LNK2005: __cexit already defined in MSVCRT.lib(MSVCR100.dll)
LIBCMT.lib(crt0dat.obj) : error LNK2005: __amsg_exit already defined in MSVCRT.lib(MSVCR100.dll)
LIBCMT.lib(hooks.obj) : error LNK2005: "void __cdecl terminate(void)" (?terminate@@YAXXZ) already defined in MSVCRT.lib(MSVCR100.dll)
LIBCMT.lib(crt0init.obj) : error LNK2005: ___xi_a already defined in MSVCRT.lib(cinitexe.obj)
LIBCMT.lib(crt0init.obj) : error LNK2005: ___xi_z already defined in MSVCRT.lib(cinitexe.obj)
LIBCMT.lib(crt0init.obj) : error LNK2005: ___xc_a already defined in MSVCRT.lib(cinitexe.obj)
LIBCMT.lib(crt0init.obj) : error LNK2005: ___xc_z already defined in MSVCRT.lib(cinitexe.obj)
LIBCMT.lib(tolower.obj) : error LNK2005: _tolower already defined in MSVCRT.lib(MSVCR100.dll)
LIBCMT.lib(strtol.obj) : error LNK2005: _strtol already defined in MSVCRT.lib(MSVCR100.dll)
LIBCMT.lib(errmode.obj) : error LNK2005: ___set_app_type already defined in MSVCRT.lib(MSVCR100.dll)
LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library
LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library

I honestly don't know what this is about, anyone have an idea?
Title: Re: Window.draw() no longer working after SFML Update
Post by: Reborn121 on December 09, 2014, 09:35:48 pm
Could it be that the SFML source version is not compatible with VS10?
Title: Re: Window.draw() no longer working after SFML Update
Post by: eXpl0it3r on December 09, 2014, 09:38:35 pm
No.

The errors mean, that you're mixing runtime libraries, meaning that SFML's library has been compiled with a different version of the runtime libraries, than your code gets compiled with.
Title: Re: Window.draw() no longer working after SFML Update
Post by: Reborn121 on December 09, 2014, 09:43:04 pm
Okay, so I built it wrong then? I followed the tutorial.
Title: Re: Window.draw() no longer working after SFML Update
Post by: Reborn121 on December 09, 2014, 09:54:24 pm
So, if I'm using Visual C++ 2010 Express, I should build SFML with Visual Studio 10. Correct?
Title: Re: Window.draw() no longer working after SFML Update
Post by: eXpl0it3r on December 09, 2014, 10:27:56 pm
This forum has an edit function. If nobody has instantly responded to your previous post, don't just post again. If you want to add something, use the edit function, otherwise just wait and try to solve things on your own. At last you want to be a programmer and solving problems is what a programmer does.

If you want to be on the safe side, build SFML from source and build your applications with the same settings that you set when building SFML. If you don't understand the settings, read the tutorial again and use Google to figure it out.
Title: Re: Window.draw() no longer working after SFML Update
Post by: Reborn121 on December 10, 2014, 02:05:36 am
This is either a bug with SFML and VC++ 2010, or SFML WinXP 32-bit. Moving the executable that gives the Access Violation error to my mac, or my Win7 computer results in no errors, and it works fine. Take this as you will, I most likely won't come to this forum for help again.
Title: Re: Window.draw() no longer working after SFML Update
Post by: Jesper Juhl on December 10, 2014, 11:44:54 pm
So, if I'm using Visual C++ 2010 Express, I should build SFML with Visual Studio 10. Correct?
You should always use a SFML that was built with the same compiler that you use to build your (SFML using) project - yes.
So, if you use VS2010 to build your project you should use a SFML version that was built with VS2010 - and you should ship the VS2010 redistributable libraries with your project since your executable will need them.
All of this should be no surprise - that's just how building stuff with Visual Studio on/for Windows works.
Title: Re: Window.draw() no longer working after SFML Update
Post by: Jesper Juhl on December 10, 2014, 11:51:56 pm
This is either a bug with SFML and VC++ 2010, or SFML WinXP 32-bit. Moving the executable that gives the Access Violation error to my mac, or my Win7 computer results in no errors, and it works fine.
I don't see the implied bug.
Just because an executable happens to display the behaviour you expect on some specific system does not mean that it has no bugs and is not prone to undefined or implementation-defined issues. Just because moving some executable to some arbitrary system causes it to execute in a manner that you expect does not mean that it will always do so.