Messages

1

Window / Re: Beginner mistake? No video modes listed

« on: December 05, 2023, 06:44:32 am »

I copied, pasted and ran your exact code and I got a sane result (approx. 30 items and they all listed) so I must presume there is some deeper issue.

Have you run just this exact code with nothing else and was that still an issue?

Do you normally have other lines of code too that might affect it?

Does it do this with a vector of other structures? Ints? Some custom structure of your own?

2

System / Re: what do I need to fully use the library of SFML?

« on: December 04, 2023, 07:47:05 pm »

First, it depends on which environment you are developing. w.g. Windows/Linux/Mac? Visual Studio/MinGW?

There are some tutorials that should guide you through setting it up (in these environments, look for the "SFML and ..."), here:
https://www.sfml-dev.org/tutorials/2.6/

Also depending on your environment is which types of files you need and where to put them.

If you are specific problems with those tutorials, you can give more information about your environment and which problems you are encountering.

3

General / Re: fatal error: SFML/Graphics.hpp: No such file or directory

« on: December 04, 2023, 07:41:28 pm »

Hi!

It doesn't look like you're including SFML's "include" folder.
In this folder should be an "SFML" folder that contains "Graphics.hpp" (as well as the others).
It should look a bit like this one:
https://github.com/SFML/SFML/tree/master/include

Note that the include folder should be included so that the SFML part can be added when using #include. e.g. #include <SFML/Graphics.hpp>

4

Graphics / Re: texture smoothing causes render artifacts

« on: December 03, 2023, 02:18:24 am »

Thanks for responding Hapax!

You're very welcome!

Please help me understand this.  What about my example texture in the code provided is a "non-perfect integer pixel"?

You're stretching a 32-pixel wide image across 40-pixels.

First, you have to know that you should consider a pixel to be a rectangle with co-ordinates at the corners. So, at 1:1 scaling ratio, a pixel at "0, 0" would be a rectangle from (0, 0) to (1, 1) and a pixel at "3, 2" would be a rectangle from (3, 2) to (4, 3).
When calculating which pixel colour is required from a texture, it can sometimes hit the edge of the pixel rectangle and have to make a decision to which side of the edge it should read from (this is not an actual decision; it's simply just an error of floating point values).
Now, imagine your 32-pixel wide image; it goes from 0 (left of first pixel) to 32 (right of 31st pixel).
If you stretch this to fix 40-pixels, the image pixel "rectangles" start to overlap two actual pixels (rectangles) of the final render. It now goes from 0 - 40 (across 40 pixels). Every 4 pixels are stretched across 5 pixels. For example, the 3nd actual pixel could be reading from the 2nd texture pixel or the 3rd texture pixel (each half of that actual pixel is a different one). When you then move everything by a slight amount, one starts to dominate more and is more likely to be "chosen". This means that a very slight (fraction of a pixel) movement can make that one pixel change from one to the next.
Luckily, without smoothing and movement, your image looks great

Add in to this a smoothed texture, and it gets even more complicated. It smooths textures by blending pixels when stretched or squashed (giving a blurry effect). That means when you stretch a 32-pixel texture across 40-pixels, it starts blending pixels. These blended/blurred pixels could be on either of the tiles (that are joined), or both, and could easily be selected. Indeed, if it picks the right pixel but part of the next pixel wants to be seen as well, it'll just blend it in.

If you want to see texture smoothing in action, try stretching an image with fine (but clear) detail.
There's a simple example in the SFML tutorials here (scroll down to the first images):
https://www.sfml-dev.org/tutorials/2.6/graphics-sprite.php#loading-a-texture
You can see that the image that has been smoothed looks slightly blurry (look at its edge) when its size has been increased.

5

Graphics / Re: Determining whether a point lies within a non-rectangle shape

« on: December 02, 2023, 03:37:56 pm »

Any sf::Transformable such as sf::RectangleShape uses a transform (sf::Transform) to convert all of the local co-ordinates of the shape to be in it is final position: the global co-ordinates. You can access this transform, for example, by rectangle.getTransform().

However, your "global" co-ordinates have already been transformed. What you could then use is a way to undo this transform and... there is a way! You can also get the "inverse transform" from an sf::Transformable like this: rectangle.getInverseTransform().

You can use this inverse transform to transform all global co-ordinates into local co-ordinates, which means that you can convert one object's global co-ordinates into another object's local co-ordinates. This means that you can work within axis-aligned boxes in the local space. This is useful for points where you can see if a point is inside a rotated rectangle.

This could be enough but if you need to compare two rectangles directly, you'll need SAT or similar.



With all that being said, I've made a function that can test collision between 2 rectangles that is on the SFML Wiki:
https://github.com/SFML/SFML/wiki/Source%3A-Rectangular-Boundary-Collision
It tests using increasing complexity until it is sure of the answer so it'll test using the usual basic AABB test, then using the method I mentioned above using transforms and points, and then, finally will test using a customised SAT calculation designed for just this exact task (and it re-uses a lot of the calculations from the previous test as well!).

So, if you have 2 rectangle shapes and want to see if they collide, that free function is the easiest way.

6

Graphics / Re: texture smoothing causes render artifacts

« on: December 02, 2023, 03:21:56 pm »

The smoothing of Render Texture (and also just Texture) smooth out pixels, especially when stretched (or squashed) so that pixels might not map 1:1 if scaled by a fraction.

It seems that your tiles are 32x32 in the (render) texture but you're scaling them to be displayed at 40x40 so, when rendering, there may be some bleed as you can see from your artifacts. The artifacts are the bleed from the neighbouring colour.

I'm not sure why you want to smooth solid colours exactly so you could easily just leave smoothing off to get the desired effect but I'm guessing you may be testing for using an actual texture. In which case, you'll need to be aware that this is a common problem when using tiles at non-perfect integer pixels. Smooth only adds to this 'error'. A usual easy fix for this is to make the texture rectangle smaller (by a pixel margin) so you could just do this and crop the outside pixel edge or duplicate the outside pixel edge and then use the normal rectangle (cropping off the duplicate edge). With smoothing, you may need extra cropping to account for the "blurred" pixels.

7

SFML development / Re: DPI-Scaling on Windows

« on: November 29, 2023, 03:48:51 pm »

Even though new apps should be DPI-aware, I think the default for SFML should be to assume that they aren't. This simplifies things for people unaware of how to work with scaling (as you said: "Windows does everything for you and the developer doesn't has to do anything.")

Of course, being DPI-aware is what we should all be aiming for so it should be possible with SFML but it should be "opt-in" because it's basically presumed at the moment. This is "not scaling" as you mentioned although it technically removes scaling if there is any already present.

The good thing about being opt-in is that it makes sure that the developer is DPI-aware so everything to do with scaling should be expected. It also means that the title bar shouldn't be an issue if externally created (if they have set it to be DPI-aware already).

Of course, we can mention in documentation and tutorials that windows may be automatically scaled and may produce slightly blurry visuals unless the windows are DPI-aware (and then have a tutorial on DPI-aware, preferably) so they know what to expect and how to learn how to avoid it if it isn't what they want.

Also, I'm curious as to how "monitor-aware" windows act when there are multiple windows on different windows and also how they act when they are across 2 (or more) windows e.g. part of the window on one monitor and part of it on another.


tldr;
To summarise the above, (I think that) DPI-unaware should be the default and DPI-aware should be opt-in.

8

General / Re: How can I pack my shader.glsl .wav files and sfml dll into exe?

« on: November 27, 2023, 04:11:35 pm »

I think it's possible you may have missed my point.

You can convert the files you wish to pack into arrays inside the code and access them directly from memory.

Maybe this will help:
https://en.sfml-dev.org/forums/index.php?topic=17256.msg124157#msg124157

9

SFML development / Re: DPI-Scaling on Windows

« on: November 25, 2023, 09:51:17 pm »

Thanks for moving it and managing to read through it all!

I should mention I linked to texus' post in my original post and did wonder why there was no discussion there.

In Windows, it's actually recommended to not automatically scale. Newer apps 'should' be marking themselves as "DPI aware" and deal with scaling themselves. Automatic scaling is for apps that cannot deal with it manually, where it just scales everything (including blurriness).
Creating a window that is "DPI aware" removes automatic scaling that is the issue when adding SFML (it removes it - but also affects the title bar for some reason).
With that said, I believe it should be possible to create an app that is not DPI-aware (where it scales automatically) and have SFML accept this and not scale the already-created windows.

Just for clarity, by the way, giving a child window to SFML causes its parent window (as well as other non-related windows) to descale. It's not just if you give a parent with to SFML.

Anyway, I should mention that creating an app that marks itself as DPI-aware involves extra steps, making everything just that little bit less simple.

The reason I mention it with an external window ("number 4") is that it's the most obvious situation, albeit probably less used. Creating SFML windows directly never show bad title bars, for example. The main issue is that it looks like SFML can't actually do the thing it pretends it can: take over an already-created window (not my opinion, by the way). It looks that way to anyone immediately trying it so it would easily put people off. Obviously, though, most of it can be overcome with some work.

I believe texus' implementation/proposal is intended to keep scaling matching across multiple monitors and it seems to do this by affecting scaling to make it seem the same size. This is still interfering with scaling (even if you don't want it to). Also, I'm unsure as to how it handles multiple windows: if you move one window to another monitor, does it rescale that window (affecting the other window not on that monitor)?

10

Graphics / Re: making of 12 beads game

« on: November 25, 2023, 09:24:15 pm »

Thanks, eXpl0it3r. I've edited my post to reflect.

11

General / Re: image cannot display

« on: November 25, 2023, 06:56:32 pm »

Hi, welcome, and glad you got it to work!

The reason it works as a member of the class is that it continues to exists (as long as the class instance does).

The other two options you mentioned both create a new texture each time and are destroyed at the end of that scope (the closing brace: } )

The one in the class's constructor is destroyed almost immediately.
The one in the loop is destroyed at the end of the loop.

But, the one in the loop is loading the texture every frame and is best avoided. Resources (especially heavy ones like textures) should be loaded once and changed as little as possible.

So, the best option here is, as you've already found, is put the texture as a class member. You can still load it in the constructor but the member lasts as long as the class instance does.

e.g.

class Game {
public:
    sf::Texture t;
    Game() {
        if (!t.loadFromFile("images/tiles.png")) {
            std::cerr << "Unable to load texture!\n";
        }
    }
}

Remember to test the return value (bool) from loadFromFile (as shown in my example) as it informs you if the texture load was successful.
You could throw an exception, for example, as it's likely you wouldn't want to continue without it.

12

General / Re: How can I pack my shader.glsl .wav files and sfml dll into exe?

« on: November 25, 2023, 06:46:22 pm »

A few ways you can do it but possibly the simplest is to convert each file into an array (all of the values separated by commas, basically), save that to a header file and include that when building.

Shaders are easier because they're already text. Just add it as a string.

You can then "load from memory" and pass the array/string as the memory.

Note that one of the DLLs cannot be "packed" due to licensing. That is the openal32.DLL, which you need for audio, so that will always be separate.

13

Graphics / Re: My SpriteSheet only animates faces to the right, and if I want it to left animat

« on: November 25, 2023, 06:42:36 pm »

As a bonus, if you're drawing lots of separate sprites, consider this, which I recently created to automatically (and very simply) batch sprites into a single draw call:
https://en.sfml-dev.org/forums/index.php?topic=29286.0 (Simple Sprite Batcher on SFML forum)
 

14

Graphics / Re: background

« on: November 25, 2023, 03:48:21 pm »

how to set a background in sfml window

Colour? Pass an sf::Color to clear().
Image? Draw a texture rectangle or a sprite to the window so that it covers the window and before you draw anything else (immediately after clearing).

there is a game called 12 beads game and when the user crosses the other bead,how do i make the second bead disappear.

What have you done so far and what exactly are you having trouble with?

how do i make a menu in the same sfml window that redirects user to the game

There are lots of ways but an SFML-based GUI might be the simplest.
Try TGUI or  ImGui-SFML, for example.

15

Graphics / Re: My SpriteSheet only animates faces to the right, and if I want it to left animat

« on: November 25, 2023, 03:39:10 pm »

But calculating transformations on every frame i think is an inefficient approach.

Calculating transformations can be expensive, yes, but the actual transformation calculations are not made until you draw it - and it's done by the graphics card*. All you're really doing when you change position, scale or rotation of an sf::Transformable (such as an sf::Sprite), is changing a few floats by adding or multiplying, which is very insignificant. Obviously, you can do many thousands or millions of these calculations every frame.

I would also say that testing memory or speed using debug is not the best option. It's up to the debugger to decide how much memory it wants to use to track the things it's doing and speed can be affected by debugging processes.
Try release mode and see if you have an issue.


*Usually. You can, of course, do CPU-based transformations calculations as well. For matrix transformations, see sf::Transform.