Messages

1

Graphics / Re: Loading SFML Textures in Opengl

« on: December 16, 2024, 05:45:20 pm »

I see.
And where you able to bind the texture as I mentioned?

2

Graphics / Re: Loading SFML Textures in Opengl

« on: December 10, 2024, 09:01:40 pm »

It looks like that original "modern" example you gave uses sf::Image to load the image data in but then uploads it to the graphics card using GL commands (sf::Image is basically just an array of pixels). Without the shaders that that code uses, it won't be able to show those textures.

SFML 3 is currently on its second Release Candidate so it's borderline being released.

I think I may have misunderstood your original question. Are you trying to use raw OpenGL calls and pass an SFML texture to use in it? If so, would it not be simpler to also use raw OpenGL calls to set up the texture?

With that said, the official example (the one that you said requires GLAD) shows how to use an sf::Texture within OpenGL.
The one I linked was the example for SFML 3. Does this work?
https://github.com/SFML/SFML/blob/2.6.x/examples/opengl/OpenGL.cpp

Anyway, in that example, this part binds the texture:
https://github.com/SFML/SFML/blob/2.6.x/examples/opengl/OpenGL.cpp#L115-L117

For some more information, you can see sf::Texture's documentation about "bind":
https://www.sfml-dev.org/documentation/2.6.2/classsf_1_1Texture.php#ae9a4274e7b95ebf7244d09c7445833b0

3

Graphics / Re: Loading SFML Textures in Opengl

« on: December 09, 2024, 07:03:07 pm »

Do you have those shader files (that that code attempts to load) as well and are they in the correct location?

Are you using SFML 2 or SFML 3?

Does this work:
https://github.com/SFML/SFML/blob/master/examples/opengl/OpenGL.cpp

4

Graphics / Re: Unabled to load file problem - loadFromFile.

« on: December 04, 2024, 02:48:17 pm »

Have you tried absolute paths to make sure the image is able to be loaded?
Presumably it's not loading because it can't find it but it might not be able to read it.

If it can't find it, it would likely be due to local paths and where your IDE is looking for them. How to change this depends on the IDE.

5

SFML projects / Re: Dispersio 3

« on: December 03, 2024, 11:04:11 pm »

Hi again and it's great to see you back at it!

I'll be interested to see your progress throughout.

6

SFML projects / Re: Shape Wars - A 2d Shooter

« on: November 27, 2024, 04:56:36 pm »

Looks good. Congrats

7

Graphics / Re: Colour individual triangles in a sf::TriangleStrip

« on: November 27, 2024, 04:41:17 pm »

You can do this with a triangle strip but it requires duplicate vertices and, if you're doing this often, it may be better to just use separate triangles.

e.g.
I'll assume you have 8 vertices in the example and they are bottom0, top0, bottom1, top1, bottom2, top2, bottom3, top3.

You can use (12 vertices) bottom0, top0, bottom1, top1, top1, bottom1, top2, bottom2, bottom2, top3, bottom3.

This allows change of colour over the doubled vertices.
Note that this works because the doubled vertex as well as the previous (or next) vertex create an infinitely thin triangle so those two triangles (where the colour transitions happen) are invisible.

A possibly simpler version
If you need each triangle pair to be the same direction then you can just duplicate the 2 vertices that represent the edge.
This works because, again, you're "drawing invisible lines".

That would be (12 vertices) bottom0, top0, bottom1, top1, bottom1, top1, bottom2, top2, bottom2, top2, bottom3, top3.
This could be more simple as you're still following the same bottom-to-top and left-to-right formula and you it looks a bit clearer in the code as you're effectively separating the vertices into groups of 4 (per quad).

Here's an image of all three of those examples with your original being the top one (number 1):

(click to show/hide)

sf::VertexArray triangleStrip1{};
triangleStrip1.setPrimitiveType(sf::PrimitiveType::TriangleStrip);
triangleStrip1.resize(8u);

triangleStrip1[0u].position = { width * 0.f, bottom };
triangleStrip1[0u].color = colorA;

triangleStrip1[1u].position = { width * 0.f, top };
triangleStrip1[1u].color = colorA;

triangleStrip1[2u].position = { width * 1.f, bottom };
triangleStrip1[2u].color = colorA;

triangleStrip1[3u].position = { width * 1.f, top };
triangleStrip1[3u].color = colorA;

triangleStrip1[4u].position = { width * 2.f, bottom };
triangleStrip1[4u].color = colorB;

triangleStrip1[5u].position = { width * 2.f, top };
triangleStrip1[5u].color = colorB;

triangleStrip1[6u].position = { width * 3.f, bottom };
triangleStrip1[6u].color = colorA;

triangleStrip1[7u].position = { width * 3.f, top };
triangleStrip1[7u].color = colorA;



sf::VertexArray triangleStrip2{};
triangleStrip2.setPrimitiveType(sf::PrimitiveType::TriangleStrip);
triangleStrip2.resize(12u);

triangleStrip2[0u].position = { width * 0.f, bottom };
triangleStrip2[0u].color = colorA;

triangleStrip2[1u].position = { width * 0.f, top };
triangleStrip2[1u].color = colorA;

triangleStrip2[2u].position = { width * 1.f, bottom };
triangleStrip2[2u].color = colorA;

triangleStrip2[3u].position = { width * 1.f, top };
triangleStrip2[3u].color = colorA;

triangleStrip2[4u].position = { width * 1.f, top };
triangleStrip2[4u].color = colorB;

triangleStrip2[5u].position = { width * 1.f, bottom };
triangleStrip2[5u].color = colorB;

triangleStrip2[6u].position = { width * 2.f, top };
triangleStrip2[6u].color = colorB;

triangleStrip2[7u].position = { width * 2.f, bottom };
triangleStrip2[7u].color = colorB;

triangleStrip2[8u].position = { width * 2.f, bottom };
triangleStrip2[8u].color = colorA;

triangleStrip2[9u].position = { width * 2.f, top };
triangleStrip2[9u].color = colorA;

triangleStrip2[10u].position = { width * 3.f, bottom };
triangleStrip2[10u].color = colorA;

triangleStrip2[11u].position = { width * 3.f, top };
triangleStrip2[11u].color = colorA;



sf::VertexArray triangleStrip3{};
triangleStrip3.setPrimitiveType(sf::PrimitiveType::TriangleStrip);
triangleStrip3.resize(12u);

triangleStrip3[0u].position = { width * 0.f, bottom };
triangleStrip3[0u].color = colorA;

triangleStrip3[1u].position = { width * 0.f, top };
triangleStrip3[1u].color = colorA;

triangleStrip3[2u].position = { width * 1.f, bottom };
triangleStrip3[2u].color = colorA;

triangleStrip3[3u].position = { width * 1.f, top };
triangleStrip3[3u].color = colorA;

triangleStrip3[4u].position = { width * 1.f, bottom };
triangleStrip3[4u].color = colorB;

triangleStrip3[5u].position = { width * 1.f, top };
triangleStrip3[5u].color = colorB;

triangleStrip3[6u].position = { width * 2.f, bottom };
triangleStrip3[6u].color = colorB;

triangleStrip3[7u].position = { width * 2.f, top };
triangleStrip3[7u].color = colorB;

triangleStrip3[8u].position = { width * 2.f, bottom };
triangleStrip3[8u].color = colorA;

triangleStrip3[9u].position = { width * 2.f, top };
triangleStrip3[9u].color = colorA;

triangleStrip3[10u].position = { width * 3.f, bottom };
triangleStrip3[10u].color = colorA;

triangleStrip3[11u].position = { width * 3.f, top };
triangleStrip3[11u].color = colorA;

Note that I set each vertex explicitly so it you could see that. However, it is pretty simple to write an algorithm to set them all automatically in a loop.

8

Window / Re: Too many resize events for switch to fullscreen and weird resolution reported

« on: October 19, 2024, 06:03:12 pm »

Does this have the same effect if you use

getFullscreenModes()[0u]

instead of

getDesktopMode()

?

9

Graphics / Re: RenderTexture blurry when scaled up

« on: October 19, 2024, 05:49:59 pm »

The render texture is blurry because it is smaller than the final image and then scaled up (as you pointed out in the title). As always, if a smaller image is scaled up, there is less detail and can appear blurry.
Remember that drawing to a larger window directly is effectively drawing to a large surface/texture so it can be expected that it would allow more detail.

The simplest way to combat this is to just make the render texture larger. Scaling down is usually less blurry.
You can start as large as you expect it to be or you can recreate the render texture after resizing the window. It can be relatively slow to recreate a render texture; just keep that in mind.

If the render texture would be far too large, you could consider one of exactly half size (in each dimension) and then scaling up. Removing smoothing would keep this nice and sharp.

10

General discussions / Re: Views and sprite world positions

« on: October 19, 2024, 05:41:20 pm »

Absolutely. It "just sits there" and then the view moves over it and it becomes visible. That's the idea behind the process indeed.

Anything you draw after "setting" the view will be drawn with that view. However, if the view is changed (set to a different view) or even if the current view is modified and then updated (which is the same as setting it to a modified version of that view), everything needs to be drawn under the new view.

With that said, the question really is: do you use more than one view and are you setting it to a different one before drawing the sprite?

It's also worth noting that if you have any calculations based on positions (and the like) of objects where you use things like "getPosition()", you should remember that it takes into account the view that is currently set "at the time of making those calculations."

11

Graphics / Re: origin relative to the Transformable

« on: September 14, 2024, 06:14:16 pm »

The origin of a drawable should always be updated

I was proposing for SFML to handle this. Thus, when I set the origin of a text to its center, then update the string in the text, I wouldn't have to worry about updating the origin as well.

The problem with this is that the required result of this can be dependent on its use, especially with text.
For example, when you change a character in all lower case string to its capital, the text would move downwards. Most often, it's best to find the "best" centre for the text and then keep that when changing the string. Note that I'm, here, talking about the y value only; the x still needs updating. Also, this is more complicated for multi-line text.

My main point really is that sometimes you may want to allow it to move the text so that the true centre is where you position and sometimes you may want to text a centre based on a 'usual baseline' and centralise the x, meaning that, since that this decision is made by the user, the user should probably centre the text manually.

Of course, you can add simple functions to do this automatically in the specific way you want it, if required. For example:

void setTextString(sf::Text& text, const sf::String& string, const bool autoCenter = true)
{
    text.setString(string);
    if (autoCenter)
        text.setOrigin( /* you know this bit ;) */ );
}

// ...

sf::Text text;
// set up the text including font and character size first!
setTextString(text, "Some string");

12

Audio / Re: Music.setVolume doesn't work.

« on: August 29, 2024, 09:24:25 pm »

Does music.getVolume() return zero correctly?

Is the volume affected if you stop and then re-start the music?

Is it possible you have a line somewhere else that sets its volume to something else?

13

Graphics / Re: origin relative to the Transformable

« on: August 29, 2024, 09:19:54 pm »

The origin of a drawable should always be updated whenever the drawable is manipulated unless you can be sure that it doesn't need it for some reason. This is particularly important with texts that change string, fonts, styles, sizes etc..

Also remember that the centre of an actual visible bit of text, the origin should also take into account the position of the local bounds (as an sf::Text's bounds can be non-zero) so it's likely that you should use (presuming SFML 2.6+) something like:

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

If you are interested in using a library that calculates different parts of a drawable automatically (or understand how to calculate it for yourself), then please feel free to have a look at Plinth, in particular "SFML Anchor" (the code - similar to above - that calculates the centre, for example, is here). This also works with SFML pre-v2.6. Note that is still requires manually updating of the origin when needed; it just simplifies the code (and tends to make it more readable).

14

Graphics / Re: Using GetWindowHandle() to make the window background transparent.

« on: August 25, 2024, 05:10:18 pm »

Any ideas why this doesn't work
[...]
"The SetWindowLongPtr function fails if[...]
Could this be a possible reason for not allowing transparency?

Is SetWindowLongPtr function failing? You haven't mentioned that.

15

Graphics / Re: LoadFromMemory Sprites

« on: August 11, 2024, 04:47:41 pm »

Since your function returns an sf::Image, you can use it directly in the call to loadFromImage, presuming you have no intention of using the sf::Image for processing.:

sf::Texture scottTexture;
scottTexture.loadFromImage(LoadImageFromResource("SCOTT_PNG"));

That image will automatically be destroyed (cleaned up) after the texture is loaded from it.