Selba Ward

[Laurent]

I used it to display the code for the Ring example in front of a Ring

Not as cool as a console that shows the code that shows the console

[dabbertorres]

There you go, make a sw::Quine SFML drawable!

[Elias Daler]

I used it to display the code for the Ring example in front of a Ring

Not as cool as a console that shows the code that shows the console

What about a ring console?

[Hapax]

Not as cool as a console that shows the code that shows the console

I suppose that's easy enough but it might be a large image and wouldn't look anywhere near as pretty!

Writing the code to the Console Screen was pretty simple. The colouring, however, was done manually, like using a highlighter pen (I'm considering adding a feature to aid in this).

(click to show/hide)

The code (cs is the Console Screen):

cs.printLine("#include <SFML/Graphics.hpp>");
cs.printLine("#include <SelbaWard/Ring.hpp>");
cs.printLine("int main()");
cs.printLine("{");
cs.printLine("    sf::Texture texture;");
cs.printLine("    if (!texture.loadFromFile(\"resources/uv map.jpg\"))");
cs.printLine("        return EXIT_FAILURE;");
cs.printLine("    sf::RenderWindow window(sf::VideoMode(200, 200), \"Ring simple example\");");
cs.printLine("    sw::Ring ring(100.f);");
cs.printLine("    ring.setTexture(texture);");
cs.printLine("    while (window.isOpen())");
cs.printLine("    {");
cs.printLine("        sf::Event event;");
cs.printLine("        while (window.pollEvent(event))");
cs.printLine("        {");
cs.printLine("            if (event.type == sf::Event::Closed)");
cs.printLine("                window.close();");
cs.printLine("        }");
cs.printLine("        window.clear();");
cs.printLine("        window.draw(ring);");
cs.printLine("        window.display();");
cs.printLine("    }");
cs.printLine("    return EXIT_SUCCESS;");
cs.printLine("}");

That's right. I didn't even read it from a file; I displayed it manually. Should've used the file; it would've been even easier! 

There you go, make a sw::Quine SFML drawable!

Quine seems to be beyond the scope of a drawable since the drawable itself is only an object that is drawn by the application.
It should be pretty easy to do too - if you relax the rule about not being able to access the code via file input.

For a moment, I thought you had a genuine drawable suggestion and I was excited 

What about a ring console?

Technically, a ring console should be possible - and pretty easy to do:
Render the Console Screen to a render texture.
Use that render texture to supply the texture to the Ring.
Voila! 
Ring's been upgraded, by the way. For a start, it can now draw a sector of a ring (like an arc with a thickness and texture) 

[Hapax]

Added new object: Crosshair



You assign a window to this object, optionally set its colour(s) and draw it. It takes care of everything else itself!
Note that it's bound to the mouse cursor's position but doesn't draw the crosshair when the mouse is outside of the window's client area.

[Mario]

I guess the crosshair is meant for debugging purposes? You should print the current coordinates next to the cursor, possibly world above, screen below - or something similar.

[Hapax]

It could be used for debugging, sure, but there are applications where a crosshair is useful. Targeting in a game or positioning in a drawing/designing application, for examples.

Crosshair does output its position so it should be trivial to output that position to next to the mouse cursor (it's trivial to do that manually anyway). Of course, drawing that information inside Crosshair makes it a lot bulkier and requires font and text work, not least to assume the size and position of the mouse cursor for correct placement.

Try it with a disabled mouse cursor. It's delightful! hehe

I used a similar class to draw a Spline while I was testing that class. Drawing them is much better with a crosshair than a pointer 

[roccio]

Awesome work!
It would be great to have also polylines

[Hapax]

Awesome work!

Thank you very much! Glad you like it 

It would be great to have also polylines

Polylines have already implemented as Spline. However, giving the spline a thickness has not (yet) been implemented.

[Hapax]

Added new object: Starfield

[Nexus]

Nice utilities! The console is really cool! And I like the library name, too

Many of the drawables shown here however are very specific. They're nice to play a bit around, but integrating them as-is in a game is difficult. I'm not sure what your plan is; it could be nice to provide configurable building-block style drawables that can be composed to build more complex objects, so that one has a greater chance of reusing them.

[roccio]

Polylines have already implemented as Spline. However, giving the spline a thickness has not (yet) been implemented.

Polylines are much more than lines with thickness. They have also the connection between lines and could have also a texture.

Anyway your library is growing better and better.

[Hapax]

Nice utilities! The console is really cool! And I like the library name, too

Thank you. I really appreciate that!

Many of the drawables shown here however are very specific. They're nice to play a bit around, but integrating them as-is in a game is difficult. I'm not sure what your plan is; it could be nice to provide configurable building-block style drawables that can be composed to build more complex objects, so that one has a greater chance of reusing them.

I'd like to know more about which drawables you are refering to. Most are a rather generic (SFML-style) version that should be able to be re-used. Which ones do you think would be difficult to integrate into a game? I'm interested in upgrading everything to be of more use.
I am unsure about the building-block idea, mainly because most of the drawables are completely different but also (I'm not sure if people actually care about this) as they can be used without the others.

Polylines are much more than lines with thickness. They have also the connection between lines and could have also a texture.

Without getting too much into a debate on definitions, I didn't say that polylines had thickness. Polylines are, in fact, multiple lines connected and treated as a single object (poly = multiple, line = straight connection of two points). Spline does this but doesn't have the ability to have thickness or texture.
Line, on the other hand, does single lines but allows thickness and may have texturing in the future.
I plan to expand Spline to have thickness (where each line connects properly at each angle change) and will probably completely remove the need for Line.
I foresee texturing a Spline/polyline that has thickness and correct "corners" to have problems. Since each segment/line is no longer a perfect rectangle, texturing becomes a bit complicated. Should the corner of the texture be chopped off at corners or stretched to match the vertices? I think the former is better target.

Anyway your library is growing better and better.

Thank you very much. I hope you find it useful 

[Nexus]

You're right, I had a closer look and many drawables are indeed flexible and reusable, Ring being a good example. I'll list a few that I consider rather specific/limited and explain why:

• Starfield: It's rather unlikely that one uses exactly such a drawable in a game. The graphics style would have to fit exactly, and there are usually other features involved (parallax, other planets/galaxies/ships in background, blinking stars, animations, particles). And it would not even help a lot if you heavily pushed Starfield's features, because scenery is unique to every game.
• Crosshair: It's similar here, users that need a crosshair probably have their own sprite for it, and may animate it/swap it depending on the game's context.
• ProgressBar: It's generally very difficult to make UI widgets useful. In order to be reusable, they must support all kinds of state-of-the-art features that can be expected from nowadays' UI, and their graphical appearance must be fully customizable to fit into many different applications.

I've also made some predefined shapes in Thor, but I soon realized that they're not as useful as I initially thought -- except for maybe lines, they're nice in debug graphics, but that's it. The pie shape that still existed in Thor 1.1 was even removed in 2.0, because it was far too specific for Thor's scope.

In the APIs, I would personally not provide many different ways to achieve the same. It seems to be convenient, but keep in mind that bigger APIs are automatically more complex, and there's more that the user has to remember. As an API user, I never know if there's an actual difference between the methods, or only a syntactic one. Minimal APIs are also SFML's philosophy. Concrete examples:

• PieChart::setRadius/setDiameter do the same, the factor 2 can easily be specified on user side
• Starfield and a few other classes provide various constructors for attribute combinations. This is not always intuitive, because the call site doesn't see what each parameter refers to. It quickly becomes impossible to remember the supported combinations, and it gets very error-prone when two parameters have the same type. This is also the reason why SFML has removed its earlier mass parameter constructors to initialize its drawables in one line.
• A create() method is not needed if the class has a constructor and is move-assignable.
• Instead of many boolean parameters with default values, you could provide an enum whose constants can be combined with bitwise OR.
• For overloads of a method with reference and pointer parameters of the same type, it's not clear if both mean the same, and if there is an actual purpose besides letting the user omit the address operator. It's even more confusing if you provide a reference overload and a std::nullptr_t overload, but no pointer overload.
• Is the default parameter of setXyEnabled(bool enabled = true) really needed? I'm not sure if the ability to call obj.setXyEnabled() without arguments is such a big advantage; it may make users wonder why there's no obj.setXyDisabled() counterpart.
• Something else: virtual void ConsoleScreen::draw(sf::RenderTarget& target, sf::RenderStates states) const; is not a valid declaration.

I find it really nice that you wrote tutorials that explain every single thing in so much detail. It takes quite a lot of effort, also to maintain this if you change the code. In that respect, something like Doxygen could also be worth some thoughts (you don't have to document obvious methods, a class description with examples -- essentially your current tutorials) is already very nice. When the description is in the code, it's less likely to forget updating it. And with a small API, the documentation is also considerably easier and faster to write and maintain

[Hapax]

Nexus, I am honoured that you have had a look through my code and I am grateful that you have taken the time to comment on it and its design.

I'll attempt to address everything that I can.

The 'collection' has a varied range of objects. Not just varied in what they're supposed to be/do but varied in their simplicity. Some are simple and quite limited whereas others can complex and relatively thorough.

You are right about Starfield's limit. This is possibly one of the most limited objects - as you mentioned. I think, though, that it would be useful in some games (probably more simple or "retro"-looking ones) but less so in games that have very complex space scenes. For example, it could be used in things like Asteroids or side-scrolling space shooters such as Defender or R-Type, or even just as a background for high-scores  It's meant to be a simple and quick way to have this effect in action.
One other point is that is can be any size, so it could be placed in a small sub-display, where space scenes could be too complex to be shown in a lot of detail.
That was the idea behind it anyway.

Crosshair: again you are right about its limits. This is another that is designed for ease of use rather than customisability. I, personally, will be using it for things like designer applications where lining up things are important but I can understand if people just skip this object completely.

I feel differently about ProgressBar. It's true that most UI details are usually custom made to match a style. Progress bars, however, can be rather universal; at least, the more simple ones can. It's quite customisable (like a rectangle shape, for example) and now that I've added anchor for the position of progression, it's easy to draw something at that position. Even if you don't actually draw the progress bar, the anchors can help with positioning.

Talking of shapes, I originally tried to create Ring as an sf::Shape; that was obviously short-lived as I realised it couldn't create it!

I'm not sure how I feel about API's complexity, especially in complex code. I have been concious of keeping the APIs relatively complex i.e. the more complex the object, the more flexibility; the more simple the object, the more restrictive.

I actually have a reason that Pie Chart has both radius and diameter methods. I created it based on the overall size - and therefore its diameter, not its radius - so the diameter is the primary method. I added the radius helper method as most people using SFML are used to using radius.

The multiple parameter constructors are kept relatively rare, especially with similar types. Ring's constructor's parameters, however, were based on SFML's circle shape as I wanted it to be similar to use.
Starfield, on the other hand, is meant to be quickly created in a short way. All of its parameters are of different types. I'm not happy with its current range of overloads for regenerate(). I think it needs more! 

I am assuming you are referring to Console Screen when you mention create()? I don't think any other object uses one. I'm not sure I understand your point on this. Create in this case (the way I see it) is equivalent to a "resize grid". If you wanted to change the number of cells in the screen, it would be (for example):

consoleScreen.create({40, 20});

With your suggestion of replacing it with move assignment, it would (I believe) look like:

consoleScreen = sw::ConsoleScreen({40, 20});

or have I misunderstood somewhere?

I'm not sure if or-ing enumerators is better than explicit booleans. It may just be seeing it too much during Windows programming that has put me off. I'll have to re-evaluate this. 

I suppose that the reference and pointer parameter overloads can be confusing. The main reason behind the null pointer overloads is to allow specifying parameters via reference instead of pointer but also allow nullifying such object. Console Screen's setTexture() is one example. Crosshair allows passing of either a reference or pointer (which can be null and is by default). This is only in the constructor though - not in setWindow(). I think this was an oversight and they should match.
I will have to consider whether or not pointers should also be able to be passed. If not, the pointer parameter should be changed to a null pointer type (as in Crosshair's setWindow()). If they should be allowed, pointers should be allowed everywhere.

The default values for "enabled" boolean setters, in my view, make more sense grammatically. I think I would personally prefer enable and disable methods, or the method not having "Enabled" in its name, but I used this naming scheme to be closer to how SFML names its methods. I think, if it has enabled in its name, it should be able to enable without having to specifically specifying that it's true that you want it to.
setShowCursorEnabled(); makes sense on its own. You are right, of course; it does seem to be odd without its setShowCursorDisabled(); counterpart. Having Enabled without Disabled is odd, even in SFML 
I think I would prefer one of:
setShowCursorEnabled() and setShowCursorDisabled(),
setCursorEnabled() and setCursorDisabled(),
enableShowCursor() and disableShowCursor(),
enableCursor() and disableCursor(),
just setShowCursor(bool) without a default parameter
Mainly, if it has enabled, it probably should have disabled. I added enabled because SFML does.

I did consider the Doxygen route. Some reasons came up that caused me to choose otherwise:

• like CMake, I've had trouble with it in the past so I have a very slight irrational hatred for it,
• I don't know if it's possible to update the GitHub wiki automatically from the code, and
• I'm used to "tighter code" during development,

Because of the latter point, and the fact that Selba Ward is the most recent project I have that is on GitHub but not working directly on the repository, I feel maintenance may even be more difficult.
Again, it's something to consider for the future.

virtual void ConsoleScreen::draw(sf::RenderTarget& target, sf::RenderStates states) const; is not a valid declaration.

Fixed.
An embarrassing oversight. Nice catch; thank you!