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

Pages: 1 2 3 [4] 5 6 7
46
SFML development / Re: Clipboard Support
« on: April 07, 2017, 05:53:52 pm »
A lot of things "wouldn't hurt", this doesn't prevent us from trying to be relevant. And I don't think a full example for demonstrating how to use "setString / getString" is relevant beyond the documentation.
+1

A minimal, compilable example of the implemented feature in a PR thread is really beneficial for testing, so people with different systems can easily check for the correctness of the implementation. Once tested though, for what is essentially a two function API, a simple mention in the docs is all that's needed.

47
I won't spend any time on this then (delivering features is everything, right? Can't let myself procrastinate on this :D ). I hope you guys will be able to provide the official VS 2017 builds ASAP. Good luck!  ;D

48
so this is incorrect ?

The VS2015 libs should be compatible with VS2017. ...

Well, before we've all switched to VS 2017, we had a problem building and running our private SFML project half of us using VS 2015 and the other one 2017. I don't remember the issue though. I think I concluded the problem must have been caused by different compiler versions and just made everyone switch to VS 2017 :D

No one has reported the old issue since. Shall I investigate this further?

49
No.
As of now, there is no VS2017 build on the download page. Building SFML by oneself w/ VS 2017 is necessary, if one wants to use VS2017.

// EDIT: That being said, I have found my own unofficial SFML build I am currently using. The version is 2.4.2, but I am not sure if it's an official release, or a couple weeks old "nightly build". Anyway, I hope it's going to be helpful.
https://rbfi.io/dl.php?key=/mnWr/SFML-64bit-Debug-VS2017.zip

50
General discussions / Re: IOS support?
« on: March 25, 2017, 09:54:10 am »
Understandably. However, the iOS support is not present not because SFML team doesn't want to support it, but because of much more pragmatic reason - there's no one to do it. SFML is an open-source project though, so free feel to help it out there, if you will.

51
General discussions / Re: IOS support?
« on: March 19, 2017, 09:42:45 pm »
There's currently no one on the team who would take care of the iOS support and development. The former one quit some time ago.

52
SFML development / Re: Suggestions
« on: March 16, 2017, 11:03:15 pm »
Oh, so it made it to being a proposal. Thank you for the info, binary1248.

53
SFML development / Re: Suggestions
« on: March 16, 2017, 09:45:49 pm »
WTH? upcoming c++ 2D library?
Last time I checked, it wasn't even an actual proposal, just a blog post of some guy, trying to make it to the proposal stage. The whole idea was so ridiculous I told myself that that it was surely not going to make it. Are we talking about the same thing?

Just to clarify, I don't mind that guy, nor the implementation. I don't like the idea. Graphics should not be standardized, should not be a part of standard library, not of a general language like C++. There are simply so many systems to support that are so different that a graphics standardization is completely useless here.

54
SFML development / Re: Suggestions
« on: March 14, 2017, 08:57:53 pm »
Vector graphics is godsend when you're dealing with multiple screen resolutions. That's why the web is moving away from raster where it can, especially when dealing with complicated GUIs.

But you are right that it will probably never be the most popular feature and it comes at price of dealing with additional dependencies.

That's why I said it was just a shot in the wild :)

55
SFML development / Re: Suggestions
« on: March 14, 2017, 07:30:31 pm »
Maybe this is a bit wild one, but what about a native vector graphics support (maybe using OpenVG)?
It has already been asked about here and here.

I for sure would be interested in this feature, but I have never actually got around to creating an extension for vector graphics support for SFML. Someone did though.

56
SFML development / Re: SFML concurrency vs C++ standard
« on: March 13, 2017, 09:27:00 pm »
I think that in this case the Facade API by SFML doesn't bring any simplification to the client code and should not be kept in the library, as opposed to the aforementioned std::chrono vs sf::Clock/sf::Time.

57
By "orthogonal" I meant "with no side-effects". Maybe it wasn't the best usage of this word though.

It wouldn't  bee to hard to change it so that every light could independently choose how to illuminate the region around it.
If it's a dedicated lighting library, I would surely allow for writing one's own shaders for lights, maybe with some basic defaults. It would be surely for the best, considering how many blending modes are actually being commonly used.

I guess what throws me off with the additive one is that it doesn't seem to brighten the scenery. It sort of slaps a translucent sheet on top of it.  The multiplicative one amplifies scenery colors (if I move the lights into a darker area, they are much less apparent, since there isn't anything to actually make brighter, which isn't the case for the additive one).
Indeed, that's how addition works. If you take a look at the link I have posted above, maybe you're actually after a different blending mode, like screen, or gamma_bright. If I were you I would try out all of them, just for the sake of it :D

58
General / Re: Static linking problem
« on: March 11, 2017, 12:34:43 pm »
This means that you point to a wrong folder, or that VS has no access to it. Check it.

Also, what compiler and linking chain do you use? The MSVC one, or CMake?

59
General / Re: Static linking problem
« on: March 11, 2017, 10:48:53 am »
Quote from: SFML downloads
The compiler versions have to match 100%!

which basically means that you need to compile SFML on your own. thankfully, with VS 2017 it's easy these days.
  • Just download the source code, open the folder in VS2017
  • in the menu hit CMake->Generate cache (if it's not done automatically)
  • Then right click on CMakeLists.txt -> Build -> All
  • Check what is the folder where it has compiled and then just point VS with your own project opened to the right folder.
  • Tadah, enjoy!
BTW, While we're at it, make sure that if you compile SFML for 32-bit, that you compile your project for 32-bit as well. The same goes for Debug/Release versions.

60
Well, the multiplicative method creates scenes with greater contrast, but it's not "orthogonal", if you know what I mean. It creates this mist-like/grungy-like effect, which looks great in your example, but indeed, it may not always be how one wants to use the lighting system. In this regard, the additive method is much less opinionated.

Still, I don't think you should just throw away the multiplication method, because it looks freaking awesome. I am not too much skilled in this area, but maybe there's a way to preserve both methods, letting the user choose the one that looks better in their case?

Pages: 1 2 3 [4] 5 6 7
anything