Messages

31

General discussions / Invalid read in KDE

« on: June 28, 2015, 11:23:49 pm »

Hello,

I 'm on Kubuntu 15.04 and running SFML applications through valgrind, they produce the following invalid read:

==14802== Invalid read of size 1
==14802==    at 0x4C2F134: strlen (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14802==    by 0x5314CC7: sf::String::String(char const*, std::locale const&) (String.cpp:73)
==14802==    by 0x50E10B7: (anonymous namespace)::ewmhSupported() (WindowImplX11.cpp:235)
==14802==    by 0x50E2849: sf::priv::WindowImplX11::WindowImplX11(sf::VideoMode, sf::String const&, unsigned long, sf::ContextSettings const&) (WindowImplX11.cpp:579)
==14802==    by 0x50D9BED: sf::priv::WindowImpl::create(sf::VideoMode, sf::String const&, unsigned int, sf::ContextSettings const&) (WindowImpl.cpp:71)
==14802==    by 0x50D9188: sf::Window::create(sf::VideoMode, sf::String const&, unsigned int, sf::ContextSettings const&) (Window.cpp:124)
==14802==    by 0x4E8D9E8: sf::RenderWindow::RenderWindow(sf::VideoMode, sf::String const&, unsigned int, sf::ContextSettings const&) (RenderWindow.cpp:45)
==14802==    by 0x4015F3: main (main.cpp:5)
 

suggesting that a non-null terminated string has been passed to strlen; in fact the string passed to it when valgrind complains is "KWin0/inA" - it is the name of the window manager, obtained from line 233 of WindowImplX11:

const char* name = reinterpret_cast<const char*>(xcb_get_property_value(wmName.get()));
 

If I had to guess, it was supposed to be "KWin" but they got their slash the wrong way round. In any case, if this is correct it is not SFML's fault, but you may have an idea how to guard against receiving such a problematic string; or perhaps you have other thoughts on the issue.

32

General / Re: explosions with smfl

« on: November 06, 2014, 10:30:31 pm »

On the other hand, Thor does have a particles module which makes creating pretty explosions pretty easy (check the fireworks example).

33

Feature requests / Re: sf::VerArray.erase

« on: November 04, 2014, 05:52:29 pm »

Suppose an erase() is implemented (presumably by index). But then, you decide to be fancy and get rid of a whole bunch with an erase-remove; sf::VertexArray is useless once again.

Of course sf::VertexArray has a reason for existing, it is a way of pairing the vertices with the primitive into a sf::Drawable, rather than throwing them around willy-nilly. Which begs the question, why the 'encapsulation' that effectively makes sf::VertexArray a handicapped vector? Why isn't sf::VertexArray exactly what's its meant to be - a struct comprising of a public vector of vertices and a primitive, with a draw function? As it is, it's a recurring joke.

34

Feature requests / Re: Provide sf::to_string() overloads for SFML types?

« on: August 27, 2014, 02:28:10 pm »

There are cases where logging is far more useful than the debugger's breakpoints; multi-threaded applications for one.

Qt offers a simple STL-like stream that can be used anywhere to output pretty representations of its classes. I made the suggestion for a similar stream in SFML:

http://en.sfml-dev.org/forums/index.php?topic=14708.msg103579#msg103579

Noone else seemed to care though.
A set of formatters for Boost.Log is another idea.

35

General / Re: Is it possible to embed an SFML game on a site?

« on: August 14, 2014, 09:56:53 pm »

This seems like an obvious place to mention Featherkit. It is not unlike SFML and it can use it as a back end. Then, one can switch to SDL as back end and use emscripten.

36

General discussions / Re: Conditional C++11 Support

« on: July 13, 2014, 05:53:36 am »

There are rules which is good. They are complex which is not so good.
Personally I prefer a simple rule: If I define any constructors/assignment/move operators then I'll explicitly list the rest as either "= default" or "= delete" (as private, protected or public as apropriate) depending on what I want.
That way I won't have to worry about memorizing the complex rules (and getting them wrong in some subtle situation with hard to debug problems to follow) I'll just be explicit and tell the compiler "I don't care what you would have done, this is what I want".

Then it would not be possible to compile pre-C++11 code with the flag and get the benefits for free (as you suggested yourself!).

Similar rules already applied with the copy constructor and assignment and the rule of three was the guide to follow, now become rule of five/zero (http://en.cppreference.com/w/cpp/language/rule_of_three) . The crux of it is do you need a hand in the class' resource management? If so, write copy/move/dtor yourself, else do not. The constructor(s) of the class should not be lumped in with the rest.

Yes, there are tricky scenarios where what is being generated makes for interesting puzzles. But i) avoid them ii) it's unlikely a mistake will result in a hard-to-debug problem; ie if you thought a move ctor was generated but is not, worst case is that the objects are getting copied instead, which should be noticeable in performance. Or if a copy ctor wasn't generated either, you 'll get a compile error.

37

General discussions / Re: Conditional C++11 Support

« on: July 11, 2014, 07:58:18 am »

User-defined copy constructors (which isn't the case to my knowledge)? Because otherwise it's not a problem.

See en.cppreference.com/w/cpp/language/move_constructor#Implicitly-declared_move_constructor

38

General discussions / Re: Conditional C++11 Support

« on: July 11, 2014, 05:38:27 am »

If you want to keep it really simple, then just add a CMake switch to enable whatever compiler flags are needed (like std=c++11 for GCC and Clang) to enable C++11 features in the compiler while building SFML. Doing nothing else will at least let the compiler take advantage of C++11 support in the standard library parts that SFML uses internally and whatever other C++11 optimization tricks it may have up its sleeve. Doing nothing but this will provide some (arguably minor) improvements to people using a C++11 compiler with SFML and won't place any undue maintenance burden on the SFML team.

You can already add flags when configuring the CMake file. Compiling with C++11 should generate default move contructors wherever possible.

39

General discussions / Re: SFML 3 - What is your vision?

« on: June 26, 2014, 04:06:14 pm »

@Kojay
Wait, I still don't get why doing that overload is a bad thing. Why not have give the option to write it either way?

Type safety is one of C++'s crown jewels. If you mean to pass a vector, pass a vector. See this presentation by Bjarne Stroustrup:

http://youtu.be/0iWb_qi2-uI?t=19m7s

It's true these overloads are present in several libraries for ease of use - Qt employs them exensively. But with C++11, there's no excuse.

40

General discussions / Re: SFML 3 - What is your vision?

« on: June 24, 2014, 04:18:47 pm »

All I want is a Line class >.<
Yup, the line is a rectangle shape with height = 1, but everytime I need to draw line, I have to calculate length and angle =)

(It was too hard to draw lightnings with rectangles  )

I concur. Yes it is possible to accomplish with the existing tools but the same could be said of the other shapes. First of all, lines drawn as vertex arrays with the primitive "Lines" are 1 pixel thick and stand apart from other shapes. Then if you decide that you want a line with thickness instead, you switch to rectangle shape - an 'implementation change' that is not seamless. In both cases you 're writing boilerplate; all in all, the absence of a LineShape has always been a very odd omission.

Very small feature:
Just as a sf::Transformable has a setPosition(float x, float y) as well as a setPosition(const sf::Vector2f& position),
it'd be nice if the setSize(const sf::Vector2f& position) function could also be setSize(float x, float y).

Guessing that setSize is from 1.6. setScale() does have such an overload, if anything however I would argue for its removal. One of the strengths of C++ is its emphasis on types, this kind of overloads defeats it. Moreover, in C++11 you may write

setScale({x,y})
 

41

General discussions / Re: SFML Game Development -- A book on SFML

« on: June 13, 2014, 03:33:05 pm »

Overloaded bitwise operators can return bool (which is presumably what you want to use them as?).

42

General discussions / Re: SFML 3 - What is your vision?

« on: May 15, 2014, 10:54:25 pm »

For a functionality-focused library like SFML (rather than one that provides features for the language itself), these concepts complicate everything. Concepts require code to be written as templates, i.e. forcing definitions in headers, delaying/hiding compile errors, exposing internals and making compile times explode. Concepts make interfaces implicit; one must read the documentation in order to know an API can be used. They abstract from the obvious parts and make APIs less simple to use.

These are shortcomings of the language, not a case against generic programming. Concepts are not currently a feature of the language, hence the obscure errors and lack of helpful intellisense. There is a discussion group and eventually they will be included in the standard; they are the cutting edge, whereas oop and RAII are as old as C++ itself.

Cleanliness, the design of specific libraries... not going to argue over such things.  I stated in the previous post what I think is the ideal method to determine new features.

43

General discussions / Re: SFML 3 - What is your vision?

« on: May 15, 2014, 02:42:11 pm »

Perhaps SFML 3 can feature genuinely modern C++. Currently, the only sense in which this is true is that it is not C, ie it is object-oriented and employs RAII. Other than that, it has little to do with the STL, the Boost libraries or Alexandrescu's book bearing that title.

• sf::Vector is a template but this genericity is mostly wasted as sf::Vector2f is the bread-and-butter point throughout the library. While the case could be made that OpenGL handles floats anyway, a whole host of other classes could fulfill the float-coordinate Point concept.
• Adapting SFML's classes to Boost.Geometry's concepts makes evident that sf::Shape, sf::Sprite and sf::VertexArray are effectively ranges of points - additionally associated with colors and/or a texture. Conceivably, a std::vector<std::complex<float>> could serve just as well.
• sf::Shape::getPoint, sf::VertexArray::operator[] and sf::Image::getPixel are essentially methods of iteration, yet require additional work to apply generic algorithms on them.

That said, these are merely observations and do not indicate whether the library should go down this road. As Stepanov said, go look at people's code. In SFML's case that's almost certainly indie games. Ideally, code from such projects should be scrutinized to abstract data structures and/or algorithms from. New features added through this method are bound to be useful.

44

General discussions / Re: Future release of SFML 2.2 (feedback needed)

« on: April 05, 2014, 07:59:25 pm »

There are also several bug reports related to windowing on Linux, but a lot of them aren't clearly investigated or reproduced. If somebody would like to help here, that would also be nice

Could you point out which ones are those?

45

SFML projects / Re: Embedded Console

« on: March 30, 2014, 09:25:55 am »

Remarks and ideas:

• No need to write Console's destructor.
• It seems more natural to keep previous lines and pop as necessary (presumably your commented out deque was to that end?
• line 65 of Console.cpp - instead of insert(make_pair()) can simply do commandList.emplace(c, f);
• The states parameter isn't used in the draw function - either pass it to the draw calls or unname it.
• line 41 of Console.cpp - gcc points out that t < 128 is always true
• I would rather the commands the user registers return an ostream instead of a string - streaming makes for nicer syntax than string concatenation and you 're already using a stringstream in handleCommand.
• Could Up and Down be used to cycle through command history instead?
• (If you want to be really fancy) Provide autocomplete.