Messages

16

Feature requests / Re: So, I'm moving away from SFML due to Wayland support

« on: October 25, 2019, 02:12:12 am »

The linked forum thread is from 2013 and the issue is from 2016 (and didn't really discuss any concrete benefits of supporting Wayland other than "it's the new thing").

We're in the latter half of 2019 now, 6 and a half years since the original thread was written. A lot has happened since then. Many mainstream distros have decided to make Wayland the default session, the latest being Debian which is a pretty significant milestone and a testament to the stability and support it has gained over the years.

I remember experimenting with Wayland back then as well. It wasn't pretty, and still really experimental. If something went wrong with your exotic setup you were pretty much on your own. It wasn't a very nice environment to develop in. This coupled with the fact that not many "casual" users would even make use of potential Wayland support on their daily drivers and the fact that Wayland didn't provide any tangible advantages over X11 back then lead to Laurent deciding not to dedicate developer time to supporting the platform.

What hasn't changed since then is that SFML is still constrained by developer time. In contrast to other libraries, none of the SFML's contributors are compensated in any way for working on SFML and it's development isn't endorsed by any organization either. Just as back then, we need to prioritize features we feel provide a meaningful benefit to the library, as opposed to features that are just "nice to have" or "would be cool".

Considering that Wayland today has matured a lot since 2013 and development should no longer be as painful as it was back then, I wouldn't say it is off the table that support for it in SFML will come one day. The question is who will implement it. Since this is a pure backend enhancement with no public API changes, the necessary discussion should be kept to a minimum. I might have a look when I have a bigger chunk of free time on my hands.

17

General discussions / Re: Is it worth it to build my own engine using SFML

« on: September 14, 2019, 02:54:05 pm »

The M in SFML stands for multimedia. You shouldn't expect SFML to realistically help you with anything else that belongs in a usable game engine.

You have to ask yourself, what is your goal. Do you want to end up with a game of sorts? Or do you "just" want to gain experience in programming, libraries, and the other 1000 things that engine developers have to care about.

There are some people (myself included) that aren't interested in the game itself but more the underlying technology which is why I enjoy programming and working on libraries even though I never actually end up with anything "shippable" to a consumer. And then there are the other people who really just want to make games that they can show their friends once they are done, this is also a task that shouldn't be underestimated.

The effort that goes into games comprises way more of actual content creation than the raw programming. If you look at teams, you will find way more artists, designers, writers, testers etc. than actual programmers. The programmers do their part of the job writing an engine the rest of the team can work with and the "stuff" that makes the game what it is comes after that. In smaller teams, you will find that each developer will have to fulfil multiple of these roles.

If you really want to do both, you will be doing the jobs that normally rest on the shoulders of multiple people, the workload included. A beginner misconception is that one must write an "engine" if one wants to make a game. This is not true. You write an engine so that non-programmers can also contribute to making the game in their own way. At the present time, if a game is big enough, writing an engine is the only way to realistically ship the game before the budget runs out, spread the work out among many people. If you are a smaller team or even just one man, you have to ask yourself: Would I really benefit from writing an engine considering I will be the only one using it?

Most indie games either use pre-existing engines or if they feel that those wouldn't get the job done as they envision their game they just write the game from scratch. I haven't heard of a small indie team writing an engine first then building their game around it. That just wouldn't be financially feasible. What does happen though is, if the first game becomes a financial success and they decide to write a sequel, they reuse parts of the first game to make the sequel. Would this be some rudimentary form of engine? I wouldn't count it as such. It is just code re-use to me.

TL;DR: Engines are just a tool to help make development of complex projects financially viable. Bigger projects always go in that direction. Smaller/Tiny projects should focus on getting deliverables out the door ASAP however they choose to do it. You have to choose now what you want to have in your hands after 2 years. It won't be both.

18

Graphics / Re: Can't construct a Texture object from another Texture object?

« on: August 30, 2019, 11:12:47 pm »

This should be fixed with PR #1609

Thanks for reporting this.

19

SFML projects / Re: SFGUI (0.4.0 released)

« on: August 30, 2019, 10:41:40 pm »

I'm not a macOS expert, so no idea what that error even means.

You could try building and linking SFGUI statically. That way the system libraries that you need to link into your final application will be covered either by SFML or your own project.

20

Feature requests / Re: glQueries

« on: August 30, 2019, 12:00:03 am »

I don't think this is within the scope of SFML.

• Using this properly requires an understanding of the asynchronous nature of the OpenGL pipeline
• Constantly querying GPU counters will cause a GPU-to-CPU sync anyway leading to a significant decrease in performance, hence previous point
• This requires an extension that is only supported in OpenGL 3+
• If you really needed such functionality, writing a wrapper yourself with the help of sf::Content::isExtensionAvailable and sf::Context::getFunction shouldn't be more than 30 lines of code
• A lof of programming literature out there (especially beginner books like "Programming: Principles and Practice Using C++") provide their own blackbox libraries to help students focus on first learning the concepts at hand rather than their concrete implementations, this would be no different

21

Graphics / Re: Can't construct a Texture object from another Texture object?

« on: August 15, 2019, 11:34:43 pm »

It could be that a TransientContextLock lock; is missing before the line that causes the error. A minimal example to reproduce the issue would help to confirm this theory.

22

Graphics / Re: A single draw call severely slows thing down

« on: August 04, 2019, 12:00:14 am »

On my RX Vega 64 the frame time is < 2 microseconds which is > 500 FPS or 20 million triangles per second.

This seems pretty normal to me. I don't think that many AAA games even draw that much and if they really needed to they have to resort to some pretty advanced tricks like instancing etc.

As eXpl0it3r said, your IGP at 129.6 GFLOPS just isn't that powerful.

23

Graphics / Re: Issue with RenderTexture to Image copy

« on: July 17, 2019, 01:08:20 pm »

https://en.wikipedia.org/wiki/QR_code

The size and thus maximum payload length depends among other things on the "version" of QR code that is used. I don't know how you are generating these, but if you make sure the version stays the same all the time then the size of the output image will not change. You just have to pick a version that is big enough to fit all your data.

Although good code readers have to put up with a lot of broken stuff, I wouldn't recommend trying to perform non-integer scaling on the final output image. This will lead to some squares being bigger/smaller than others and might throw off the reader in certain situations where it can't synchronize with the timing pattern.

If you really need to do it anyway and are confident that readers will be able to read a scaled image, then since you are already using STB you can use stb_image_resize.h for your purposes...

24

Graphics / Re: Issue with RenderTexture to Image copy

« on: July 16, 2019, 09:14:40 pm »

I'm just wondering if there is a thin abstraction library over FreeType or not.

When I first had to do TrueType things myself I was also looking for such a library for quite a while.

Over the years I have come to the conclusion that there is a reason why wrapper/abstraction libraries don't exist for certain C libraries. It is probably because their API is so "simple" to use that a wrapper or additional abstraction wouldn't add much value that it offsets any potential disadvantages (like performance overhead, additional dependency, etc.) that might be incurred. FreeType is such a library. It is used everywhere, by many people and there is still no widely used wrapper of it.

Furthermore I will need to include a small scissor image which needs to be scaled.

If the target resolution stays the same throughout the life cycle of your application, just pre-scale the image yourself with a high quality filter and bake in the final bitmap data. Any algorithm that is optimized for real-time scaling, up/down sampling such as those found on GPUs will never achieve the quality of a good offline algorithm.

25

Graphics / Re: Issue with RenderTexture to Image copy

« on: July 16, 2019, 04:09:01 pm »

Since you are targeting systems without real GPUs, we can assume that SFML is choosing the FBO emulation path via pbuffers or hidden windows. In this case it is up to the system how large the pbuffers are allowed to be and if it really had to fall back to creating hidden windows there might be some strange interactions with the fact that it is a sub-process of another process. pbuffers were never really a clean thing either.

As I already said, it might be comfortable for you as the application developer, but from an implementation point of view, so many things are being used in ways they were never meant to be used that nobody is going to guarantee any kind of behaviour in this scenario. You are basically on your own at this point.

Realistically, the time you would invest in figuring this problem out (if you can actually resolve it) would be better spent in coming up with a clean, supported solution from the get go. The solution I detailed above is purely CPU based, requiring nothing more than CPU and memory. It would even run on headless systems without a desktop environment, which makes it more amenable to being run in the cloud. Considering your target platforms, it is the only path I can recommend.

26

Graphics / Re: Issue with RenderTexture to Image copy

« on: July 16, 2019, 02:13:08 pm »

This seems a bit over-engineered to me.

If all you want to do is combine text, rectilinear lines and a generated QR code bitmap into a single bitmap, you don't even need SFML to do this. Just use FreeType directly to rasterize the text for you and you will have all the bitmap data you need to combine into the final image.

SFML is a library aimed at real-time GPU accelerated rendering. If you know that your target system will typically not have a (usable) GPU then SFML probably isn't the right library for your work. In your case you don't even want to render/draw more than a single frame. The time it takes to set up the graphics pipeline far outweighs the time it would take it to render that singular frame let alone transfer the data back to main memory to save as an image. Performance-wise it is a nobrainer that this is better done purely on the CPU.

If FreeType seems daunting to use at first, that might be so. Just have a look at the tutorials and familiarize yourself with the API. Rasterizing non-rotated LTR western script text to a bitmap can be done in 100-200 lines of code. From there you can combine the bitmap data with the rest of your elements into the final image.

27

Graphics / Re: Should I try to adjust SFML or use OpenGL? Missing some 3D features.

« on: May 06, 2019, 12:59:38 am »

The reason why SFML doesn't try to "do 3D" is because it is way more complex than it might seem to beginners (i.e. a big chunk of the SFML userbase). Too many unhealthy compromises would have to be made to establish a lowest common denominator. 2D graphics hasn't really changed much in the past 30 years, 3D graphics on the other hand...

When I wrote 3DEE I never really meant for it to gain any realistic traction. It was more of a proof of concept that the existing SFML concepts could be extrapolated into another dimension. It might have been usable for a tiny amount of people, but for the majority who are serious about working on a long-term 3D project, it was just never enough, by design.

SFML provides enough OpenGL support that many people have successfully employed SFML for window management, input, audio and of course OpenGL context management. Anything graphics related is then built fully custom for the project on top of the OpenGL layer.

The concepts you listed are some of the most basic concepts that any 3D graphics programmer should understand, and be able to implement themselves if need be. Realistically any library that would provide helpers for those concepts are only going to save you a few hours of work if you are already familiar with 3D graphics programming. The important thing to note is that one should not use such helper libraries as black boxes in order to not have to understand the underlying concepts. Everything is so interconnected that any holes in one's knowledge will seriously hinder progress later down the road.

Familiarize yourself with OpenGL and 3D graphics programming, from the beginning to whichever point you feel is necessary to realize the project you have in mind. You can use SFML as a base for the lower level stuff along the way.

You might have seen this already, but this video is a good example of what can be done in SFML with enough knowledge and effort.

28

General / Re: undefined reference to GLX functions when using cmake with static libs on linux

« on: April 12, 2019, 07:51:46 pm »

One has to pay careful attention to the fact that the same script is used to link against EGL and all the other non-desktop-legacy-OpenGL stuff as well, this includes Android and friends. I am pretty sure that the CMake guys had good reasons to go their way with the GLVND change they implemented at some point, but this also means we need to take all the possible scenarios into account ourselves.

See: https://github.com/Kitware/CMake/blob/master/Modules/FindOpenGL.cmake

29

Graphics / Re: Regarding the VertexBuffer implementation in Renderables..

« on: March 22, 2019, 01:24:14 pm »

I really don't see why, from a technical perspective, what you are trying to achieve is only doable by creating a temporary sprite every frame...

Assuming that the user should be able to actually recognize something on their screen, said sprite would have to be drawn over multiple frames anyway, meaning that it would have to be recreated multiple times with very similar if not identical parameters. Except for special cases (static linking combined with some heavy duty LTO), the call to the constructor of sf::Sprite and indirectly its members will not be optimized away and will also have some kind of CPU performance impact. The fact that it doesn't stick out (yet) in a measurement does not mean it doesn't exist.

While I am not the original author of the documentation, I can say that the term "lightweight" came in when switching from SFML 1.6 to SFML 2.0 in order to emphasize the fact that sf::Sprite no longer holds the huge chunk of texture data like it used to in SFML 1.6. Making any other forms of performance guarantees, especially when relying on the graphics hardware/drivers to do the right thing, is not such a good idea. Something that runs fast on one system does not have to run fast on another, especially when it comes to OpenGL.

When considering such optimizations, we always consider what kind of effects it might have on the behaviour and performance of the program. It was already clear back then that frequent creation of sf::Sprites and all the other drawables would cause VBOs to be created and destroyed all the time. Based on inspection of publicly available code, it was clear that this usage pattern wasn't really something to take into consideration since performance concious users would, as explained above, reuse objects over a longer period of time, or just forget the pre-made drawables and manage vertex data themselves.

We optimize for best and average case performance. Worst case performance is something no library/API/programming language will optimize for since it is virtually impossible to predict all the ways something can be used incorrectly let alone infeasible to write workarounds for every single case. Unlike algorithms that operate on input data which cannot be known beforehand and have to reckon with the worst, we assume developers do not program randomly and have some kind of motivation to get the best performance out of their application whatever means necessary. As long as there are enough ways to get good performance, we won't let worst case performance regressions hinder any optimizations made to improve the former.

Last but not least, the main reason this change was necessary, regardless of performance impact, is that client side arrays are no longer supported in core OpenGL 3.2+ and OpenGL ES 2+. In order to future proof SFML and be able to gradually move in this direction, we had to add an implementation that uses VBOs for vertex data storage instead of system RAM. Disabling this change in any way would lock the implementation and your application to using legacy OpenGL and/or OpenGL ES 1.0 forever.

Future optimizations can always be made to optimize even such usage patterns. Making use of a single large VBO from which we allocate fragments to every drawable is something I have had on my list for quite some time, I just haven't got around to doing that just yet. The necessary backend changes to make this possible are being worked on already, it's just a matter of time until it sees the light of day.

30

Graphics / Re: Using geometry shaders on sf::Drawables

« on: March 18, 2019, 01:23:31 pm »

SFML drawables all send primitive information to OpenGL in the form of triangles. You have to make sure your geometry shader also accepts triangles as the input primitive instead of points as is the case in your example.

For more information, refer to the available documentation, e.g. https://www.khronos.org/opengl/wiki/Geometry_Shader