Messages

1

General discussions / Re: SFML API ugliness

« on: July 17, 2012, 04:20:16 pm »

I followed this thread and expected some suggestions or notes from BHXSpecter. But nothing.

As a noob i would be very interested what's so ugly in SFML.

I second this notion. I can't speak for others, but I myself probably would learn a thing or two if BHXSpecter shared not only their opinion but also arguments backing up that opinion.

I also can't quite understand why hold back on it. What anyone has to lose here?

2

General / (Solved) Need help with errors after updating SFML

« on: May 28, 2011, 01:16:20 pm »

Edit: Figured it out, I had simply selected wrong generator for CMake. I figured Visual Studio 10 Win64 would be correct since I have 64 bit Windows, but that apparently is not the case. Sorry about the fuss.

I'm not sure if my issue is related but it's quite similar. I was already creating a new topic for it when I noticed this one.

I updated to a new version of SFML2 from a version that was more than a year old. So I got the latest source from Github and followed the instructions here.

I built the thing and now I'm getting the following errors:

Code: [Select]

RenderingWindow.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: virtual __thiscall sf::Window::~Window(void)" (__imp_??1Window@sf@@UAE@XZ) referenced in function "public: virtual __thiscall RenderingWindow::~RenderingWindow(void)" (??1RenderingWindow@@UAE@XZ)
1>RenderingWindow.obj : error LNK2001: unresolved external symbol "private: virtual void __thiscall sf::Window::OnCreate(void)" (?OnCreate@Window@sf@@EAEXXZ)
1>RenderingWindow.obj : error LNK2001: unresolved external symbol "private: virtual void __thiscall sf::Window::OnResize(void)" (?OnResize@Window@sf@@EAEXXZ)

RenderingWindow is my own class that inherits from sf::Window. I made some tests and it seems that any call to any SFML function gives this kind of error (at least several sf::Window methods, sf::Input::IsKeyDown and sf::Clock::GetElapsedTime). The source I'm using to compile SFML does have all those methds defined, obviously.

This happens with both release and debug mode. I've triple-checked that my paths to the .lib files are correct and the .dll-files are in the working directory of the project. I've tried both STATIC_STD_LIBS disabled and enabled. SFML_DYNAMIC is defined, I also tried without defining it in case things have changed since last time I set SFML up. I noticed the .dll names have "-2" affixed to them (sfml-window-d-2.dll, for example), in desperation I also tried removing the "-2", to no avail.

I'm using the same instance of Visual Studio 2010 to build both SFML and my own project, so it shouldn't be a matter of different compiler version for SFML and my own project.

I've pretty much followed the 1.6 tutorial when setting things up, and just found out SFML2 procedures differs somewhat (SFML_STATIC, for example). I'm using dynamic libraries, but are there any other gotchas that are not needed for 1.6 (and thus I would have missed them)?. The year old version of SFML2 I've been using that still used SVN worked perfectly with the 1.6 instructions. I then updated my ATi drivers which messed things up and I thought updating the SFML might work.

I apologize for intruding the thread, I just feel the issues are so close to each other that a separate thread would be unnecessary pollution.

Edit: I'm linking to

sfml-main.lib/sfml-main-d.lib
sfml-system.lib/sfml-system-d.lib
sfml-graphics.lib/sfml-graphics-d.lib
sfml-audio.lib/sfml-audio-d.lib
sfml-network.lib/sfml-network-d.lib
sfml-window.lib/sfml-window-d.lib

in case that's any help.