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

Author Topic: SFML 3 - What is your vision?  (Read 260908 times)

0 Members and 2 Guests are viewing this topic.

silverweed

  • Newbie
  • *
  • Posts: 24
    • View Profile
    • Email
Re: SFML 3 - What is your vision?
« Reply #315 on: September 06, 2017, 08:23:27 pm »
One thing I'd really like to have is the ability to independently set the translation, scale and rotation origin for sf::Transformable. I know I can use sf::Transform directly, but I think a middle-ground solution would be convenient, as the complication of using sf::Transform is barely justified for such a common1 need IMHO.

1 "common" in my experience, of course. Maybe there are far fewer people than I think who ever need this capability.

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 11001
    • View Profile
    • development blog
    • Email
Re: SFML 3 - What is your vision?
« Reply #316 on: September 06, 2017, 08:49:32 pm »
Can you elaborate more on your problem?
sf::Transformable has all the set and get functions for transform, scale and rotation.
Or do you mean, you want to access a transform that has only set the scale or only set the transform?

Personally, I would say if such transforms are needed, then your own custom "layer" might be useful that provides such an interface and generates the various transforms.
I mean SFML itself doesn't hold the transforms separately, so they would need to be calculated anyways.
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Hapax

  • Hero Member
  • *****
  • Posts: 3379
  • My number of posts is shown in hexadecimal.
    • View Profile
    • Links
Re: SFML 3 - What is your vision?
« Reply #317 on: September 06, 2017, 11:08:29 pm »
It sounds like Silverweed would like to be able to use a separate origin for each transformation.
Selba Ward -SFML drawables
Cheese Map -Drawable Layered Tile Map
Kairos -Timing Library
Grambol
 *Hapaxia Links*

Sygmei

  • Newbie
  • *
  • Posts: 22
    • View Profile
Re: SFML 3 - What is your vision?
« Reply #318 on: September 18, 2017, 01:50:12 pm »
I do agree, separate origins would be nice, I needed it and had to create a whole class for it.

Phanoo

  • Full Member
  • ***
  • Posts: 136
    • View Profile
Re: SFML 3 - What is your vision?
« Reply #319 on: September 18, 2017, 04:38:04 pm »
- Automatic batching of draw calls that use the same texture
- More powerful Text class : set line height, letter spacing, align releative to user defined bounds, automatic wrapping...
- Drag & drop support
- Clipboard support
« Last Edit: September 18, 2017, 04:39:57 pm by ratatax »

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: SFML 3 - What is your vision?
« Reply #320 on: September 18, 2017, 10:42:37 pm »
Quote
set line height, letter spacing
Clipboard support
All done (will be released in 2.5). This kind of non-breaking changes don't need to wait for SFML 3, and we can discuss them at any time in the "feature request" sub-forum.

Don't hesitate to have a look at github to be aware of the coming / pending changes.
Laurent Gomila - SFML developer

Phanoo

  • Full Member
  • ***
  • Posts: 136
    • View Profile
Re: SFML 3 - What is your vision?
« Reply #321 on: September 19, 2017, 11:41:08 am »
Very nice ! I think i'll get the development version to start using it.

MetalCoder

  • Newbie
  • *
  • Posts: 31
    • View Profile
Re: SFML 3 - What is your vision?
« Reply #322 on: October 28, 2017, 03:43:53 am »
Will there be a C and .NET port of SFML 3?

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: SFML 3 - What is your vision?
« Reply #323 on: October 28, 2017, 07:44:29 am »
Quote
Will there be a C and .NET port of SFML 3?
If someone writes them, yes.
Laurent Gomila - SFML developer

MorleyDev

  • Full Member
  • ***
  • Posts: 219
  • "It is not enough for code to work."
    • View Profile
    • http://www.morleydev.co.uk/
Re: SFML 3 - What is your vision?
« Reply #324 on: October 29, 2017, 01:45:59 pm »
Not sure if this has been brought up before, probably has, but it occurs to me a current limitation with SFML is that you cannot dynamically swap the underlying rendering platform at runtime. To use Irrlicht as an example, you can create DirectX drivers, OpenGL drivers, and Software Rendering drivers and decide on which one to use at runtime.

If SFML allowed for this, even if it only had one officially supported driver, it would serve to document *how* a person who needs to can modify SFML to support a different rendering platform, which at the moment feels more like going in and 'hacking SFML apart until it works'.

This could aid future efforts for support for new platforms that may not necessarily have any OpenGL access, and would make porting to DirectX, or even back down to older versions of OpenGL, or to Vulkan, or to a chosen version of OpenGL ES easier for people who decide they want to do so for whatever reason.

It would also keep a migration path open for developers if/when SFML moves up to newer OpenGL versions as they come out and settle, allowing for older ones to have official support deprecated without immediately breaking code and requiring a new major release.

Additionally, if SFML was also 'interface-driven' (which fits nicely with the above), then SFML could be easily mocked out when unit testing the graphics code, and that'd also be quite nice. At present you need to write a facade around SFML to accomplish this. Though I admit, not as many people care about unit testing their game rendering code as should darn it :P
« Last Edit: October 29, 2017, 05:55:40 pm by MorleyDev »
UnitTest11 - A unit testing library in C++ written to take advantage of C++11.

All code is guilty until proven innocent, unworthy until tested, and pointless without singular and well-defined purpose.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: SFML 3 - What is your vision?
« Reply #325 on: October 29, 2017, 09:01:01 pm »
I'm not in favor in abstracting the graphics back-end. I don't think it has any practical benefit (except the "technical challenge" and "others do it"), and would make the code less maintainable (any addition has to be implemented in all the back-ends) and less optimizable.

However, I know that other team member(s) have a different opinion on this topic, so who knows ;)
Laurent Gomila - SFML developer

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
Re: SFML 3 - What is your vision?
« Reply #326 on: October 30, 2017, 11:06:02 am »
I don't like it much because I fear that more projects would use DX because it's more known or "all the other AAA games use it so it must be better". Lots of SFML projects aren't cross-platform already because people use platform-specific path separators ('\' vs '/'), Windows-only headers or case-insensitive filenames. With a DX backend, people might be more tempted to use DX-exlusive features.

DeathRay2K

  • Newbie
  • *
  • Posts: 24
    • View Profile
    • Email
Re: SFML 3 - What is your vision?
« Reply #327 on: October 30, 2017, 03:08:34 pm »
I think it would only make SFML more flexible to include a layer of abstraction over the graphics back-end. I don't think it makes sense for that to include developing additional back-ends though. There's no reason there should be an official DirectX back-end, but a developer who knows they need such a thing will have the option to create one and ensure it will integrate relatively easily with SFML.

If someone is using SFML more casually, they will surely use the default OpenGL back-end and have the best chance of developing cross-platform code. Besides, with a common abstraction for all graphics back-ends, there's no opportunity for adding DX-specific features without sidestepping the abstraction or building the feature into it.

A clean abstraction should make the code easier to maintain as well, as long as it doesn't mean developing additional back-ends.

MorleyDev

  • Full Member
  • ***
  • Posts: 219
  • "It is not enough for code to work."
    • View Profile
    • http://www.morleydev.co.uk/
Re: SFML 3 - What is your vision?
« Reply #328 on: October 31, 2017, 12:50:03 am »
Sorry if this wasn't clear, but I wasn't specifically suggesting actually maintaining multiple official backends. The key point was more:
* "If SFML allowed for this, even if it only had one officially supported driver, it would serve to document *how* a person who needs to can modify SFML to support a different rendering platform, which at the moment feels more like going in and 'hacking SFML apart until it works'."

That and the interface-driven point, namely interfaces enabling mocking out of SFML for easier unit testing of code that calls SFML :)
UnitTest11 - A unit testing library in C++ written to take advantage of C++11.

All code is guilty until proven innocent, unworthy until tested, and pointless without singular and well-defined purpose.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: SFML 3 - What is your vision?
« Reply #329 on: October 31, 2017, 07:39:26 am »
It's nearly impossible to design a robust abstraction for graphics rendering with only a single back-end in mind. You have to cope with limitations and design philosophy of all back-ends -- at least the two major ones. This also means that your abstraction, being a common denominator, will be less flexible and optimized, compared to what we do currently with the direct OpenGL integration.

Is there any use of interfaces other than for unit testing?
Laurent Gomila - SFML developer