Messages

1

Graphics / Re: MacOS Build and Windows Build has a Difference when Drawing Rectangle on Screen

« on: May 13, 2024, 11:14:23 pm »

The first thing to consider are views. Which view are you using when drawing each item? Are you changing it between draw calls? If all your draw calls are together, this should be simple to check.

Then, consider where you are getting values such as "width" and "height". They likely should be the view's width and height, not the window's.

Also, consider that you must always know whether you are using view co-ordinates or pixel positions. e.g. getting the mouse position will be in pixel positions so does not necessarily match the location of objects until converted to co-ordinates. Note that if you are converting to co-ordinates, it must know which view's co-ordinates you wish to convert to. If you don't provide a view to "mapPixelToCoords", it will use the currently active view and, if you use multiple views, this may not be the one you actually draw it with.

2

Window / Re: How to 'suspend' fullscreen mode?

« on: May 13, 2024, 11:07:41 pm »

Have you tried using the Lost Focus event?
https://www.sfml-dev.org/documentation/2.6.1/classsf_1_1Event.php#af41fa9ed45c02449030699f671331d4aabd7877b5011a337268357c973e8347bd

I would expect alt-tabbing to a different window would cause the original window to lose focus so this event should be received. You could reform the window as a normal window without fullscreen or hide it. You could also create a new window (or reuse the main one if you'd like) to allow access back or even should a smaller version of the main fullscreen window!

The opposite event, Gained Focus, could also be used when alt-tabbing back (or just clicking on the window) where you could then un-hide the full window (or reform it again if needed).

3

Graphics / Re: Align the text perfectly centered inside any shape

« on: May 13, 2024, 10:52:52 pm »

    text.setOrigin(text.getGlobalBounds().getSize() / 2.f + text.getLocalBounds().getPosition());
 

I think these should both be local bounds. i.e.:

text.setOrigin(text.getLocalBounds().getSize() / 2.f + text.getLocalBounds().getPosition());

4

Feature requests / Re: export vertexes from the Shape class

« on: May 13, 2024, 10:40:20 pm »

It's likely a good idea to contain the vertex array within another class. The class would be the "drawable object" and the vertex array would be its "visible representation."

This is how SFML shapes (and many other drawables) do it; the SFML shapes store a vertex array within its class. They also inherit from both sf::Drawable (so it can have the draw method) and sf::Transformable - as FRex mentioned - (so the entire shape can be transformed (moved/rotated/scaled)) at once without having to make those calculations. In fact, the transformation calculations are done on the graphics card when doing it this way so it's worth learning about this method.

The usual form of a drawable would be something like:

class DrawableName : public sf::Drawable, public sf::Transformable
{
public:
    DrawableName();

private:
    sf::VertexArray m_vertices;
    void draw(sf::RenderTarget& target, sf::RenderStates states) const;
}

// this is the constructor
DrawableName::DrawableName()
    : m_vertices(6u)
{
}
// this is the draw method that can be called later like this: window.draw(drawableName);
void DrawableName::draw(sf::RenderTarget& target, sf::RenderStates states) const
{
    states.transform = getTransform();
    target.draw(m_vertices, states);
}

You can, of course, add other methods as you like to control things like size and colours or any other vertex manipulation.
Note that since the class inherits from sf::Transformable, you can also use the setPosition(), setScale(), setRotation(), move(), scale(), rotate() methods to manipulate the entire shape. Of course, getPosition, getScale and getRotation is also provided.

Slightly more advanced:
instead of using a vertex array, you can instead use an std::vector of sf::Vertex i.e.:

std::vector<sf::Vertex> m_vertices

To draw it then, you would need something like:

target.draw(m_vertices.data(), m_vertices.size(), sf::PrimitiveType::Triangles, states);

Note here that you must specify the primitive type but you can choose to store it separately as a member of the class, somewhere in the cpp file, or express it directly as in this example.



Note that if you use SFML 3, the draw method needs the sf::RenderStates to be passed as a reference, not as a copy.

5

Graphics / Re: How do I disable font smoothing?

« on: May 02, 2024, 11:09:21 pm »

If you downloaded SFML from the Download page of SFML's website, you are downloading pre-built binaries. That is, all the CPP files have been compiled already so the source CPP files are no longer necessary.

If you want to modify the code, you'll need to build that code yourself after your modification.
The source code for version 2.6 (the "latest stable version") is here:
https://github.com/SFML/SFML/tree/2.6.x
(note that it contains Font.cpp)

If, however, you'd like to try using the most recent version that is currently in development (version 3), you can get the code here:
https://github.com/SFML/SFML/tree/master

If you use GitHub, you can also fork the repository and modify it in your own version.

sf::Font's setSmooth should be available in both v3 and also v2.6.1. Are you using an older version as it appears it might not have been available in v2.6.0. (see here)

6

Graphics / Re: [SOLVED] SFML DIY RectangleShape Collision detection only partially working

« on: May 02, 2024, 10:40:37 pm »

To check if two (non-rotated) rectangles are intersecting, you can use Rect's intersects function (SFML 2 only; for SFML 3, you'll need the findIntersection function).

For example:

const sf::Vector2f rect1TopLeft{ 100.f, 100.f };
const sf::Vector2f rect1Size{ 200, 200.f };
const sf::Vector2f rect2TopLeft{ 200.f, 200.f };
const sf::Vector2f rect2Size{ 200, 200.f };
const sf::FloatRect rect1{ rect1TopLeft, rect1Size };
const sf::FloatRect rect2{ rect2TopLeft, rect2Size };
bool isRect1CollidingWithRect2{ rect1.intersects(rect2) };

It's a pretty simple function and you can do something similar yourself by comparing the edges: the right side of the leftmost rectangle must be past (more to the right than) the left side of the rightmost rectangle and/or the bottom side of the topmost rectangle must be past (lower than) the top side of the bottommost rectangle.

If you'd like to use rotated rectangles, there is a short simple function that can do that for you too:
https://github.com/SFML/SFML/wiki/Source%3A-Rectangular-Boundary-Collision
Obviously, it works on non-rotated rectangles too!

7

Graphics / Re: Clarification from the sprite tutorial

« on: April 18, 2024, 09:35:46 am »

Once you've 'sorted' the textures to avoid switching and all is left to do is group (batch) together the objects to avoid multiple draw calls, you can use this simple batcher (that I created):
https://github.com/SFML/SFML/wiki/Source%3A-Simple-Sprite-Batcher

It's simple to use (sprites only) and should always reduce time used to draw. The more sprites to batch, the more effective the batcher is!
Remember, though, that you can only batch sprites that use the same textures.

8

Graphics / Re: Clarification from the sprite tutorial

« on: April 17, 2024, 07:59:23 pm »

I don't know the technically exact cost but larger textures should not incur a significantly larger cost to switch to or from - if any at all - than a smaller texture.
It's the switching that's costly but why it's costly and how costly it may be may or may not be partly related to its size.

The 'solution' to your question is a third option, re-order so that all the draws with the big texture are drawn next to each other (or even as one) and the small texture together the same way.
If they 'must' be drawn in this way, consider adding the small texture to the big texture.
With the 'alternating small textures', you could always combine them both into one, reducing the switching of textures and potentially reducing all of those alternating draw calls to just one.

Just remember, if you're trying to be efficient with your textures, use one at a time (avoiding switching) and draw multiple objects using that texture at once (avoiding excessing draw calls).

So, to provide a possible solution to your original post:
place the textures for both sprites into one image (you can do this programmatically if you'd like), and then load it to a texture. Then, draw each sprite with that same texture but use the texture rectangle (textureRect) to specify which part.

9

General / Re: Why anything after "while (window.pollEvent(Event))" kills framerate ?

« on: April 09, 2024, 07:14:12 pm »

Is it possible that you tested the rate of slightly different code? For example, without the "game logic" section.

The reason I ask is that if you don't have those braces (curly brackets) after the poll event loop, the very next line of code would be only executed whenever there is an event and, if the "game logic section" is not there, the next line would be the heavy-duty pixel-manipulating for loop.
This would mean that those pixel updates only got updated whenever there was an event but not when there weren't any so it would run faster without that for loop.

Adding the braces/brackets after the poll event would then make the pixel-updating for loop run on every single main loop and could be the cause of such a significant delay.

10

Graphics / Re: Clarification from the sprite tutorial

« on: April 02, 2024, 12:00:17 am »

That's right.

When you a draw something that uses a different texture to the previous thing drawn, the texture has to be swapped on the card and can be expensive.

Setting the texture of a sprite actually only stores a pointer so it's extremely lightweight; it's the draw that can be expensive.

11

Graphics / Re: Draw pixels in real-time

« on: April 01, 2024, 11:51:35 pm »

You are very welcome. Glad what I said helped.

Yes, indeed. Textures (from a render texture or not) are on (and stay on) the graphics card. "Getting" a texture really just gives you access to the object that controls it (sf::Texture). sf::Textures that you create yourself can be modified by updating it (copies image from RAM to graphics card) but the sf::Texture you get from a render texture is const and cannot be modified so everything stays on the graphics card.

All (pixel) render targets work the same way so it's the same drawing to a window as drawing to a render texture. That is, yes, co-ordinates would likely require offsetting by (0.5, 0.5). Note that just as windows, you can change a render texture's view so draw co-ordinates might not match the pixels exactly. If you need perfect matching, you should make sure the view is as required. In fact, you could move the (default) view by -(0.5, 0.5) and then draw to integer values!

Modern versions of OpenGL are generally compatible with older versions, yes. The version you choose to use with SFML (or in your shaders) will determine their compatibility.

12

Graphics / Re: Understanding the getPoint() index for sf::RectangleShape getPoint()

« on: March 27, 2024, 03:22:49 pm »

As an example of collision, you could take a look at:
https://github.com/SFML/SFML/wiki/Source%3A-Rectangular-Boundary-Collision

If you feel that it doesn't already do for you the collision that you need, it at least shows an example of how to get the points of a rectangle (using local points and its transform) as well as using an inverse transform to convert into local co-ordinates of a different shape.

13

Feature requests / Re: export vertexes from the Shape class

« on: March 27, 2024, 03:15:22 pm »

You can get each of the vertices by simply getting the shape's points:

for (std::size_t i{ 0u }; i < shape.getPointCount() ; ++i)
    std::cout << "Point " << i << ": (" << shape.getPoint(i).x << ", " << shape.getPoint(i).y << ")" << std::endl;

However, this is likely not how you would build the shape to draw (other than using its original primitive type).
Much more likely is you'd like to be able to build that shape with separated triangles (as any shape can be built this way) as you can then batch them together using that same primitive.
So, you could extract the triangles from the original shapes and then draw them as triangles. Since everything is just triangles, you can also batch them together if required.
To extract the triangles from a shape, you could use this:
https://github.com/SFML/SFML/wiki/Source%3A-Triangles-Extractor

Note that best results are observed if shapes don't change often and/or there are very many (to reduce those significant draw calls) and they are causing an speed issue.

14

Graphics / Re: Draw pixels in real-time

« on: March 17, 2024, 06:14:51 pm »

An sf::Image is basically just an array of pixels in standard RAM.
Updating (or loading) the texture from an image copies this memory (either fully or in part) to the graphics card memory (the 'image' of a texture is stored on graphics card memory). This is then used by the graphics card to when drawing the sprite (in this case). Updating the texture from the image is the heaviest part of this operation but - depending on how much you may be processing pixels - CPU image processing may also be heavy.

An sf::RenderTexture is similar to an sf::Texture in that it already resides in graphics card memory and can be used by the graphics card for both drawing to (when changing it) and drawing from (when drawing the sprite in this case).
So, in theory, this is lightest process since you don't need to transfer anything (much) from CPU to GPU to be able to draw the render texture. However, anything you do change does need to be sent to the graphics card so if that is every pixel every time, this could be even heavier as each vertex also has extra information (i.e. a position and a texture co-ordinate) that wouldn't change.
If you are only changing (modifying pixel colours) 'some' pixels or are 'moving' (changing their positions rather than them having static pixel positions) them, this could be more efficient.
Also, this method also allows you to let the graphics card do some processing. e.g. you can use vertex or geometry shaders to modify the 'pixels' (vertices) by just giving parameters.

Note that you do something similar using fragment shaders and an image/texture.



In conclusion:

If you are modifying every pixel every time (whether it needs modifying or not), using an sf::Image is likely the simplest and possibly fastest method. Use this for video input, for example.

If you are only modifying a few pixels and/or not modifying them often, a vertex array with a render texture could be more efficient.

Note that an sf::VertexBuffer can also add additional features for this but may not be more efficient if transferring a lot of information.

15

Graphics / Re: Optimization of hexagon-grid

« on: March 12, 2024, 09:41:18 pm »

You should note that setting frame rate limit only caps the highest possible rate so it won't go above that rate. It can't force a slow rate to be quicker, for example.
If you are also using v-sync, it could be limiting to your display's refresh rate. It's generally recommended to only use v-sync or a frame rate limit, not both.