hapaxia / selbaward

A collection of SFML drawables

• 👋 Hi, I’m @Hapaxia
• 👀 I’m interested in problem solving.
• 🌱 I’m currently learning 日本語 (Japanese).
• 💞️ I’m looking to collaborate on something for fun.
• 📫 How to reach me: My Mastodon or My Twitter
• 🔗 Other links: Link Tree

Not the most interesting profile but I'd rather spend time doing stuff 😁

selbaward's Issues

Error LNK2019

I'm trying to include a Line.hpp file, but when linking a program I get an error "unresolved external symbol". Am I doing something wrong or do I need to include some lib file?

Suggestion. sw::Spline -> sw::Polygon.

You asked for suggestions, so here's one.

The sw::Spline class is great, I love it, but we are talking about a line (of some thickness). What I would like (and have a use for) is to have a sw::Polygon, with which I mean to say, a sw::Spline that is filled. The Spline (the outline) is closed, in this case, of course.

Maybe you can have a think about it, if it's not clear, just post here.

Wiki - Spline doesn't compile with versions of SFML below v2.4

SFML only introduced the LineStrip, TriangleStrip and TriangleFan enums in v2.4 (instead of LinesStrip, TrianglesStrip and TrianglesFan), and thus Spline doesn't compile in previous versions of SFML. However, the Setup page in the wiki only specifies to have SFML v2.

I know it's a very simple and minor issue but it spent me an hour trying to figure that out >_<

NinePatch does not combine its transform with the RenderStates transform

Line 247 of NinePatch.cpp should be: states.transform *= getTransform(); instead of states.transform = getTransform();

Ring shape - incorrect size

Ring shape 10 times bigger than SFML circle. When I put ring radius 64 it cowers half of my screen.
Same time when use SFML circle with radius 32, I got exactly what expected - circle with proper size.

Continuous Integration Error Output

The CI tests are outputting errors.

One such error is CMake-based:

CMake Error: CMake was unable to find a build program corresponding to "Ninja".  CMAKE_MAKE_PROGRAM is not set.  You probably need to select a different build tool.

Question: plans to port to SFML 3?

I'd be quite eager to use ConsoleScreen and PixelDisplay, but, alas, they rely on the deprecated sf::PrimitiveType::Quads (if I remember correctly).

Any plans to migrate to the SFML 3 API?
(I've ported a small GUI lib and Thor2 already (for my personal use), but kinda have run out of steam for yet some more. :) )

Some missing explicit inclusions and namespaces

In some (mainly older) drawables, there is some usage of a standard library without any explicit inclusion of that library. There are also some occasions where the calling of functions from these libraries do not specify their specific namespace and are called from global scope.

This may compile okay using some compiler due to the automatic and implicit inclusion of these libraries by certain compilers but will not compile with all. To stay cross-platform, this should be rectified.

Initialization Order.

Not all fields are initialized in the correct order:

1>..\src\SelbaWard\ConsoleScreen.cpp(685): warning : field 'm_buffers' will be initialized after field 'm_do' [-Wreorder]
1>..\src\SelbaWard\ConsoleScreen.cpp(696): warning : field 'm_numberOfTilesPerRow' will be initialized after field 'm_palette' [-Wreorder]
1>..\src\SelbaWard\ConsoleScreen.cpp(697): warning : field 'm_palette' will be initialized after field 'm_cursor' [-Wreorder]
1>..\src\SelbaWard\ConsoleScreen.cpp(702): warning : field 'm_darkAttributeMultiplier' will be initialized after field 'm_characterMap' [-Wreorder]
1>..\src\SelbaWard\ConsoleScreen.cpp(703): warning : field 'm_characterMap' will be initialized after field 'm_defaultPrintProperties' [-Wreorder]
1>..\src\SelbaWard\ConsoleScreenOld.cpp(299): warning : field 'm_buffers' will be initialized after field 'm_do' [-Wreorder]
1>..\src\SelbaWard\ConsoleScreenOld.cpp(308): warning : field 'm_numberOfTilesPerRow' will be initialized after field 'm_colors' [-Wreorder]
1>..\src\SelbaWard\ConsoleScreenOld.cpp(310): warning : field 'm_palette' will be initialized after field 'm_cursor' [-Wreorder]
1>..\src\SelbaWard\ConsoleScreenOld.cpp(312): warning : field 'm_attributes' will be initialized after field 'm_stretch' [-Wreorder]
1>..\src\SelbaWard\Crosshair.cpp(99): warning : field 'm_vertices' will be initialized after field 'm_horizontalColor' [-Wreorder]
1>..\src\SelbaWard\Crosshair.cpp(101): warning : field 'm_verticalColor' will be initialized after field 'm_window' [-Wreorder]
1>..\src\SelbaWard\ElasticSprite.cpp(143): warning : field 'm_offsets' will be initialized after field 'm_weights' [-Wreorder]
1>..\src\SelbaWard\ElasticSprite.cpp(146): warning : field 'm_usePerspectiveInterpolation' will be initialized after field 'm_requiresVerticesUpdate' [-Wreorder]
1>..\src\SelbaWard\ElasticSprite.cpp(148): warning : field 'm_textureRect' will be initialized after field 'm_pTexture' [-Wreorder]
1>..\src\SelbaWard\GallerySprite.cpp(51): warning : field 'm_vertices' will be initialized after field 'm_pTexture' [-Wreorder]
1>..\src\SelbaWard\GallerySprite.cpp(53): warning : field 'm_exhibits' will be initialized after field 'm_currentExhibit' [-Wreorder]
1>..\src\SelbaWard\NinePatch.cpp(150): warning : field 'm_textureRectangle' will be initialized after field 'm_trimmedSize' [-Wreorder]
1>..\src\SelbaWard\ProgressBar.cpp(40): warning : field 'm_size' will be initialized after field 'm_showBar' [-Wreorder]
1>..\src\SelbaWard\ProgressBar.cpp(47): warning : field 'm_textureRectangle' will be initialized after field 'm_backgroundTexture' [-Wreorder]
1>..\src\SelbaWard\SpinningCard.cpp(42): warning : field 'm_depth' will be initialized after field 'm_vertices' [-Wreorder]
1>..\src\SelbaWard\Spline.cpp(131): warning : field 'm_showHandles' will be initialized after field 'm_useBezier' [-Wreorder]
1>..\src\SelbaWard\Sprite3d.cpp(93): warning : field 'm_backTextureOffset' will be initialized after field 'm_size' [-Wreorder]
1>..\src\SelbaWard\Sprite3d.cpp(104): warning : field 'm_isBackFacing' will be initialized after field 'm_compactTransformMatrix' [-Wreorder]

No biggie, but could be better.

Spline closes incorrectly with certain corner types

Spline doesn't close properly when the corner types are something other than Point.

When closed, it needs to treat the final (joining) vertex as one with a corner as all the other vertices. This requires extra output vertices to allow the creation of the corner. Point works because it manipulates the usual points to form the point.

Unable to make a rotating cube

There seems to be some limitation about axes, No matter how hard I try I'm unable to create a rotating 3 face cube.
I theory I should be able to do it by just setting origin z for all faces equal to texture size / 2 and then increment the angles with a 90 degrees offset in X for the 2nd face and in Y for the 3rd face. The faces are floating in random directions instead.

BitmapText does not check if internal font handle is null

I'm using the most recent version of SelbaWard, and it appears that BitmapText, after settings the string property, in updateVertices will attempt to dereference its internal font pointer without checking for its null-ness.

The crash occurs when executing this statement:

const int kerning{ (character < m_string.length() - 1) ? m_pBitmapFont->getKerning(m_string.substr(character, 2)) : 0 }; on line 139, which will obviously go very poorly if one has not yet set the font.

I think it would be reasonable to check for the texture for null, and the statement would look nearly identical:

const int kerning{ (character < m_string.length() - 1) && m_pBitmapFont ? m_pBitmapFont->getKerning(m_string.substr(character, 2)) : 0 };

It would also allow us to set the properties in any order, much like SFML allows.

Thank you for this I dont know who to contact

I just wanted to say, I've been trying to get my own ms paint like drawing started and a week passed by with pure frustrations as I only managed to get a single line going, along with a quill type style where moving in certain angles won't provide even thickness.

I came across your Spline section so I wanted to just say thank you because after tinkering with some of your class functions I managed to get one up and running. I can handle some trig but after a while on this stuff, I just want it done and move on to the next project Lol. Anyway, thank you for this cheers~

ProgressBar

I try to use "Progress bar" example, some errors are appearing:
error LNK2019: unauthorized external character reference "public: __cdecl selbaward::ProgressBar::ProgressBar(class sf::Vector2)"
error LNK2019: ссылка на неразрешенный внешний символ "public: void __cdecl selbaward::ProgressBar::setRatio(float)"
error LNK2019: ссылка на неразрешенный внешний символ "public: void __cdecl selbaward::ProgressBar::setShowBackgroundAndFrame(bool)"

I absolutely don't understand why erros appeared, please help me

Remove Old Version of Console Screen

The newest (current) version of Console Screen (version 2) succeeds its previous version (1 but named as "old" here) and therefore the old version is no longer required and should be removed.

This can be done at any time but should at least be done before updating the library to suit SFML 3.

Console Screen - incorrect buffer width when selection rectangle not within screen limits

When the selection rectangle extends beyond the limits of the screen, the buffer width can be incorrect.

Currently, it takes the buffer width directly from the width of the selection:
buffer.width = selectionRectangle.width;
but should only be the width of what it actually copies (within the screen limits)

The purpose of subdivision in Sprite3D

Would you explain please what is the purpose of the subdivision in your Sprite3D class?

(ElasticSprite) Texture cut off when perspective interpolation enabled

When an ElasticSprite has perspective mode enabled, the texture seems to be offset by some amount, cutting off the right and bottom sides of the image, and even pulling in pixels from beyond the left and top edges. The problem does not occur in bilinear mode.

Bilinear:

Perspective:

Furthermore, the degree to which the sprite gets cut off varies depending on the textureRect's position: the farther it is from the texture's top-left corner, the more severe. At offset {0, 0}, there's no cutoff at all. I've included some testing code, and three different images that demonstrate this. (Uncomment the appropriate init code to test each image.)

    static bool              init     = false;
    static sw::ElasticSprite sprite;
    static bool              bilinear = true;
    static sf::Texture       tex;

    if (!init) {
//        //  No padding
//        tex.loadFromFile("/home/hadrosoft/Desktop/test_image.png");
//        tex.setSmooth(true);
//        sprite.setTexture(tex, true);

//        //  Small padding
//        tex.loadFromFile("/home/hadrosoft/Desktop/test_image_padded_small.png");
//        tex.setSmooth(true);
//        sprite.setTexture(tex);
//        sprite.setTextureRect({220, 177, 508, 508});

        //  Big padding
        tex.loadFromFile("/home/hadrosoft/Desktop/test_image_padded_large.png");
        tex.setSmooth(true);
        sprite.setTexture(tex);
        sprite.setTextureRect({2664, 1956, 508, 508});


        sprite.setPosition({100, 100});
        sprite.setUseShader(true);
        if (bilinear) {
            sprite.activateBilinearInterpolation();
        }
        else {
            sprite.activatePerspectiveInterpolation();
        }
        init = true;
    }

    static sf::Vector2f vtx[4] = {{0, 0}, {0, 0}, {0, 0}, {0, 0}};
    static int          vi     = 0;
    static const float  inc    = 2.0f;

    /*  The following keyboard input stuff is just pseudocode for simplicity;
        sub in your favorite keyboard handler, or just modify the vertex offsets
        in vtx[] manually.
        This isn't even strictly necessary, since the bug shows no matter what
        the vertex offsets are.     */

    if (input.key_new_press(" ")) {
        ++vi;
        if (vi == 4) { vi = 0; }
        std::cout << "Now modifying vertex #" << vi << std::endl;
    }
    if (input.key_is_pressed("Up")) {
        vtx[vi].y -= inc;
    }
    else if (input.key_is_pressed("Down")) {
        vtx[vi].y += inc;
    }
    if (input.key_is_pressed("Left")) {
        vtx[vi].x -= inc;
    }
    else if (input.key_is_pressed("Right")) {
        vtx[vi].x += inc;
    }
    if (input.key_new_press("P")) {
        bilinear = !bilinear;
        if (bilinear) {
            sprite.activateBilinearInterpolation();
        }
        else {
            sprite.activatePerspectiveInterpolation();
        }
        std::cout << "Interpolation: " << ((bilinear) ? "Bilinear" : "Perspective") << std::endl;;
    }

    for (int x = 0; x < 4; ++x) {
        sprite.setVertexOffset(x, {vtx[x].x, vtx[x].y});
    }

    window.clear(sf::Color(192, 192, 192, 255));
    window.draw(sprite);

SFML version: 2.4.2
Testing environment: Ubuntu 18.04.2
GPU: GeForce GTX 950

Test images: (Right click -> Save As...)
test_image.png
test_image_padded_small.png
test_image_padded_large.png

Line - Global Bounds doesn't take into account transformations

Currently, Line's global bounds is identical to its local bounds.
The SFML transform should be applied to the points before forming the rectangle.

m_thickness not initialized in Spline class

m_thicnkess isn't initialized in the Spline class, which results in undefined behavior if one does not set it manually.

Spline should limit corner point length

Spline's point length on corners should be limited. This limit can be altered by the user.

The problem with implementation at the moment is that the point is calculated as the intersection of the two edges. If that point is brought closer in, the vertex is closer, which makes the Spline thinner at the corner (and to the both connected points - it tapers).

To fix this, point corners can be created using extra output vertices: 3 pairs instead of 1 pair - this is the edge of each line (as with a bevelled corner) as well as the point part. This allows the point to be brought closer while the lines are not thinned. Since this requires more vertices, it may be better to provide a separate corner type that can be safer and limit the point but requires extra vertices, leaving the original corner type using fewer vertices but can be less 'safe' around extreme angles.

Note also that the inside of the point corner can be so long that it can be visible. This should be fixed too eventually but can only be fixed by recognising which direction the corner is turning and so which edge is the "inside".

Console Screen - Colour commands don't work properly in printStretchedAt()

When using printStretchedAt(), if a colour command is "ignore", it overwrites it with its default colour, where it should be left unchanged.

Contrast and Invert colour commands are also affected and do not work as expected.