Messages

61

Graphics / Re: Maximum number of quads in a sf::VertexArray ?

« on: June 21, 2020, 09:43:17 pm »

@Nexus: in your example you choose 100x100 cells because 10^4 quads is what the average gpu can handle easily at once?

No, it was just an example with arbitrary numbers. I don't know how many quads can be handled.

You may need to experiment to find what works best. With smaller regions, you are on the safer side, but it costs you some extra drawcalls.

62

Graphics / Re: Maximum number of quads in a sf::VertexArray ?

« on: June 21, 2020, 02:59:20 pm »

To extend eXpl0it3r's answer:

Put it in an other way, is there a maximal size above which it is not safe/performant to use sf::VertexArray ? Will SFML or OpenGL automatically split my sf::VertexArray if it is too big for the buffer of my GPU ?

No, SFML/OpenGL will not split the vertex array.

Apart from VRAM, you also are limited by RAM -- since sf::VertexArray is backed by an std::vector, you need enough contiguous memory to store all the cells. Even if modern machines come with lots of RAM, you need a big enough chunk of memory at once.

What I would probably do is hierarchical rendering. Split the world into regions, where one region is e.g. 100x100 cells. Render each region separately, and only if it's in view.

There are futher optimizations you can do:

• Obviously, only update sf::VertexArray if the cells in that region change
  
• Do not recreate/assign the vertex array, instead use clear() + append() or resize() + operator[]
  
• Depending on your graphics, it may be enough to render the active cells (often a sparse subset of all cells)
• At some zoom level, you may end up with so many tiny cells that the quad representation is inefficient, and you can e.g. render dots instead, or use a shader

63

SFML development / Re: SFML Move Semantics

« on: June 21, 2020, 01:12:12 pm »

You mention some good points. I also think a modular approach makes more sense -- could even be on a class/group of classes basis, to have smaller incremental steps that can be reviewed in reasonable time.

I expect that after the release of SFML 2.6, the master branch will start targeting SFML 3 and new features will be merged against that. eXpl0it3r probably knows the approach in more details here.

So, what's left to decide is really:

are move semantics pressing enough to introduce them into SFML 2.x
or should we prioritize making a development branch available for SFML 3, so that PRs with new features can be processed?

64

SFML development / Re: SFML Roadmap

« on: June 21, 2020, 01:04:51 pm »

Error Handling
I don't like the idea of having resources constructed through factory methods. Once we get move semantics implemented, you could implement your own factory methods that handle errors in what ever way you like. Forcing an error handling method would be an opinionated debate with no right or wrong answers.

The library still has to provide this functionality. "Opinionated" in this sense mostly means "consistent" and "that's the recommended way of doing it".

Currently, this API is

sf::Texture texture;
if (!texture.loadFromFile(...))
{
    // error handling
}

and this is equally opinionated, but has several technical drawbacks: easy to forget checking the return type, no const variables, no way to get error message/code, unclear semantics when re-loading (and failing), dealing with invalid (unloaded) states, etc.

Of course it can be discussed if this would remain the best API for SFML 3, but keep in mind that the original reason to do it like this was because SFML doesn't use exceptions, so constructors cannot fail.

Constructors on the other hand are not a good idea, as they cannot specify the source (file, memory, stream...), and this would need to be dispatched solely based on parameter types. There would already be conflicts now, e.g. with sf::Shader.

Hence the suggested named constructor idiom (factory) -- it's an established idiom and shines especially in combination with move semantics.

65

SFML development / Re: SFML Move Semantics

« on: June 18, 2020, 11:33:41 pm »

Keep also the SFML Roadmap thread and its ongoing discussions in mind, when providing additions possibly targeted to SFML 3.

Some things may still change

What exactly is a huge change? To stop supporting non-C++11 compilers? I don't think it's that huge

I was thinking the same here, and maybe this is a part that should be discussed in the roadmap. The biggest risk I see is that SFML 3 is again several years away, and people have to wait even longer for useful additions like move semantics.

Projects that want to do "everything right" at once are often problematic. But as eXpl0it3r mentioned, SFML 3 might be rather short-lived, hoping that we can iterate faster on possible design mistakes.

66

SFML development / Re: C++ standards

« on: June 18, 2020, 11:10:40 pm »

Thanks for the link, I missed that latest update. SFML 3 planned directly after 2.6 changes things of course.

I've added some more concrete suggestions (so far mostly on the C++ side) directly in the other thread.

67

SFML development / Re: SFML Roadmap

« on: June 18, 2020, 11:06:41 pm »

[Edit] Now that I think about it, this might as well be its own topic. Feel free to split, if you want to keep this thread focused on the high-level roadmap, without going into detail about C++ related API changes.



Maybe we should start discussing the bigger API changes, especially those that break existing code.
I'm just brainstorming here, so all I write is neither complete nor definitive.

Here's a good overview over new library and language features for all C++ standards.

Error Handling
It would be nice if resources could be returned from factories (named constructors), such as:

sf::Texture tex = sf::Texture::loadFromFile(...);
sf::Image img = sf::Image::loadFromMemory(...);

It would need to be discussed what to do in the error case.

• Exceptions: Nice to use in the happy path, but can be forgotten. Would require exception hierarchy and error discrimination/display mechanism. Requires exception safety everywhere.
• std::optional<T> -- Can be empty for failure, but there's no way to convey the error.
• std::variant<T, E> -- Either the type or an error. Like Rust's Result, but very unidiomatic to use in C++.
• sf::Result<T> or sf::Result<T, E> -- a simplified version of the above, tailored to SFML. Could have syntax sugar like * dereference.

Major removed APIs
Main candidate I see is sf::Thread.
With it come sf::ThreadLocal and sf::ThreadLocalPtr.

It can be discussed whether sf::Time is necessary given std::chrono, but the latter is very generic and can be overwhelming for the small amount of functionality that SFML needs. Interop (conversion from/to) should definitely be provided though.


Filesystem and path
C++17 Filesystem could benefit both public API and implementation.
If it's too tedious to construct strings to be used in place of std::filesystem::path, convenience overloads for sf::String or const char* can be offered.



Ownership and smart pointers
I can't think of a vast number of places where SFML would benefit from smart pointers, but I could imagine that std::unique_ptr and std::shared_ptr could clarify ownership semantics, when the library does not simply "borrow" (reference to) a user-created object, but (partially) own it.

std::unique_ptr in particular is a good abstraction boundary, when pointers to abstract base classes, such as sf::Drawable or sf::Shape have to be moved (ownership-transferred).

Apart from that, move semantics should be employed in the library, mainly for heavy resources.


New emerged idioms
Smaller things like:

• passing {x, y} for sf::Vector2 parameters, and subsequently a smaller number of constructors.
  
• If there are callback-like classes, instead of having an abstract base class with 1 method, we could use std::function. SFML doesn't use that a lot though.
  
• std::byte instead of char/void pointers.
  
• enum struct
  
• Lambda expressions mostly to simplify the implementation. As expressions, they have no direct use in the API.
• Range based for loops
• [[deprecated]] attribute
• nullptr everywhere, NULL should no longer be used
  
• std::optional for parameters and return types
  
• override, = default, = delete, and if absolutely needed final
  
  

Out of scope
I think we also have to be careful what not to include. In particular, we should not have the mindset "this feature is new, so we have to use it", but rather evaluate on a case-to-case basis, if a new C++ language/library feature actually fits in the scope.

Some things I'm thinking of that should be used with care:

• Type inference. auto is nice for iterators, but using it for ints and vectors may easily make code less readable. Same for inferred return types -- apart from readability and increased compile time, they can also introduce subtle bugs/breaking changes if a return expression changes type by accident.
  
• Template metaprogramming. Variadic templates, folding expressions, variable templates, and all the dark magic around it. If it allows something to be used much easier, why not, but it shouldn't be the primary API design tool  ;)
  
• Uniform initialization. This is the biggest misnomer and in my opinion one of the worst additions to the language. Instead of making anything uniform, now we're left with 4 (!!) syntaxes to initialize a variable, and new ambiguities (std::vector<int>{2, 3}) are introduced. A strict convention which syntaxes to use would solve this problem.
  
• constexpr and compile-time computations. Those are almost always optimizations, and thus should have low priority compared to more important features. We need to keep in mind that adding the keyword to a majority of the public API also has a readability/usability cost, possibly for a small number of users truly benefitting. It's different for cases where it's easy to add and can significantly improve performance in the general case.

68

SFML development / Re: C++ standards

« on: June 17, 2020, 10:36:02 pm »

What I wrote almost 2 years ago:

When choosing a standard, we need to decide:

• Who are we targeting? Does our main user base have access to recent compilers?
• What newer C++ features can SFML directly benefit from?
• When would SFML 3 emerge?

The last point is important. If we were to choose C++14 at this very moment, it's already "outdated" by 4 years. Add to that the time until SFML 3 is ready.

And SFML 3 is still nowhere. So I'm no longer sure if this should be the criterion.

Would we even require a major version to add more modern C++ features?
A new C++ version is a breaking change only w.r.t. old compilers, it's not breaking client code. Intuitively, it appears to me that a typical SFML user has access to an at most 3 years old compiler (to support C++17).

My suggestion:

• Start from C++17 -- it's old enough to have decent compiler support but also has helpful stdlib additions
• Include support from SFML 2.6 or (depending on time to implement) 2.7
• Use features mainly to add nicer APIs (move ctors, conversion from std::chrono/std::filesystem/...) and simplify internal implementations (lambdas, unique pointers)

SFML 2.6/2.7 could then be seen as a "proof-of-concept" of more modern features, and maybe based on that, we learn how to improve APIs for SFML 3.

69

General / Re: Noise when using threads

« on: February 01, 2020, 03:02:44 pm »

You should offload computation to multiple threads, not rendering. Rendering should happen in the main thread, and it's likely not the CPU bottleneck.

You need to synchronize access to shared resources from your threads (C++11 has a lot of threading primitives).

I wouldn't use sf::Image, it's a RAM-based pixel container and not made for fast graphics updates. There are multiple options what to do instead, e.g. you could use a sf::RenderTexture (don't forget to call display()), and render points to it with sf::VertexArray.

70

System / Re: Non-Locked threads and Locked Threads

« on: January 30, 2020, 05:54:26 pm »

Also, since C++11 we have threading functionality in the standard library.

After learning general multithreading concepts, you may want to have a look at it:
https://en.cppreference.com/w/cpp/thread

71

SFML projects / Re: [Steam Release] Castle Clamber - A retro arcade platformer

« on: January 27, 2020, 10:25:45 pm »

This looks like a fun little game! From the trailer, the goal was not very clear to me, but then I found a gameplay video here:

[Edit] how can I not embed a Youtube video?

I like the graphics style, simple but still polished and not overly crowded. I especially like the banners and the lava (texture and its wave effect). I think the explosions still have some room for improvement (maybe smoke or so)

Since you mentioned real-time lighting, have you considered adding shadows? I could imagine that a subtle shadow beneath entities or platforms could add quite some depth.

72

General / Re: Trying to build with DEV-C++, getting linked errors

« on: January 19, 2020, 10:34:03 am »

Dev-C++ is a very old IDE, I remember having my first C++ steps with it in the 2000s...

Is there a reason why you don't use a more modern one, e.g. Visual Studio 2019 Community, which is free to use?
It may simplify a lot of configuration/setup on your end, and more people would be able to help you.

73

General / Re: Avoid collision of nodes while representing Binary Tree in SFML

« on: December 27, 2019, 11:38:09 am »

Can you help in this regard, please? Or provide a different solution? Thank you!

Regarding different solutions, I'm wondering why you don't use standard containers? It would be much faster, easier and less error prone.

In this case, it looks like std::map would fit your purpose -- even though it's usually implemented as a red-black tree, you can use it for binary searching, insertion, removal, etc. And it will manage all the memory automatically -- this is something you should always prefer, avoid using new/delete in C++.

74

Audio / Re: How to properly remove sfml::sound/music (AL lib: (EE) alc_cleanup: 1 device...)

« on: December 21, 2019, 05:19:31 pm »

So I was able to resolve this warning for sfml::music by using "GameData->assets.music.~SoundSource();" before I exited the window. However I am not sure that is proper.

I'm sure it's not proper.
In fact, calling destructors manually is undefined behavior (UB), if they are called again automatically.

        void AssetManager::RemoveSoundBuffer(const string name) {
                if (this->_soundBuffers.find(name) != _soundBuffers.end())
                        _soundBuffers.erase(name);
        }

I don't know what data structure _soundBuffers is -- but if it's a std::vector or std::deque, erasing one element will invalidate pointers to the erased element and all subsequent elements. Since every sf::Sound stores a pointer to a sf::SoundBuffer, you may trigger UB here as well, due to dangling pointers. A std::list or std::map would not have this problem, they are stable data structures.

It's relatively simple to get sound lifetimes right, you need to consider the following rules:

• Use automatic memory for all the objects (STL containers and smart pointers). Do not use new/delete, manual destructor calls or other unnecessarily low-level techniques.
• Every sf::SoundBuffer must outlive all the sf::Sound instances that refer to it.
• A sf::SoundBuffer must not be moved/copied while it's in use (e.g. by erasing from a container).
• Don't allocate any SFML objects globally (this obviously includes other objects that are global and contain SFML objects). Initialization and destruction order of global variables is a big mess in C++.
  

In case you want a readily available solution for managing resources like sf::SoundBuffer, you might be interested in my library Thor (here's a tutorial which shows some examples).

75

Graphics / Re: Sfml drawing faster algorithm slower

« on: December 18, 2019, 09:15:51 pm »

Well, im stupid. I used vectors for int and bool not a dynamic array. Now I got 800fps.

This doesn't make sense. std::vector is a dynamic array, and has the same performance as new[]. Just enable Release builds, and make sure optimizations are on and debug symbols off.

If the iteration is the bottleneck even with a Release build, you might be doing something wrong or unnecessarily expensive. Hard to say without knowing what exactly you're doing in the loop.

Also, not sure what you mean with "2D vertex array" -- are you sure you're not looking for a sf::RenderTexture? You could keep the data on the graphics card and modify it either by drawing pixels onto the texture, or by running shaders (i.e. still drawing).