You should check the sfml forum, anyway this error usually means that you are yousing wrong library files, sometimes the debug in release or the release in debug. Pleas check this and the forum.
Means a program was trying to write data to the memory at byte three. Are you following a tutorial? Because I don't see any glaringly obvious holes right off the bat. Have you checked to see if myText actually points to something (you can just cout << &myText; to output the pointer value, or you can use a debugger)
You could be linking to the release dlls (ie no-d in the dll name) and trying to build against the debug library files, or the other way around.
@ OP: Did you remember to recompile the SFML library from source using your new version of MSVS? There is no downloadable for 2013 from SFML's website so you have to do this by hand.
Is there anyone who has built sfml for visual studio 2013 express and could walk me through the steps, starting with exactly what to download and so on? Sorry for being such a baby, thanks. :)
I'd say GCC\MingW, but that's more of a personal preference then a functional one. You'll want something that is up to date so Clang might be another choice to look into.
@Manga
You certainly can use SFML with VS2013. IIRC the latest version of cmake generates correct VS2013 project files, if not you can generate 2012 files, when you open the solution in 2013 it should convert them.
Yes i have. But you shouldn't have to covert the solution. I just generated VS2013 files using the latest cmake (3.0) and it generated correct files that built without issue. What version of cmake are you using?
To be honest, I have never used CMake before so I must learn it first. But I was not sure if it was even possible but thanks for letting me know it can be done. When you use sfml with vs2013 do you get any trouble with the sf::Text? I read this is a common problem.
This is only a common problem because what you did is a common mistake. This kind of error suggests that a stack corruption is the underlying issue. So when people on forms read it they understandably expect the error to be present in the users code just like the other posters in this thread did. Would you like to know how you can tell? Look at how many hits you get when you Google this error, then tell me how many of those issues are resolved or even not abandoned all together. If it were an issue with the framework then that would be reliably replicated. The SFML developers would then run a stack trace and resolve it with a hot patch, they are not amateurs after all.