1
SFML development / Re: SFML Move Semantics
« on: August 13, 2020, 01:55:09 am »
SFML Devs: Can we please get some final input on the topic, or start making some progress on the PRs? Not sure if there is anything else I can do.
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.
2
SFML development / Re: SFML Move Semantics
« on: July 07, 2020, 02:21:27 am »
Thank you for the theory Nexus, I have not been exposed to the copy-and-swap pattern before so it is interesting to see why and when it could be useful.
After reading through your response and seeing your example implementation, how does this sound as the implementation strategy going forward?
Considering you have now created the move semantics branch, should we consider your texture implementation as the first official commit and PRs be accepted when ready to this branch?
After reading through your response and seeing your example implementation, how does this sound as the implementation strategy going forward?
- Where possible, rely on default implementations of the big 5.
- For resources that have custom ownership semantics:
- Implement move/copy operations via swap method.
- Use consistent naming (copied, moved, swapped) for the "rhs" parameter.
Considering you have now created the move semantics branch, should we consider your texture implementation as the first official commit and PRs be accepted when ready to this branch?
3
SFML development / Re: SFML Move Semantics
« on: July 05, 2020, 10:36:30 am »
I personally don't have a preference for how we approach move semantic support. I agree that manually writing the big 5 for each class is undesirable and I am also in support of concise, readable code. However, I really want behaviour to be logical, and I don't think that swapping internal state for resources like windows during move operations is logical.
A note worth mentioning is that if the internal handles were unique pointers then default move constructors would be perfect. Maybe this is a more valid approach for move semantics in some cases.
Ultimately, I am happy to work on this job in what ever way you more senior members think is best. We just need to be consistent. Please, contribute to the discussion and be harsh on the PRs. I will do the grunt work
A note worth mentioning is that if the internal handles were unique pointers then default move constructors would be perfect. Maybe this is a more valid approach for move semantics in some cases.
Ultimately, I am happy to work on this job in what ever way you more senior members think is best. We just need to be consistent. Please, contribute to the discussion and be harsh on the PRs. I will do the grunt work
4
SFML development / Re: SFML Move Semantics
« on: July 04, 2020, 07:48:14 am »
There are two active PRs for move semantics on Github at the moment that have taken different approaches. I think this provides a good opportunity to discuss a method to standardise on.
Shaders
https://github.com/SFML/SFML/pull/1676
Performs move by swapping lhs object state with rhs object state.
Window
https://github.com/SFML/SFML/pull/1681
Performs move by destroying lhs object state, assuming rhs object state, and reinitialising rhs object state with sensible defaults.
I personally think that the first method is more prone to undesired behaviour. For instance, if the move constructor for a window was to perform a straight swap, then both windows would remain open after the operation completes. Any thoughts? Should we push for a consistent approach for move semantics?
[Edit]:
I found a discussion on the topic from SO.
https://stackoverflow.com/questions/6687388/why-do-some-people-use-swap-for-move-assignments
Shaders
https://github.com/SFML/SFML/pull/1676
Performs move by swapping lhs object state with rhs object state.
Window
https://github.com/SFML/SFML/pull/1681
Performs move by destroying lhs object state, assuming rhs object state, and reinitialising rhs object state with sensible defaults.
I personally think that the first method is more prone to undesired behaviour. For instance, if the move constructor for a window was to perform a straight swap, then both windows would remain open after the operation completes. Any thoughts? Should we push for a consistent approach for move semantics?
[Edit]:
I found a discussion on the topic from SO.
https://stackoverflow.com/questions/6687388/why-do-some-people-use-swap-for-move-assignments
5
SFML development / Re: SFML Move Semantics
« on: June 27, 2020, 07:21:25 am »Quote
You mention some good points. I also think a modular approach makes more sense -- could even be on a class/group of classes basis, to have smaller incremental steps that can be reviewed in reasonable time.
Adding the move semantics on a class/group of classes basis is a great idea. As well as making review more managable, it also means more poeple can work on the task in parallel.
Quote
are move semantics pressing enough to introduce them into SFML 2.x
or should we prioritize making a development branch available for SFML 3, so that PRs with new features can be processed?
I am not fussed either way, I feel that adding move semantics in SFML 2.x would be in conjunction with sf::NonCopyable, where as SFML 3.0 is an opportunity to ditch sf::NonCopyable altogether. I am not whether a conclusion was ever reached on that discussion.
One last thing I would like to know, what module do you think would be most pressing to work on?
6
SFML projects / Re: Megaman Battle Network (ongoing fangame)
« on: June 26, 2020, 02:32:47 pm »
This is an incredibly cool project. Your video was motivating to the point that I am now programming instead of going to bed like I should 
7
DotNet / Re: SFML.Net Core???
« on: June 20, 2020, 04:30:45 am »
I recently invested a couple hours trying to get an SFML.NET project to build on Linux (I am not a .NET user) and failed. I didn't realise it was this easy. Is it worth adding these instructions to the SFML wiki page?
https://github.com/SFML/SFML/wiki/Tutorials
We could replace the "SFML.Net on OSX" page with "SFML.Net using .NET Core" as it applies to all OS.
https://github.com/SFML/SFML/wiki/Tutorials
We could replace the "SFML.Net on OSX" page with "SFML.Net using .NET Core" as it applies to all OS.
8
SFML development / Re: SFML Move Semantics
« on: June 20, 2020, 02:41:09 am »
Alright, I am ready to start working on move semantics again, but a few conversations have happened around the place and I would like to make some suggestions about how to approach the problem.
Non-breaking move semantics
The initial plan is to implement move constructors and assignment operators only, and leave sf::NonCopyable to handle deleted copy functions. This way, the changes can roll straight in without API breakage. I assume that in the future, we may want to instead use =delete instead of sf::NonCopyable during a major update. This will be a much quicker job if the move semantics are already implemented.
Implement on a per-module basis
Implementing move semantics in SFML will not be trivial. The biggest risk is that I start working on it, make decent progress, but stop short due to lack of time or interest. Someone else might also try and do the same, and it becomes an endless ordeal. I suggest that we implement move semantics on a per-module basis. This would be less intimidating to work on and the job could be divided up for others to help with if it interests them.
Non-breaking move semantics
The initial plan is to implement move constructors and assignment operators only, and leave sf::NonCopyable to handle deleted copy functions. This way, the changes can roll straight in without API breakage. I assume that in the future, we may want to instead use =delete instead of sf::NonCopyable during a major update. This will be a much quicker job if the move semantics are already implemented.
Implement on a per-module basis
Implementing move semantics in SFML will not be trivial. The biggest risk is that I start working on it, make decent progress, but stop short due to lack of time or interest. Someone else might also try and do the same, and it becomes an endless ordeal. I suggest that we implement move semantics on a per-module basis. This would be less intimidating to work on and the job could be divided up for others to help with if it interests them.
9
SFML development / Re: SFML Roadmap
« on: June 20, 2020, 02:14:54 am »
This is a really good conversation starter Nexus! I have some thoughts in response..
Error Handling
I don't like the idea of having resources constructed through factory methods. Once we get move semantics implemented, you could implement your own factory methods that handle errors in what ever way you like. Forcing an error handling method would be an opinionated debate with no right or wrong answers.
Major removed APIs
I agree that sf::Thread has no place anymore, but totally support keeping sf::Time for the reduced verbosity. We could add an std::chrono::duration operator to the Time class so that it works natively with std::thread::sleep functions.
Ownership and smart pointers
I like the idea of using std::unique_ptr for handling object lifetimes inside SFML classes, but personally would prefer if SFML never forced the user to create a smart pointer to interact with the library. This is just personal preference, it would be good to hear what others thought.
Error Handling
I don't like the idea of having resources constructed through factory methods. Once we get move semantics implemented, you could implement your own factory methods that handle errors in what ever way you like. Forcing an error handling method would be an opinionated debate with no right or wrong answers.
Major removed APIs
I agree that sf::Thread has no place anymore, but totally support keeping sf::Time for the reduced verbosity. We could add an std::chrono::duration operator to the Time class so that it works natively with std::thread::sleep functions.
Ownership and smart pointers
I like the idea of using std::unique_ptr for handling object lifetimes inside SFML classes, but personally would prefer if SFML never forced the user to create a smart pointer to interact with the library. This is just personal preference, it would be good to hear what others thought.
10
Graphics / Re: SFML Shader Gradients
« on: June 18, 2020, 04:01:01 pm »
That is actually a pretty creative solution..
11
SFML development / Re: Allow changing processing interval in SoundStream
« on: June 04, 2020, 08:02:33 am »
Hi guys,
Do you have any thoughts regarding my comment on the Audio Processing Interval PR?
https://github.com/SFML/SFML/pull/1666
Do you have any thoughts regarding my comment on the Audio Processing Interval PR?
https://github.com/SFML/SFML/pull/1666
Quote
I have updated the test which audibly demonstrates the change in processing interval. Interestingly, changing the processing interval to zero does not produce the outcome that I would have expected in terms of reducing audio latency. At the standard 10ms interval, you want about 20 to 30 ms of audio per chunk to prevent the audio device from starving, but reducing the interval to zero does not reduce the amount of audio that you need per chunk. I suppose this would also require a change to the internal audio buffer sizes.
This is not a bug, but maybe an indication that a tunable processing interval alone is not enough to acheive the desired outcome?
12
General discussions / Re: SFML GameDevelopment LoadingState
« on: June 01, 2020, 02:18:50 am »
There are many, many different ways that you can acheive this. One really simple way to do this would be to have a vector of textures, sounds, etc as members of the Parallel Task class. The constructor might take in a vector of strings that represent the file paths to those resources. Then in your execute function, you iterate over the strings, load resources into their vectors. Once the thread is finished, you can get the resource vectors from the Parallel Task object via getter functions. As for the "getCompletion", that could return the percentage of resources that have been loaded.
One thing to consider though, is that your resource loading will be so fast that it wont be worth the overhead of creating a thread. But for educational purposes, it is still nice to explore.
What do you think of this solution? Can you see any potential problems? Can you see a better way of doing it that might be more generic?
One thing to consider though, is that your resource loading will be so fast that it wont be worth the overhead of creating a thread. But for educational purposes, it is still nice to explore.
What do you think of this solution? Can you see any potential problems? Can you see a better way of doing it that might be more generic?
13
Graphics / Re: Blend with previous frame using coefficent
« on: May 30, 2020, 01:59:26 am »
I think that a shader is going to be the most effective solution for this problem. Try not to worry about experience, the SFML shaders are incredibly easy to use. See the Fragment Shader heading in this tutorial which is similar to the logic you would need:
https://www.sfml-dev.org/tutorials/2.5/graphics-shader.php
When multiplying the color of the texture, you can do something like:
gl_FragColor = gl_Color * vec4(pixel.r, pixel.g, pixel.b, myCustomAlphaValue);
You can bind multiple textures simultaneously for access in the shader code so you can combine the pixel data however you see fit.
https://www.sfml-dev.org/tutorials/2.5/graphics-shader.php
When multiplying the color of the texture, you can do something like:
gl_FragColor = gl_Color * vec4(pixel.r, pixel.g, pixel.b, myCustomAlphaValue);
You can bind multiple textures simultaneously for access in the shader code so you can combine the pixel data however you see fit.
14
General discussions / Re: Concerned and Eager
« on: May 27, 2020, 02:15:51 am »Quote
SFML has a high quality standard
We try to get the code (and commits) as good as possible before merging them. This leads to Pull Requests not being accepted (but also not rejected) that don't meet that "quality". The advantage is that once a feature is merged, it has been tested, is stable and usually doesn't require regression fixes.
Personally, I don't think we should make compromises here, as it would only reduce the quality and push the required work further back.
I agree that compromises should not be made here, but I can see why it could slow down progress when it feels more like work than play to contribute.
Quote
SFML is cross platform
A lot of people underestimate the amount of work required to implement a "simple" feature. You have to pick an API design for SFML, then you need to make sure that it works for Windows, Linux and macOS and then you need to implement for all these platforms and after all that, there's still Android and iOS.
I could see some room for providing feature implementation for just one platform, but this has the danger of diverging the feature sets and making the library less "cross-platform".
I would lean more towards providing implementations for platforms as they become available with exceptions being thrown in unsupported OS. You will get the good chemicals more often working on 5 smaller issues of "implement and test X on Y OS".
Quote
If you want a feature, you need to get active and help get the feature finished.
I find this refreshingly motivating
Thanks for the detailed response eXpl0it3r. I shall find feature to start pushing.
15
SFML development / Re: SFML Move Semantics
« on: May 27, 2020, 02:04:48 am »
I am currently postponing work on this feature in favour of something that is on the critical path to SFML 2.6. I shall return!