Topics

1

Window / Bug on Windows with 4k screens and scaling setting

« on: June 17, 2019, 10:47:56 pm »

Hello, I've found the following bug and I don't know if the culprit is SFML or Windows.
The bug does involve 4k screens and the GUI scaling setting of Windows.
If I run a fullscreen window with a scaling setting different from 100% then it appears as in the following image.

If I change the scaling setting to 100%, the bug disappears. Another important variable is the scaling that was set when the operative system initialized.

I tried different combinations (the native screen resolution is 3840*2160):

A) The OS starts with 100% scaling.
   1) Fullscreen at 3840*2160 -> OK
   2) Fullscreen at 1920*1080 -> OK
   3) Fullscreen at 1366*768  -> OK

B) The OS doesn't start with 100% scaling
   1) Fullscreen at 3840*2160 -> OK
   2) Fullscreen at 1920*1080 -> BUG
   3) Fullscreen at 1366*768  -> BUG

C) The OS starts with 100% scaling and I change the scaling to another value without restarting.
   1) Fullscreen at 3840*2160 -> BUG
   2) Fullscreen at 1920*1080 -> BUG
   3) Fullscreen at 1366*768  -> BUG

D) The OS starts with scaling different from 100% and I change it to 100% without restarting.
   1) Fullscreen at 3840*2160 -> OK
   2) Fullscreen at 1920*1080 -> OK
   3) Fullscreen at 1366*768  -> OK
   

I'm sorry if the bug was already reported. I even don't know it this is the right section to report bugs, but I couldn't find a specific bug section.

2

Graphics / Vertices z-order and alpha blending

« on: November 05, 2018, 12:37:05 pm »

Hello everyone,
I'm making an isomethric 2d game. I'm trying to find the (performance-wise) better way to display the sprites ordered by a z-level.
The best I can do now is to sort a vector of sprites, before drawing them as an ordered sf::VertexArray.

I know that SFML is built upon OpenGL and that actually every primitive is rendered as a 3D flat polygon (excuse me if I don't use a technical terminology). So I was wandering if I could delegate the z-sorting to OpenGL passing directly the z of each sprite.

Then I found this old topic and this post:

Is there any reason for SFML not to include support for depth buffering? (ie does it alter performance?). Or is it simply based on another way of rendering or something like that.

There are three reasons (from most important to least):
- it doesn't work with semi-transparent entities
- it makes the API slightly more complex for little gain
- user can break SFML by disabling depth buffer

The bolded sentence has somewhat answered my initial question, but I'd like to have a confirmation, also because six years have passed since.

If I use directly OpenGL, bypassing SFML, there would be no way to improve the performance passing directly the z of each sprite. This is because, when doing a 3D rendering, the algorithm doesn't take transparency into account. Only the meshes are used for the hidden surface determination and not the texture. In this case the mesh would be the flat primitive (an sf::Quads for example). So, also by directly using OpenGL, likewise I would end up "manually" sorting the flat meshes, otherwise OpenGL can't deal with transparency of the texture.
Is it correct? Or there would be advanced techiques now to overcome the problem?

Thanks