Messages

1

Graphics / Re: Debug symbols not loading for sfml-graphics-d.lib

« on: February 06, 2015, 11:10:07 pm »

I think you need to calm down a bit. SFML changes undergoe pretty extensive testing before being pushed to the main branch, and even more testing before an official release is made. That being said, the team is small and its unfair to expect them to be able to test everything, especially since, for example, the MacOS and mobile sides have few contributors.

To the point, nothing is stopping you from building SFML yourself and using the symbols from those. SFML does not need to ship with debug symbols.

You're missing my point. I was demonstrating that it IS ordinary for software projects to have bugs, I was not criticising that fact. My point is that since there IS a small development team, it makes sense to empower users to help in the debug process.

Given that including PDB files does not require any extra effort on the part of the development team (they are automatically built; you must specifically choose not to build them), it puzzles me that they would not be included.

I'm not aware of any reason why I should not be able to debug open-source code;

You can of course, just not with the officially provided files. AS Gambit pointed out you can build it yourself, though it even might need a tweak in CMake, otherwise you'd end up with multiple vs12.pdb files or similar.

How is this a justification for not releasing the prebuilt ones? I'm wondering why PDB files are intentionally not included, forcing users to build them themselves. I'm understanding of any reason it somehow puts unnecessary burden on the dev team, but I'm not seeing one.

It's not as if it's bug-free, to my knowledge, there are 55 bugs being tracked in the git at the moment.

No software is ever bug free. Git is used for version control not for tracking bugs. The issue tracker is hosted on GitHub, which is a Git front-end, but not Git itself.

I was not implying anything critical about the subject, I was pointing out that very fact that every project is vulnerable to bugs and so empowering users to debug it works towards the goal of reducing them.

As for git, doesn't it seem a little bit like pointless arguing of semantics here? We both know what I was referring too. The fact I said Git and not "Hosted on Github" is neither here nor there.

After I recently ran into this post, I've been left wondering if we shouldn't care more about the PDB files.

If you're wondering whether we should care more about them, barring any reason that they should not be included, why not just include them? Once again, I'm not seeing any reason whatsoever why they should not be.

2

Graphics / Re: texture.loadFromFile doesn't work

« on: February 03, 2015, 03:25:03 am »

That code works for me. That means the code is fine, so all I can think of is it's either:

A) The specific image, though you seem to have troubleshooted for this. Have you tried a completely different image just to be sure? Try creating a new image in GIMP that is just solid black, 40x40, and in the RGB mode format.

One thing I've run into is that 8-bit PNGs are not supported, although they are unusual. However if the issue is related to a property of the image, you'll discover this if a completely new PNG made to standard works fine.

B) A problem with the DLLs. Check all dependencies are up to date, recopy all of the binaries to your project and .exe folder.

3

Graphics / Re: AW: Debug symbols not loading for sfml-graphics-d.lib

« on: February 03, 2015, 02:58:33 am »

The pdb files which contain the debug symbols aren't being shipped.
Question is, why do you need to debug SFML itself?

Isn't the question more: "Why wouldn't I want to debug SFML itself?". I'm not aware of any reason why I should not be able to debug open-source code; so that being said all not shipping the symbols does is limit my ability to potentially uncover an issue or at least better describe it. It's not as if it's bug-free, to my knowledge, there are 55 bugs being tracked in the git at the moment.

Now, I may be missing something and I'm open to hearing it!

4

Graphics / Debug symbols not loading for sfml-graphics-d.lib

« on: February 01, 2015, 04:23:33 am »

I haven't had any issue running my basic sfml test program, but for some odd reason Visual Studio is not loading the debug symbols from the debug library or is unable too. As a consequence I can't debug any Graphics objects.

First of all, I'm running Visual Studio 2012. I also have the correct and up to date version of SFML, I double-checked (fully reinstalled and copied the bins) before posting. I've verified my Project Configuration against the tutorial, I'm using the correct debug libs. I've played around with different Subsystems and Runtime Library settings. The problem remains.

I have verified that other SFML libs are not affected, sf:Keyboard for example is debuggable.

Anyone have any ideas? I've tried googling to no avail.

5

Graphics / Re: sf::Sprite/Texture(/Image) and pointers

« on: July 10, 2012, 05:40:34 pm »

Ah, I see! Alright thanks for all the help and patience guys, that's one of the reasons I switched to SFML, the great community

6

Graphics / Re: sf::Sprite/Texture(/Image) and pointers

« on: July 09, 2012, 09:11:30 pm »

First, dont use new and delete. Especially with the availability of STL containers and the C++11 std::unique_ptr, manual memory management makes code unnecessarily complicated and error-prone. Have a look at the RAII idiom. And don't use std::shared_ptr unless you really need shared ownership, because it has quite a big runtime overhead.

Second, the dereferencing operator just returns a reference to the pointee object, no copy is performed.

As I've already said, I am aware of the dangers of using new/delete, and do plan to replace them with smart pointers later. They are however useful placeholders, as I know there are no heap problems right now.

Copying objects and dereferencing pointers are two different and independent operations, the copy constructor is simply called when you proceed to copy an object.

sf::Texture* t1 = new sf::Texture();

sf::Texture& t2 = *t1; // no copy, using a reference
sf::Texture  t3 = *t1; // copy constructor called
 

In your case, sf::Sprite::setTexture takes a reference (const sf::Texture&), so no copy is done here.

Alright, so no copy is made when dereferencing to a reference. Why is that though? Isn't there only two ways to pass data, by reference or by value? According to Wikipedia, dereferencing passes an equivalent l-value, so in my mind, unless that means copying the entire data structure, you're passing by reference.

I guess what I'm trying to figure out is, what exactly occurs when you dereference a pointer? What does the compiler do? (My assumption was that it essentially it copied the value the pointer pointed too and passed that as an argument)

7

Graphics / Re: sf::Sprite/Texture(/Image) and pointers

« on: July 09, 2012, 06:07:46 am »

As a rule of thumb, when using tons of objects, it's best to place them on the heap, as the stack has a fairly limited size. In this particular case, I have a game with a tile engine, which not only caches the tiles on the "screen" in memory, it caches the entire map as well. As such, there could easily be 10 000 tiles or more in use at once, just to host a 100*100 tile map.

I require the use of pointers. The way my tile engine works (there's a vector of tiles (pointers) representing what's on the screen, upon which the player walks, and a seperate vector containing all of the tiles (pointers) in the map, the ones surrounding the player are copied to the screen vector), due to this design, it's much simpler to simply use a vector of pointers, which are deleted when the screen changes and replaced using a copy constructor (overloaded to perform a deep-copy) built into the Tile class. Perhaps this is not the best design, but I'm purposely trying to go through the evolution of my engine in order to teach myself, rather than just have someone tell me the best way to do it. Either way, that's outside the scope of this thread.

I realize that using "new" is asking for trouble down the line, and I do plan to replace manual allocation with boost::shared_ptr's later on. However, I'm not having heap issues atm (thanks Valgrind ), and I'm still early in development, so I'd rather save that for later.

How about I put it this way (and perhaps I'm still not fully understanding dereferencing), but when you dereference a pointer, is the copy constructor for the object called, and a copy made?

8

Graphics / sf::Sprite/Texture(/Image) and pointers

« on: July 09, 2012, 04:22:28 am »

I'm a new user of SFML, and so far I'm really enjoying it. However, I'm having a bit of a problem understanding how SFML objects (particularly Graphics objects) work when you're creating them on the heap, and then passing them around as pointers. If I need to pass a sf::Texture to an sf::Sprite, if I'm passing a pointer to it (as I have to when it's on the heap, of course), I'm forced to dereference it first. My question regarding this is, will dereferencing a pointer to an SFML object, as an argument to another (see example to clarify what I mean), result in a copy of the first being made?

For example:

sf::Texture* texture;
sf::Sprite* sprite;

texture = new sf::Texture;
sprite = new sf::Sprite;

sprite->setTexture(*texture);

Is there a better way to pass SFML objects on the heap around, rather than dereferencing them all the time (which sounds like terrible design on my part)? Furthermore, do SFML top-level objects (i.e sf::Sprite, sf::Sound) store most of their data on the heap already (and hence it should be fine to store the objects themselves on the stack)? I know things like sf::Texture store pixel data in video memory, but say I'm juggling 50 sprites, would it make sense to put them on the heap? Or are they lightweight enough to go on the stack?