Messages

1

General discussions / Re: SFML 2.3 released!

« on: May 13, 2015, 09:35:33 pm »

Hi!

Great work indeed. I picked up SFML again after a few years, and was glad to find that the project really took off.

I am developing an OpenCL-OpenGL interop application, and sadly I need the C++11 alignof/alignas operators that are only available in VS2015. Simply linking to the VS2013 binaries of SFML fails miserably. I either have OpenGL window, or properly aligned structs. However, building the libs comes with great pain and cascade of yak shaving.

The audio and graphics libs fail with the following errors:

1>------ Build started: Project: sfml-audio, Configuration: Release x64 ------
2>------ Build started: Project: sfml-graphics, Configuration: Release x64 ------
1>     Creating library C:/Users/nagy-_000/Build/SFML/VS14/lib/Release/sfml-audio.lib and object C:/Users/nagy-_000/Build/SFML/VS14/lib/Release/sfml-audio.exp
2>     Creating library C:/Users/nagy-_000/Build/SFML/VS14/lib/Release/sfml-graphics.lib and object C:/Users/nagy-_000/Build/SFML/VS14/lib/Release/sfml-graphics.exp
1>flac.lib(stream_decoder.obj) : error LNK2019: unresolved external symbol __iob_func referenced in function FLAC__stream_decoder_reset
1>flac.lib(stream_encoder.obj) : error LNK2001: unresolved external symbol __iob_func
1>flac.lib(win_utf8_io.obj) : error LNK2001: unresolved external symbol __iob_func
1>flac.lib(bitreader.obj) : error LNK2019: unresolved external symbol fprintf referenced in function FLAC__bitreader_dump
1>flac.lib(bitwriter.obj) : error LNK2001: unresolved external symbol fprintf
1>flac.lib(win_utf8_io.obj) : error LNK2019: unresolved external symbol vsnprintf_s referenced in function local_vsnprintf
1>MSVCRT.lib(vsnprintf_s.obj) : error LNK2001: unresolved external symbol vsnprintf_s
1>MSVCRT.lib(vsnprintf_s.obj) : error LNK2001: unresolved external symbol _vsnprintf_s
1>C:\Users\nagy-_000\Build\SFML\VS14\lib\Release\sfml-audio-2.dll : fatal error LNK1120: 4 unresolved externals
2>freetype.lib(bdf.obj) : error LNK2019: unresolved external symbol sprintf referenced in function _bdf_parse_properties
2>jpeg.lib(jerror.obj) : error LNK2001: unresolved external symbol sprintf
2>jpeg.lib(jerror.obj) : error LNK2019: unresolved external symbol __iob_func referenced in function output_message
2>jpeg.lib(jmemmgr.obj) : error LNK2019: unresolved external symbol sscanf referenced in function jinit_memory_mgr
2>C:\Users\nagy-_000\Build\SFML\VS14\lib\Release\sfml-graphics-2.dll : fatal error LNK1120: 3 unresolved externals
3>------ Skipped Build: Project: INSTALL, Configuration: Release x64 ------
3>Project not selected to build for this solution configuration
========== Build: 0 succeeded, 2 failed, 6 up-to-date, 1 skipped ==========

I started to build libFLAC statically, which in turn depends on ogg... and all the solution files they provide are not so friendly... and I haven't even reached libJPEG.

Could someone with Solution files all setup for SFML building with all it's extern deps be an amazing fellow and compile them with VS2015 RC? It is RC afterall. Any other suggestions what I might do?

2

Feature requests / Custom made event handling

« on: May 16, 2012, 05:45:49 pm »

I think many people would welcome the idea of a custom made messages could be passed to threads constructed from sf::Thread. sf::Window can accept messages coming from the OS, react to them, and also put the controlling thread to sleep until a message arrives.

Would it be possible to have an sf::EventHandler class, that is practically this functionality, only without a window (so practically not making a hidden window, only for a message handler), and be able to pass messages between threads, with the possibility of puting one thread to sleep until it recieves a custom message?

By custom messages I mean templated events (or any type of event that allows custom data to be carried along with it) that the user can use as he/she sees fit.

This would be the basis of proper event-based application design.

So far the event system is only usable for OS-window communication.

3

Graphics / Re: Resize window of app with native OpenGL render

« on: May 11, 2012, 12:01:57 pm »

Forgive me, but 2 minutes after posting (yes, 62 minutes of debugging) I found the problem. The statement (exactly the same routine) made me think, and infact they were not the same, and the far culling distance was too small.

Anyhow... I'll be off to finding the second bug in my app (2 days of debugging this last issue actually, but I'll give it a little more thought).

I'll leave the code sniplet here in case someone would actually really mess up a resize routine, cause this one works ( you might want to remove the debug instructions though).

4

Graphics / Resize window of app with native OpenGL render

« on: May 11, 2012, 11:52:55 am »

Hi,

I have read through the search hits to this problem and found no solution, so I take the liberty of posting a new question after roughly an hour of debug to no avail.

I have an app that uses native rendering beside SFML text render, and I have a problem when I resize my window. Infact the entire screen turns black.

Every frame when I render my things, I issue glUseProgam() to enable using my shaders, and when redering text, I use push/popGLStates to save my state of the statemachine, and to revert it back. I have found that push states does not save the program being used, that's why I lazily issue it every time before render. However, when I handle events at the begininng of the guiLoop(), I have to update my viewMatrix inside the shader. For that I need glUseProgram so the application knows which shader should have it's matrix updated. Here is the code:

// Set view matrix upon window resize
if (event.type == sf::Event::Resized)
{
        m_matProj = glm::perspective( 45.0f, ((float)event.size.width)/event.size.height, 0.01f, 100.0f);
        OpenGL.lock();
        mainWindow->setActive();
        mainWindow->setView(sf::View(sf::FloatRect(0, 0, (float)event.size.width, (float)event.size.height)));
        glViewport(0, 0, event.size.width, event.size.height); auxRuntime->checkErr(glGetError(), cl::ERR, "glViewPort()");
//      glUseProgram(glProgram); auxRuntime->checkErr(glGetError(), cl::ERR, "glUseProgram(glProgram)");
        std::cout << glProgram << "  " << projectionMatrixLocation << "\n";
        glUniformMatrix4fv(projectionMatrixLocation, 1, GL_FALSE, &m_matProj[0][0]);
        auxRuntime->checkErr(glGetError(), cl::ERR, "glUniformMatrix4fv(projectionMatrix)");
        mainWindow->setActive(false);
        OpenGL.unlock();
}

Funny thing is, having glUseProgram uncommented, things only distort, but when I actually try to update the matrix, the screen turns black. It is the very same routine I used to initialize the matrix in the first place.

What am I doing wrong?

5

Feature requests / Re: Windows 8 support

« on: May 04, 2012, 01:40:19 pm »

Win 8 uses two runtime APIs, the regular WinAPI, and a newer WinRT. As it is known, Win 8 starts along a new path with it's Metro UI, designed mainly for portable (touchscreen) devices, which is very frustrating for some desktop users. Win 8 also provides a conventional desktop beside the new Metro UI.

However (!) an application written in WinAPI cannot appear on the Metro "desktop", while WinRT applications will not function as window applications on the conventional desktop. That is because Metro does not have windows the way we are used to them.

WinRT applications can run hidden (services mostly), run as a tile on the Metro UI, run in reduced mode (hardcoded 25% width of the screen), large mode (the remaining 75% of the screen, if another app is shown in reduced), and fullscreen mode. These are the only types of "windows" WinRT applications are allowed to have. This naturally incorporates a somewhat different "windowing" API incorporated into WinRT.

Microsoft does not hide the fact that Win 8 is a transiitional OS, and they intend to remove WinAPI and the old dekstop from Win 9. Win 8 only keeps this duality to give the developers some time to rewrite their apps to WinRT.

Thus a windowing system like SFML could provide functions through sf::Window, whether the application is forced (or put) into any of these modes and redraw the contents accordingly.

Recently I had to reinstall my computer, and I gave the Consumer Preview a try, and it really convinced me that this will be a good thing. VS2011 along with Microsoft Blend is a REALLY AWESOME IDE. Metro UI is practically based on HTML5, and therefore all application GUIs must be created in HTML5. Blend is a WYSIWYG HTML5 editor of Microsoft, and now it is integrated into VS2011, meaning one can import/export/transport Blend and VS2011 projects into one another. One can create a GUI, export it to VS2011 and get a bunch of handles to buttons, scrollbars or whatever that only need to be filled with C++ code, or just the other way around.

The only reason I uninstalled Win8 and reverted to Win7, was because I couldn't compile SFML, not even with 1 hour of messing, and my diploma thesis is more important, which is built on top of SFML. Once I hand it in, I might mess with it again.

Anyhow, SFML could provide a simple wrapping Metro "windows" for those who do not feel up to the task of learning a new runtime API.

6

Feature requests / Windows 8 support

« on: May 04, 2012, 11:41:04 am »

Hi!

I know this is yet another request that is less pressing than some current issues, however:

- Could the CMake scripts be made Win8-ready? I have tried to build SFML under Win8 Consumer Preview with VS2011 (first with NMake), but the scripts fail to find many files. It was strage, that gl.h doesn't ship with the dev SDK of Win8, neither does it come with VS2011.

- Creating a new WinRT variant of the classes I believe would take a HUGE effort, but if people would find it useful, put a "+1" here.

7

General discussions / Re: Avast alarm

« on: April 20, 2012, 09:54:48 pm »

I don't know either why it behaves this way. Pong is the only example that doesn't trigger Avast. Tomorrow I'll build with the latest 2.0 rc and see if it still persists. If it does, I'll report is as false.

8

General discussions / Re: Avast alarm

« on: April 20, 2012, 08:04:57 pm »

If Laurent says that he is absolutely positive that no ugly hacking is inside the code that could trigger a virus scan, then I'll report it as a false alarm. I do not wish to set every single SFML executable name as a white-list member in avast.

I'm in favor of Avast, because unlike AVG, it doesn't bitch about everything. That is why I would like to know why this is happening...

9

General discussions / Avast alarm

« on: April 20, 2012, 07:34:05 pm »

Hi,

I know I must've been very famous with my switching from dynamic cmake scripts to the static ones, but here's the next issue:

for some unknown reason, Avast seems to argue about my application, that it is suspected to be a malware. I thought that it might think because I'm launching new threads (but hey, that is no black magic), but now I'm seeing that all (!) SFML and SFGUI examples also cause an alarm. You know all the details of the lib, I have no chance at guessing what could cause the trouble. I'm building both libs statically, and Avast just got updated today (or yesterday, can't remember).

Would you like me to do any tests?

Cheers,
Máté

p.s.: could it be the doing of importing symbols of GLEW at static build?

10

General discussions / Re: GLEW and not exporting the GLEW symbols in SFML

« on: April 16, 2012, 10:13:29 am »

Unfortunately, static link is currently required in order to avoid a SFML bug at application exit. But this will have all my attention and will hopefully be solved soon.

Laurent, I know you most likely focus on the SFML 2.0 sample apps right now, but if this is the same bug that causes SFGUI to crash at exit and you would solve this issue, could you please post a note also in: http://en.sfml-dev.org/forums/index.php?topic=6112.300

It would be appreciated. Thanks.

11

Feature requests / Re: SFML & Marmalade

« on: April 12, 2012, 08:42:40 am »

I would like to suggest that first mobile platform be Win8 and it's WinRT for making Metro UI apps. I know that most likely it's nearly as much effort as Android or any other OS, but Win8 is gonna hit the mobile devices hard.

12

SFML projects / Re: SFGUI

« on: April 04, 2012, 07:18:34 pm »

If you read back a bit, then you'll see it's neccessary because SFGUI crashes on every application exit because of an issue that arises due to the way libs unload. Static linking can solve the issue.

13

SFML projects / Re: SFGUI

« on: April 04, 2012, 06:11:07 pm »

I defined SFML_STATIC ahead of all includes, then there were lots of conflicting "already defined in..." messages. I had to use "Ignore Spcific Default Libraries" in "Linker->Input" by removing those responsible for conflicting defines:

MSVCRT;MSVCPRT

Plus I had to remove GLEW64.lib as a required input, as it was conflicting with sfml-graphics-s.lib. Now I only got a few unresolved external symbols, namely:


1>  main.cpp
1>sfml-system-s.lib(String.cpp.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static unsigned __int64 __cdecl std::ctype<wchar_t>::_Getcat(class std::locale::facet const * *,class std::locale const *)" (__imp_?_Getcat@?$ctype@_W@std@@SA_KPEAPEBVfacet@locale@2@PEBV42@@Z)
1>sfml-system-s.lib(String.cpp.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: wchar_t __cdecl std::ctype<wchar_t>::widen(char)const " (__imp_?widen@?$ctype@_W@std@@QEBA_WD@Z)
1>sfml-system-s.lib(String.cpp.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: char __cdecl std::ctype<wchar_t>::narrow(wchar_t,char)const " (__imp_?narrow@?$ctype@_W@std@@QEBAD_WD@Z)
1>sfml-window-s.lib(WindowImpl.cpp.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __cdecl std::_Container_base12::~_Container_base12(void)" (__imp_??1_Container_base12@std@@QEAA@XZ)
1>sfml-graphics-s.lib(Shader.cpp.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: class std::basic_istream<char,struct std::char_traits<char> > & __cdecl std::basic_istream<char,struct std::char_traits<char> >::read(char *,__int64)" (__imp_?read@?$basic_istream@DU?$char_traits@D@std@@@std@@QEAAAEAV12@PEAD_J@Z)
1>sfml-graphics-s.lib(Shader.cpp.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: class std::fpos<int> __cdecl std::basic_istream<char,struct std::char_traits<char> >::tellg(void)" (__imp_?tellg@?$basic_istream@DU?$char_traits@D@std@@@std@@QEAA?AV?$fpos@H@2@XZ)
1>sfml-graphics-s.lib(Shader.cpp.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: class std::basic_istream<char,struct std::char_traits<char> > & __cdecl std::basic_istream<char,struct std::char_traits<char> >::seekg(__int64,int)" (__imp_?seekg@?$basic_istream@DU?$char_traits@D@std@@@std@@QEAAAEAV12@_JH@Z)
1>sfml-graphics-s.lib(ImageLoader.cpp.obj) : error LNK2001: unresolved external symbol __imp_ldexp
1>D:\ToBeSaved\Develop\SFML_GL_test\\bin\SFML_GL_test.exe : fatal error LNK1120: 8 unresolved externals
1>
1>Build FAILED.

Any ideas how to resolve this last issue?

ps.: am I really that underschooled using static linking (I'm not a big fan of it, neither on windows or linux) or are things really that buggy? I figured it would take 5 minutes top to change cmake config, rebuild libs and change project properties, but I have been messing with it for hours now.

14

SFML projects / Re: SFGUI

« on: April 04, 2012, 05:18:28 pm »

For some reason I cannot build SFGUI statically, neither can I build an SFML application using the statically built SFML libs that used to work before with the dynamic variants.

Using dynamic libraries, everything was fine. Tank suggested to build and link both SFML and SFGUI statically. Most likely the mistake is on my part, but when I try to build the same project that used to work with DLLs (SFML only just yet), even though I updated lib names in the "Linker->Input" property part to be:

sfml-main.lib;sfml-system-s.lib;sfml-window-s.lib;sfml-graphics-s.lib;opengl32.lib;glu32.lib;GLEW64.lib;%(AdditionalDependencies)"

when I compile my program it gives heaps of undefined external symbols looking like:

1>------ Build started: Project: SFML_GL_test, Configuration: Release x64 ------
1>Build started 2012.04.04. 16:39:30.
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(299,5): warning MSB8004: Output Directory does not end with a trailing slash.  This build instance will add the slash as it is required to allow proper evaluation of the Output Directory.
1>InitializeBuildStatus:
1>  Touching "x64\Release\SFML_GL_test.unsuccessfulbuild".
1>ClCompile:
1>  main.cpp
1>msvcrt.lib(ti_inst.obj) : error LNK2005: "private: __cdecl type_info::type_info(class type_info const &)" (??0type_info@@AEAA@AEBV0@@Z) already defined in LIBCMT.lib(typinfo.obj)
1>msvcrt.lib(ti_inst.obj) : error LNK2005: "private: class type_info & __cdecl type_info::operator=(class type_info const &)" (??4type_info@@AEAAAEAV0@AEBV0@@Z) already defined in LIBCMT.lib(typinfo.obj)
1>LIBCMT.lib(crt0init.obj) : warning LNK4098: defaultlib 'msvcrt.lib' conflicts with use of other libs; use /NODEFAULTLIB:library
1>main.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual class sf::Vector2<unsigned int> __cdecl sf::RenderWindow::getSize(void)const " (__imp_?getSize@RenderWindow@sf@@UEBA?AV?$Vector2@I@2@XZ)
1>main.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual __cdecl sf::RenderWindow::~RenderWindow(void)" (__imp_??1RenderWindow@sf@@UEAA@XZ)
1>main.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __cdecl sf::RenderWindow::RenderWindow(class sf::VideoMode,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,unsigned int,struct sf::ContextSettings const &)" (__imp_??0RenderWindow@sf@@QEAA@VVideoMode@1@AEBV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@IAEBUContextSettings@1@@Z)
1>main.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __cdecl sf::View::View(class sf::Rect<float> const &)" (__imp_??0View@sf@@QEAA@AEBV?$Rect@M@1@@Z)

When I try to build SFGUI to make static libraries, I get the following in nmake:

Linking CXX static library lib\sfgui-s.lib
[ 84%] Built target sfgui
[ 85%] Building CXX object examples/CMakeFiles/Box.dir/Box.cpp.obj
Box.cpp
NMAKE : fatal error U1073: don't know how to make 'C:\Kellekek\SFML\lib\sfml-gra
phics.lib'
Stop.
NMAKE : fatal error U1077: '"C:\Kellekek\Microsoft Visual Studio 10.0\VC\BIN\amd
64\nmake.exe"' : return code '0x2'
Stop.

I don't know why is it looking for sfml-graphics.lib when I told it in cmake that SFML was built statically, so I would think it should be looking for sfml-graphics-s.lib (which exists as expected in it's intended install location) Can someone tell me where I am going wrong?

Thank you for the help in advance,
Máté

15

SFML projects / Re: SFGUI

« on: March 29, 2012, 12:15:01 pm »

I am talking about the crash, that happens when closing the application. I create an sf::Text object to draw an FPS counter which I keep updating with an instance of sf::String and when the application closes, it segfaults. All SFGUI samples behave this way, although I pulled master from both SFML and SFGUI just yesterday. Is there anything to do about this? I do not recall using getDefaultFont, but it might just occur that this function runs somewhere if I do not specify a specific font anywhere else.