Messages

1

Graphics / Re: SDL_RenderCopyEx equivalent

« on: May 05, 2025, 10:45:24 pm »

Everything kojack said would be the first things I would check. Did that fix it for you?

It looks suspiciously like you're using SFML 2.. 

I noticed that you're using integers for positions so could those positions be pixel positions instead of co-ordinates? If so, make sure your view is correct and convert between the types if necessary.

Also, consider if you are drawing in the range of the window.

sf::Sprite::rotate takes a float (in SFML 2) so you could just pass it as a float.

All in all, remember that for each frame, you must:

window.clear();
window.draw(someObject);
window.display();

If you're using a render texture, you'd need to:

//RENDER TEXTURE: clear, draw, display
renderTexture.clear();
renderTexture.draw(someObject);
renderTexture.display();

// use a "render" sprite to draw the render texture
renderSprite.setTexture(renderTexture.getTexture());

// WINDOW: clear, draw, display
window.clear();
window.draw(renderSprite);
window.display();

2

SFML wiki / Re: Tutorial - Understanding Text Bounds

« on: May 05, 2025, 10:31:16 pm »

Thank you!

It comes up so often and is something I'd been meaning to do for a while. I thought someone else might have already done it by now.

With the "blockquote" sections, are you suggesting that, for you, they are less noticeable? I agree with this and is the intention. I consider them "notes" and the entire tutorial should be able to be read without them; they are there for extra information. Maybe, "tip" might be appropriate if going along the alert route.

I actually intentionally avoided going into the baseline definition too much since it brings with it questions, namely "how do I find the baseline of my text?" and SFML doesn't actually give the ability to answer this question. The baseline in the example(s) is the bottom of bounds when the string is just "x", for example.
Sphinx is a good one indeed. Capitals, high lower-case letters, tittles, descenders etc..

I thought I had explained why there is an offset but it seems that I had not. Or, at least, not until you slowly get through the examples. So, I have added an extra note to explain the overall idea behind it (immediately after the sentence you mentioned).

3

Graphics / Re: Text and shaders

« on: April 30, 2025, 07:04:09 pm »

I realised that gradients in texts are so common that I really should have a shader prepared for that sort of thing already but alas, I did not.

That was then (up to yesterday) and this is now!

I present to you my new shader: multiGradient!

I've added it to be a part of my Lens collection. All shaders are in the "Lens" folder of that directory.
For information on how to use it, you can read the short wiki entry:
https://github.com/Hapaxia/Lens/wiki#multigradient

It allows to provide multiple heights (y positions) and multiple colours to the shader. The shader then interpolates those colours based on the current y position, creating a gradient.
This can be used on textured or non-textured objects and there can be up to 16 different heights and colours!

Here are a couple of quick test examples...

3 steps (3 different colours - yellow, magenta, cyan):


10 steps (10 different colours, yellow, magenta, cyan, white, blue, yellow, magenta, cyan, red, black):

4

Graphics / Re: sf::View responsive zooming (solved)

« on: April 29, 2025, 07:37:35 pm »

Hi and welcome

It's good that you managed to already fix this issue by yourself but it should be noted that there is already code available to do this for you (or to show you how to do it).
It's on the SFML wiki and, although it's currently targetted at SFML 2, it should be easily adjusted for SFML 3.

The effect that you are describing is often called the Letterbox effect and here is the code that automatically does that for you:
https://github.com/SFML/SFML/wiki/Source%3A-Letterbox-effect-using-a-view

5

Graphics / Re: Text and shaders

« on: April 29, 2025, 07:26:33 pm »

Presumably, the vertical gradient is to what you refer?

This effect can be done in SFML simply with two very different methods.

The first would be to use a bitmap text instead of a scalable text (like TTF, for example).
One example of this is Selba Ward's Bitmap Text:


The second would be to use a fragment shader. Fragment shaders adjust the pixel dependant on a multitude of things but included is the pixel position so you can, for example, just adjust the colour based on the y position of the fragment (pixel). Note, though, that OpenGL fragment shaders use non-inverted y axis; that is, the opposite to SFML - the y value increase as it goes up instead of down.
These can seem to be a bit complicated at first but once you get used to them, they are very powerful and flexible, and - I expect - would be the ideal approach for your situation.


EDIT:
In addition, there is another rather simple solution but adds additional overhead (cost of the simplicity):
Render the text to a render texture and the draw that render texture with a quad (vertex array). This vertex array can have different colours per vertex so each corner can have a different colour. This allows both the top corners to be the same and both the bottom ones to be the same. However, the top and bottom can be different, causing linear interpolation - vertically - causing a gradient. If you want to try this method, remember to render the text as while (on a transparent render texture) and note that you can only pick two colours (the top and bottom) so you cannot have it go from one colour to another and back again without splitting the quad into pieces (although that is relatively simple to do too!).

6

SFML wiki / Tutorial - Understanding Text Bounds

« on: April 23, 2025, 09:31:55 pm »

Hello all.

I have written a small tutorial to explain how text bounds work for the wiki:
https://github.com/SFML/SFML/wiki/Tutorial%3A-Understanding-Text-Bounds

Hopefully, this can help to reduce the common confusion to how they work.

Feel free to refer to it when people ask about this topic!

7

General discussions / Re: Rendering to outside of a window possible?

« on: April 16, 2025, 10:49:21 am »

If you have a lot of things drawn - or are otherwise having performance issues - you may need to consider optimising what is drawn by "culling" things that are not in the range of the window as this is not done automatically. You can do this simply by using the method you described. More complicated methods exist including using "chunks" that can in turn reduce the number of intersecting tests but, again, this is much more complicated.

As an answer to the question, yes, things outside of the window will still be processed by the rendering process. Note, though, that this is basically all of the shaders up to the fragment shader; this shader only applies to actual pixels that are visible. So, the fragment shader will not be run on the things outside of the window but the vertex shader - for example - will still be run on every vertex (that you draw).

8

SFML projects / Re: Screenshot Thread

« on: March 12, 2025, 06:23:07 pm »

I recently decided to push myself to see how much I could get out of my own knowledge of raw OpenGL (it's not much!) within SFML. Along the way, I factored it into a library and ended up arranging it so its use is very similar to SFML's graphics module.
Note that this is all done with SFML and only the OpenGL that is included by SFML's headers. No other external library (even any OpenGL) was included.





Here's a screen recording of the full test scene!


Note that this "library" is just a personal test. It isn't being developed for public use; at least, not yet...
It also acts as a kind of "proof of concept" of what SFML 3D might have looked like.

9

Graphics / Re: Window to fill all screen and Texture transparent color

« on: March 12, 2025, 04:05:32 pm »

The size parameters for getLetterboxView are the actual width and height of the window. If your window is full-screen, these parameters should be the current resolution. Otherwise it should be the size of window in pixels.

sf::Vector2u windowSize{ window.getSize() }; // get the current size of the window
getLetterboxView(target, windowSize.x, windowSize.y) // use the window size here; the function sorts out the rest.

My guess as to how it would look in your code would be something like:

Vector2u windowSize = new Vector2u(Images.window.getSize()); // get the current size of the window
View target = new View(new Vector2f(200, 150), new Vector2f(400, 300));
Images.window.SetView(getLetterboxView(target, windowSize.x, windowSize.y); // use the window size here; the function sorts out the rest.

10

Graphics / Re: Window to fill all screen and Texture transparent color

« on: March 10, 2025, 09:57:51 pm »

We should clarify something here.

A window that is 400x300 will not fill the screen unless the screen's resolution is 400x300.
So, to fill the screen, we can change its resolution and go fullscreen with the window,
or we can make the size of the window the same size as the current resolution (this is commonly called "Windowed Fullscreen".)

The other thing to consider is that I expect you want to work with co-ordinates that go from (0, 0) to (399, 299) and to set that, you use a view.

So, first create a "target view" (the one you want to use within the window) like this:

sf::View targetView{};
targetView.setSize({ 400.f, 300.f });
targetView.setCenter({ 200.f, 150.f });

NOTE: I've set the size and center separately so it's clear what is happening but you can also set it in its constructor.

Then, set the window to use this target view:

window.setView(targetView);

Then, you can change the size of the window to match the full screen (or allow it to be resized).
The window will change size but the view will always be 400x300 so drawing at (200, 150) will always be in the centre.

You can just leave it there if you don't don't want the letterboxing effect and the window will always use the co-ordinates (0, 0) - (400, 300)-ish

But, since you do also want the letterboxing effect, you can use that function like this (whenever the window changes size, including when you set it or when it is resized):

window.setView(getLetterboxView(view, windowSize.x, windowSize.y));

windowSize is the actual current size of the window, and
view is the view we created earlier (it doesn't change)

This is obviously C++ code that I've used for the examples so you'll need to adapt to the version/language you're using.

11

Graphics / Re: I tried to build a particle system with VertexArray

« on: March 10, 2025, 06:39:04 pm »

The best option is pretty much always to draw them all together as a single vertex array. However, it's (a little bit) more complicated than just drawing lots of sprites.

Another option is to use some form of sprite batching. You can use a pre-made one or make your own.
I have two types already created:

https://github.com/SFML/SFML/wiki/Source%3A-Simple-Sprite-Batcher
takes a vector of pointers to already-created sprites and batches them into a single vertex array. This can be done every frame if required and should see an increase of speed to around 200% (or more!).
Here's a video example (warning: fast movement - flickering effects - may be unsuitable to watch):


https://github.com/Hapaxia/SelbaWard/wiki/Sprite-Batch
is a different approach. It itself contains the sprites and you update them via its interface (or copy a sf::Sprite). This way it can make internal optimisations so should result in better/faster results. This is a part of Selba Ward so feel free to have a look around for other things there you'd like to use too

12

Window / Re: Integrating SFML with wxWidgets

« on: March 10, 2025, 06:23:28 pm »

Is this placing SFML inside wxWidgets? If so, is this issue only in Debug builds? How is it in Release builds?

13

Graphics / Re: Graphical glitch appearing

« on: March 03, 2025, 11:53:08 pm »

If you want to avoid the copying (mentioned above by eXpl0it3r), you could skip the "first sprite" temp and construct it directly in the vector since you already have a constructor ready:

sprites.emplace_back(default_texture);

14

SFML projects / Re: BubbleByte 🫧🐱 incremental/clicker game about cats & bubbles!

« on: March 01, 2025, 05:32:34 pm »

I think my point about stress is it seems to be a "if you're slow, you progress slowly" as opposed to a "if you're slow, you'll fail until you're quick enough" type, which is more stressful so this would less so

Your bubbles look quite nice. I had presumed they were just static sprites; I had not realised that they were adjustable on the fly with your shaders. Nice work!

For me, though, overall, there seems to be too many "particles" (it seems "fussy"). But that's just me; I don't really play bullet hell games for this reason.

15

SFML website / Re: Sticky menu hides linked content in the documentation

« on: March 01, 2025, 05:28:26 pm »

Just since this was brought up, I should mention that there are a couple of errors here and there in the documentation, whether it be not updated to 3 or may have been updated to 3 before it changed? I'll try to make a note of them when I spot them again.

Also, could we *please* have a dark theme for the documentation?