Messages

1

Window / Re: Class for multi-layer sprites rendering

« on: July 10, 2024, 09:27:35 pm »

You'll need to make sure that all of the pointers are valid. That is, both 'not null' and 'of type sf::Drawable*'.

Presuming your using my exact code, is it crashing on where I wrote "i expect this to work"?

Thinking about it, I think I used the wrong cast. It should not be "reinterpret_cast", it should instead be "dynamic_cast". I'll edit my post.

I've also realised that that loop doesn't need to be a reference. i.e. "const auto t" instead of "const auto& t" since it's just a pointer and a reference to a pointer seems to make little sense (unless in very specific scenario).

2

Window / Re: Class for multi-layer sprites rendering

« on: July 06, 2024, 10:40:17 pm »

sf::Drawable is a virtual "base" type. To be an 'actual' type, it requires to be derived/inherited. For example, any of the pre-defined shapes such as sf::RectangleShape, sf::CircleShape and sf::Sprite etc..

You can, however, hold pointers to that base type in an attempt to hold different children types.
Be careful though because it requires casting to and from the different types when needed. This means that something, somewhere, needs to know what type this is, if you need any of the children's features. You can, of course, use the base stuff such as draw easily.

Note that an std::vector is not an array (or std::array). Where arrays take [] to determine its size, a vector does not. It takes a parameter instead (so () or {}) but it can also be created empty and elements/items can added individually later.

If you are wanting an array of vectors (or a vector or arrays), it would be better to specify it like this:

std::array<std::vector<const sf::Drawable*>, 5u> layers{}; // an array of size 5, each with a vector of drawable pointers.

e.g.

std::vector<const sf::Drawable*> buffer(5u); // or std::array<sf::Drawable*> buffer[5u];

void WindowHandler::draw(const sf::Drawable& targ, int priority)
{
    buffer[priority] = dynamic_cast<const sf::Drawable*>(&targ);
}

void WindowHandler::render()
{
    win.clear();
    for(int i = 4; i >= 0; i--)
    {
        for(const auto& t : buffer[i])
        {
            if (t != nullptr)
                win.draw(*t); // i expect this to work...
        }
        buffer[i].clear();
    }
    win.display();
}
 

I haven't tested this exact code; a lot of it is copied directly from your post.

Another way to approach this, is to create a structure that holds priority and the drawable's pointer and then have a vector of those. Then, you can sort them easily using that priority.

e.g.

struct OneThing
{
    int priority
    sf::Drawable* drawable;
}
std::vector<OneThing> things{};
std::sort(things.begin(), things.end(), [](OneThing lhs, OneThing rhs){ return lhs.priority > rhs.priority; });
 

EDIT:
modified the cast from "reinterpret_cast" to "dynamic_cast".

3

General / Re: checking collisions with array of objects takes too much

« on: June 26, 2024, 11:08:11 pm »

I wouldn't actually say it's just redundant. Rather, it's likely incorrect.

For example, if "i" is 27, all of those ifs would be executed.

So, the if...else if...else if...else is likely the best choice here as Johnny mentioned.


As an added bonus, the expressions: (ButtonState == BTN_HOVER) and (ButtonState == BTN_ACTIVE) evaluate to booleans. Therefore, since you return true if the boolean is true, you can simply return the expression directly.
e.g.:

const bool Button::isPressed() const
{
   return (ButtonState == BTN_ACTIVE);
}

As for freezing, how and when are you executing those two loops?
I noticed that you are loading a font in with each creation of a Button so that's 32 fonts loaded with that first "i" loop. Loading fonts can be a slow process so it's my guess that it's that that's causing the slow-down.

The other "i" loop sets a font within the loop. It's possible that this may also cause a delay if the fonts are being rendered for the first time. This is not anywhere near as slow as loading though so fix that first

One thing you should note is that the Button should not know or care what the font is (so should not be loading it itself), especially since you give the ability to set it externally.
Instead, load the font outside of the Button class and pass a pointer to it only. This way it will loaded only once and each button can use the same one(s).

You should likely pass the font to the Button class during construction along with all its other parameters.

4

General / Re: Mouse motion trouble #2

« on: June 26, 2024, 10:52:44 pm »

Is this a continuation of this thread?:
https://en.sfml-dev.org/forums/index.php?topic=29559.msg181897#msg181897

5

General / Re: Efficient ways to create buttons

« on: June 24, 2024, 09:02:43 pm »

Another way is to use events only as you can then only do something when you would expect to.

For example, check events to see if a mouse button press happened and then check if the mouse was inside the button. Similar work for mouse button release if you want it to activate on release.

If you also want the ability to hover, then - again with events - check to see if mouse was moved and then check if the mouse is now inside the button. If so, it's now hovering; if not, it's now not.

6

General / Re: Setting bullets position to a weapon sprite that changes its rotation

« on: June 22, 2024, 03:08:00 pm »

To move globally in the direction of its local y axis as well as its x axis, you can add the sin/cos for each angle of the axis together.

Also, depending on how your doing collision, you might also consider moving the bullets origin "left" so that it would appear in the correct place automatically. e.g. to move the bullet 32 on its x axis (after rotation), subtract 32 from its origin's x.

7

Graphics / Re: Sprite not displaying after successful texture load

« on: June 18, 2024, 09:47:22 pm »

Sometimes, just loading it into an editor and re-saving it can fix these weird anomalies.

At least you can be clear exactly which format is being used and you can (re-)save other images using that exact format in the future.

8

Graphics / Re: Text is always blurry on low resolution games.

« on: June 16, 2024, 09:54:51 pm »

The first thing to make sure is that your text co-ordinates are rounded to the nearest pixel.

Assuming your view is 1:1 with pixels (e.g. 1024x576 view for 1024x576 pixel sized), your text position and origin should both be rounded to an integer.

Note that, also, scaling text can cause it to be blurry. For larger, non-blurry text, use a larger character size instead of scaling up. If you're animating, you should likely use the larger text and scale it down instead of using a smaller text and scaling it up.

So, assuming you're now using a scale of (1,1), your view matches the actual pixel size of its viewport, and your positions and origins are all rounded values, you should now how non-blurry text.

Remember that resizing a window will not resize the view automatically so you would need to update the view when it gets resized.



In addition, I think there is an update along these lines (ability to turn off texture smoothing for text) too but I'm not sure if that has been completed.

9

Graphics / Re: How expensive are sprites?

« on: June 04, 2024, 09:38:14 pm »

I'd just like to add that if you still want to use sprites and the interface that comes with it, you'll need to use some sort of "sprite batcher". This is in effect just a vertex array but compiles the sprites into a vertex array automatically.

For example, this sprite batcher on the Wiki:
https://github.com/SFML/SFML/wiki/Source%3A-Simple-Sprite-Batcher
allows you to pass the normal (and lightweight) sf::Sprites to it and it batches them into a vertex array automatically. Using this will almost definitely improve performance over just using sf::Sprites directly. From tests, it seems to be usually twice the speed.

Slightly better - and with better performance - would be a batcher that is designed to not build everything from scratch every frame so you can pass an sf::Sprite and it would change just that part.
The Sprite Batch that is a part of Selba Ward (although it can be used separately from the rest of the collection) can do just that along with allowing you to apply sf::Sprite properties directly to it so you don't even need separate sf::Sprites! You can still use separate sf::Sprites if you'd prefer, of course!

Note: a single vertex array requires the use of a single texture so these sprite batchers also have that requirement.

10

SFML development / Re: Font/Text Direction

« on: May 29, 2024, 11:11:17 pm »

I think you may be right; more should be provided for a thorough access to proper vertical advancement.

Exposing just the vertical advance value may give enough information to lay out the text correctly in relation to itself but may be technically incorrect when needing the rest of the information. That is, for example, the vertical baseline (usually the centre).

Note that the change is really in sf::Glyph but would need modifications in its use. Definitely in sf::Text and also a little bit in sf::Font.

Its likely that the terminology wouldn't need to be changed to be 'correct' as I think it'll be understood. For example, "line spacing" still makes sense to be horizontal if it's vertical text.

I'm not sure I fully understand lsbDelta and rsbDelta but since it seems to be used by kerning, and kerning is also needed for vertical text, these could either be renamed as something else (presuming lsb is left-side-boundary or similar, it could be least-side-boundary and most-side-boundary, for example) or the vertical ones could be included in addition (tsbDelta and bsbDelta - top and bottom).

11

General / Re: I have a problem with background

« on: May 25, 2024, 10:25:29 pm »

To move the 'view' up, you can simply move the background down. So, draw the background lower.

You could also use an sf::View to do this; it simplifies things. You move the view 'up' and everything gets drawn lower automatically.

Note that when you 'look up', you don't just move the background down; you will also need to draw more of the background above what you could see before.

12

SFML development / Re: Font/Text Direction

« on: May 25, 2024, 10:21:50 pm »

Indeed, FRex; that was basically the point I was making - that the small change to expose that value would allow custom text classes to make use of it instead of having to skip sf::Font altogether.

The follow-up suggestion of expanded sf::Text's ability would likely be included in sf::Text's overhaul to accommodate the eventual integration of HarfBuzz, if it's what it seems to be to me.

HarfBuzz, by the way, looks like an great thing to be including in SFML if it's possible. Everything being ASCII/English is often due to the simplicity of its use. Making it simple to use any Unicode - ASCII or not - makes it the same to use or not so might as well, right?

13

Graphics / Re: How to correctly draw a triangle fan?

« on: May 18, 2024, 11:18:29 pm »

If the triangle solution works, you must check your formation of the triangle strip to see if it's correct, including infinitely thin or 'backwards' triangles (breaking the triangle strip shape).
It might be worth making the calculations using doubles - for more accuracy - and then only converting to floats when creating the graphics (triangle strip).

14

Graphics / Re: How to correctly draw a triangle fan?

« on: May 17, 2024, 10:46:51 pm »

It seems that there is an issue when those triangles are thin - possibly infinitely thin or even inverted due to rounding errors.
Triangle fans are not supposed to have overlapping triangles so it could have an issue with this when those triangles are 'thin'.

You could try replacing it with a triangle strip; this should be able to do similar but would require specifying the centre point multiple times. Plus, the strip might also suffer from the same issues, depending on Open GL feels about that.

The safest bet, I would say, is to use separate triangles. The formation of the triangles does not matter so if they overlap or 'go backwards', it's fine since each triangle doesn't affect any other triangle.

Of course, you would need almost 3 times as many vertices (it would be 3 times the vertices you have now minus 2) since you would just simply specify each triangle's vertices separately, repeating quite a few.

15

Graphics / Re: [SOLVED] MacOS Build and Windows Build has a Difference when Drawing Rectangle

« on: May 17, 2024, 10:30:26 pm »

In addition - and something I was going to mention in my previous post but forgot - you should consider DPI awareness.

This can throw all sorts of things out if one version is DPI aware (even if automatic) and the other is not.

It's a very complicated issue, by the way, but I think Mac and Windows treat it differently by default. Possibly the way SFML treats it is different in those operating systems too but I'm not sure.