-
Welcome to Selba Ward!
.................."check in to check it out"
(http://i.imgur.com/0k0um5B.jpg) (https://github.com/Hapaxia/SelbaWard/wiki)
Introduction
Selba Ward (https://github.com/Hapaxia/SelbaWard/wiki) is a collection of generic, reusable and flexible drawable objects for SFML.
Objects
Currently available objects:
- Bitmap Text (https://github.com/Hapaxia/SelbaWard/wiki/Bitmap-Text)
- Console Screen (https://github.com/Hapaxia/SelbaWard/wiki/Console-Screen)
- Crosshair (https://github.com/Hapaxia/SelbaWard/wiki/Crosshair)
- Elastic Sprite (https://github.com/Hapaxia/SelbaWard/wiki/Elastic-Sprite)
- Gallery Sprite (https://github.com/Hapaxia/SelbaWard/wiki/Gallery-Sprite)
- Line (https://github.com/Hapaxia/SelbaWard/wiki/Line)
- Nine Patch (https://github.com/Hapaxia/SelbaWard/wiki/Nine-Patch)
- Pie Chart (https://github.com/Hapaxia/SelbaWard/wiki/Pie-Chart)
- Pixel Display (https://github.com/Hapaxia/SelbaWard/wiki/Pixel-Display)
- Polygon (https://github.com/Hapaxia/SelbaWard/wiki/Polygon)
- Progress Bar (https://github.com/Hapaxia/SelbaWard/wiki/Progress-Bar)
- Ring (https://github.com/Hapaxia/SelbaWard/wiki/Ring)
- Spinning Card (https://github.com/Hapaxia/SelbaWard/wiki/Spinning-Card)
- Spline (https://github.com/Hapaxia/SelbaWard/wiki/Spline)
- Sprite 3D (https://github.com/Hapaxia/SelbaWard/wiki/Sprite-3D)
- Starfield (https://github.com/Hapaxia/SelbaWard/wiki/Starfield)
- Starfield 3D (https://github.com/Hapaxia/SelbaWard/wiki/Starfield-3D)
- Tile Map (https://github.com/Hapaxia/SelbaWard/wiki/Tile-Map)
Usage
Selba Ward (https://github.com/Hapaxia/SelbaWard/wiki) can be built as a single library and then the objects can be included as required (as I use it myself) or the individual objects can be copied into your project and built along with it. The drawable objects are completely independant of each other. However, they will also require the very light Common.hpp header, along with any dependants (e.g. Bitmap Text requires Bitmap Font) or extras (e.g. Palette Enums can be useful with Console Screen)
Future Objects
Small and quick objects can usually be added quite quickly when they are added to the to-do list.
Suggestions will be taken into serious consideration, even larger objects.
SFML
All objects in Selba Ward (https://github.com/Hapaxia/SelbaWard/wiki) require SFML version 2+. The latest version is recommended, although some objects may not have been tested with that version.
Feedback
As always, feedback (on the currently available objects, their interface, or the underlying code) is highly appreciated.
Suggestions for objects will also be taking into consideration.
Please report any problems with specific versions of SFML to me. This thread can be a good place for that.
Demo Animation
Best viewed in 1080 quality and 60 FPS.
http://www.youtube.com/watch?v=Yjs-oRhn2fE
Examples
Console Screen
Simple example:
(http://i.imgur.com/Oe75aRo.png)
Showing some attributes:
(http://i.imgur.com/qShsYGM.png)
Starfield 3D
Simple example 2:
(https://i.imgur.com/3NnjF8r.gif)
Sprite 3D
Simple example:
(http://i.imgur.com/A4869Z3.png)
Polygon
(https://i.imgur.com/b6th5VC.png) (https://i.imgur.com/ZDJSZp6.png)
Spline
Simple example (thick):
(http://i.imgur.com/2zzYDrD.png)
Simple example (thick with rounded corners and caps):
(https://i.imgur.com/JzyDo0i.png)
Simple example (thick curve):
(http://i.imgur.com/wpNKarD.png)
Simple example (thick curve with rounded corners and caps):
(https://i.imgur.com/AZTZiQd.png)
Simple example (thick and closed with anti-aliasing):
(http://i.imgur.com/t85IW67.png)
Simple example (per vertex colour and thickness with anti-aliasing):
(http://i.imgur.com/yUP6VrZ.png)
Elastic Sprite
Simple example (texture):
(http://i.imgur.com/zodshBH.png)
Simple example (colour):
(http://i.imgur.com/eorXw2D.png)
Simple example (texture and colour):
(http://i.imgur.com/2Ok37Pn.png)
Simple example (perspective interpolation):
(http://i.imgur.com/gcg39PI.png)
Bitmap Font
Simple example:
(http://i.imgur.com/Er0fpAZ.png)
Same font and texture as in the simple example but with font setup:
(http://i.imgur.com/8KrxKfS.png)
Progress Bar
Simple example:
(http://i.imgur.com/GUzgNDI.png)
Example (https://github.com/Hapaxia/SelbaWard/blob/master/examples/progressBarExample.cpp) (cropped):
(http://i.imgur.com/aXcb6ZG.png)
Tile Map
Simple example:
(http://i.imgur.com/MZAWrBD.png)
Pie Chart
Simple examples:
(http://i.imgur.com/eDYNfda.png) (http://i.imgur.com/zgLFBu9.png) (http://i.imgur.com/0Q9pVia.png)
Ring
Simple example:
(http://i.imgur.com/76RUYvz.png)
Pixel Display
(https://i.imgur.com/SefOZbM.gif)
Nine Patch
Simple example:
Texture:
(http://i.imgur.com/Vye2MTt.png)
Screenshot:
(http://i.imgur.com/qRk0t9Q.png)
Starfield
Simple example:
(http://i.imgur.com/vfO63YV.png)
Crosshair
Simple example:
(http://i.imgur.com/8TZC8e9.png)
The code for each "simple example" is provided in the Selba Ward wiki (https://github.com/Hapaxia/SelbaWard/wiki) on the object's page. Other examples can be found in the examples (https://github.com/Hapaxia/SelbaWard/tree/master/examples) folder
Thank you for reading and I hope you find Selba Ward (https://github.com/Hapaxia/SelbaWard/wiki) useful!
Selba Ward is available here on GitHub and is under the zLib licence (same as SFML). (https://github.com/Hapaxia/SelbaWard/wiki)
EDIT: Added link for Polygon (from the list) and removed the listing of the old Console Screen as its no longer available.
-
Sounds interesting. Thanks for putting together and sharing! :)
-
I see it! draW ableS ;)
-
I see it! draW ableS ;)
Ha-ha, that's clever :D
The library looks pretty neat. I looked at the implementation and my implementation of the stuff I use (line and bitmap text) is pretty similar to yours, so now I'm relieved that I did things pretty okay :D
-
that really a cool stuffs, thanks for sharing.
wiki info and min-examples are indeed comprehensive and simpified, i'm sure it will be useful for others
-
Sounds interesting. Thanks for putting together and sharing! :)
I try to share most of my stuff. Eventually ;)
I would like to develop the objects further so if you have any suggestions for improvements or any new objects, I'll be glad to hear them!
The library looks pretty neat. I looked at the implementation and my implementation of the stuff I use (line and bitmap text) is pretty similar to yours, so now I'm relieved that I did things pretty okay :D
Thanks! Similarly, it's nice to hear that I did things the right way so it's good to know that you did it in a similar way :)
that really a cool stuffs, thanks for sharing.
wiki info and min-examples are indeed comprehensive and simpified, i'm sure it will be useful for others
Thanks and you're welcome!
Others? I use this stuff myself all of the time!
In fact, since I have started to rebuild Faux Car from scratch, I have used a couple of these already for informational purposes (progress bar, for example) and will almost definitely be using Bitmap Text there too! ;) (The old Faux Car used the original version of Console Screen for the bitmap text display, which I'm rewriting)
New ideas for objects usually come up when I have a need for them. They are then "generified" to be usable in different situations. If you have an idea for an object, let me know!
I see it! draW ableS ;)
Bah! I was hoping it would take longer to be noticed :P
(Mini-trivia: I also considered the idea of calling it Selb Award!)
-
Very cool stuff, indeed useful ;) Thanks, as always Hapax.
I will take a look especially at Progressbar, because that's something I want to implement in the next weeks.
-
In fact, since I have started to rebuild Faux Car from scratch, I have used a couple of these already for informational purposes (progress bar, for example) and will almost definitely be using Bitmap Text there too! ;) (The old Faux Car used the original version of Console Screen for the bitmap text display, which I'm rewriting)
this is really a great news that a new version of Faux car will be out soon :)
(IMHO) Faux car is top game, specially when you added 3 cameras to the scene, it gives fabulous effect to the game. honestly i don't know how you did that but it is considered a credit for you as experienced programmer. i'm really admire your job in this kind of games. personally i can't wait to see a new version of Faux car.
New ideas for objects usually come up when I have a need for them. They are then "generified" to be usable in different situations. If you have an idea for an object, let me know!
for objects
unfortunately i can understand what you mean by "generified". :-\
for my understanding, there are two kind of objects static and movable, the static objects like trees and billboards ..etc are easy to implements and nothing fancy can be done to them, however the movable objects is indeed worth to experiment a new ideas specially the AI, it is bit trickier but it well make the game more excited.
-
Handy stuff, and super clever name!
-
Nice.
Is that stuff you did for other projects of yours or do you develop the library as a project itself?
-
Handy stuff, and super clever name!
Thank you!
Very cool stuff, indeed useful ;) Thanks, as always Hapax.
I will take a look especially at Progressbar, because that's something I want to implement in the next weeks.
Thanks. Glad you like it!
Why implement it when it's already available to use? ;)
Nice.
Is that stuff you did for other projects of yours or do you develop the library as a project itself?
Thanks!
Most of the objects come from my own necessity. If I end up needing an object more than once, I will usually make a generic version. Using Selba Ward to keep this together also forces me to make sure that each object is separate so I have to remove any use of any libraries I may normally use (usually my own small helper libraries) inside them.
Some have come into existence for other reasons. Spinning Card, for example, was created as a challenge for myself to show how to effectively fake a rotating playing card without using any actual 3D. Sprite3D was then a massive overhaul and improvement on that to actually rotate a sprite in 3D space using only Vertex Arrays.
this is really a great news that a new version of Faux car will be out soon :)
(IMHO) Faux car is top game, specially when you added 3 cameras to the scene, it gives fabulous effect to the game. honestly i don't know how you did that but it is considered a credit for you as experienced programmer. i'm really admire your job in this kind of games. personally i can't wait to see a new version of Faux car.
Thank you for your kind words but I would not consider myself to be "experienced".
The camera views were quite simple (although took a lot of exact tweaking): offsets for positions and moving the vanishing point. The car sprite was rendered afterwards to match.
The newer version was created with much more flexibility - the camera can be moved around and the vanishing point can be moved anywhere!
When I get it to a similar point to where it was before, I'll start posting updates in the Faux Car thread :)
New ideas for objects usually come up when I have a need for them. They are then "generified" to be usable in different situations. If you have an idea for an object, let me know!
unfortunately i can understand what you mean by "generified". :-\
for my understanding, there are two kind of objects static and movable...
The objects that I was talking about are for here (in Selba Ward) and I invented the word "generified"*. It basically meant to make more generic so that it is transportable and can be used in lots of situations.
*I thought I invented the word but it looks like the internet beat me to it.
the movable objects is indeed worth to experiment a new ideas specially the AI, it is bit trickier but it well make the game more excited.
As for the AI in Faux Car, I'm looking forward to eventually finishing the track drawing engine and creating a track designer so that I can hopefully eventually make a game from it! ;D
-
Cool stuff, Hapax! And great presentation -- especially the name is neat. :P
-
Progress bar looks cool! Gonna use it. :)
-
thanks for sharing it, that's cool, probably gonna use it :)
-
Cool stuff, Hapax! And great presentation -- especially the name is neat. :P
Thank you! Much appreciated :)
Progress bar looks cool! Gonna use it. :)
Good to hear!
Remember that the sizes and colours can be customised. It inherits from sf::Transformable too so it can be transformed as usual! ;)
thanks for sharing it, that's cool, probably gonna use it :)
Thanks! Glad you like it :)
-
Added new object: Nine Patch (https://github.com/Hapaxia/SelbaWard/wiki/Nine-Patch)
(http://i.imgur.com/9YyUzl0.png)
-
I'd probably use a different texture to show this off, maybe some borders similar to classic Windows 95 look. Just something that feels less "stretched", even if it isn't the case. :)
-
Your Sprite 3D thingy is just awesome! :) :)
I'll surely use it when i'm working on a new project. Thanks for sharing dude!
-
I'd probably use a different texture to show this off, maybe some borders similar to classic Windows 95 look. Just something that feels less "stretched", even if it isn't the case. :)
You're totally right. It was just a quick texture that I threw together to test it with. I'll have a look at something a little thinner around the edges ;)
Your Sprite 3D thingy is just awesome! :) :)
I'll surely use it when i'm working on a new project. Thanks for sharing dude!
Thank you!
Glad you like it and you're welcome :)
-
Added new object: Pie Chart (https://github.com/Hapaxia/SelbaWard/wiki/Pie-Chart)
(http://i.imgur.com/eDYNfda.png) (http://i.imgur.com/zgLFBu9.png) (http://i.imgur.com/0Q9pVia.png)
-
Created new Nine Patch texture so that it will no longer look stretched.
New texture:
(http://i.imgur.com/Vye2MTt.png)
New screenshot:
(http://i.imgur.com/qRk0t9Q.png)
-
Ah, that's a lot better. :) Didn't dig through the code so far. How do you scale the center parts? Do you repeat, stretch, or is there an option for this?
-
Thanks :)
The (non-corner) sections are scaled.
The object is based on this concept (http://developer.android.com/tools/help/draw9patch.html).
-
Nice stuff! I think I need to use this technique for menus in my game.
Here's how the sprite looks (scaled 4x):
(http://i.imgur.com/JlShitu.png)
You can use this sprite as an example on github if you want :D
-
Menues must be the reason that the 9patch exist.
@Elias Here's the texture you'd need to recreate that texture you just posted using Selba Ward's Nine Patch!
(also scaled x4)
(http://i.imgur.com/6dwmePv.png)
Here's the actual texture:
(http://i.imgur.com/h3DU8WL.png)
The result when used in the example (no cursor shown):
(http://i.imgur.com/D5Uf3uE.png)
One good thing about it is that the setup is all in the texture; there's no need for extra data. The parts that stretch are indicated inside the image file itself!
-
Yeah, it's cool that it saves lots of place and I can reuse this in a lot of ways. I can even draw a transparent border and then use some tiled texture for the background (which can lead to some customization like most of the old RPG's allowed you to do :D)
Btw, why isn't is completely symmetrical?
-
Btw, why isn't is completely symmetrical?
It's the encoded data. It requires a transparent border that is one-pixel thick. In that border, black lines describe how it is to be used. The black line on the top and left show which part of the texture is to be stretched. Selba Ward's version doesn't make use of the right and bottom lines, which describe where content should go, although I will be adding a way to retrieve that information.
The black lines don't have to be two-pixels (or more) long, they can be just a single pixel!
My version has the added bonus that if no black lines (guides) are present, the entire image is stretched to match the given size. Can be useful if you need to rescale to a specific size rather than scale.
(http://i.imgur.com/ZE653Oq.png)
Have a look at my previous post. I edited it to show my version of your texture in use! :)
EDIT: For more information on the 9patch and a view of what the black lines look like on all four sides, see this article (http://developer.android.com/tools/help/draw9patch.html).
-
Oh, that's pretty clever! Stretched box looks great. :D
-
Cool thing, but I only know that technique as 9-Slice though :D
-
Oh, that's pretty clever! Stretched box looks great. :D
Nine Patch is really new to me - I only saw it for the first time a few days ago - but as soon as I saw it, I knew I had to implement it!
Cool thing, but I only know that technique as 9-Slice though :D
Thanks :)
I just looked up "9 slice" and I see what you mean! It looks like it's also called that by other companies. I guess you can always:
sw::NinePatch nineSlice;
;)
-
Added new object: Console Screen (https://github.com/Hapaxia/SelbaWard/wiki/Console-Screen)
(http://i.imgur.com/cHFYp9S.png)
-
Great work Hapax!
-
Added new object: Console Screen (https://github.com/Hapaxia/SelbaWard/wiki/Console-Screen)
(http://i.imgur.com/cHFYp9S.png)
Impressive, even the character set matches. Brings back memories of memcpy'ing junk to (far *) 0xb8000000... Only missing is blinking support ;)
-
it looks awesome, good job :)
-
This could be particularly helpful maybe for Slice 9(aka 9 Patch):
http://renderhjs.net/shoebox/
-
This could be particularly helpful maybe for Slice 9(aka 9 Patch):
http://renderhjs.net/shoebox/
I had a look at this. Not sure how much help you need to make Nine Patch textures, though. Just mark the black pixels where they can stretch :P
Great work Hapax!
Thanks!
it looks awesome, good job :)
Thanks!
Impressive, even the character set matches.
I created the texture myself...from a screenshot of a Windows console after printing out the entire ASCII set:
(http://i.imgur.com/kP2AnrB.png)
It was edited to change the characters from the default grey to the final perfect white.
Afterwards the background was removed (not in the image shown above) to allow just the characters to be used in Console Screen, since Console Screen can display its own cell backgrounds.
#include <Dev.hpp>
#include <Plinth.hpp>
int main()
{
DEV::KeepConsoleOpen keepConsoleOpen;
const bool displayCharacterIndex{ false };
const unsigned int gridWidth{ 16u };
for (unsigned int y{ 0 }; y < 256 / gridWidth; ++y)
{
for (unsigned int x{ 0 }; x < gridWidth; ++x)
{
const unsigned int index{ y * gridWidth + x };
std::string output;
if (displayCharacterIndex)
output += pl::padStringLeft(pl::stringFrom(index), 3) + ": "; // display character index
if (index != 7 && index != 8 && index != 9 && index != 10 && index != 13)
output += static_cast<char>(index);
output = pl::padStringRight(output, (displayCharacterIndex ? 8 : 1)); // pad to 8 cells (for displaying character index) or 1 cell (for characters only)
std::cout << output;
}
std::cout << '\n';
}
return EXIT_SUCCESS;
}
Console Screen has been around for a while - I used it to display the (bitmap) text overlay UI in Faux Car (http://i.imgur.com/RLXRRb7.jpg) and I used it to display the tile map when creating the base for a platform game (http://i.imgur.com/grlQLGj.png) - but I rewrote it (line by line) for Selba Ward. Although, in the future, Faux Car would probably use Selba Ward's Bitmap Text instead, and the platform game would probably use Selba Ward's Tile Map (still to come!). This version of Console Screen doesn't have all of the features of the original version but I plan to reintroduce them over time (not too long, hopefully!)
EDIT: corrected paste error in code inside spoiler
-
Argh I forgot that you have to mark them with your system:D
-
Argh I forgot that you have to mark them with your system:D
Have to? I'd argue that the convenience of just adding - visually - the area that you wish to use in a standard image file can be simpler than using meta-data along with a custom file type :P
The software you linked to, by the way, also creates the version with the black line guides. At least, it mentions that it should but it "doesn't work yet but it will". ;D
-
Hehe, I didn't intend to make it sound negative, I just forgot that you have to do it that way if you intend to use your system.
I just worked without the black bars so far, so it feels more "natural" to me to use text files to describe which part goes where and which part is supposed to be stretching etc. which isn't supposed to mean your way is inferior, just that I didn't use it that way(until now)
-
I created the texture myself...from a screenshot of a Windows console after printing out the entire ASCII set
Your efforts are greatly appreciated! It's hard to describe the joy of seeing that authentic console window :)
By the way, the Hercules graphics card (and some later compatible ones) used 14x9 font that looked much better than CGA's 8x8 - you can view the bitmap here (https://en.wikipedia.org/wiki/IBM_Monochrome_Display_Adapter).
-
Hehe, I didn't intend to make it sound negative, I just forgot that you have to do it that way if you intend to use your system.
I just worked without the black bars so far, so it feels more "natural" to me to use text files to describe which part goes where and which part is supposed to be stretching etc. which isn't supposed to mean your way is inferior, just that I didn't use it that way(until now)
No worries!
I like the simple interface of the so-called Android way. You can design easily in an image editor. Either way could makes equal sense other than the fact that Selba Ward's Nine Patch does it this way! :P
I created the texture myself...from a screenshot of a Windows console after printing out the entire ASCII set
Your efforts are greatly appreciated! It's hard to describe the joy of seeing that authentic console window :)
By the way, the Hercules graphics card (and some later compatible ones) used 14x9 font that looked much better than CGA's 8x8 - you can view the bitmap here (https://en.wikipedia.org/wiki/IBM_Monochrome_Display_Adapter).
Glad you like it :)
The Windows Console that I captured was using a 8x12 font, which is what I used for that example.
I'm not sure what your link was aimed at but I didn't see the 14x9 font or 8x8 font you were referring to. There is, however, a 8x12 Windows font (or very similar) screenshot on that very page! ;D
-
Added new object: Ring (https://github.com/Hapaxia/SelbaWard/wiki/Ring)
(http://i.imgur.com/76RUYvz.png)
-
Take a look at the ibm monitor to see the 14x9 he was referring too.
-
The green display? It's not very clear, unfortunately. However, you can of course use these fonts in Console Screen ;)
Also, I didn't realise at first that size was being specified height-first.
-
Just another Console Screen example.
I used it to display the code for the Ring example in front of a Ring 8)
(http://i.imgur.com/hvtaxBb.png)
(click on image to see full size)
-
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 8)
-
There you go, make a sw::Quine SFML drawable!
-
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 8)
What about a ring console? ;D
-
Not as cool as a console that shows the code that shows the console 8)
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).
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! ;D
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? ;D
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! 8)
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) :)
-
Added new object: Crosshair (https://github.com/Hapaxia/SelbaWard/wiki/Crosshair)
(http://i.imgur.com/8TZC8e9.png)
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.
-
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.
-
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 ;)
-
Awesome work!
It would be great to have also polylines
(http://3.bp.blogspot.com/-HzNJi1xfN8A/UNaqwBGs1gI/AAAAAAAALpg/bPJa7Dr30zg/s1600/polylines.png)
-
Awesome work!
Thank you very much! Glad you like it :)
It would be great to have also polylines
Polylines have already implemented as Spline (https://github.com/Hapaxia/SelbaWard/wiki/Spline). However, giving the spline a thickness has not (yet) been implemented.
-
Added new object: Starfield (https://github.com/Hapaxia/SelbaWard/wiki/Starfield)
(http://i.imgur.com/vfO63YV.png)
-
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.
-
Polylines have already implemented as Spline (https://github.com/Hapaxia/SelbaWard/wiki/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.
-
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 (https://www.google.co.uk/#q=define+polyline) (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 :)
-
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 (http://www.bromeon.ch/libraries/thor/v2.1/doc/namespacethor_1_1_shapes.html), 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 (http://www.bromeon.ch/libraries/thor/v1.1/doc/namespacethor_1_1_shapes.html) 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 (http://www.sfml-dev.org/contribute.php#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 ;)
-
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 ;D 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! :o
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. ;D
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() (https://github.com/Hapaxia/SelbaWard/blob/master/src/SelbaWard/Crosshair.hpp#L55)). 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 :P
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 (https://github.com/Hapaxia/SelbaWard/blob/master/src/SelbaWard/ConsoleScreen.hpp#L181).
An embarrassing oversight. Nice catch; thank you!
-
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.
It's normal that complexity increases with functionality. What I was referring to is that the complexity of your API increases beyond that, because there are many methods for convenience. The same functionality can be easily provided with a fraction of the public methods, and I think it would help the user get a quicker overview and know what to use in which situation.
I am assuming you are referring to Console Screen when you mention create()?
Yes, and I assumed it would do the same as the constructor. Based on that: create() methods that (re-)initialize the object made sense in C++98 where it was expensive to copy-assign another object. With C++11 move semantics, this is almost free, and creating a new object assures that it's in a fresh state. One doesn't need to maintain code duplication in constructor and create().
Now that I realized it's not the same, I think the method should be renamed. "create" without further specifying the object leads to the assumption that a new object of the same class is created. Why not "resizeGrid"? And is that change actually needed or can the user achieve the same by creating a new object?
I'm not sure if or-ing enumerators is better than explicit booleans.
console.printAt(pos, 'A');
console.printCharAt(pos, 'A', true);
console.printCharAt(pos, 'A', true, true);
console.printCharAt(pos, 'A', sf::Color::White);
console.printCharAt(pos, 'A', sf::Color::White, true);
console.printCharAt(pos, 'A', sf::Color::White, sf::Color::Black);
There are 6 possible argument combinations for this simple method. The difference between those calls, as well as the meaning of the magic true values is impossible to know without learning the API by heart. Even when seeing the function declaration, it's still unclear what happens exactly when colors are overwritten -- which color is then used?
Expressivity is a core criterion for API quality. In my opinion, function overloads and default parameters are overused here -- interestingly, you did not use it for one of its main purposes: type inference. There's no harm in treating single chars and std::strings the same. By the way, character types should be char, not unsigned char. std::string also uses char.
It may be overkill in this situation, but since you use a lot of foreground-background color pairs, why not treat them as first-class citizens? For example as a type with named constructor idiom:
struct ColorPair
{
static ColorPair foreground(const sf::Color& color);
static ColorPair background(const sf::Color& color);
static ColorPair pair(const sf::Color& foregroundColor, const sf::Color& backgroundColor);
static ColorPair none(); // maybe find better names
// members and private constructor
};
With that, the method calls are much more expressive. A user actually knows what happens when reading the code, without even knowing the exact declarations, or even worse, the implementation.
console.printAt(pos, 'A', ColorPair::foreground(...));
console.printAt(pos, 'A', ColorPair::background(...));
console.printAt(pos, 'A', ColorPair::pair(..., ...));
console.printAt(pos, 'A', ColorPair::none());
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.
But what do you gain by that? The "advantage" of omitting & at call site is shadowed by the confusion arising from the possibility to pass nullptr, but not T*. I've never seen an API that does that.
What you're actually looking for are optional types. They will soon be introduced as std::optional in C++, and my library Aurora already provides them (https://github.com/Bromeon/Aurora/blob/master/include/Aurora/Tools/Optional.hpp#L68-L96). They're very easy to use:
aurora::Optional<int> x = 32; // contains a value
aurora::Optional<int> y; // is empty
aurora::Optional<int> z = aurora::nullopt; // is empty
if (x) // check if not empty
output(*x); // access stored int value
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.
But SFML does not allow setXyEnabled() without a parameter.
I think it's a fundamental design question: do you want to make all users happy and leave it up to them what style to use, or is your focus on a concise API that precisely says "in order to achieve that, you must do this". I personally prefer the latter option by far, because:
- Users can get a quick overview over the functionality when there's no redundancy.
- It's clear that two different methods are actually different and don't just seem so.
- Different users of my API understand each other, because there's only one style.
- There's a consistency throughout my API. Users knowing my API style can use new classes directly, as they're used to the API and have expectations that are fulfilled.
- I have less maintenance overhead as a developer, and potentially fewer bugs.
I don't say you should follow this style, I merely want to give you some insights in how I design interfaces in my libraries and what criteria are important to me personally.
-
I think the method should be renamed. "create" without further specifying the object leads to the assumption that a new object of the same class is created. Why not "resizeGrid"? And is that change actually needed or can the user achieve the same by creating a new object?
I have to admit that I'm not fully sure why it was called create to start with. I can probably assume that it meant create new internal screen as all the internal data (the screen content) is recreated or something like that. Obviously I realised that resize() gave the impression that the size of the final visual representation would change. The method is needed as it gives the ability to change the actual content; it could be compared perhaps to changing a display "mode". Creating a new object to do just this seems to be overkill. A lot of the setup stays the same when "resizing the grid" - texture setup, colours etc..
In conclusion, the method needs renaming. However, resizeGrid is not exactly what I would like as grid is not a word I have associated with the set-up elsewhere. I've just now started to like "changeMode()" ;D
I'm not sure if or-ing enumerators is better than explicit booleans.
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. ;D
I think it's probably much better. I'm not even sure why I said this. I generally use enums instead of booleans at any possible occasion as who knows when its dedicated state might expand to a possible 3 or more states. It's the or-ing together that I generally avoid, though I will make an effort to involve this technique in the future.
The difference between those calls, as well as the meaning of the magic true values is impossible to know without learning the API by heart. Even when seeing the function declaration, it's still unclear what happens exactly when colors are overwritten -- which color is then used?
The method is designed to be used with internal stored ("current") colours and is therefore a simple method that prints a character at the location with the current colours (as is normal in a console's display). The overrides are to allow a colour other than the current colours to be temporarily used for that single "print". The reason the booleans are also an option is to allow the ability to print at a location without changing the colours that are already at that location.
Therefore, this method can do three things, print the character at the location:
1) without changing the colour(s) at its destination,
2) by replacing the colours at the destination with the current colour(s),
3) by replacing the colours at the destination with the specified colour(s).
It may be overkill in this situation, but since you use a lot of foreground-background color pairs, why not treat them as first-class citizens? For example as a type with named constructor idiom
Although the colours are sometimes available to be changed together, they refer to two completely separate things. The main (or foreground) colour is the 'important' colour whereas background colour can be relatively trivial and/or ignored. In times when the background is disabled, its colour would be useless and therefore should be able to be ignored.
interestingly, you did not use [function overloads] for one of its main purposes: type inference. There's no harm in treating single chars and std::strings the same.
I think I had some trouble with calling internal methods using type inference. e.g. calling printCharAt from printAt. I can't remember fully and I'll look into maybe combining the two. It's possible I may just have been trying to be explicit. However, I can't at the moment think of a reason why I wouldn't like printing characters as also using print or printAt. I will definitely look into this.
By the way, character types should be char, not unsigned char. std::string also uses char.
This was intentional as 'tiles' can also be specified by actual value and negative numbers would not be intuitive here.
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.
But what do you gain by that? The "advantage" of omitting & at call site is shadowed by the confusion arising from the possibility to pass nullptr, but not T*. I've never seen an API that does that.
The point here is to allow passing by reference. Things like textures, however, obviously need to be able to be nullified. Realising now, there's no need to allow a null pointer to do this, especially when a normal pointer is not accepted. This can be done with no parameter at all or a differently named method:
1) setTexture();
2) resetTexture();
although reset isn't that clear. Neither is clear(). nullifyTexture() is clear but ugly. noTexture() or unlinkTexture() seem average. unassociateTexture() seems too verbose.
What you're actually looking for are optional types. They will soon be introduced as std::optional in C++, and my library Aurora already provides them (https://github.com/Bromeon/Aurora/blob/master/include/Aurora/Tools/Optional.hpp#L68-L96). They're very easy to use
I will have a look into optional types. I don't know much about them at the moment.
Unfortunately, using aurora in this case is not an option. My aim is to have Selba Ward unlinked from any other library (I remove any dependance from my own libraries before adding them to the collection).
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.
But SFML does not allow setXyEnabled() without a parameter.
That's actually my point: I think that it should.
setXyEnabled() sounds like it should set it to enabled so allowing it to disable doesn't make much sense. Grammatically, setEnabled(false) sounds like it isn't going to do anything.
I will probably move away from using "enabled" in methods in the future and don't usually use it elsewhere. It was used in Selba Ward because SFML uses it. It allows it without parameters because it makes (more) sense without them.
I will consider removing "enabled" from switches i.e. setXy(bool)
I think it's a fundamental design question: do you want to make all users happy and leave it up to them what style to use, or is your focus on a concise API that precisely says "in order to achieve that, you must do this". I personally prefer the latter option by far, because:
- Users can get a quick overview over the functionality when there's no redundancy.
- It's clear that two different methods are actually different and don't just seem so.
- Different users of my API understand each other, because there's only one style.
- There's a consistency throughout my API. Users knowing my API style can use new classes directly, as they're used to the API and have expectations that are fulfilled.
- I have less maintenance overhead as a developer, and potentially fewer bugs.
I don't say you should follow this style, I merely want to give you some insights in how I design interfaces in my libraries and what criteria are important to me personally.
I actually loved that you wrote this. The two options of design were both taken into consideration during development. That is, they are both evident. Obviously, they cannot co-exist comfortably so one must choose one or the other. I have not do so and I think I have tried to include the former too much while the latter is the logical choice. I will definitely make a conscious effort to be more mindful of sticking closer to latter design choice.
-
Update Console Screen (https://github.com/Hapaxia/SelbaWard/wiki/Console-Screen) to version 1.1.
Reworked some of the code, added new features, and changed a few things to be more consistent.
Some of the new features:
Customisable colour palettes with indexed colours,
Colour commands that generate colours automatically,
Text-editing-style cursor controls.
The palette and the way to specify colours is the largest change. See the Colours section of the wiki (https://github.com/Hapaxia/SelbaWard/wiki/Console-Screen#colours) for more information.
It also does away with the seemingly random boolean parameters that were mentioned in the discussion above with Nexus.
A number of the points (e.g. create(), null pointers, type inference of printAt(), unsigned char and unclear boolean parameters) in that discussion with Nexus have been addressed and I would like to thank him for the critique as it helps make me look at and consider things from a different perspective, so thank you!
Although the GitHub commit message should contain a lot of specific information about the update, I intend to create a "changelog" to describe the update in a more human way.
I still have plans for Console Screen. In fact, the screen buffers feature that I want to implement had already been somewhat started. You can see the screenbuffer vector already sat there waiting (https://github.com/Hapaxia/SelbaWard/blob/master/src/SelbaWard/ConsoleScreen.hpp#L216) and it's been there since v1.0! ;D
That said, if you have any suggestions for something a console screen should be able to do, or just a palette that you think should be included, let me know! :)
(these are the palettes that are already included (https://github.com/Hapaxia/SelbaWard/blob/master/src/SelbaWard/ConsoleScreen.hpp#L270-L286))
-
With palette, is there a reason you made it an enum class, rather than just a class that could be constructed from either, a preset palette, a list of colours, or a list of other palettes, and could have its own methods like setBrightness() for example? I only ask, because this would make it easier to modify palettes and use them for several objects. Also, is there any difference between greyscale and grayscale? It is nice to see the British spelling included, as I already have to live with littering my code with words like 'color', however I feel the inclusion of both goes against thr idea of simplifying the API if they aren't actually different.
-
The Palette enum class is simply the choice of preset palettes. You can create your own palette, colour by colour, or alter the preset ones after loading - again, colour by colour. This is obviously not the most convenient way to work with palettes if you use them often and switch custom palettes a lot but I'm not sure if that would be used. It's a possible future upgrade, of course - switching in full palettes. Even better would be the ability to load and save palettes from a file - and that is a considered upgrade - but depends on how much request I get for that.
The next palette upgrade, I think, would be adding or setting multiple colours at once:
cs.addPaletteColor({sf::Color::Black, sf::Color::Red, sf::Color::Green, sf::Color::Blue, sf::Color::White});
although this could get ugly quickly if the palette is large. Allowing an entire vector to be passed kind of relocates the work. Instead of adding colours to the palette, you add colours to the vector before passing it to Console Screen.
Another reason why file work would be useful ;D
I'm not sure why a palette would need a setBrightness() function.
Are you suggesting adding colour manipulation to Console Screen? However convenient that would be, I'm not sure that it is its primary role and colour manipulation can be easily performed elsewhere, plus, externally, you could perform any colour transformations required.
Greyscale and Grayscale. Right. I made this class for myself so I used Greyscale. When I decided to include Console Screen in Selba Ward for others and rewrote it from scratch, I added the Grayscale. Funnily enough, when I committed the new version to GitHub, I was still deliberating over including both. I ended up having faith that people would not get confused because "it's obvious that it's just both spellings and they are the same". I guess I may have erred slightly. Grayscale is, then, included for convenience and, ironically, was to reduce to confusion as to why "it's spelt wrongly". If it was a common and focal part of the class (like Color, for example), I'd probably remove one of them but since it's only used occasionally (how often do you load a palette?), and is only an enum value, I'm not sure removing it would help.
-
It is nice to see the British spelling included, as I already have to live with littering my code with words like 'color'
British? ;) As a non-native English speaker, I was not biased towards one dialect. Eventually, American English's tendency of having simpler words and its bigger popularity in programming made me use it almost exclusively.
If it was a common and focal part of the class (like Color, for example), I'd probably remove one of them but since it's only used occasionally (how often do you load a palette?), and is only an enum value, I'm not sure removing it would help.
It would, that's exactly what I meant with "redundancy in the API is confusing" ;)
It being rare may even add to the confusion, as the first association is usually "this can't be, I must have missed something".
I'm actually curious what the intent behind such duplication is (this is not a rethorical question, I really would like to understand that decision). To me, it seems weird to provide things in different dialects just to let people choose... You don't provide different code conventions either, for reasons of consistency; why doesn't this reasoning apply to other kinds of code duplication (parameter types/order, dialect, pointer/reference)?
-
I haven't looked through much of the code of the library and was just going off the file you linked so I may have misunderstood things. I was suggesting that a palette could be used by multiple objects of different types, and that you might want to change the brightness for example of that palette (which in my examlke is being used as a whole program colour scheme).
Nexus, I understand the rationale behind using the American spellings, I just innately dislike the oversimplification of words to something which to me just looks like someone didn't know how to spell and guessed. For the record, that is my personal opinion, I do not intend to go on a large rampage and demand things be changed, I just liked seeing someone using what I have always known as the 'correct' spelling after years of having to use what I've always known as the 'incorrect' spelling. Can you tell I'm being careful because I'm used to people turning the subject into a giant fight?
-
British?
I believe the "official" term is now "British English".
I'm not sure removing it would help.
It would, that's exactly what I meant with "redundancy in the API is confusing" ;)
It being rare may even add to the confusion, as the first association is usually "this can't be, I must have missed something".
I'm actually curious what the intent behind such duplication is (this is not a rethorical question, I really would like to understand that decision). To me, it seems weird to provide things in different dialects just to let people choose... You don't provide different code conventions either, for reasons of consistency; why doesn't this reasoning apply to other kinds of code duplication (parameter types/order, dialect, pointer/reference)?
The reason behind including "grayscale" was explained above: I thought it might reduce confusion for people feeling they have to use the "wrong" spelling. I am not firmly set on this decision and it looks like I may have been right (in my deliberations) to remove grayscale. Really, I should not have added it in the first place.
Which parts do you think those kinds of code duplication apply to?
Dialect, I understand is certainly in Console Screen in the Palette enumeration value and l will very likely remove one of them. If I'm to understand your point here, it's that you think I should keep "grayscale" and remove "greyscale"?
I think pointer/reference usage is pretty consistent as I avoid pointers as much as possible. Is it just the pointer/reference parameters options that I provided in some classes that you refer to? I will be removing them; I have already removed Console Screen's null pointer overload.
I'd like to know more about what you mean by 'inconsistent parameters types/order'.
I haven't looked through much of the code of the library and was just going off the file you linked so I may have misunderstood things. I was suggesting that a palette could be used by multiple objects of different types, and that you might want to change the brightness for example of that palette (which in my examlke is being used as a whole program colour scheme).
Ah, okay. The palette is only included in Console Screen. It's simply a list of colours that can be chosen by index instead of specifying a full colour each directly each time.
Also, all drawable objects in Selba Ward are independant of each other. However much that can be convenient and easy to use, one of the tradeoffs is that it objects can include code repetition (in that several objects have need of similar code).
I understand the rationale behind using the American spellings, I just innately dislike the oversimplification of words to something which to me just looks like someone didn't know how to spell and guessed.
I don't think they are "simplified"; I often find them downright confusing. It's weird when you have to translate from English to English.
-
Don't worry, I won't debate about American vs. British English ;)
(Straya's gonna rule anyway mate 8))
The problem is when you mix both, and use two different terms to identify the same thing. The other forms of duplication have been mentioned in my previous posts, e.g. pointer/reference:
void method(..., T* param);
void method(..., T& param);
and unnecessary combinations of parameter type/order:
console.printCharAt(pos, 'A');
console.printCharAt(pos, 'A', true);
console.printCharAt(pos, 'A', true, true);
console.printCharAt(pos, 'A', sf::Color::White);
console.printCharAt(pos, 'A', sf::Color::White, true);
console.printCharAt(pos, 'A', sf::Color::White, sf::Color::Black);
-
You're right, of course, and I will be moving one. I'm just stuck on which one. I think I'm being swayed though; if I'm already using "color", I should probably use "gray" :(
The duplication of methods for references and pointers have been already removed from Console Screen. I will be fixing the other few in time.
and unnecessary combinations of parameter type/order:
Console Screen no longer has "printCharAt", and printAt no longer accepts booleans :p (have a look at the v1.1 documentation (https://github.com/Hapaxia/SelbaWard/wiki/Console-Screen) if you have time)
It does have (only) a few options: location and content + foreground (optional) + background (optional).
However, there are type combinations for a reason: convenience. You've mentioned you don't like things that are "only" for convenience but that's the sole reason the print methods exist at all. You can do all of the same things manually using the other methods, setValue, setColor, or even poke, but the convenience of the print methods is the central premise of the usage of Console Screen. Printing in this way can allow much cleaner code, and it's based on how BASIC would have drawn in a simple way to the screen.
-
Added new object: Tile Map (https://github.com/Hapaxia/SelbaWard/wiki/Tile-Map)
(http://i.imgur.com/MZAWrBD.png)
Main things needed for this are: tileset texture, level data (in a vector or similar), and a camera position. Have a look at the (interactive/movable) simple example (https://github.com/Hapaxia/SelbaWard/wiki/Tile-Map#simple-example) that generated this screenshot :)
-
I haven't posted here for a while as I didn't want the thread to become a constant update of "oo look; I just added a line of code!"
However, I've still been updating/upgrading things on GitHub as some of you may already know/have realised.
Here are some of the most recent updates:
Tile Map (https://github.com/Hapaxia/SelbaWard/wiki/Tile-Map)
(now version 1.3)
Since version 1.0:
- Smooth Scroll to allow pixel scrolling,
- Camera Target to allow specifying which tile is the focal point of the camera position,
- Texture Offset to allow tile set to be a sub-texture rather than having to be at top-left of the texture,
- Ability to customise default value of tile for "out-of-bounds" tiles
- Retrieval of which level position is at a given co-ordinate (where in the map is this point?),
- Retrieval of which tile is at a given co-ordinate (which tile is at this point?),
- Co-ordinate of any part of the level (where is this part of the map?),
The three final points above all take into account the tile map's transformations so can simplify, for example, clicking on a tile even when it's been rotated.
Progress Bar (https://github.com/Hapaxia/SelbaWard/wiki/Progress-Bar)
Now at version 1.1, Progress Bar can use textured for both the background and the bar.
Progress Bar also supplied the locations of three points at the progress bar's current position: top, centre, and bottom. These points take into account the transformations so it's possible to lock onto the bar's edge and draw other things.
Here's a screenshot that is textured and also shows the three points by locking three circles to them (red - top, yellow - centre, green - bottom):
(http://i.imgur.com/aXcb6ZG.png)
The interactive code that generated the above screenshot can be found here (https://github.com/Hapaxia/SelbaWard/blob/master/examples/progressBarExample.cpp).
Sprite 3D (https://github.com/Hapaxia/SelbaWard/wiki/Sprite-3D)
Now at version 1.1, Sprite 3D can take a three-dimensional origin; that is, you can now specify a depth (z) for the origin. The 3D rotations transform around this origin. This means that the sprite can now rotate around a point not on its own plane!
Console Screen (https://github.com/Hapaxia/SelbaWard/wiki/Console-Screen)
(now version 1.3)
By far, the largest project inside the Selba Ward collection, Console Screen has been updated to version 1.3 (the last post here about it was for 1.1, which was the major update that introduced palettes and colour commands)
Since v1.1:
- Ability to "paint" colours. This allows multiple cell colours to be manipulated at once in a similar way to printing but without affecting the characters/cell values (kind of like a highlighter),[/lli]
- Cell Attributes. Each cell can store multiple "flags" to enabled/disabled certain states for that cell.
These attributes are:
- Inverse - displays the colour and background colour of that cell swapped,
- Bright - displays fully bright (darkens the colour if disabled)
- FlipX - displays the tile flipped horizontally,
- FlipY - displays the tile flipped vertically
- Painting Attributes. Attributes can also be "painted" in the same way as colours.
- Clipboards. Multiple clipboards/buffers can be stored and recalled at will. Buffers can be the entire screen or just a rectangular region and they can be "pasted" at any position
- Double-height. A cell can now be a part of a double-height cell using the "stretch" ability. The top and bottom halves can be used together or separately. Double-height cells can have both top and bottom printed at once automatically - using printStretchedAt()
Here's a screenshot showing some of the latest features (attributes, double-height):
(http://i.imgur.com/ximkIZw.png)
In that screenshot, you can see the Selba Ward title being double-height. Below it, it's being display flipped vertically (but not stretched) and it also has the bright attribute switched off (it's on by default).
"Console Screen" also has attributes painted over it: a switched-off bright attribute over "Console" and a switched-on inverse attribute over part of both "Console" and "Screen".
-
I didn't know 9-patch was a thing until now. Seems like such a nice feature, I'll definitely try it.
I'm curious, what is/was/will be the Spinning Card?
-
Nine patch was pretty new to me too but I couldn't not create it as soon as I found it! I really need to remember to use it. It's so awesome! :)
Spinning Card is/was a simple and light class that could be used to rotate a sprite horizontally or vertically in a pseudo 3D way.
I wanted to challenge the idea that the only way to "spin a card" was to animated its width or height and decided that animating its corners in an ellipse gave the impression of depth.
It takes a sprite, duplicates its setup and then splits it into a number of triangles (I think it stands at 8) to help slightly avoid the texture distortion that occurs when primitives are stretched. The "card" was intended to be used for the animation (of a spin) only and then destroyed afterwards where you would continue to use the original sprite.
Also, it can only rotate horizontally or vertically - never both at the same time.
It is included for both nostalgia and for people that either already used it or want a very light class to do this task. However, it has very little use since Sprite 3D renders it pretty useless. Sprite 3D can completely replace a standard sprite and is used in the same way, rather than just a temporary animation object. It also splits the object into a customisable number of triangles - to the point where you could be having a quad per texture pixel (or more!) if absolutely necessary. Still, it can be used with only triangles as with a normal sprite.
To clarify, Spinning Card is the original idea and Sprite 3D is the successor of that idea and should be used instead.
-
Ah, I see now. Nice little features to have, I'll add the library to my toolbox :)
-
Major update of Console Screen (https://github.com/Hapaxia/SelbaWard/wiki/Console-Screen)
Console has been updated to version 2!
Some new features:
- Streaming replaces printing and reading methods and a lot of other things can be streamed (e.g. cs << "Some text.";),
- Now uses actual palettes - if a palette colour is changed then all cells set to that colour will also change,
- Stack printing allows cells to be stacked on top - and below - the main cells (buffers can paste onto stacks too),
- Cursor commands can be mapped to characters to greatly simplify input (e.g. using \n in a string - cs << "These\nwords\nwould\nall\nbe\non\nseparate\nlines.";),
- Screen fill - similar to clear but replaces all cells with the given cell.
View the Change Log (https://github.com/Hapaxia/SelbaWard/blob/master/changelogs/ConsoleScreen.md).
I've also started to create tutorials for using Selba Ward drawables. So far, the only drawable that has a tutorial is Console Screen (https://github.com/Hapaxia/SelbaWard/wiki/Tutorial%3A-%27Console-Screen%27-Basics) and it is designed to get you started with using it. More Console Screen tutorials will follow that will introduce other features and more Selba Ward tutorials will follow to introduce you to the other drawables.
View the Selba Ward tutorials (https://github.com/Hapaxia/SelbaWard/wiki/Tutorials).
I'm also working on a small, demo/animation to kind of show some (all?) of the drawables in action. Created some music for it already :)
-
Updates!
New Drawable!
Gallery Sprite (wiki (https://github.com/Hapaxia/SelbaWard/wiki/Gallery-Sprite))
A sprite class that also stores texture rectangles so a single texture section can be recalled by a single value. Useful for spritesheets - even irregular ones!
Note that if you also use Plinth (https://github.com/Hapaxia/Plinth), you can pair this with Plinth's Frame Sequence to simplify frame animation (they were actually originally created to be used together). Eeach frame can have separate settings - including duration - and can use exhibits in any order as well as use them more than once.
Each texture rectangle also has an accompanying 'anchor' point by which the sprite is offset automatically. The texture rectangle and anchor are stored in a struct called "Exhibit" and this is the name given to an individual sprite 'frame' (hence the name Gallery Sprite).
Changing the exhibit can be done by specifying a specific exhibit or by adding or subtracting values from the object itself which offsets the exhibit number.
Console Screen (wiki (https://github.com/Hapaxia/SelbaWard/wiki/Console-Screen)) (change log (https://github.com/Hapaxia/SelbaWard/blob/master/changelogs/ConsoleScreen.md))
The colours in the palette can now be 'cycled' e.g. colour-cycling. This can affect the entire palette or just a range of the colours and can be cycled in either direction.
Scrolling can now be restrained to a specified rectangular region instead of only being able to scroll the entire screen.
Console Screen can now inform you of the "perfect size" - the recommended size, in pixels, of the screen so that it would display the texture at its exact original size.
Starfield (wiki (https://github.com/Hapaxia/SelbaWard/wiki/Starfield))
The colour of the stars can now be altered without having to regenerate the entire starfield.
Line (wiki (https://github.com/Hapaxia/SelbaWard/wiki/Line))
When a thick line is used, it can now be textured.
Bitmap Text (wiki (https://github.com/Hapaxia/SelbaWard/wiki/Bitmap-Text))
The local and global bounds are now available.
Selba Ward Demo Animation 2016
Still working on this demo animation that is intended to show the drawables in action.
All visuals in the demo are Selba Ward drawables and all resources used in the demo are/will be created by myself.
When it's ready, there will be available a full video of the animation.
For now though, here's a screenshot of the opening section (yes, this is Console Screen):
(http://i.imgur.com/Z2lle0n.jpg)
Hopefully, the animation will be finished soon otherwise it might need to be changed to 2017! ;D
-
Great job! Really looking forward to the demo. :)
And I think I'll try some things in your lib for fun, maybe I'll use them in my game or maybe I'll just learn some cool stuff that I'll shamelessly steal will inspire me to rewrite some of my own graphics code.
-
Hi Hapax,
Is it posible to use Selba Ward in C#.Net projects? Or will it be?
Thanks
-
Great job! Really looking forward to the demo. :)
Thank you!
And I think I'll try some things in your lib for fun, maybe I'll use them in my game or maybe I'll just learn some cool stuff that I'll shamelessly steal will inspire me to rewrite some of my own graphics code.
Would be much better if you just used them, especially if you provided feedback so that they might improve. :P
Hi Hapax,
Is it posible to use Selba Ward in C#.Net projects? Or will it be?
Hi.
Selba Ward is a collection of open source, cross-platform SFML-based C++ drawables and is, therefore, not going to be much use with C# unless anyone is interested in converting or binding it as I have very little experience with C# myself.
-
Would be much better if you just used them, especially if you provided feedback so that they might improve. :P
My game doesn't have much graphics stuff going on (and probably won't ever have....?), just some tiles, animation and simple shaders. So there's not much I need but I see how useful it can be for other people. :D
-
Hi. Got a strange issue with a SelbaWard, can anyone help me?
When compiled for release I got some strange linking issue:
./Release/application.cpp.o:application.cpp:(.text+0x30b7): undefined reference to `selbaward::Line::isThick() const'
Compiler is MinGW (i686-posix-dwarf) with -O2 -std=c++11 -Wall -DNDEBUG under Windows.
With some vodoo I found that problem arose when compiling with any of -O keys and it's bothering me. I can't afford myself to compile without optimization, 'cause it's quite big project with massive calculations that should work on rusty toasters, my customer be damned.
So, any bright ideas? Excuse my english, not native.
-
Hi, EllareMezzo.
Thank you for your interest in Selba Ward.
Selba Ward's Line has been patched. Will you try the latest version and post here your results? If you are still having trouble, the problem will be investigated further.
Hapaxia.
-
Hi and thank you for your attention to your project, Hapaxia.
Issue already been solved by a hack on my side, just had a quick glance at your fix - you did the same thing with removing inline. So I'm sure it's right assumption you had there. Now it's linking allright. Kinda strange that no one had this problem before though, may be it was specific to MinGW. I'm gonna try my project with another compilers when it's over and post here if I'm to find anything else.
Thank you again for your work on SelbaWard, it's irreplaceable addition to SFML.
-
Feels bad to bother you again with questions, Hapaxia, but can I ask with what compiler and what os in mind did you designed SelbaWard?
Just had multiply issues with ambiguous call to overloaded function with abs call somewhere in Sprite3d, in short it's all like in that SO question:
http://stackoverflow.com/questions/30084577/ambiguous-call-to-abs
Not sure if it's SelbaWard issue, though, it can be some interference from my side, still can't allow myself enough time to do proper testing due to work, sorry. Right now just hacked some more #include <cstdlib> in every .cpp that have had this issue, it's Line, PieChart, Ring, SpinningCard, Spline, Sprite3d and may be somewhere else I forgot, gonna clean up later. But I think you might be interested in knowing about that issue.
I'm still promise: just after I getting my things done on that week I'm gonna do some real testing to help you with your brilliant work on Selba Ward =)
-
Hi and thank you for your attention to your project, Hapaxia.
[...]
Thank you again for your work on SelbaWard, it's irreplaceable addition to SFML.
You're welcome and I am glad you enjoy it! :)
Kinda strange that no one had this problem before though, may be it was specific to MinGW.
It's an odd thing as inline was being used to inline within the translation unit as it's a private method but since it's declaration is public in the header, it doesn't like it. This is part of the reason I've started to use more anonymous/unnamed namespaces in cpp files instead of private method where possible.
Feels bad to bother you again with questions, Hapaxia, but can I ask with what compiler and what os in mind did you designed SelbaWard?
No worries. The more people inform me of things that can be done better, the better they can be done. I use Visual Studio 2015 (now) but developed most of Selba Ward using 2013. I don't have chance to test on others compilers, however, so feedback is essential to correct issues on other ones. I do aim to keep as generically C++ compatible as possible but all compilers have their quirks.
Just had multiply issues with ambiguous call to overloaded function with abs call somewhere in Sprite3d, in short it's all like in that SO question:
http://stackoverflow.com/questions/30084577/ambiguous-call-to-abs
Not sure if it's SelbaWard issue, though
When changing to VS 2015, I noticed that this problem appeared in my Plinth library, which should now be fixed by always using an internal abs function. As mentioned above, though, Selba Ward was mostly developed using VS 2013 and this abs thing didn't show up then and I haven't seen the problem arise yet. I'll consider options and fix it when I can. Thanks for the link.
I'm still promise: just after I getting my things done on that week I'm gonna do some real testing to help you with your brilliant work on Selba Ward =)
Test away! Let me know how it goes :D
-
every .cpp that have had this issue, it's Line, PieChart, Ring, SpinningCard, Spline, Sprite3d
I have patched all of these (except SpinningCard as it's old and is only included for completeness; I'll maybe tidy it up at some point or just remove it since Sprite3D is its successor) and hopefully will now no longer cause the error you were receiving.
-
What have you used to compile the code for the ConsoleScreen, because I seem to be getting a bunch of errors.
enum class Direction;
enum class Palette;
enum ColorCommand;
enum Direct;
The last two declarations give me errors (error: use of enum 'ColorCommand' without previous declaration). So I switch the deceleration and definition to enum class instead. (See also: http://stackoverflow.com/questions/71416/forward-declaring-an-enum-in-c)
void ConsoleScreen::clear(const ColorCommand backgroundColorCommand)
{
clear(priv_getModifiedColorFromColorPairUsingSpecifiedColorType({ m_cursorPrintProperties.colors.foreground, backgroundColorCommand }, ColorType::Background));
}
I guess this might be an issue because I switched to enum class which can't be implicitly converted to integer?
(The brace-enclosed values get interpreted as initialization-list which then of course don't match the function signature and it fails to compile. The priv function takes a ColorPair and the ColorPair takes two Colors, yet the code is trying to pass a ColorCommand, is that implicitly convertible to Color?)
I don't have time right now to further investigate, but maybe I'm just approaching this all wrong anyways?
I'm using MinGW-w64 (x64) with -std=c++14.
-
Thanks for trying this out, eXpl0it3r. I will get this thing to work for everyone :-\
I'm using VS 2015 and the code doesn't result in any errors.
Console Screen only forward declares the enums which values aren't used until the source and the definition is still including in the header (they're at the bottom).
I guess VS allows this because it doesn't need to know the values or underlying storage, just that that particular enum will be passed as a parameter. Still, if others don't allow this, I can move the definitions inline or maybe just include the storage type (enum ColorCommand : int;). Is VS wrong here? The post you linked is unfortunately very old.
I'll modify it to use the (newer) storage type version. See if that works any better. I'll be uploading the newest updates with it so it'll be 2.2 ;)
Color can be created from a ColorCommand, yes, and is implicitly convertible. Color is basically an integer value: a positive value is a palette index whereas a negative value represents a command. ColorCommand is an enum with only negative values.
-
Updates!
Console Screen (wiki (https://github.com/Hapaxia/SelbaWard/wiki/Console-Screen)) (change log (https://github.com/Hapaxia/SelbaWard/blob/master/changelogs/ConsoleScreen.md))
v2.2.0
A single character can now be streamed directly without first requiring a string being constructed from it.
Buffers can now be added and resized as well as have their cells manipulated directly.
A few fixes since v2.1 including adding storage types to forward-declared enums
Global
Removed inline from multiple source files when declaration is in a header.
Fixed some function calls being ambiguous.
Selba Ward Demo Animation
I haven't had much time to work on this recently but I did create a small walking animation to be used for it so I thought I'd share that for you lovely people ;D
(http://i.imgur.com/RF9jPxu.gif)
-
Nice! Hope I get to play around with it later on this evening. :)
Btw. have you considered providing a CMake file to build it as library?
-
I have considered providing a CMake file to build it as library, yes, but I am yet to have a successful experience with CMake.
I hope you enjoy it. I think Selba Ward is really useful; maybe I'm biased but I do actually use it all the time ;D
-
Too bad, I still can't compile Console Screen.
Now it complains that the types of the enums are not the same, so I think you'll need to add : int to the definition of the enums as well.
Next this line doesn't seem to compile, because you don't provide a value for CellAttributes and the constructor of CellAttributes is defined explicit, so it must be called.
void ConsoleScreen::crash()
{
for (auto& cell : m_cells)
{
cell = { randomByte(), ColorPair(priv_getRandomColor(), priv_getRandomColor()) };
}
So changing to:
cell = { randomByte(), ColorPair(priv_getRandomColor(), priv_getRandomColor()), StretchType(), CellAttributes() };
seems to work.
But the compilation spits out quite a few errors:
src\ConsoleScreen.cpp||In member function 'selbaward::ConsoleScreen& selbaward::ConsoleScreen::operator<<(const selbaward::ConsoleScreen::CursorCommand&)':|
src\ConsoleScreen.cpp|494|warning: narrowing conversion of '(((selbaward::ConsoleScreen*)this)->selbaward::ConsoleScreen::m_cells.std::vector<_Tp, _Alloc>::size<selbaward::ConsoleScreen::Cell, std::allocator<selbaward::ConsoleScreen::Cell> >() - 1ull)' from 'std::vector<selbaward::ConsoleScreen::Cell>::size_type {aka long long unsigned int}' to 'unsigned int' inside { } [-Wnarrowing]|
src\ConsoleScreen.hpp||In constructor 'selbaward::ConsoleScreen::ConsoleScreen(sf::Vector2u)':|
src\ConsoleScreen.hpp|479|warning: 'selbaward::ConsoleScreen::m_buffers' will be initialized after [-Wreorder]|
src\ConsoleScreen.hpp|455|warning: 'selbaward::ConsoleScreen::ActionFlags selbaward::ConsoleScreen::m_do' [-Wreorder]|
src\ConsoleScreen.cpp|632|warning: when initialized here [-Wreorder]|
src\ConsoleScreen.hpp|508|warning: 'selbaward::ConsoleScreen::m_numberOfTilesPerRow' will be initialized after [-Wreorder]|
src\ConsoleScreen.hpp|491|warning: 'std::vector<sf::Color> selbaward::ConsoleScreen::m_palette' [-Wreorder]|
src\ConsoleScreen.cpp|632|warning: when initialized here [-Wreorder]|
src\ConsoleScreen.hpp|491|warning: 'selbaward::ConsoleScreen::m_palette' will be initialized after [-Wreorder]|
src\ConsoleScreen.hpp|482|warning: 'selbaward::ConsoleScreen::CursorProperties selbaward::ConsoleScreen::m_cursor' [-Wreorder]|
src\ConsoleScreen.cpp|632|warning: when initialized here [-Wreorder]|
src\ConsoleScreen.hpp|494|warning: 'selbaward::ConsoleScreen::m_characterMap' will be initialized after [-Wreorder]|
src\ConsoleScreen.hpp|462|warning: 'const selbaward::ConsoleScreen::PrintProperties selbaward::ConsoleScreen::m_defaultPrintProperties' [-Wreorder]|
src\ConsoleScreen.cpp|632|warning: when initialized here [-Wreorder]|
src\ConsoleScreen.cpp||In member function 'void selbaward::ConsoleScreen::scrollRight(unsigned int)':|
src\ConsoleScreen.cpp|1651|warning: narrowing conversion of '((((selbaward::ConsoleScreen*)this)->selbaward::ConsoleScreen::m_cells.std::vector<_Tp, _Alloc>::size<selbaward::ConsoleScreen::Cell, std::allocator<selbaward::ConsoleScreen::Cell> >() - ((std::vector<selbaward::ConsoleScreen::Cell>::size_type)i)) - 1ull)' from 'std::vector<selbaward::ConsoleScreen::Cell>::size_type {aka long long unsigned int}' to 'unsigned int' inside { } [-Wnarrowing]|
src\ConsoleScreen.cpp||In member function 'unsigned int selbaward::ConsoleScreen::addBuffer(sf::Vector2u)':|
src\ConsoleScreen.cpp|2235|warning: narrowing conversion of '((selbaward::ConsoleScreen*)this)->selbaward::ConsoleScreen::m_buffers.std::vector<_Tp, _Alloc>::size<selbaward::ConsoleScreen::Buffer, std::allocator<selbaward::ConsoleScreen::Buffer> >()' from 'std::vector<selbaward::ConsoleScreen::Buffer>::size_type {aka long long unsigned int}' to 'unsigned int' inside { } [-Wnarrowing]|
src\ConsoleScreen.cpp||In member function 'void selbaward::ConsoleScreen::resizeBuffer(unsigned int, sf::Vector2u)':|
src\ConsoleScreen.cpp|2261|warning: narrowing conversion of '(buffer.selbaward::ConsoleScreen::Buffer::cells.std::vector<_Tp, _Alloc>::size<selbaward::ConsoleScreen::Cell, std::allocator<selbaward::ConsoleScreen::Cell> >() / ((std::vector<selbaward::ConsoleScreen::Cell>::size_type)buffer.selbaward::ConsoleScreen::Buffer::width))' from 'std::vector<selbaward::ConsoleScreen::Cell>::size_type {aka long long unsigned int}' to 'unsigned int' inside { } [-Wnarrowing]|
src\ConsoleScreen.cpp||In member function 'int selbaward::ConsoleScreen::priv_getIndexOfClosestPaletteColor(const sf::Color&) const':|
src\ConsoleScreen.cpp|3080|warning: narrowing conversion of '((const selbaward::ConsoleScreen*)this)->selbaward::ConsoleScreen::m_palette.std::vector<_Tp, _Alloc>::size<sf::Color, std::allocator<sf::Color> >()' from 'std::vector<sf::Color>::size_type {aka long long unsigned int}' to 'unsigned int' inside { } [-Wnarrowing]|
src\ConsoleScreen.cpp|152|warning: 'void {anonymous}::addPalette2ColorWhiteBlack(std::vector<sf::Color>&)' defined but not used [-Wunused-function]|
src\ConsoleScreen.cpp|146|warning: 'void {anonymous}::addPalette2ColorBlackWhite(std::vector<sf::Color>&)' defined but not used [-Wunused-function]|
Maybe you could try and raise the warning level in VS and try to fix all the warnings?
I have considered providing a CMake file to build it as library, yes, but I am yet to have a successful experience with CMake.
Maybe I could help you out build one. ;)
Edit
Since the little example uses the PaletteEnum header, I also included it and well I get a bunch of errors, because you apparently can't make an enum const.
PaletteEnums.hpp|45|error: 'const' can only be specified for objects and functions|
Edit2
You might want to enforce a standard so you can detect these non-standard behavior: https://blogs.msdn.microsoft.com/vcblog/2016/06/07/standards-version-switches-in-the-compiler/
Edit3
Do you know why some elements don't load or load wrong when using only a few tiles?
(http://i.imgur.com/5SnJio0.png)
vs
(http://i.imgur.com/eOrRZYu.png)
-
Thanks for the feedback. I really appreciate it!
I have added the storage types to the definition of the enums as well. Hopefully, you'll have more luck with that :)
The default constructor of CellAttributes was declared as explicit, which, it seems, should be ignored. Still, I've removed the explicit keyword from all default constructors as they don't really serve a purpose. Not providing a default value in the initialisation list should call its default constructor, right? If not, I can add constructors to Cell to allow it.
The warning level in VS has been set to its default setting: /W3, which includes warnings that are "severe", "significant" and "production quality". I've taken the level up to /W4 now, which includes "informational" warnings. I've also tried /Wall and that gives me lots of warnings. Most, however, are in "cmath" and SFML.
Still, even using /W4, I get no warnings about forward-declaring enums, const enums or explicit default constructors. Still, I've fixed those now so feel free to give it another try...
I'm not even sure why you get a warning about the order in which members will be initialised. Can you see why?
Even though I'm aiming for C++11, I've used the C++14 standards switch and it still throws out no warning about forward declaring enums... Or, indeed, anything else at its current state (there may be some warnings in "Console Screen Old" as I'm not fixing those :P )
Looking at your screenshots, it seems that the cursor is over the s in SFML in the first one and in the bottom-right corner in the second one. Did you use "direct printing" i.e. using Cs::Begin and Cs::End? It doesn't affect the cursor so "SFML !" gets printed while the cursor stays in the top-left.
You could print without using begin and end to use the cursor or you could hide the cursor (cs.setShowCursor(false);)
-
Looking at your screenshots, it seems that the cursor is over the s in SFML in the first one and in the bottom-right corner in the second one. Did you use "direct printing" i.e. using Cs::Begin and Cs::End? It doesn't affect the cursor so "SFML !" gets printed while the cursor stays in the top-left.
You could print without using begin and end to use the cursor or you could hide the cursor (cs.setShowCursor(false);)
Ah, I didn't know that there was a cursor! That must be it. :)
Will try the updated version later on.
-
Seems to work fine now, but still getting warnings. ;)
src\ConsoleScreen.cpp||In member function 'selbaward::ConsoleScreen& selbaward::ConsoleScreen::operator<<(const selbaward::ConsoleScreen::CursorCommand&)':|
src\ConsoleScreen.cpp|510|warning: narrowing conversion of '(((selbaward::ConsoleScreen*)this)->selbaward::ConsoleScreen::m_cells.std::vector<_Tp, _Alloc>::size<selbaward::ConsoleScreen::Cell, std::allocator<selbaward::ConsoleScreen::Cell> >() - 1ull)' from 'std::vector<selbaward::ConsoleScreen::Cell>::size_type {aka long long unsigned int}' to 'unsigned int' inside { } [-Wnarrowing]|
src\ConsoleScreen.cpp|509|warning: unused variable 'currentIndex' [-Wunused-variable]|
src\ConsoleScreen.cpp|514|warning: variable 'belowCellAltered' set but not used [-Wunused-but-set-variable]|
src\ConsoleScreen.hpp||In constructor 'selbaward::ConsoleScreen::ConsoleScreen(sf::Vector2u)':|
src\ConsoleScreen.hpp|481|warning: 'selbaward::ConsoleScreen::m_buffers' will be initialized after [-Wreorder]|
src\ConsoleScreen.hpp|457|warning: 'selbaward::ConsoleScreen::ActionFlags selbaward::ConsoleScreen::m_do' [-Wreorder]|
src\ConsoleScreen.cpp|666|warning: when initialized here [-Wreorder]|
src\ConsoleScreen.hpp|510|warning: 'selbaward::ConsoleScreen::m_numberOfTilesPerRow' will be initialized after [-Wreorder]|
src\ConsoleScreen.hpp|493|warning: 'std::vector<sf::Color> selbaward::ConsoleScreen::m_palette' [-Wreorder]|
src\ConsoleScreen.cpp|666|warning: when initialized here [-Wreorder]|
src\ConsoleScreen.hpp|493|warning: 'selbaward::ConsoleScreen::m_palette' will be initialized after [-Wreorder]|
src\ConsoleScreen.hpp|484|warning: 'selbaward::ConsoleScreen::CursorProperties selbaward::ConsoleScreen::m_cursor' [-Wreorder]|
src\ConsoleScreen.cpp|666|warning: when initialized here [-Wreorder]|
src\ConsoleScreen.hpp|496|warning: 'selbaward::ConsoleScreen::m_characterMap' will be initialized after [-Wreorder]|
src\ConsoleScreen.hpp|464|warning: 'const selbaward::ConsoleScreen::PrintProperties selbaward::ConsoleScreen::m_defaultPrintProperties' [-Wreorder]|
src\ConsoleScreen.cpp|666|warning: when initialized here [-Wreorder]|
src\ConsoleScreen.cpp||In member function 'void selbaward::ConsoleScreen::scrollRight(unsigned int)':|
src\ConsoleScreen.cpp|1710|warning: narrowing conversion of '((((selbaward::ConsoleScreen*)this)->selbaward::ConsoleScreen::m_cells.std::vector<_Tp, _Alloc>::size<selbaward::ConsoleScreen::Cell, std::allocator<selbaward::ConsoleScreen::Cell> >() - ((std::vector<selbaward::ConsoleScreen::Cell>::size_type)i)) - 1ull)' from 'std::vector<selbaward::ConsoleScreen::Cell>::size_type {aka long long unsigned int}' to 'unsigned int' inside { } [-Wnarrowing]|
src\ConsoleScreen.cpp||In member function 'unsigned int selbaward::ConsoleScreen::addBuffer(sf::Vector2u)':|
src\ConsoleScreen.cpp|2300|warning: narrowing conversion of '((selbaward::ConsoleScreen*)this)->selbaward::ConsoleScreen::m_buffers.std::vector<_Tp, _Alloc>::size<selbaward::ConsoleScreen::Buffer, std::allocator<selbaward::ConsoleScreen::Buffer> >()' from 'std::vector<selbaward::ConsoleScreen::Buffer>::size_type {aka long long unsigned int}' to 'unsigned int' inside { } [-Wnarrowing]|
src\ConsoleScreen.cpp||In member function 'void selbaward::ConsoleScreen::resizeBuffer(unsigned int, sf::Vector2u)':|
src\ConsoleScreen.cpp|2326|warning: narrowing conversion of '(buffer.selbaward::ConsoleScreen::Buffer::cells.std::vector<_Tp, _Alloc>::size<selbaward::ConsoleScreen::Cell, std::allocator<selbaward::ConsoleScreen::Cell> >() / ((std::vector<selbaward::ConsoleScreen::Cell>::size_type)buffer.selbaward::ConsoleScreen::Buffer::width))' from 'std::vector<selbaward::ConsoleScreen::Cell>::size_type {aka long long unsigned int}' to 'unsigned int' inside { } [-Wnarrowing]|
src\ConsoleScreen.cpp||In member function 'int selbaward::ConsoleScreen::priv_getIndexOfClosestPaletteColor(const sf::Color&) const':|
src\ConsoleScreen.cpp|3161|warning: narrowing conversion of '((const selbaward::ConsoleScreen*)this)->selbaward::ConsoleScreen::m_palette.std::vector<_Tp, _Alloc>::size<sf::Color, std::allocator<sf::Color> >()' from 'std::vector<sf::Color>::size_type {aka long long unsigned int}' to 'unsigned int' inside { } [-Wnarrowing]|
Also, how do I change the mode of the CS while keeping it's content?
Edit
Could the backspace command be checked to only go back where stuff was actually printed?
Like if you print a newline and then use backspace, it will start at the line end, instead of where you inserted the new line.
Edit2
Well I got it working, but it's not really as nice as I'd like to be. But here's the result.
(https://i.imgur.com/CUA13II.png)
(https://imgur.com/download/xnABHXB)
-
Glad you got it to work. Hope you'll enjoy it! :)
Although changing the mode does clear the screen and reset the palette (as actual console screens would do), it also clears the buffers, which would be able to be copied over after adjusting the mode if they remained. You can, of course, copying all of the cells into your own vector of cells and add them back after changing the mode but this would be 'fiddly'. They were cleared because buffers were originally full-screen only so would be out of range with different modes but now that's relaxed due to having ability of having different sized buffers and off-screen pasting is just ignored, the buffers could be kept during a mode change. I'll change that so that buffers remain; you will then be able to copy the screen, change the mode and then paste the buffer onto the new mode.
That said, now there is the ability to use buffers in that way, changing the mode wouldn't actually need to clear the screen; it could automatically do the copying and pasting. However, I'm not sure about that. I would expect changing a screen's mode to clear it plus copying and pasting onto the new mode would be a waste if the screen then needs to be cleared.
What use requires the content to be still available after a change of mode? I've just noticed your "resize" gif that shows the content stretching to match the screen.
I don't know how you did it :P You could be changing the mode and copying across the cells/re-printing after a size change or changing how many columns to use depending on the window size (where part of the Console Screen would be "off-window")?
One thing to note is that Console Screen is mainly just a screen, not a text/content editor so keeps no track of where a line of text ends, for example. The text-editor-style manipulation is provided mainly to move around the cursor. The "new-line" command doesn't add a new-line character to the screen; it simply moves the cursor.
Extra cursor commands can to added so there could be one that repeats backspace until it reaches a specified cell value but this isn't identical to the functionality that you wanted and I'm not sure it makes a decent addition, especially since it's simple enough to do manually.
Also, it's worth noting that a cleared/deleted cell has a cell value of zero. Depending on your texture setup and character mapping, zero might actually be a character (it doesn't have to be ASCII ordering). This means it's not as simple as just if something was printed there as it completely depends on which values you consider as being printed.
It's nice that it's working well with SFGUI too :)
I don't see any warnings to worry about ;) I still don't know why it's warning that numberOfTilesPerRow will be initialised after m_palette...
You may be interested in this quick basics tutorial (https://github.com/Hapaxia/SelbaWard/wiki/Tutorial%3A-%27Console-Screen%27-Basics) ;)
Edit
Patched Console Screen to v2.3.1. Buffers now persist over mode changes so you can do something like this to keep content:
cs.copy();
cs.setMode(newSize);
cs.paste();
cs.removeBuffer();
Note that it doesn't wrap content as in your animation; it merely pastes the content on top of the new mode. If the new mode is larger, the extra cells will be empty. If the new mode is smaller, the previous cells that do not fit will be discarded (they would still be available in the buffer if you don't remove it).
-
Demo Animation:
http://www.youtube.com/watch?v=Yjs-oRhn2fE
(best viewed in 1080 quality and 60 FPS)
Loading Intro
Just Console Screen for this part. The Console Screen is the light blue section. The "screen border" is the colour of the window and is just cleared to a solid colour (the flashing "loading" border is just clearing to a randomly chosen colour from the Console Screen's palette). The content is then "typed" one character at a time. The cursor is shows/hidden based on the current time in the animation (so that it flashes):
cs.setShowCursor(anim.csCursorVisibility.get(currentTime) && (currentTime % sf::seconds(1.5f) < sf::seconds(0.9f)));
anim.csCursorVisibility is an animation track that allows the cursor to be switched on and off depending on the current time in the animation. This line, then, flashes the cursor only when the cursor should be visible.
Actually, the Console Screen is technically drawn onto a render texture and then that texture is drawn to the window using a sprite; we use a Sprite 3D to achieve this.
Cube
The Console screen persists from the loading intro but the palette colours are changed. The Sprite 3D is animated to rotate to look like a cube. There are two Sprite 3Ds here, both using the same texture (from the render texture of the Console Screen) so both (seemingly all) faces of the "cube" are identical. As one face becomes completely obscured by the other, it effectively rotates 180° to continue as the next face. The Sprites are darkened based on their angle away from the "camera" to give some impression of 3D lighting.
There are also 7 Splines that have their vertices and (Bezier) handles animated based sinusoidally (a recurring technique in this animation). The vertices are equally spaced horizontally; only the y position of the vertices and handles are animated.
The Starfield, which is drawn behind everything else, is constantly moved left to give the impression of travelling to the right.
The "flashes" that match the music are only the window's background colour.
When the "yellow flashes" occur, the colour of the Splines transition from yellow/red-based to blue-based while the palette colour of the Console Screen that fills most of the screen changes from blue to red.
The phrase "Check in to check it out" shown on the Console Screen is output to the screen's stack cells. These particular cells are "on top" of the standard cells so are always displayed above them.
The entire screen is scrolled so that the title is at the top, scrolling the URL off the top. Note that stack cells don't scroll.
At the beginning of the animation, a buffer is prepared from a bit pattern for the block logo. This is made up of quarter cell blocks to display a mosaic logo. This is pasted at different positions on the screen so it can scroll onto the screen.
The title is scrolled left (just the top section is scrolled now, not the entire screen), wrapping from one side to the other. This gives the impression that the logo moves from one face to the next.
The "police line" row is flashed by animating the inverse attribute of that row (in a similar way to animating the flashing cursor):
cs << Cs::Begin;
if (currentTime % sf::seconds(1.2f) < sf::seconds(0.5f))
cs << Cs::CellAttributes(Cs::Affect::Inverse) << Cs::Affect::Inverse;
else
cs << Cs::CellAttributes(Cs::Affect::None) << Cs::Affect::Inverse;
cs << csFlashLineLocation << Cs::Wipe(textFlashLine.size());
cs << Cs::End;
Scroller
The Console Screen (and its Sprite 3D, although only one is used now) persists through this section as well. The palette is manipulated so that the colours that were shown are now all transparent except the title's text.
The Starfield persists too but is now moved in the opposite direction (but slows down toward the end).
The VU meters are three Progress Bars. The one on the left represents the left channel, the one on the right represents the right channel and the central one represents both. This is why the centre bar is always higher than both. The progress bar is "rounded" to one of the blocks so that it doesn't "light up" only half of a single light block.
The meters themselves use the actual music as input and the result is based on the music's current decibel level, not just its peak or even its RMS. To allow simpler access to the music's samples for this, the music is loaded as a sound buffer and played as a sound, rather than opened and streamed using sf::Music.
The scrolling text is a single Bitmap Text object that is just moved to scroll. The Bitmap Font used is customised to allow features like hanging letters (e.g. g, j, y) without increasing the entire cell for each character/glyph, different widths (e.g. l, i, j are thinner) and kerning (e.g. capital t followed by lower-case e "Te" are closer together).
Snake
The Starfield is now moved upwards (quite quickly) to the impression of moving downwards (quickly, similar to falling).
The "snake" here is a group of Rings that use the same motion paths. They differ their position on the path but the path used is the same. The path and the positions for each ring are sinusoid-based.
The texture used for the Rings is multi-coloured but not very saturated so that all of the colours still exist. For the first half of the snake section, the rings are coloured (multiplied by a colour) by a rainbow of colours. This gives each Ring a different base colour.
The Rings are drawn in the same order each time. The "back" ones (the ones drawn first) are slighly smaller to give the impression of depth. The "front" Ring has the entire ring segment and each ring behind it has a little less segment. Each ring is also rotated clockwise a little more than the one in front of it to give it a "corkscrew" look, although all rings are also being rotated constantly together as well.
The "hole" of all of the Rings are animated together to match the music in the first half of the snake section.
In the second half of the snake section, however, things are different...
The holes are no longer animated but the scale of the Rings are now animated to follow the beat of the music.
The segments of all of the rings are now animated similarly to the scale to follow the beat of the music. At their largest scale, the segments are as they were in the first half but at their smallest scale, the segments have a further 90° of the ring removed.
The colours of the Rings are now all set to white so that the original "pastel rainbow" texture can be seen on each ring. This gives each ring multiple colours. Note that because of the "corkscrew rotation", the colours also follow that look.
The asteroid that is introduced in this section is drawn using a Gallery Sprite, which just has its y position moved until it "collides" in the next section while it is just rotated.
The "snake" is moved off the top of the screen before the next section.
Rocket
A 2D side-scroller-style map using Tile Map then moves onto the screen quickly until the asteroid collides with it. At which point, the map, the asteroid, the stars, the rocket (a Gallery Sprite) and the rocket stand/astronaut animation (also a Gallery Sprite) all cease motion.
The asteroid's explosion is a Gallery Sprite that plays through its "exhibits" (or animation frames). The asteroid is removed when the explosion is large.
After the explosion has happened, the astronaut animation shows a door opening in a wall and a character jumping from it to the rocket's ladder. The ladder is then closed into the rocket and the door on the wall is closed. This is a frame animation and uses a Gallery Sprite. The frame durations are not equal; Plinth allows each frame of a Frame Animation to have its own duration. This allows delays on a single frame and some animation sections to have differing frame rates - as this animation does.
Following the astronaut's boarding the rocket, the rocket takes off. The rocket is a Gallery Sprite with 4 exhibits: 1 that is just the rocket and 3 of the rocket with propulsion flames that can be cycled for an animated flame. Note that the rocket is clearly drawn behind the Tile Map so that the flames don't appear over the map.
The rocket is then rotated to fly to the right and the Tile Map's camera is moved to the right (along with the stars being moved to the left) so that the level is scrolled to the left.
Note that there is, in fact, two Tile Maps here: the main "grey" one and a secondary, slightly smaller, bluer one behind it. The idea behind that was to create some depth but it ended up not being very noticeable.
The UI of the "side-scroller" is then scrolled into view. The texts are Bitmap Texts (using the same Bitmap Font as the scroller) and Progress Bars. Fuel and Power are simple coloured bars on coloured backgrounds but the Life bar is a texture bar. The texture is the width of a single "heart" image and contains only a full heart and an empty heart below it. The texture is repeated so that multiple heart can be seen by using a texture rectangle that passes the boundaries of the texture.
As the rocket moves up and down, the Tile Map camera is also moved up and down and the stars are moved accordingly.
The rocket's "laser" is just a Line. That is, it is a thick, textured Line. Whenever the laser is fired, "Power" is reduced by a small amount.
The level's "defence guns" are static level tiles and the level data is manipulated when they change to "damaged" (by changing the value of that tile). Similarly, the "barrier" that is shot away is a static level tile that is changed to a blank tile.
Since there is never more than one explosion on the screen at any one time, the same explosion Gallery Sprite is re-used for each explosion.
When the rocket "escapes the confines of the side-scroller to become a top-down scroller, the rocket is scaled up to show that it is now above the map. After leaving the map, however, it "drops" back down (scales down) to begin the vertical shooter-style section. The Starfield is moved downwards for this section.
The enemy ships are all Gallery Sprites. The enemies have animations for each gun firing. The actual enemy shot, though, is a thick, solid colour, Line.
For the "hyperspace" animation, multiple Lines are used. All lines are actually really long and just scrolled onto the screen together. The Starfield is removed too at this point.
Walk
Following the "clear white" of the hyperspace, the white is removed to reveal a walk animation on a coloured background. The character walking is a Gallery Sprite cycling through an 8-exhibit animation (in time with the music). The animation is "zoomed in" quite extremely and then zoomed back out to reveal lots of similar walking animations.
The "spiky" animation in the centre here is a Pie Chart. Each slice is "exploded" (pushed out from the centre) by a different amount based on - you guessed it - a sinusoid.
The floor here is made up of two separate things: a Ring and a Line.
The thick Line is the straight floor and the Ring segment is the curved part of the floor. As the floor moves, the Ring segment increases and the Line is reduced. The texture rectangle are adjusted to match their positions.
The characters walk along the straight floor and then up the curved (actually circular) floor. The floor moves to be a full Ring. At this point, the Line is no longer used.
Next, the Pie Chart's explosions are stopped as the characters have their heights scaled in a sinusoidal pattern. This scaling is to how the characters are clearly anchored to the floor. Technically, the "origin" of the Gallery Sprite is still at (0, 0). This is because each exhibit can have its own anchor point, which, in this case, is where the floor would be.
After some rotations of everything, the Pie Chart explosions return and the characters' heights are restored to normal just before "rolling" the entire thing off the screen.
Credits
The credits section uses the Nine Patch to display a strechable rectangle. Note that the corners are always the same size; it's the rest of the image that is stretched.
The Console Screen returns for this section. Its size and position is determined by the rectangle returned by the Nine Patch's "content area".
The screenshots gallery shown on the right use a Gallery Sprite. All of the screenshots are contained on one texture and the Gallery Sprite moves through those exhibits. It fades in and out and scales in and out for each screenshot.
The shadow on the Console Screen is created by copying the screen into a buffer, changing all of the colours in the buffer to be "shadow black" (black with some transparency) for the foreground and completely transparent for the background. The buffer is then pasted onto the stack (the "under" stack) so that it is shown below all of the standard cells. Stack cells can also have their position offsets so that allows the shadow's offset.
Note that this animation does not do this effect particularly efficiently. These shadows are created on every frame; that is, the entire screen is copied, manipulated, pasted and the buffer and all of the stack are both removed constantly. It would have been better to have done this only when the screen actually changes or, better still, use either a texture that contains the shadow or use a shader. However, this was done to make use of the "under stack" and its ability to be shown under the standard cells as well as having positional offsets (which is why the bespoke texture and shader techniques weren't used).
Console Screen's crash method was used for the crash screens. During those "crashes", the Nine Patch is faded out.
The final display on the Console Screen is the block/mosaic logo that was used earlier on the "cube" section. This time, however, the shadow is still being created so the logo has a bit more detail.
Finally
In this post, I have attempted to explain which Selba Ward object was used for which task and how it was used to achieve that particular effect. There was not much actual code shown here as most of the things done are controlled by Plinth (https://github.com/Hapaxia/Plinth/wiki)'s animation tracks and the actual main code is not organised well. However, there should be the information you need to understand what it going on and if you use the objects, you should be able to perform these tasks.
If there is anything you would like me explain in more detail, something you don't understand or just any questions about Selba Ward or the demo animation or its resources, feel free ask on this thread.
For more information, you can read the Selba Ward wiki (https://github.com/Hapaxia/SelbaWard/wiki).
-
that's incredible amazing, i thought i were know what Selba Ward could do based on my earlier work out, but after watching the demo it changes my respective completely.
-
Thanks, Mortal! :)
-
Updates!
Spline (wiki (https://github.com/Hapaxia/SelbaWard/wiki/Spline))
v1.1
Added ability to draw a thick spline instead of an infinitely thin (and therefore drawn as a single pixel-width) spline.
Specifying a thickness of zero uses the infinitely thin spline (uses sf::LineStrip) whereas any other thickness amount is used to generate a thick spline. "Line joints" are calculated to keep consistent thickness.
Thickness works with both linear splines (angled line segments) and Bezier splines (interpolated curves).
Replaced deprecated SFML enum value (sf::LinesStrip) with valid value (sf::LineStrip).
Plus, a few fixes.
Console Screen (wiki (https://github.com/Hapaxia/SelbaWard/wiki/Console-Screen)) (change log (https://github.com/Hapaxia/SelbaWard/blob/master/changelogs/ConsoleScreen.md))
v2.3.2
More double-height functionality: cursor commands and wrapping while printing moves two rows at a time and automatic scrolling move two rows if set to "both". Cursor becomes double height when cursor's print properties is set to "both".
Stack cells can now be positioned "off-grid". Since they are individual cells that float above (or below) the main cell grid, they can be independantly positioned.
Buffers are no longer removed when mode is changed as they are not required to match the mode exactly.
However, stack is now removed when mode is changed.
Numerous fixes since v2.2.0.
v2.4 coming soon... (it's already started but want to try to have more things in the update)
Nine Patch (wiki (https://github.com/Hapaxia/SelbaWard/wiki/Nine-Patch))
v1.3
You can now set (and get) its colour - the colour of all of its vertices. The default usage of this colour is to "multiply" it with the texture (as with standard SFML drawables).
Gallery Sprite (wiki (https://github.com/Hapaxia/SelbaWard/wiki/Gallery-Sprite))
v1.1
Texture rectangles now use floats instead of ints allowing "smoother" choices.
Plus, minor fixes.
Line (wiki (https://github.com/Hapaxia/SelbaWard/wiki/Line))
v1.2
Thick line now uses a manually calculated vertex array rather than an sf::RectangleShape.
Bounds now take into account thickness.
Thickness amount fixed (was thickness on both side - 10 thickness resulted in a line 20 thick - but is now correct).
Texture rectangle uses floats instead of ints to allow "smoother" choices.
-
Added a couple of simple examples to Spline's wiki page (https://github.com/Hapaxia/SelbaWard/wiki/Spline) to show how thick splines look.
Both use a spline of only three vertices.
Simple example 3 (thick):
(http://i.imgur.com/2zzYDrD.png) (https://github.com/Hapaxia/SelbaWard/wiki/Spline#simple-example-3)
Simple example 4 (thick curve):
(http://i.imgur.com/wpNKarD.png) (https://github.com/Hapaxia/SelbaWard/wiki/Spline#simple-example-4)
-
A new drawable, Elastic Sprite, is currently a work-in-progress.
Feel free to try this testing application (Windows only):
http://www.mediafire.com/file/sdw0acme64lgvo9/testSelbaWardElasticSprite.exe
(http://i.imgur.com/xclFcUo.png)
It's statically built so you only need the single executable file.
However, as always, if you don't already have it, you may need the Microsoft Visual C++ 2015 Redistributable:
https://www.microsoft.com/en-us/download/details.aspx?id=53587
-
Nice! :)
-
New Drawable! (finally)
Elastic Sprite (wiki (https://github.com/Hapaxia/SelbaWard/wiki/Elastic-Sprite))
A sprite class that can have its vertices (corners) manipulated individually: position offsets and/or their colours.
Screenshots of the simple examples, available on its Wiki (https://github.com/Hapaxia/SelbaWard/wiki/Elastic-Sprite):
Simple example - texture (https://github.com/Hapaxia/SelbaWard/wiki/Elastic-Sprite#simple-example---texture):
(http://i.imgur.com/zodshBH.png)
Simple example - colour (https://github.com/Hapaxia/SelbaWard/wiki/Elastic-Sprite#simple-example---colour):
(http://i.imgur.com/eorXw2D.png)
Simple example - texture and colour (https://github.com/Hapaxia/SelbaWard/wiki/Elastic-Sprite#simple-example---texture-and-colour):
(http://i.imgur.com/2Ok37Pn.png)
-
Nice, good job! :)
I really should play around more with your libraries.
-
Getting better and better! Thank you!
-
awesome, gotta update Selba Ward libs :)
-
Thank you!
After trying it (or anything else), let me know what you think and anything you think needs improving :)
-
Pardon me if I'm wrong here, but it appears m_thickness isn't initialized in the Spine class. Without explicitly setting it, its value is undefined, just some garbage value. Thus, the examples on the Wiki do not produce the expected results.
Not that it's that big of a deal, but I wanted to mention it.
-
Sorry for the second post.
But regardless of that, I modified SelbaWard slightly to expose the interpolated points that the Spline class makes and wrapped a SplinePath class with it. Combined it with Thor in our engine to make particle effects that follow a path. Still working on making the particles look nicer, but it fits the bill.
https://youtu.be/Lo55-PfwSoc
Or see a gif if you don't wish to condone my shameless self-promotion:
(https://media.giphy.com/media/ZyDcMcIja1oTm/giphy.gif)
-
it appears m_thickness isn't initialized in the Spine class.
You are correct; an oversight on my part. I will fix this as soon as I can. Feel free to open an issue on Selba Ward's GitHub so I don't forget about this.
I modified SelbaWard slightly to expose the interpolated points
Although Selba Ward's objects are drawables by design and creating a spline control path isn't really within that design, exposing the interpolated points could be useful in a number of ways without introducing any complications to the class. Therefore, this simple feature is now "planned" ;)
-
Update!
Spline (wiki (https://github.com/Hapaxia/SelbaWard/wiki/Spline))
v1.2
Added ability to specify initial vertices by a list of positions directly in the constructor using an initializer list (see simple examples (https://github.com/Hapaxia/SelbaWard/wiki/Spline#simple-example))
Added ability to automatically close the spline. This also takes into account the angle connection of the first and final vertices for thick Splines:
(http://i.imgur.com/s6WpgHl.png)
With anti-aliasing:
(http://i.imgur.com/t85IW67.png)
Added ability to retrieve an interpolated position of the Spline as well as the number of interpolated positions in the entire Spline - useful for control paths:
https://www.youtube.com/watch?v=ppqqly7xtBA
Plus, a few fixes, including setting the colour not affecting the thick Spline - only the thin one - and an internal miscalculation.
@JayhawkZombie, I noticed you're spinning the SFML card at the beginning of your video. Are you using Selba Ward's Sprite3D? If so, consider increasing the subdivision amount ;) Also, if you set its origin to its centre, it rotates around the centre in 3D too!
-
Added ability to specify initial vertices by a list of positions directly in the constructor using an initializer list (see simple examples (https://github.com/Hapaxia/SelbaWard/wiki/Spline#simple-example))
That will make the syntax much cleaner.
It probably would have been proper of me to tell you how I extended Spline, but it appears you exposed identical functionality that I did, minus a difference in the parameter list.
All I added was:
sf::Vector2f getInterpolatedVertex(unsigned int index);
unsigned int getInterpolatedVertexCount() const;
Added ability to automatically close the spline. This also takes into account the angle connection of the first and final vertices for thick Splines:
That will (probably) take care of the hitch that occurs when paths meet. I had duplicated the meeting vertex at that point.
Added ability to retrieve an interpolated position of the Spline as well as the number of interpolated positions in the entire Spline - useful for control paths:
;) My particle effects much appreciate
Can this allow you to retrieve the interpolated thick points? One could create several parallel paths that way with only one spline.
@JayhawkZombie, I noticed you're spinning the SFML card at the beginning of your video. Are you using Selba Ward's Sprite3D? If so, consider increasing the subdivision amount ;) Also, if you set its origin to its centre, it rotates around the centre in 3D too!
We are! Actually, it would be more accurate to say we're integrating SelbaWard into our Engine, but that was there for just showing it off. The subdivision amount completely slipped my mind - I'll try that!
We used SelbaWard in our "tech" demo a couple days ago. We had "smokey" particles following a path in one menu, and used your Starfield in the physics / time dilation demo.
Having time freeze for everything but the starfield had a cool-looking effect.
https://www.youtube.com/watch?v=96tadraw8Ho&t=3s
The anti-aliased spline looks really nice.
We're migrating our code base from our old design repo to our official open-source repo. Once that's done, I'll try to make a tech demo and leverage some more SelbaWard functionality.
OH, we also used your Bitmap font/text classes to speed up text rendering. Those things are a godsend.
-
I have a few other things planned for Spline - one of which will allow parallel control paths. One important thing to note about these parallel paths is that the interpolated positions that are equivalent are not equal distance apart. For example, through a bend, the outside of that bend has the same number of points that are further away than the inside of that bend. The solution for that in animation paths is to use the points as a target and then move towards that target using a velocity.
Also, on sharp bends, the sides aren't always as expected - a sharp corner only becomes that angle for its single position and any positions before and after are still "normal" so inners can cross in a weird way (you can see this effect by drawing a thick spline with a semi-transparent colour).
Adding an extra vertex at the end that matches the first vertex was not enough to close the Spline correctly. The angle of the ends still didn't match as they don't take into account the angle of the path before or after it. To see what I mean, create an open spline with very few interpolated positions and a bend at connection.
Note that, with Spline, I intentionally only use the word vertex to refer to the control vertices of the Spline and never the actual rendered vertices (that only occurs in the implementation code).
I see you have quite a few libraries in your engine! I happen to use Plinth (https://github.com/Hapaxia/Plinth/wiki) in everything I make. It even has some things designed alongside Selba Ward things (Frame Sequence was designed alongside Gallery Sprite, for example) ;) and you may want to consider Kairos (https://github.com/Hapaxia/Kairos/wiki), the timing library, especially since you seem interested in "bending time" ;D
Oh, and one thing to note about subdivision in Spline 3D: don't overdo it! It increases exponentially so double digits could easily kill computers :P
-
Note that, with Spline, I intentionally only use the word vertex to refer to the control vertices of the Spline and never the actual rendered vertices (that only occurs in the implementation code).
Yes, I wasn't as deliberate. My path class was the only one referencing the functions.
I see you have quite a few libraries in your engine!
Yes... Is that bad? Only a couple graphical helpers, but the rest are scripting/physics/serialization.
you may want to consider Kairos, the timing library, especially since you seem interested in "bending time" ;D
I had no idea that existed, lol. It looks pretty cool. Probably doing time management better than we are currently.
-
Updates!
Nine Patch (wiki (https://github.com/Hapaxia/SelbaWard/wiki/Nine-Patch))
v1.4
Added ability to provide a rectangle that specifies which part of the texture to use; this include the control edges. This allows for a Nine Patch texture to be a sub-texture rather than requiring the entire texture to itself.
The axis-aligned content area bounds can now be retrieved for both local and global.
Added ability to test if a point is inside the actual transformed content area; this is not limited to axis-alignment!
Spline (wiki (https://github.com/Hapaxia/SelbaWard/wiki/Spline))
v1.3
Added ability to specify colours and thicknesses per vertex.
These values are multiplied with the global values and are interpolated linearly between vertices:
(http://i.imgur.com/A0FAnV8.png)
With anti-aliasing:
(http://i.imgur.com/yUP6VrZ.png)
More information is available from the interpolated positions:
- the tangent (unit vector),
- the normal (the tangent rotated 90 degrees anti-clockwise),
- the interpolated vertex thickness,
- the thickness correction scale (highest at sharper corners and one for straight sections).
Example animation using this information:
https://www.youtube.com/watch?v=CrvOsypfYMQ
I see you have quite a few libraries in your engine!
Yes... Is that bad? Only a couple graphical helpers, but the rest are scripting/physics/serialization.
If a library already provides what you need, using it makes sense.
-
More information is available from the interpolated positions:
- the tangent (unit vector),
- the normal (the tangent rotated 90 degrees anti-clockwise),
- the interpolated vertex thickness,
- the thickness correction scale (highest at sharper corners and one for straight sections).
This is awesome. I can come up with quite a number of uses for the tangent vector here.
If a library already provides what you need, using it makes sense.
Yes, we saw no point in reinventing the wheel.
Speaking of libraries, I did checkout Kairos, and rewrote our ticking system and rendering system to use it and interpolate between physics states when rendering. Makes everything look soooo much smoother. No more jittery colliders, and them being rendered 1 tick behind isn't really noticeable, since the physics logic is still being updates at 40fps. I think the smoothed-out motion is worth the 1 frame of lag.
https://www.youtube.com/watch?v=i09kn48DdxE
-
Can those spline be textured? I mean following the curve.
Top work yours!
-
@JayhawkZombie, glad you like the new Spline stuff! :) and Kairos too! ;)
@roccio, no. Splines cannot be textured at all. Although I have considered the implementation of texturing the Spline, I don't think that it would be the result expected/hoped for.
Note that there are limitations/restrictions to using the "per vertex" attributes (colour and thickness). Using thickness per vertex can cause "slightly off-looking" angle at sharp corners as well as a slight sharp bump on the inner edge whereas using colour per vertex may not be interpolated as expected; note also that the Spline segments are drawn in order so if a corner overlaps itself, the colour behind would be overdrawn. Colours and thicknesses per vertex are more useful if there are no sharp corners.
With that, image the result that could occur with texturing!
-
Are you planning on adding a feature to the Nine Patch to allow multiple stretching sections? Something along the lines of what this post on StackOverflow (http://stackoverflow.com/questions/3733471/android-9-patch-png-what-if-i-need-smth-like-a-11-patch-png) is trying to achieve?
-
There are currently no plans to expand Nine Patch to have more than nine patches although it can be a consideration for the future.
Note that it can be achieved by displaying Nine Patches together.
-
Update!
Elastic Sprite (wiki (https://github.com/Hapaxia/SelbaWard/wiki/Elastic-Sprite))
v1.1
Added ability to use perspective interpolation instead of bi-linear interpolation.
Bi-linear interpolation can look 'rubbery' but remains evenly distributed and edges match easily. Note that lines can be bent (notice the red diagonal squares 0-9 in the examples below); then again, it is technically a similar method to calculating bezier curves...
Perspective interpolation adjusts the apparent 3D rotation of the quad to match the vertices' positions. This is similar to Photoshop's free transform's individual corner manipulation. Note that distribution is no longer even and edges will not match so easily.
Compare below.
Bi-linear:
(http://i.imgur.com/zodshBH.png)
Perspective:
(http://i.imgur.com/gcg39PI.png)
One additional thing to note is that the RGB components of the sprite's colour are disabled when drawn using perspective interpolation; the alpha is used as normal.
The reason for this is because an extra "weight" float per vertex that would be interpolated like other vertex attributes is needed. Since SFML's vertex format is rigid and only has 2d position and texture co-ordinates, this value could not be passed through a spare. This led to the decision to encode the float into the three colour (RGB) components of the sprite's colour.
-
Updates!
(summary since previous post)
Console Screen (wiki (https://github.com/Hapaxia/SelbaWard/wiki/Console-Screen))
v2.4.1
- Can stream numbers using the new Number type.
- Can now get cell location of a given co-ordinate
- Can get (transformed) co-ordinate of a cell location.
- New 8-bit RGB palette
- Can now set the cell value used for 'clearing' a cell; it is no longer required to be zero.
- Can now customise the multiplier used for darkening a cell's colour when using Dark attribute (Bright has been swapped for Dark).
(more info. (https://github.com/Hapaxia/SelbaWard/blob/master/changelogs/ConsoleScreen.md))
Tile Map (wiki (https://github.com/Hapaxia/SelbaWard/wiki/Tile-Map))
v2.0.1
- Now fully templated.
- Connect the level when needed rather than having to pass it with every update.
- Level width is now also stored and can be changed separately.
Elastic Sprite (wiki (https://github.com/Hapaxia/SelbaWard/wiki/Elastic-Sprite))
v1.2
- Fixed perspective interpolation when used with larger texture or offset
- Perspective interpolation can now be used with colours
Spline (wiki (https://github.com/Hapaxia/SelbaWard/wiki/Spline))
v1.5
Multiple corner types
These are applied at every point (except start and end points) including interpolated ones.
They allow corners to take a form that is different from the original 'point' corner.
The corner types available are:
Point
The original type. This extends the edges until they meet. This has no limit.
PointLimit
Similar to Point. This extends the edges until they meet. However, if the length of this point is greater than the maximum allowed length (customisable), this point is 'pulled inwards' until it reaches that length.
PointClip
Also similar to Point. This extends the edges until they meet. However, if the length of this point is greater than the maximum allowed length, this corner is converted into a bevel-style corner (see below).
Bevel
This does not extend the edges until they meet. The two corners of the rectangles - that make up the two joining thick straight lines - are joined together.
Round
This also does not extend the edges until they meet. This is similar to Bevel except the the corners are joined together using a circular curve. The interpolation level of round corners can also be customised; a level of zero is visually equivalent to a bevel corner.
Multiple cap types
Caps are how the start and end of the Spline are drawn.
Each cap (start and end) can be customised separately.
Available cap types:
None
This adds nothing to the spline. It therefore appears as a flat edge that passes across the vertex.
Extended
This extends the flat edge so that it is half of the thickness of the Spline away from the vertex. This leaves half thickness around the vertex.
Round
This adds a semicircle to the flat edge. The centre of the semicircle is the vertex. Its radius is half of the thickness. It reaches the same distance as the Extended type. This leave half thickness around the vertex.
The interpolation level of round corners can be customised; a level of zero is visually equivalent to "None" and a level of one is a "triangle" cap.
Random normal offsets
Each point (including all interpolated points) can be offset along its normal by a random amount. The range of this random distance can be customised. Each vertex also has this range so it is interpolated and multiplied in a similar way to the thickness and vertex thicknesses. The offset, however, is centred on the original Spline path. This allows 'lightning' style effects.
Optimisation
The updates have been optimised, allowing only the visual representation to be updated if the Spline itself hasn't moved or interpolation settings haven't changed. Basically, as long as it doesn't need to calculate the points or interpolation points, just the visual representation can be updated separately.
Note that the corner and cap types only apply to a thick Spline whereas the random normal offsets apply to both a thick and a thin Spline.
Simple Example 3b (https://github.com/Hapaxia/SelbaWard/wiki/Spline#simple-example-3b) (thick with rounded corners and caps):
(https://i.imgur.com/JzyDo0i.png)
Simple Example 4b (https://github.com/Hapaxia/SelbaWard/wiki/Spline#simple-example-4b) (thick with rounded corners and caps):
(https://i.imgur.com/AZTZiQd.png)
Simple Example 1b (https://github.com/Hapaxia/SelbaWard/wiki/Spline#simple-example-1b) (random normal offsets - lightning):
(https://i.imgur.com/xdliudn.png)
General
Numerous fixes that include compiler errors or other bugs.
-
I want to thank you for the amazing console screen, it is just what I was looking for, to make a simple text editor in SFML :).
Now I'm using CSFML, so I can't use this, but I wonder if I can build a little lib only with the console screen sources, or do I need to compile all sources for the console to work?
-
Thank you for your kind words. It's always a good feeling when you hear that someone is enjoying Selba Ward.
I'm not sure I understand your move from C++ to C but I won't judge (too much) ;D
Selba Ward is built so that each drawable object can be used separately from any of the others. So, to use just Console Screen, you can simply copy the files into your project and link them. The (3) files you need would be ConsoleScreen.hpp, ConsoleScreen.cpp and Common.hpp. You could, if you wish, also include PaletteEnums.hpp if you wish to use those but this is not required. Then, just compile along with the rest of your project.
It's worth noting, though, that the files themselves are written in C++ so would need converting to plain C first. Or you could build just those files as a library and use that. Never needed to do this though so it may or may not work or even be possible.
Hope it works out for you!
-
Thank you for your kind words. It's always a good feeling when you hear that someone is enjoying Selba Ward.
I'm not sure I understand your move from C++ to C but I won't judge (too much) ;D
Selba Ward is built so that each drawable object can be used separately from any of the others. So, to use just Console Screen, you can simply copy the files into your project and link them. The (3) files you need would be ConsoleScreen.hpp, ConsoleScreen.cpp and Common.hpp. You could, if you wish, also include PaletteEnums.hpp if you wish to use those but this is not required. Then, just compile along with the rest of your project.
It's worth noting, though, that the files themselves are written in C++ so would need converting to plain C first. Or you could build just those files as a library and use that. Never needed to do this though so it may or may not work or even be possible.
Hope it works out for you!
Thanks a lot!
-
Just saw that you added the Pixel Display (https://github.com/Hapaxia/SelbaWard/wiki/Pixel-Display) and while reading through the wiki page, I wondered, why is there no shiftUp/shiftDown? ;)
-
Well spotted! However, there is a reason...
What scrolling does is pretty obvious. The scroll movement can happen in either direction of either of the two dimensions.
It moves the pixels around the 2D space.
Shifting is different and is similar to bit shifting.
All pixels are stored in a single, one dimensional vector that wraps across the 2D space.
Shifting left moves all pixels in the vector left within the vector. This means that on the 2D display, they wrap onto the row above, not the same row.
To be more clear with a simple example:
A similar effect is having a text editor with "wrap" enabled and lots of characters without any line breaks. If you delete the first character, they all shift to the left. The letters from the left of a row appear at the end of the row above. If you deleted most of the characters, you could end with the characters from the bottom now on the top line.
I've probably explained this far too detailed and most people would understand it from the first part (without the example). The example is just for clarity.
Hope that helps :)
-
Threadomancy incoming!
I decided to give the ElasticSprite a go but for some reason it draws the texture upside down. If I replace it with a regular sprite this does not happen.
The reduced relevant code would look something like this:
UPSIDE DOWN:
while (window.isOpen())
{
window.clear();
sf::RenderTexture pre;
pre.create(resolutionX, resolutionY);
//Write lots of stuff to pre
pre.display();
sw::ElasticSprite esprite(pre.getTexture());
window.draw(esprite);
window.display();
}
NOT UPSIDE DOWN
while (window.isOpen())
{
window.clear();
sf::RenderTexture pre;
pre.create(resolutionX, resolutionY);
//Write lots of stuff to pre
pre.display();
sf::Sprite sprite(pre.getTexture());
window.draw(sprite);
window.display();
}
Is there something I'm not allowed to do with my rendertexture before I write it using the elastic sprite?
-
You need to treat your render texture like a window - that is, create it only once, then call renderTexture.clear() before you draw on it, followed by renderTexture.display() when you've finished drawing.
sf::RenderTexture rt;
sf::RenderWindow rw;
rt.create(w,h);
rw.create(w,h);
while(rw.isOpen())
{
rt.clear();
//draw stuff
rt.display();
rw.clear();
//draw other stuff
rw.display();
}
-
You need to treat your render texture like a window - that is, create it only once, then call renderTexture.clear() before you draw on it, followed by renderTexture.display() when you've finished drawing.
Seems reasonable, and when/if I use it for real I'll do it that way :)
I changed it in my experiment and its still upside down. And it works with a regular sprite ???
I also tried to turn of the shaders with setUseShader(false) and then it works, so the problem seems to be in the shaders.
-
My guess is that this is, as binary1248 put it, a "feature and not a bug".
See the explanation of RT with Shaders on this GitHub issue (https://github.com/SFML/SFML/issues/1733#issuecomment-761708945) and the related forum post (https://en.sfml-dev.org/forums/index.php?topic=27815.0).
Not sure if Selba Ward could be adjusted to account for RT usage.
-
My guess is that this is, as binary1248 put it, a "feature and not a bug".
See the explanation of RT with Shaders on this GitHub issue (https://github.com/SFML/SFML/issues/1733#issuecomment-761708945) and the related forum post (https://en.sfml-dev.org/forums/index.php?topic=27815.0).
Not sure if Selba Ward could be adjusted to account for RT usage.
Aha, makes sense. It's a bit much to try and reverse engineer the selba ward shaders right now, but now I at least know what I need to do if I want to try this again.
Thanks!
-
Yes, I believe this is related to the post linked by eXpl0it3r.
Luckily, there seems to be a simple solution (hack?)! You can invert the texture rectangle in the Elastic Sprite for drawing to a render texture. This is a pretty simple, one-time change although if you need to draw to a render texture and the main window (or even a render texture on a render texture!), you may need to keep switching the texture rectangle.
To flip the texture:
if you use the entire texture - and the texture is set to repeat - you can just negate the height.
if you use a section of a texture, you can add the current height to "top" and then negate the height.
I guess this isn't a big deal-breaker for using Elastic Sprite (or anything with shaders on a render texture) but I suppose it shouldn't be too difficult to add a "flip switch" either ;D
p.s. No problem for the necro. This thread is allowed to be necroed :P (otherwise there might be multiple threads relating to the same subject)
-
Update!
Elastic Sprite (wiki (https://github.com/Hapaxia/SelbaWard/wiki/Elastic-Sprite))
v1.3
Added ability to assign a flip to the texture.
Horizontal and/or vertical flips can now be assigned to the texture in Elastic Sprite. This allows the ability to assign the texture rectangle as normal but still use it flipped. This works with both interpolation shaders as well as without the shader.
If es is the Elastic Sprite, to assign the flip you can do both or either of:
es.setTextureFlipX(true);
es.setTextureFlipY(true);
You can also 'unflip' by setting them to false.
-
Latest!
It has been a while since I've updated this post so I thought it time to bring everyone up to speed with the current state of Selba Ward (https://github.com/Hapaxia/SelbaWard/wiki)!
Here, I will be listing the main updates that I've not previously mentioned.
First, though, it should be mentioned that Selba Ward now has a branch that can be used with the currently work-in-progress version 3 of SFML.
You can visit that branch here:
https://github.com/Hapaxia/SelbaWard/tree/sfml3
Note that the documentation is still for the current version of SFML (v2) and will stay that way until the official release of SFML 3. However, very little has changed with the way it can be used anyway; most of the (current) changes are just so that it can communicate with SFML 3 without errors.
Now, back to the main (master) branch and SFML 2...
Generally, all drawables have had any use of the quad primitive removed in advance of the upcoming depreciation of it within SFML. This allows it to be more 'future-proof' for later 2.x versions of SFML as well as bridging a gap to the upcoming v3.
The old version of Console Screen has been removed. The newest version is better anyway ;)
New Additions!
Starfield 3D (wiki (https://github.com/Hapaxia/SelbaWard/wiki/Starfield-3D))
v1.0.1
A 3D starfield of randomly generated stars.
I'm sure you must have all seen Starfield (https://github.com/Hapaxia/SelbaWard/wiki/Starfield) by now. You may also have noticed its limitations due to its simplicity. It's still, of course, available and can be useful for a simple way to draw pixel stars. The pixel limitation was the reason I decided to make something a bit better; if a screen is high-resolution, pixels are smaller and therefore the stars become less noticable and may require drawing to a render texture first before then enlarging them to be able to see them.
Now, Starfield 3D alleviates this issue by allowing you to draw and actual star shape for every star instead of just a single pixel! In fact, this star shape can be anything at all; you can customise it fully (shape and colour)! Starfield 3D then scales and colours the stars based on depth but the scales and colours can be customised too.
Not just that, but the actual starfield itself is now projected with perspective and is now 'actually' 3D. This allows full control over camera movement to allow fully-3D motion including forwards and backwards (into and out of the scene).
Here is a short animation showing the style of effect:
(https://i.imgur.com/3NnjF8r.gif)
Note that this GIF animation is looped so there is a noticeable jump when the animation restarts. This does not occur in the actual code.
These are the default star shapes but, as mentioned previously, they can be any shape at all - any collection of triangles (positions and colours!). You can simply pass a vertex array to Starfield 3D and it will copy it as a star template. Remember, of course, that it will be drawn with a primitive type of sf::PrimitiveType::Triangles so the vertex array should probably match that if you want predictable results. Note also that stars cannot be textured.
Polygon
v1.1
Creates a filled polygon from any given number of vertices/points.
Yup! Any convex/concave shape!
It automatically triangulates any 'solid' shape although you should note that overlapping edges are not allowed. It's not perfect and can break and very very complicated shapes but it does the job fine for most normal shapes and I plan to improve it over time.
(https://i.imgur.com/b6th5VC.png) (https://i.imgur.com/ZDJSZp6.png)
There is no documentation for this right now but, of course, there will be. Plus, it should be pretty self-explanatory. You may notice there are some methods customise the way that triangulation is performed but there are no extra options at the moment; these will be used when those are added.
Pixel Display (wiki (https://github.com/Hapaxia/SelbaWard/wiki/Pixel-Display))
v1.0.1
A resizable grid or squares that be coloured individually.
Its intention is to simplify emulating more retro-style displays but can be used for any mosaic-style art.
It stores a palette of colours and then you can reference them by palette index instead of colour. This means if the palette changes, the display also changes and uses the new palette colours. This also allows (built-in) colour-cycling (as shown in the following animation).
You could think of it as a tilemap for colours instead of textures. It also has built-in 'commands' to manipulate it as if it were a pixel display.
It was used to create this animation:
(https://i.imgur.com/SefOZbM.gif)
Updates!
Now for some updates to already existing drawables:
Spline (wiki (https://github.com/Hapaxia/SelbaWard/wiki/Spline))
v1.6.2
A few additions and fixes:
- In standard usage, corners no longer overlap so transparency can be used.
- A Spline can be added to the end (or beginning) or a Spline.
- A Spline can be 'connected' to another Spline. This can move the entire Spline or just the single vertex required. The Spline can also be automatically rotated so that the two joining vertices match orientation.
- Both of the above methods can be done as one act - adding a Spline to the end of the Spline while also moving and/or rotating to match.
General
Patch updates
All or most of the drawables have had patch updates to fix various issues including:
- Removing the use of the quad primitive in advance of it becoming deprecated.
- Fixing compiler errors.
- Code consistency.
-
Awesome! :)
Need to play around a bit more with all these goodies ;)
-
So cool to see people building on top of v3!
-
Thanks and I hope you enjoy them :)
-
Update!
Polygon (wiki (https://github.com/Hapaxia/SelbaWard/wiki/Polygon))
v1.2
Polygon can now create a polygon...with holes!
Now also has documentation! See its wiki page (https://github.com/Hapaxia/SelbaWard/wiki/Polygon) for a couple of simple examples including one that produces this image:
(https://i.imgur.com/KVziKUn.png)
-
Hey! I was building an app using the ConsoleScreen, and I've noticed that it fails to set the background whenever I pass a background color to it.
I've called cs.crash() and streamed the default color green change directly to the console?
-
Hi!
I'm glad you're finding use of Selba Ward!
However, I'm sorry to hear that you're having some issue with the use of Console Screen.
Could you please provide some small code that reproduces this issue that I can test as I've not yet come across an issue where the background colour has failed to set when required?
Thank you very much! I'd like to find this issue as soon as possible so there can be a fix :)