Messages

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 / Re: Vertices z-order and alpha blending

« on: November 09, 2018, 02:09:33 pm »

I’ve done a benchmark, and a brute depth ordering of 1.5 million sprites per frame it’s really too heavy. I see some tweaks to reduce CPU-usage but each one would bring to some limitations:
-I have a 100x150x50 tiles map. I could draw each floor separately and limit the sort toa single floor. But this would forbid sprites taller than a floor (if each floor is rendered over the previous one, the tallest sprites of the lower floor would be cut).
- I could also render only a small portion of the map around the player, but this would make impossible the use of the zoom out.
 
Moreover in each case I would still have a lot of cpu-side work that would steal resources from the real simulation, so I’d like to delegate as much as possible to the GPU.
Now, since I don’t know anything about OpenGL, I’d like to know if it’s actually possible to do this delegation without giving up the use of flat sprites. I’m only interested in alpha blending for full-transparent parts of the sprites, not for translucent parts.
If it were possible I’d be happy to deal with the lower layer and learn everything about it.

Thanks

EDIT:
I’ve found an answer to the question here. So if I use z-buffering I have to give up translucency (unless I sort the translucent objects) but I can easily keep full-transparency. I can’t figure out what this will entail in the future development, maybe translucency is very important in 2D graphics

3

Graphics / Re: Vertices z-order and alpha blending

« on: November 05, 2018, 01:34:07 pm »

Thanks, you hit the nail in the head 
I've not benchmarked yet because the game is in an early phase of development. But in the final game there will be something like 1.5 millions quads of vertices in the map (although they won't be all visible at the same time), and I think that the z-sorting could become a bottleneck, but I can't be sure until I touch it.

4

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