SfmlExt: An extension to SFML using Thor and C++11

[Glocke]

Hi there,

during the last months, I was working on my Isometric Coop Rogue-like Game Rage, which is currently paused because of too less spare time. So I started reworking/refactoring the entier codebase. During this process I found some pieces of code which are solving several problems I faced during development. So I started to isolate those solutions to make them reusable. Finally, I decided to put those solutions on github and call this repository "SfmlExt" - because it seems like an extension - at least to me.

It requires C++11 (which should be wide-spread by now), works with SFML 2.2 and can be found here: https://github.com/cgloeckner/SfmlExt

Briefly, it's a set of functionality which is distinct from the current SFML release as well as from Thor. Currently, there the following "sub-projects" are included:

This list is outdated. View README on github for further details.

(click to show/hide)

• image_atlas: A tool to create a few framesets from a large unmber of single frames. It was already presented at this forum
• resource_cache: A cache implementation holding resources in unique ownership and returning references to the resources. This is not a substitution for Thor's resource caching system - but it is an alternative, because currenlty Thor only provides shared ownership, which is not always the optimal solution.
• resource_archive: In addition to resource caching, this allows to create and load binary resource containers which can currently hold multiple resources of a single type, indexing them by their previous filename.

Additional features are planned but not finished, yet. I don't like publishing semi-completed code Just as a teaser, here's a possible list:

• tiling: A tool to encapsulate map tiling. It allows iterating a limited area in a renderable order by using range-based loops providing map coordinates. It also provides coordination transformations (e.g. isometric screen coordinates to orthogonal world coordinates). Might also provide hexagonal grids, later
• light_ui: A light-weight GUI framework providing a very limited set of GUIs: Those which can be accessed only by keyboard/gamepad (see: Diablo 1 Title Menu).
• astar: An A*-implementation based on a fix-sized 2d map (not just those who are orthogonal in their model, such as topdown- and isometric maps, but possibly also hexagonal maps). Native C++11 doesn't provide a suitable datastructure, because A* needs to search the openset for a specific node, which is inefficient with std::priority_queue - but there is a way to do so on fix-sized maps.

So, stay tuned for future commits For updated examples view the GitHub repository!

Thanks for reading! I'm looking forward to your feedback.

Kind regards
Glocke

/EDIT: (10.01.15) Major API Update (removed outdated examples from this post)
/EDIT: (21.01.15) Moved outdated feature-list (see spoiler)

[Mutoh]

Aw, no namespace? That is always nice having in libraries you want to distribute.

Also, in your second example code:

    // load that archive
    TexArchiveReader reader;
    assert(reader.open("out.bin"));

Even if is just example code, I heard that it's not wise to put fundamental actions inside assert's, because in some compilation settings the entire assert line might be optimized away - and with it, reader would never open "out.bin".

[Glocke]

Aw, no namespace? That is always nice having in libraries you want to distribute.

Yes, that's right! The code pieces are small and not really related to each other. So I don't see a necessary to introduce namespaces. But this might change in future

Also, in your second example code:

    // load that archive
    TexArchiveReader reader;
    assert(reader.open("out.bin"));

Even if is just example code, I heard that it's not wise to put fundamental actions inside assert's, because in some compilation settings the entire assert line might be optimized away - and with it, reader would never open "out.bin".

Well good point! I'm not quite sure whether the checking is the only thing that's "optimized away". If the entire expression is dropped, you're totally right! But maybe only the checking is optimized away. So the assertion might be replaced by the previous evaluation - without asserting it at runtime. If the expression is pure const, the compiler might also optimize it away... don't know how it's done, sry.

But thanks

[Jesper Juhl]

assert()s are usually macros that are simply not defined in release builds, so they go away completely. That includes any code passed as arguments. So you should never put any code with side effects in an assert.

[Glocke]

assert()s are usually macros that are simply not defined in release builds, so they go away completely. That includes any code passed as arguments. So you should never put any code with side effects in an assert.

Ok thanks! I'll change this soon!

[Glocke]

Hi there!

I just pushed a major API change / repository cleanup to the repository. Here's a (brief) list of changes:

General:

• seperation of example and testing
• assert() is now evaluating real expressions (instead of method calls' return values)
• added namespace sfext
• added resources from "battle for wesnoth" (see README) to ship compilable examples with the framework
• dependencies are now stated: C++11, SFML 2.2, Boost.Math, Thor

Image Atlas:

• API cleanup: one public class for the entire altas generation
• some internal improvements
• updated, compilable example
• seperate unit testing

Resource Caching:

• a cache can now hold multiple resources of multiple types
• resource archives are removed (at least temporarily)
• updated, compilable example
• seperate unit testing

Thanks for reading View the repository https://github.com/cgloeckner/SfmlExt for further details

And thanks for your feedback (see red changes)

Kind regards,
Glocke

[Glocke]

And currently, I'm working on a tiling implementation. A attached an example screenshot.

[SpeCter]

Any reason you use push_back in your atlas.hpp to add the chunk instead of defining a constructor and using emplace_back instead?

[Glocke]

Any reason you use push_back in your atlas.hpp to add the chunk instead of defining a constructor and using emplace_back instead?

No, it's just laziness.. But that's a good idea!

/EDIT: But another solution (without defining a ctor) might be: emplace_back without arguments, calling back() to get the reference and than set the properties. Writing a ctor isn't really necessary, because there's only one spot where a chunk is initialized, and there is no RAII-critical data access.

[Ixrec]

I suspect a push_back(args) isn't all that different from an emplace_back() followed by thing.setArgs(args).  Probably shouldn't worry about it until you have profiler data showing it makes a difference.

[SpeCter]

I only asked because emplace_back describes more clearly that he only wants to move a temporary into the vector, not for performance reasons 

[Glocke]

Hi, about that push_back/emplace_back: I'll think about it which fit's the code best!

Update on SfmlExt:
I just finished an initial tiling implementation. It's main use is to encapsulate common tiling operations like iterating all visible tiles - or briefly:

for (auto const & tile_pos: scene) {
    // ... render this tile
}

Here's a list of features:

• Coordinate transformation (world <-> screen)
• Range-based iteration (based on a fixed tile size and a sf::View used as camera to determine range)
• Get a tile position's neighbors (which is different from orthogonal to hexagonal grids etc.)
• Check a position whether it is valid (based on a fixed map size) - useful when working with neighbors

There's also an example you can check out! Again, everything is located at http://github.com/cgloeckner/SfmlExt (including compilable examples).

About the implementation and possible usage:

• A range-based iteration can be used for rendering, where you want to access each visible tile position once. After iteration you can change the camera to e.g. render the second scene (e.g. for splitscreen) using the same tiling-instance.
• The actual tiling approach (called "GridMode") is given as template-argument. I don't know of any usecase where the type of the tiling might change while runtime. Also compile-time polymorphism improves the speed of e.g. iteration, because the actual operator++ is determined at compile-tile. Currently supported grid modes are orthogonal and diamond-shaped isometric maps. Other maps (e.g. hexagonal or staggered isometric) might be implemented some day (I don't need them at the moment).
  
• The example provides using different tiling modes in one application (just for presentation purpose). Maybe a splitscreen example using one mode will be written some day^^

Feel free to discuss about implementation or API details.

Kind regards
Glocke

[Glocke]

Hi, today I had enough time to finish working on a simple menu-gui-system. The commit was just pushed, so implementation and example code can be found on GitHub!

An overview:

• A Menu class is used as context, widget container and widget factory.
• All widgets appearance and behavior can be customized
• Keybindings (including "Joystick-bindings") are available through thor::Action
• Mouse support is not planned. The menu is designed as pure left-right-up-down-activate-styled menu
• Currently "implemented" widget: button, checkbox, selectbox.

See the example code for further details! Feel free to feedback about this commit

Kind regards
Glocke

PS: A screenshot of very simple menu example is attached.

[Glocke]

Meanwhile, initial implementations for a context-related state machine / application wrapper class and a blueprint for logging mechanics with support for various SFML-types (like Vector2<T>) has been finished.

Feel free to feedback

[Glocke]

Today, I added an initial implementation for audio fading. The fading is determine by two lambda functions (for fading in and fading out) which can be modified during runtime.

There's a MusicManager class which is able to fade between two music track just by triggering another one to be played! Full commit can be viewed here. The code is currently out of comments - this will be fixed soon!

A runnable example is located at the github repository. But here is "fader in a nutshell" - hope you like it!

#include <SFML/Window.hpp>
#include <SFML/Audio.hpp>

#include <SfmlExt/fader.hpp>

int main() {
        auto t = sf::milliseconds(50);
        sfext::MusicManager manager;
        float volume = 100.f;
       
        manager.play("data/wesnoth.org/battle_edit.ogg");
       
        while (true) {
                if (sf::Keyboard::isKeyPressed(sf::Keyboard::Return)) {
                        // fade-in / cross-fade
                        manager.play("data/wesnoth.org/battle_edit.ogg");
                }
                if (sf::Keyboard::isKeyPressed(sf::Keyboard::Space)) {
                        // fade-out
                        manager.stop();
                }
                if (sf::Keyboard::isKeyPressed(sf::Keyboard::Up)) {
                        // volume up
                        volume = std::min(100.f, volume + 5.f);
                        manager.setMaxVolume(volume);
                }
                if (sf::Keyboard::isKeyPressed(sf::Keyboard::Down)) {
                        // volume down
                        volume = std::max(0.f, volume - 5.f);
                        manager.setMaxVolume(volume);
                }
               
                manager.update(t);
                sf::sleep(t);
        }
}