Messages

1

Graphics / Re: Update function for re-drawing sprite

« on: December 02, 2015, 06:33:01 pm »

In your drawCup1 function, you're resetting the position of the sprite to (150, 230), undoing the work you did in the update function. Don't do that. As an aside, loading the texture every time you draw the sprite is a strange, and extremely inefficient thing to do.

2

Feature requests / Re: Distribute pdb files with Visual Studio prebuilt

« on: February 09, 2015, 07:57:09 pm »

Debug builds of SFML are available. It's just the PDB files that are not. Not the same thing.

Yes. I know. The problem is that when you build against those libraries, VS will complain about the missing PDB files. There is also no way to silence the warning (as far as I am aware), because it is on the list of warnings too important to ignore.

I freely admit, this is a minor problem, but a problem none the less. And the solution is fairly simple. At least it is simple from the IDE end. I'm not sure exactly what needs to be done for CMake to generate the correct build files in the first place. I'd be willing to investigate myself exactly how that can be done, if the Devs agree that it's something that should be fixed.

3

Feature requests / Re: Distribute pdb files with Visual Studio prebuilt

« on: February 09, 2015, 07:45:07 pm »

Well, actually, the Debug packages are useful if you want to debug your own code. Because depending upon whether you build in debug mode or release mode, different versions of the runtime library are used. Mixing runtime libraries is possible but not recommended, so if you want to build your own code in debug mode, it's best to use a version of SFML which was also built in debug mode.

However, like I've said, it's possible to build a library in debug mode (i.e. using the debug runtime libraries), but with no debug information for the library itself. Just remove the /Zi flag.

4

Feature requests / Re: Distribute pdb files with Visual Studio prebuilt

« on: February 08, 2015, 11:41:46 pm »

Well, I did search for it. It's not in the feature request forums. I also searched other forums, but there were many results, and I did not read them all, I'm afraid. However, the ones I did read suggested, as I said, building the libraries yourself.

Okay, so your response at the end of that discussion is:

I see a very good reason for not including them: they would double (or even triple) the size of SDKs, for just a tiny amount of users very capable of building SFML themselves.

Perfectly understandable. So how about my other suggestion? Remove the /Zi flag when building. This will make the distributed libraries even smaller.

5

Feature requests / Distribute pdb files with Visual Studio prebuilt

« on: February 08, 2015, 10:41:14 pm »

When you link to SFML statically, and build in debug mode, Visual Studio generates warning LNK4099(https://msdn.microsoft.com/en-us/library/b7whw3f3.aspx) for every object file in the libraries you link. I searched in the help forums to see what other people did about this, and the solution always seems to be "build the library yourself".

Is there any particular reason the pdb files can't just be distributed with the prebuilt versions of the library?

Alternatively (perhaps preferably), remove the /Zi option (https://msdn.microsoft.com/en-us/library/958x11bc.aspx) when building the libraries, in order to generate no debug info. Or change it to /Z7, in order to put the debug info in the object files themselves.

6

Feature requests / Auto linking in Visual Studio

« on: December 16, 2011, 09:25:29 pm »

Visual Studio allows you to set up linker options through preprocessor directives.  You can link to libraries like this:

#pragma comment( lib, "sfml-window.lib" )

Boost uses it, and it makes development much easier, especially when doing small projects just for testing something out.  Will this feature be considered for SFML?

http://msdn.microsoft.com/en-us/library/7f0aews7.aspx

7

General / FindSFML.cmake and SFML_STATIC

« on: October 08, 2011, 02:30:24 am »

I finally got SFML 2.0 static libraries working.  I figured out from searches leading to some guy's blog that I needed to define SFML_STATIC.  First of all, is this accurate?  Or am I likely doing something wrong in my setup that makes this necessary?

And if this is necessary, don't you think FindSFML.cmake should do this for me if I set the CMake variable SFML_STATIC_LIBRARIES?

I guess that last part should go in feature requests or a bug report, but first I want to make sure I'm not doing something wrong.

8

General / Issue with building a window

« on: July 14, 2011, 12:50:11 am »

Good ideas.  It's just that when I was trying to compile and use the static libraries, I was having difficulties and I gave up and decided to just use the dynamic libraries.  I can't remember what the problem was.  As for adding SFML\bin to my path, I don't add anything to my path unless it absolutely needs to be there.  I'm paranoid about name conflicts.  I doubt I'll compile SFML all that often, but if it becomes an issue I'd rather just write a shell script that retrieves the files I need.

9

General / Issue with building a window

« on: July 13, 2011, 11:11:04 pm »

You need to copy sfml-window.dll either:

1) to the same directory as your executable, or
2) to some other location that windows knows to search for.  http://msdn.microsoft.com/en-us/library/ms682586%28v=vs.85%29.aspx

This is not something you set through Visual Studio.  I would recommend you just stick with option (1), because when you distribute your program, your users are unlikely to have the dll installed on their own system, and you might forget that they need it.

What I do is whenever I start a new project, I just copy every single dll that I think I might need to my output directory.  Then I don't have to worry about it while I'm developing.  When your project is finished and ready for distribution, you can always remove the ones you didn't end up using.

Also, if you're going to run your program from within Visual Studio (ctrl-F5), you'll need an additional copy of the dlls in your actual project directory, not your output directory, becuase Visual Studio runs the program from there, instead of the output directory.  I recommend you instead just run the program from it's own folder via a your shell.

10

General / Why is my program using SFML so slow?

« on: July 12, 2011, 12:13:08 am »

Okay.  I fixed the problem.  I may have wasted your guys' time.  Sorry.  I'm still confused though.  It seems I just had too many programs open.  So I closed them all, and the fps shot up to 300.

The thing that confuses me though, is now I've reopened all those programs, and the fps is still up around 300, they were mostly idle programs, nothing taxing.  Not really SFML's problem, I guess it's just something with my computer that I'll need to figure out.

Thanks for the quick replies anyway.

11

General / Why is my program using SFML so slow?

« on: July 11, 2011, 11:57:58 pm »

Okay.  Results not good.

I comment out the both the drawing and the updating of my playArea object. (That's pretty much the entire contents of the 'game' outside of the boilerplate stuff).  No improvement.

Then I comment out the updating and displaying of the frame counter, and replace it with console output so I can still see the framerate.  Slight improvement there, ~0.5-1.5 fps.  Mind you, all I have now is an 800x600 black screen refreshing at ~12.5 frames per second.

I comment out the clearing of the window, + ~1 fps.

Then the event handling, doesn't help.

Finally, I comment out window.Display(), and I get + ~1500 fps.

Obviously, I can't take that out.

@Laurent: Release mode.

12

General / Why is my program using SFML so slow?

« on: July 11, 2011, 10:39:46 pm »

I began developing a C++ wrapper over SDL here:

https://github.com/blindley/Zik-Multimedia-Library

I'm also working on a clone of Space Invaders to test it, here:

https://github.com/blindley/Space-Invaders

I was about to work on the input system, then I learned about SFML, which basically does everything I want in my library to do.  So I decided to branch my Space Invaders clone, but using SFML instead, here:

https://github.com/blindley/Space-Invaders/tree/use-sfml

However, when I compiled it, it was very choppy.  I reduced the number of aliens from 50 to 1, and it didn't help.  I added a frame counter(very convenient that a default font is included by the way) and it's at ~11-12 frames per second.

The only differences between the SDL version and the SFML version are the SpaceInvaders::PlayArea::draw function, here:

https://github.com/blindley/Space-Invaders/blob/use-sfml/source/PlayArea.cpp

And the SpaceInvaders::Main function, here:

https://github.com/blindley/Space-Invaders/blob/use-sfml/source/SpaceInvaders.cpp

Can anybody see anything I am doing inefficiently (SFML-wise) that could be causing this slowness?  My computer is not top of the line by any means, but there's no excuse for these framerates on such a simple program.  Right now, all it's doing is displaying a square going back and forth across the screen.