Messages

1

General / Re: [Advice/Warning] RenderWindow Android Crash

« on: April 14, 2016, 09:08:24 am »

Nope, it's well-known that globals are bad and that global OpenGL/SFML resources tend to blow up.

Yes, global variables are really error-prone (initialization and destruction order, multithreading, no access control, lots of dependencies). Even more sf::RenderWindow, never make it global.

I cannot remember exactly what goes wrong when you have a global resource (if there is a post explaining that in detail the forum search isn't good enough to find it) but I'm under the impression that this is not the sort of thing SFML can "fix" but rather an inherent problem with using global variables that refer to objects from an extremely stateful API like OpenGL.

2

Feature requests / Re: sf::Distance ?

« on: April 10, 2016, 12:29:37 pm »

The ability to convert "real world" distances to and from pixel counts might be a useful feature, but if so it should be part of the proposals for fetching monitor information and properly supporting multiple monitors, because it's the monitors that define what that conversion would be. It doesn't make any real sense to provide such conversions as constants in an sf::Distance class because they obviously can't be determined at compile time, and even after your program starts up they can vary depending on which monitor you're currently working with.

3

General / Re: Updating Only Portion of Rendering Region

« on: April 08, 2016, 11:20:02 pm »

I believe it should be possible to achieve arbitrary-shaped clipping without raw OpenGL by drawing to a RenderTexture. I haven't fiddled with RenderTextures in a while so I'm not sure if your clipping mask texture would have to be the clear() color or transparent or something else but there ought to be a way to make that work. Of course whether this approach makes sense depends on how much clipping you're trying to accomplish.

But even if that's not enough, before totally resorting to raw OpenGL you should try sf::Shaders first, since then you only have the GLSL half of OpenGL to worry about.

4

General / Re: Updating Only Portion of Rendering Region

« on: April 06, 2016, 09:30:11 pm »

Is this what the people here would say is a good way to accomplish this clipping that I want?

Can't speak for everyone, but this is definitely the simplest way I'm aware of.

Is it safe to set the window view to just the view to only render in this element's rendering region, clear it, and then render, then reset the renderWindow's view back to normal after doing this and then displaying?  I seem to have a gap in my understanding of the API.

Any element may, without notice, update itself and need to be rendered again. Currently, the application does not render any object unless it absolutely has to. 
For instance, just sitting there with the mouse just sitting there (no animations or anything) will cause no rendering to be done - it will wait for an event (actually wait by sleeping the event thread).
However, if a single element is updated, then I don't see any reason to wake up my main render thread and waste CPU time by rendering everything over again.
I could very well just be over-complicating this (I have a horrible habit of doing that).

It's hard to tell exactly what you mean here and thus whether you're doing anything wrong. So to save time, I'll quote the big red box from the official drawing tutorial:

This clear/draw/display cycle is the only good way to draw things. Don't try other strategies, such as keeping pixels from the previous frame, "erasing" pixels, or drawing once and calling display multiple times. You'll get strange results due to double-buffering.
Modern graphics hardware and APIs are really made for repeated clear/draw/display cycles where everything is completely refreshed at each iteration of the main loop. Don't be scared to draw 1000 sprites 60 times per second, you're far below the millions of triangles that your computer can handle.

It is completely okay to lower your framerate or even stop rendering entirely if you know you don't need as many frames anymore. But when you do draw a new frame, you absolutely must do the clear/draw/display thing, and every single object that you want to be visible in that frame must go through one of the draw() calls. But it is also completely okay to "cull" or not draw() objects which you know aren't going to be visible anyway. Changing the window's view just to draw() a single object differently is also completely fine, as long as this one object really is unique in some way that prevents it from being drawn alongside all the others.

I think that covers everything you might have been doing wrong or might have been worried about potentially doing wrong.

5

Network / Re: Sockets cannont be a vector

« on: April 06, 2016, 09:03:48 pm »

For completeness, what namosca said is true of any "node-based container" (i.e. a container implemented with "nodes" that hold one item alongside pointers to other nodes). That includes std::list, std::map, std::set, and so on. These containers do not require the items they contain to be copyable because they never copy an item after it's been inserted, no matter what methods you call on them, which is why they work with non-copyable classes like sf::TcpSocket.

The downside of a node-based container is that it can't guarantee contiguous memory like a std::array or std::vector can, and there's the storage and runtime costs of chasing a bunch of pointers. But for many purposes you won't even notice that. It was silly of me not to mention this option in the last post.

6

General / Re: scale animation problem

« on: April 05, 2016, 02:36:58 am »

I don't know the direct solution to your problem, but I see a huge opportunity for simplification that may very well solve it or at least make it much easier for you to figure out yourself.

Pass the desired duration of the animation to scalingEffect() along with the stuff you're already passing to it, and compute the speed based on that. Then you can get rid of scalingEffect's return value, and the entire closeEnough() function and its epsilon weirdness, since you can detect whether the animation is over simply by comparing the time elapsed so far to the desired duration of the animation.

7

Graphics / Re: Getting strange Frames Per Second results (Pics included)

« on: April 05, 2016, 02:10:16 am »

Since it may not have been clear from Hapax's post, the key point here is that most sleep() functions are not guaranteed to sleep for exactly the length of time you ask them to. Many of them will effectively act as if they're rounding the time you give them up or down to a multiple of whatever timer resolution the OS supports.

8

Network / Re: Sockets cannont be a vector

« on: April 03, 2016, 10:25:13 am »

That error message is telling you that sf::TcpSocket lacks a copy constructor. Many SFML classes deliberately lack copy constructors because semantically it just doesn't make any sense to copy things like keyboards or mice or network connections (see the sf::NonCopyable documentation for a list of all the other non-copyable SFML classes).

The issue you've run into, which is a general C++ thing and not unique to SFML, is that std::vector can only store copyable types (or in C++11, moveable types). This is correct, because many of the typical std::vector operations require copying (or moving) the contained objects, so it would be wrong to let you compile this.

Depending on what you want to do with sockets, you can either use a raw array as your container, or you can have your container hold smart pointers to sf::TcpSockets instead of the sf::TcpSockets themselves.

9

Feature requests / Re: Add readCurrentReadPosition in sf::Packet

« on: March 28, 2016, 03:42:26 pm »

My preferred solution would be privatize append() in SFML 3, but also take a few features from SFNUL like the ability to packet-ize arbitrary STL containers, since I believe containers and std::string cover all the legitimate reasons for wanting to read/write a blob of bytes to a packet. But I don't even use SFML packets so my opinion probably doesn't matter much.

10

Graphics / Re: I want to fit a text inside a box

« on: March 28, 2016, 03:14:10 pm »

Because text is extremely complicated, there is no perfect answer to this question, but without writing an essay about descenders and base lines and other stuff you probably don't care about...

As far as I know, in SFML there's simply no way to go from a desired pixel width/height to its closest characterSize. I believe this is because fonts are simply too complicated for such a thing to be possible in the first place, but someone else will have to confirm that. So you're going to have to write some "guess and check" code.

I can think of three parts of the SFML API that you can play the guess and check game with: First, sf::Font::getLineSpacing(), which is probably the simplest option if you mostly care about the height. Second, sf::Text has getLocalBounds() and getGlobalBounds() methods. Third, you could use sf::Font::getGlyph() to get the bounding rectangles for every glyph in your string and add up their widths and heights.

11

Feature requests / Re: Add readCurrentReadPosition in sf::Packet

« on: March 28, 2016, 11:19:30 am »

Is it possible sf::Packet::append was meant to be a protected method rather than a public method? There don't seem to be any sf::Packet methods to read "the next n bytes" that 1aam2am1 could be using, and a public append() method for raw bytes doesn't make a lot of sense without an equivalent read method for raw bytes.

12

Window / Re: Hardware Position of mouse?

« on: January 27, 2015, 08:36:33 am »

It sounds like you're asking for the ability to "capture" the mouse.  Some work has been done on this feature (https://github.com/SFML/SFML/pull/614) but I don't think it's been finished yet.  You can try building that branch yourself if you need this feature.

13

Graphics / Re: sf::Texture load from memory

« on: January 25, 2015, 11:15:40 pm »

To my knowledge resource files are a Windows-specific thing; at least I was never able to find any evidence that Mac and/or Linux support anything similar.  So you'll have to look at Windows documentation and tools to figure that out. SFML definitely doesn't support it directly.  Of course, that would make your code no longer cross-platform.

14

Graphics / Re: sf::Texture load from memory

« on: January 25, 2015, 11:06:08 pm »

Yes.

15

SFML projects / Re: SFBL (SFML Box2D Light)

« on: January 23, 2015, 11:30:36 pm »

It's your project.  Changing the license is entirely up to you.