Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - binary1248

Pages: [1] 2 3 ... 92
Feature requests / Re: SFML on NVIDIA Jetson nano
« on: May 03, 2020, 02:10:12 pm »
That probably means that desktop OpenGL support is emulated by the OpenGL ES driver. SFML still makes use of the pretty old OpenGL API, meaning there is a high likelihood most of the calls it makes will have to go through the emulation layer. This might lead to poor performance.

You can try to build and run SFML on the Jetson Nano. In theory it should work, however whether the performance holds up to expectations is another story.

Feature requests / Re: SFML on NVIDIA Jetson nano
« on: April 30, 2020, 02:31:12 am »
Same story as all the other embedded systems including mobile devices: SFML's support for OpenGL ES is currently still "lacking".

General / Re: General Questions
« on: February 09, 2020, 12:51:15 pm »
Multi-threading in SFML is no different than in any other programming library. Unless stated otherwise, simultaneous access to the same object from multiple threads requires synchronization.

Using views allows you to control a 2D virtual "camera". You choose where to place it in your 2D scene, how big the area should be that it should capture and the target region of your window where the contents should be projected. There is no right or wrong here. It depends on what you are trying to achieve artistically. Rendering to a view whose source rectangle size does not exactly correspond to its viewport size will cause the contents to be stretched or squashed along one or both axes. If you want your rendered graphics to be reproduced 1:1 you should avoid any kind of scaling and make sure your view source rectangle size matches its viewport size in pixels exactly.

General / Re: Need Advices for performances + shaders
« on: January 18, 2020, 07:36:48 pm »
As for your first question:

Judging by your pictures... you could benefit from using geometry shaders to generate the vertex information within the shader based on data you pass in the position vertex attributes. That way you can also perform the matrix multiply within the shader as well which will probably lead to a huge performance improvement because that is what they are made to do.

As for your second question:

In theory you can move the decision on whether to "apply" a shader to a primitive from CPU to GPU. In effect, the same shader program is left enabled and run over all vertices, but you can program the shader to only really "do stuff" when certain conditions are met (which you can control via uniforms) and just pass through the data in all other cases.

I think you overestimate the "difficulty" of using OpenGL. Sure it might not be as close to a walk in the park as maybe learning SFML might be. But as I have always said, the hardest part about learning OpenGL is not actually getting familiarized with the API itself but learning the general 3D graphics programming concepts that it is built on. Based on what you have shown, you are already familiar with these concepts, so I don't think extending your knowledge to OpenGL will be that much work.

Look at it this way: trying to accomplish what you want your game to look like is probably doable using SFML and GLSL alone, but the effort you will have to invest will be more than just learning OpenGL and doing it with that instead. The nice thing about learning new skills is that the knowledge will keep benefiting you even after you are done with your project. The techniques/hacks you would have to come up with doing everything with SFML and GLSL will probably only be applicable to your current project and almost useless anywhere else.

Graphics / Re: Embedded RenderWindow depth buffer issues on linux
« on: December 09, 2019, 02:12:28 am »
In the Linux Xlib world, the pixel/surface format of the window can only be set when creating the window. It cannot be retroactively changed. Since you create your window using wxWidgets you will have to get wxWidgets to create a window with the correct format and pass it to SFML. The context settings parameter for the window handle overload is more or less meaningless on Linux, it is there because of the other platforms where retroactively changing the pixel format is possible.

You should still be using wxGLCanvas even when intending to render with SFML. The normal wxControl object doesn't know much about OpenGL surface attributes.

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.

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.

This should be fixed with PR #1609

Thanks for reporting this.

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.

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

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.

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.

Graphics / Re: Issue with RenderTexture to Image copy
« on: July 17, 2019, 01:08:20 pm »

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...

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.

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.

Pages: [1] 2 3 ... 92