Messages

16

General discussions / Re: Shader uniform API -- part II

« on: August 29, 2015, 02:38:53 pm »

If you have a const char* originally and pass it to this function, a std::string is constructed to match the const reference std::string required, then it is destroyed. Depending on the size of the string content and the STL implementation, you do pay more than if you just wanted the function to read your original const char* (in particular if the small-buffer-optimization can't be used, the string will allocate and deallocate, which you want to avoid most of the time in a critical loop).

If you're using std::string instead of char* to begin with, this would avoid this scenario. 

Of course. I said so in the later paragraph. If you look at the example too, there is a common case where you think you use std::string but you don't

Anyway I don't have enough experience with shader to know if it there will be performance concerns here. It just feel to me that the values will be passed often (once per frame?) and if someone do

    setUniformFloat( "my_value_have_a_long_name", 42.0f );

each frame, they are paying something each frame which they might think is not a lot. To escape this issue one would make sure to store these names in exactly const std::string (not a sfml::String nor any other type to avoid the copy construction).

Also, even if you use static const std::string for fixed names, you also pay the cost of std::string for a compile-time value. So you still pay for something (allocation). And if your string values are stored in a big string buffer, then you have to build std::strings for that.
It really depend on what kidn of code this is about of course, so it might not be important here, I'm not sure, but so far I thought this kind of api was called a lot.

Though again it's a minor concern for now I guess?

17

General discussions / Re: Shader uniform API -- part II

« on: August 29, 2015, 01:44:12 pm »

SFML is a C++ library and while const char* vs std::string is personal preference I believe that std::string is considered the prefered choice of the two.

I know I know, all of that, of course.   

I participate to the C++ community so I'm not for const char *. I'm pointing a potential performance issue which is very well known in the community. The usual solution is to have something like std::string_view (not in the standard yet but voted in the coming one) (or boost string_ref ) etc. which avoid a potential std::string construction in some hidden cases which are legion string-manipulation code.

That's a minor issue of course and could be fixed later if performance shows.

The overloads that a const std::string& (Reference) instead of a copy if thats what you mean by allocations.

If you have a const char* originally and pass it to this function, a std::string is constructed to match the const reference std::string required, then it is destroyed. Depending on the size of the string content and the STL implementation, you do pay more than if you just wanted the function to read your original const char* (in particular if the small-buffer-optimization can't be used, the string will allocate and deallocate, which you want to avoid most of the time in a critical loop).
That's the usual performance concern with this kind of interface. (again not deadly important here, I don't mind a lot, just pointing the thing)

The std::string_view (again not yet in the standard but a variant is available for example in boost) would take a const char* or a std::string and never ever allocate anything in the background and work like a const refrence without the need to make implicit conversions.

On the other hand, SFML comes with its own string implementation named sf::String which is of course non-standard.

I didn't consider this but I don't think that solves anything.

Anyway I don't have enough experience with shader to know if it there will be performance concerns here. It just feel to me that the values will be passed often (once per frame?) and if someone do

    setUniformFloat( "my_value_have_a_long_name", 42.0f );

each frame, they are paying something each frame which they might think is not a lot. To escape this issue one would make sure to store these names in exactly const std::string (not a sfml::String nor any other type to avoid the copy construction).

I don't see any class that looks like a string_ref/_view in the SFML api so right now I guess it's not important and maybe later if such tool is provided then an optimization pass would be done on the API (with 100%compatibility I believe).

18

General discussions / Re: Shader uniform API -- part II

« on: August 29, 2015, 12:15:16 am »

At the moment, the current incomplete API looks as follows:

void setUniformFloat(const std::string& name, float x);
void setUniformVec2(const std::string& name, const Vec2& vector);
void setUniformVec3(const std::string& name, const Vec3& vector);
void setUniformVec4(const std::string& name, const Vec4& vector);
void setUniformVec4(const std::string& name, const Color& color);

void setUniformInt(const std::string& name, int x);
void setUniformIvec2(const std::string& name, const Ivec2& vector);
void setUniformIvec3(const std::string& name, const Ivec3& vector);
void setUniformIvec4(const std::string& name, const Ivec4& vector);

void setUniformBool(const std::string& name, bool x);
void setUniformBvec2(const std::string& name, const Bvec2& vector);
void setUniformBvec3(const std::string& name, const Bvec3& vector);
void setUniformBvec4(const std::string& name, const Bvec4& vector);

void setUniformMat3(const std::string& name, const float* pointer);
void setUniformMat3(const std::string& name, const Mat3& matrix);
void setUniformMat4(const std::string& name, const float* pointer);
void setUniformMat4(const std::string& name, const Mat4& matrix);
void setUniformMat4(const std::string& name, const sf::Transform& transform);

void setUniformFloatArray(const std::string& name, const float* valueArray, std::size_t length);
void setUniformVec2Array(const std::string& name, const Vector2f* vectorArray, std::size_t length);
void setUniformVec3Array(const std::string& name, const Vector3f* vectorArray, std::size_t length);
void setUniformVec4Array(const std::string& name, const Vec4* vectorArray, std::size_t length);
void setUniformMat3Array(const std::string& name, const Mat3* matrixArray, std::size_t length);
void setUniformMat4Array(const std::string& name, const Mat4* matrixArray, std::size_t length);

void setUniformSampler2D(const std::string& name, const Texture& texture);
void setUniformSampler2D(const std::string& name, CurrentTextureType);

Do you really need to use std::strings? or would it be ok to use const char* or something like string_ref/string_view (from other libraries - does sfml have something like that already?)? I'm fine with strings of course, but it looks like there might be a lot of allocations potentially going on just for some reading code.

19

General discussions / Re: Building SFML for Visual Studio 2015

« on: July 24, 2015, 08:03:06 pm »

Last time I compiled SFML with VS2015, the only issue was that the dependencies binaries (which are in the repository???) are built with another compiler, so link errors.

20

General discussions / Re: Why use SFML over SDL?

« on: July 20, 2015, 12:04:40 am »

As a game (among other things) developer, the main reason to use SDL over SFML are:

 1. A lot of money/efforts is put into it's development (Valve in particular);
 2. It's apparently VERY portable (like, it is apparently easily ported to consoles);
 3. It's tested and used and fixed a lot more and faster than SFML;

I remember also Laurent (maybe in pm) pointing that for serious development that needs stability, SDL is definitely less of a risk and should be the default choice. I agree with this pragmatic thinking, though I would use SFML for anything where I'm ok with the risks, just because it's far better to code with SFML than SDL.

I don't like the issues related to raw C usage so I avoid SDL as much as I can but recently I decided to replace my input library in my commercial game with SDL (the transition is not done yet though). I would have chosen SFML by default if I didn't need very long term support for that one.

21

General discussions / Re: SFML 2.3 Visual Studio 2015 Binaries

« on: June 30, 2015, 11:57:08 pm »

Wait, scratch that, the debug binaries are in the zip, only the 64bit version is missing. Sorry about that 

22

General discussions / Re: SFML 2.3 Visual Studio 2015 Binaries

« on: June 30, 2015, 11:41:17 pm »

Hi, this is helpful thanks.

Could you also provide:

 - a debug version?
 - 64bit version?

I was playing with this but with only 32bit release I'm a bit limited in usage.

23

General discussions / Re: Incredible performace of Lua (luajit) over C++

« on: May 29, 2015, 10:24:43 pm »

Well if fraps tells you that you got low fps, it's certainly that there is a problem with your gpu-side work. In particular when you're doing nothing else than display.
Which means it have nothing to do with C++ or lua....

24

General discussions / Re: Here is an open source dynamic Queue I wrote for anyone who is interested

« on: May 24, 2015, 12:09:43 pm »

std::queue is a thin wrapper over a container and unfortunately it is not useful as a queue most of the time.
std::deque works but have specific performance characteristics which might not fit your use case (aka: it's not a vector inside). Also it's not a circular buffer, you would still have to augment it's behaviour by wrapping it.

Other than boost, there was some proposal to add actually useful (non-concurrent) queue types in the C++ standard in the last year, but I don't remember if it was well received or not.

25

General discussions / Re: 50% Discount on SFML e-books!

« on: May 05, 2015, 07:15:21 pm »

By the way, was the book updated since it's first publication? Maybe the pdf version?

26

Feature requests / Re: Facility to load dynamic libraries

« on: February 01, 2015, 01:27:43 am »

Indeed! I think that's a good candidate for a very simple RAII object.

The only part that might be difficult to make simple is to provide a way to demangle symbols, like the BOOST_DLL_AUTO_ALIAS, otherwise it makes interfacing with C++ functions very hard for cross-platform code (because of different mangled names depending on compilers).
Or you could just forget it and let users use only C interfaces, at least for a start (that's what Boost.SharedObject from CPPCMS does, I believe).

Boost.DLL doesn't offer much more than these features either (except maybe the function to list available dlls). The author made sure it's very customizable to match all cases, including very advanced usage. Of course I agree that SFML need to go that far.

27

Feature requests / Re: Facility to load dynamic libraries

« on: January 31, 2015, 05:45:52 pm »

Something with of a similar limited scope but SFML-like interface than Boost.DLL (currently proposed for inclusion in boost but not yet officially reviewed) would be useful indeed even for simple applications or games (I never developped a pc game not needing dynamically loading dlls, but I might be doing strange stuffs).

So maybe Boost.DLL will gives ideas or at least some data to think with: http://apolukhin.github.io/Boost.DLL/index.html

There was also Boost.SharedObject and a few other proposals.
See this discussion: http://boost.2283326.n4.nabble.com/Checking-interest-in-DynamicLoad-DLL-DSO-Plugin-library-td4666378.html
EDIT: Also this one: http://boost.2283326.n4.nabble.com/Boost-DLL-Formal-Review-request-td4668079.html

I like the lasts Boost.DLL versions but it is based on shared_ptr and I'm not sure if it would be a good design for SFML. I suspect Laurent to prefer a specific type with simple ownership semantic to represent a loaded module (even if it's a shared_ptr inside).

28

General discussions / Re: Future release of SFML 2.2 (feedback needed)

« on: April 04, 2014, 08:34:21 pm »

I just noticed this thread and it's really good timing because:

 1. I would like to replace my OOIS code by either SDL or SFML;
 2. Ogre3D people are considering switching to SDL or SFML too (instead of OIS and custom windowing code), but SDL is maintained by people at Valve so it looks like a safer long-term bet, while SFML is far nicer on composability and simpler code. In the end, an experiment using SDL is going on and I think have been merged. The discussion is there: http://ogre3d.org/forums/viewtopic.php?f=4&t=79237
 3. The STL mail is good feedback too.

Basically, SFML is a very close challenger to SDL when it's used as basic layer for the windowing and input system, and that's a good thing but it's not yet the best long-term choice.
I prefer SFML personally, and I target only desktop in my current game so I'm almost sure I'll use it instead of SDL, but frankly on the long term it seems that SDL is always a best bet (until Valve people or other people related to game dev are starting to contribute).

Now, the important additional feedback that you can get from Ogre:
If the windowing system could be separated from the input system (maybe in an optional way?), it would allow a better composability, for example when you want the graphic rendering system to use a specific windowing system, and a very different input api, all sharing the same window handle from the windowing system.
Also, lack of force feedback info in the input.

29

General discussions / Re: Anyone interested in collaboration

« on: October 01, 2013, 06:12:48 pm »

Then I suggest you avoid calling yourself intermediate C++ coder until you understand more about what would be expected from one. I'm not saying this to lower your current level, I think you're on a good way to be an expert, but you're not there yet and anyone saying he's expert C++ coder is very suspicious, and anyone saying he's intermediate without being comfortable (or having a sane fear) of pointer would be decredibelised.

With that said, I hope you find a collaborator, I think if you know what you don't know that's a good sign and also you want to make something rather simple but not as simple as a beginner would expect, so it's cool.

30

General discussions / Re: C++ ISO Standard Committee 2D Graphics Library Discussions

« on: September 27, 2013, 12:48:39 pm »

C++ will not have a big library as Java does

My main fear about the current acceleration of the development of C++ standard is that, in a "few" years we have a good core language but a huge s(t)l with a lot of deprecated features – that's how I see Java: a relatively good language with a crippling library... I hope this fear is unfounded.

[/quote]
They are aware of the potential problem but I'm not sure if they are looking for a solution to easily change versions in the future or if they just want to rely on genericity.

But it's clear that the design task won't be easy: how do you create a nice abstract API for completely different backend (OGL/DX/...)? Also the specific goals of the API is not yet clearly identify.

The goal is not to provide low level graphic api, but high level. It's not to provide OGL/DX kind of API, but SFML/Cinder/OpenFrameworks kind of API.
So it's not a problem what the backend is. The problem is mainly to decide what features are both generic and useful to draw things on the screen.