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

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Gez

Pages: [1]
1
Graphics / Re: Crash on exit with fonts
« on: March 12, 2013, 09:56:44 pm »
Don't use global font instances, their destructor is not trivial and involves internal resources.
Thanks, I guess a FontManager class to encapsulate those fonts is more elegant anyway and it works around the issue nicely.

2
Graphics / Crash on exit with fonts
« on: March 11, 2013, 10:00:28 pm »
Hello,

I'm using SFML f5b9c7e2160e758f32aa6453c9f6b001fabbcca8 straight from GitHub. I have compiled it aswith MS VC++ 2005 Express Edition, using the project files generated by CMake. (BTW, this isn't supported by VC++ 2005. Not that it really matters I guess.)

It is statically linked to this program, a generic archive/resource/map editor for Doom engine games. The problem is what happens when the SFML code is called to render some text. When quitting afterwards, the program crashes, with exception c0000005 (access violation).  I have tried debug, release, and minsizerel builds, with no difference in outcome.

Important note: this doesn't seem to happen when compiled with Visual Studio 2010 or 2012, as the other developer working on the same project doesn't run into the issue anymore, though he did with the RC version.

What happens is that there are several global sf::Font instances that are created when the application is started. Much later, at the user's input, they might be used to draw text, on a RenderWindow that is created when needed. This happens notably when using the map editor part of the app.

I have found out that if instead of setting text directly to one of the global fonts, I instead create a clone of it with the copy constructor, then I do not get the appcrash on exit. However, this hurts performances, since the font is copied every time text is drawn. (And it is horribly ugly code anyway.)

I have no idea what to do. Looking at the closed ticket and related thread, it seems I'm getting a bug that has been fixed for other people. Is it VC++ 2005's fault? Or is there an obscure platform-version conditional somewhere in SFML that creates this difference?

3
I have the same problem so I figured it'd be okay to use the same thread, even if it is an old one?

Quote
1>Linking...
1>sfml-system-s.lib(String.cpp.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static unsigned int __cdecl std::ctype<wchar_t>::_Getcat(class std::locale::facet const * *,class std::locale const *)" (__imp_?_Getcat@?$ctype@_W@std@@SAIPAPBVfacet@locale@2@PBV42@@Z)

The IDE and compiler used is good old VC++ Express 2005.

Project settings that might be relevant:
Quote
Multi-threaded DLL (/MD)
__cdecl (/Gd)
Compile as C++ Code (/TP)

/O2 /Oi /D "WIN32" /D "USE_SFML_RENDERWINDOW" /D "__WXMSW__" /D "_WINDOWS" /D "NOPCH" /D "_CRT_SECURE_NO_WARNINGS" /D "_CRT_SECURE_NO_DEPRECATE" /D "GLEW_STATIC" /D "SFML_STATIC" /D "NDEBUG" /D "UPDATEREVISION" /D "_UNICODE" /D "UNICODE" /GF /FD /EHsc /MD /Gy /Fo"Release\\" /Fd"Release\vc80.pdb" /W3 /nologo /c /Zi /TP /errorReport:prompt

And yes, wchar_t is treated as a built-in type.

This is using the SFML 2.0 RC I downloaded from the official site yesterday (SFML-2.0-rc-windows-32-vc2008.zip from 14 June 2012); so I didn't build SFML myself. Can this be caused because it was apparently compiled with MSVC++ 2008? It'd be the first time I'd see such an incompatibility between both versions though.

4
Feature requests / Enhanced Music Control
« on: March 05, 2012, 09:44:11 pm »
Since this topic is relatively recent...
Quote from: "iwflmt"
DUMB: cross-platform, BSD-like license, no more maintained (2005), ~200Kb, IT/XM/S3M/MOD support.


Has anyone successfully interfaced DUMB with SFML? I'm attempting to do something with it, but my flailing efforts are met with an amusing variety of problems.

What I've done is take the dumbout example program from DUMB, insert it as a function, and changed it so that it writes in memory instead of a file. Then I LoadFromMemory() into a sound buffer, and attempt to play it. Even if I got it working (rather than crashing or not playing any sound), it's not an optimal approach since it's not real-time anyway (first render the song, then play it).

If there are examples of working code interfacing the two, I'd like to see them. :)

Pages: [1]