Messages

1

SFML development / Re: C++ standards

« on: August 28, 2018, 02:38:36 pm »

Here is my current opinion, considering SFML:
Go with C+17.

Aguments:

 - std::filesystem : if SFML relies on it by default (or not use filesystem at all and let the user feed SFML), the codebase would be reduced;
 - std::string_view: There are several (not all) interfaces of SFML that take std::string while std::string_view would be a far better default. Notably the API for passing shader scripts (which imply a lot of copies). I pointed this issue before but the (reasonable) answer was that adding a string-ref type would be another thing to maintain, and there is no SFML dependency providing one. With C++17 std::string_view would do the job.
 - std::any and std::optional might be very helpful in several SFML APIs evolutions.
 - it's completely implemented by major compilers (I think there might be holes that SFML will not use anyway);
 - if the next release of SFML happen around the end of the year or next year, there will be about a year before the following standard is ratified (and a lot of it's stabilized features are already implemented in at least 2 compilers);
 - backward compatibility should be good enough to not force users to change their code (except for changing APIs);
 - it's the simplest way to open the possibility of reducing drastically codebase size (less code, less bugs - most of the time) (I'm htinkin both C++14 and C++17 here);
 - changing the C++ version do not mean that all the code have to be upgraded immediately or ever, but it makes it possible and easy to check;


I was wondering: what are the arguments against going directly to the current standard? It's not really clear from the current discussions.

2

SFML development / Re: SFML Roadmap

« on: August 28, 2018, 02:26:58 pm »

Indeed at least separating them would help.

Using CMake apparently would work with recent versions but I didnt try (last time I used ExternalDependency module it failed quite spectacularly for my use case but it was a very complex use case). I know they made efforts in this direction but it's only available in last version(s).

I think at least separating the dependencies and listing the package names and versions somewhere in the root directory would be a good first step for the future of this project's dependenies management.
I guess I long as it's easy for beginner (one command to get everything), it should be fine.

3

SFML development / Re: SFML Roadmap

« on: August 28, 2018, 12:11:30 pm »

Would it be ok to consider switching to using a dependency management tool for that version?
I'm thinking mainly about solving the issue of having binary dependencies inside the extlibs directory.

4

General discussions / Re: Continuous Integration

« on: December 05, 2015, 11:53:03 pm »

Thanks for the input, it clarify a lot the "flexibility vs simplicity" feedback I got so far.

5

General discussions / Re: Continuous Integration

« on: December 05, 2015, 09:49:31 pm »

I'm interested and curious about knowing what made you choose  Buildbot. I want to setup CI too but have been pondering between Jenkins (apparently easy to setup) and Buildbot (apparently more flexible?).
Was it chosen just because the team was familiar with it or is there some other interesting reasons?

6

General discussions / Re: Android with VS2015

« on: November 07, 2015, 05:30:50 pm »

I'm trying several approaches to the problem and will report if I find a simple and clean way to do it.

7

General discussions / Android with VS2015

« on: November 03, 2015, 07:30:00 pm »

I am considering making a small project this weekend on Android and SFML and I would ideally use VS2015 but I am not familiar with the Android toolchain for SFML.

I was wondering if someone already tried to build and run SFML with a VS2015 android project?

I am considering several approaches but they all look like dirty hacks for now. Or maybe I missed a simple way to doit.

8

General discussions / Re: Why do so many game take so much space?

« on: September 27, 2015, 03:53:42 pm »

Well, first Elite was less than 48Kb. =)

Well Elite games didn't take much space because of their massive use of procedural content, and they didn't take much in ram because the generated content was not as detailed as something you will display on hd monitors today, so yeah.

9

General / Re: Can't place variables outside function

« on: September 22, 2015, 12:17:43 am »

Nexus is correct for C++03 and before. However if you use C++11 (needs a flag on gcc and clang, automatic in Visual Studio 2015), restrictions have been lifted and this code is valid:
http://coliru.stacked-crooked.com/a/96f4c2a789640d65

I don't remember all the rules but I know that:

 1. It does not work the way you wrote it, it's forbidden to use directlyt he constructor through () with member initialization;
 2. You can use {} for member initialization (see previous link);
 3. You can use operator= if the type allows it, but it's better only when you deduce the value from a function. Here is a "bad" example : http://coliru.stacked-crooked.com/a/5bbb9f01e75951c2

10

SFML development / Re: API deprecation model

« on: September 19, 2015, 04:35:13 pm »

Concerning runtime warnings/logs: that's definitely something to consider. I think it should be part of our overall log/error output redesign.

Cool! Is there a specific thread where you are discussing/anouncing this? I searched with these words but didn't find anything recent. I don't follow much these forums but I'm interested in the rationals for these kinds of "looks simple but actually hard" topics.

11

Feature requests / Re: Facility to get standard paths

« on: September 19, 2015, 03:32:30 am »

I think the question which needs to be sorted out first is: should we just provide those paths (either as objects, variables or getter functions), without bothering to check if they actually exist on the machine SFML is installed on, or should we also ensure the paths we retreive from the API are always valid?

Since we don't want to turn SFML into another filesystem library, I'd say just provide the paths.

By the way, the unicode mess on Windows might be a major issue for providing any kind of path using just std::string. The basic issue is that if the path have unicode characters, they are provided by the Windows API as either UTF-16 in wide chars, or as ANSI something in chars with non-ansi characters replaced by '?'.
Therefore, you need to use the UTF-16 way on Windows to get something useful, then you need to decide what is the encoding of your output std::string, then convert from one to the other.
The solution boost::filesystem took is to keep the internal representation of the system (UTF-16 on windows) to avoid conversions as much as possible, but then if you as a string from it it will do a dumb conversion OR use a codecvt you provide, which migth do the right thing (or not). Unfortunately there is a strange behaviour where no conversion happen if the type used for storage (char/wchar_t) is same between the two encodings (which mean that a linux OS which is not UTF-8 might have no conversion, or I'm wrong, which might be possible for these kinds of details which I couldn't manage to properly check so far).
In my dayjob I had to work on these kind of issues recently. We chose that any std::string in the API is expected to be UTF-8. We have a path type which currently uses boost:::filesystem::path inside (it's open source by the way but I wouldn't call it a perfect example), then do the conversion when you need a string (so UTF-8) depending on the plateform we are on, so that whatever the boost representation, we always end up with UTF-8.

I don't know what is the policy of SFML regarding encoding of API-provided strings, but if there is none, providing a system paths api will requires that.

12

General discussions / Re: Fundraiser for a Mac mini

« on: September 19, 2015, 03:20:10 am »

800.74 € out of 800.00 €

Oh wow, that was fast!

There is far more interest in SFML than I expected, even if I like it more than most alternatives.
I'm impressed, good job!

13

SFML development / Re: API deprecation model

« on: September 19, 2015, 03:18:10 am »

[[deprecated]] and other non-standard C++ compiler-specific intrinsics can be used as an implementation detail of a deprecated-function-marking macro. IMMIC they are all compatible in that you can use them in the same places in code.

Just some input from how we do it in my dayjob (humanoid robot APIs, which have the same kind of issues because interface evolve a lot but most interfaces need to be usable for a long time):

 1. Compile Time: we have a macro using whatever the compiler have available to trigger warning to users of functions and types we mark with that macro. It indeed works well at compile time IF you manage to not have any other warnings on all your supported plateform. We use Boost so we get often tons of warning on some plateforms so it works but we have to patch Boost each time we upgrade it. I don't think SFML would have this kind of problem.

 2. Runtime: we have a logging system and we add a log at "warning" level each in the implementation of each function we mark as deprecated. It helps in our case because we have some magic making our API available through RPC calls automatically, so most APIs are actually messages between processes and when APIs evolve, your client code should still work after at least one iteration of the API. Which basically mean that users might not compile your API code and just do RPC calls so the only way for them to know (in this case) that they are calling a deprecated API is at runtime.
   The obvious side effect is that logging happen even in previously very fast API functions, though it's not yet an issue for us, at least not for deprecated APIs as we are not yet reaching the point where we will need to have tighter performance (it's not one application, its tons of them, so it's almost impossible to try to improve performance on a case by case, we mostly do performance optimization in inter-process and multithreading systems).
   The other issue is that it relies on the fact that the user will use our logging system, which he will in our very specific case but can't work with SFML I believe. I don't know what would work in the case of SFML for this.

14

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

« on: September 09, 2015, 10:53:51 pm »

Generally speaking for the std::string approach (instead of the C approach), but mostly for the "do we have a proof of performance boost with a more complex code?".

Same here, that's why I was asking more experienced shader users if they actually do call these kind of apis in critical loops.

I think the overload solution might work well indeed. The standard committee voted string_view in the coming standard to help library implementor later, but as already discussed it's not available here.

I didn't know the values were stored in a map... I though the values were only sent to opengl.

15

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

« on: August 30, 2015, 01:12:49 am »

My thoughts about Klaim's suggestion:

• The arguments are string literals in more than 99% of the cases, so const char* would suffice.
  
• const char* would indicate that the user is expected to pass string literals -- a good or bad thing?

Is it a convention specific to SFML? Otherwise as a user seeing const char* (after finding why it's not a std::string), I would just suspect the implementation to either read or copy the content of the string and not expect the lifetime of the passed string to be required to live longer than the call (except documented otherwise but even standard exception message are like that). Also, this forces null-terminated strings which is not the case with std::string and string_view/ref which are "ranges" that can contain several null characters.
The passed pointer could be a litteral or something coming from a big text buffer, it wouldn't make a difference (as long as it's null terminated). I'm guessing that part of what is reasonable depends on the opengl api too.
All these points should be considered I guess.

To clarify: I don't tend to consider const char* to ask specifically for sttring litterals so I'm not sure if that's how such an API will be considered by other users.

• The allocation is probably negligible compared to the OpenGL calls. This may change when SFML batches uniforms one day, instead of passing them to OpenGL immediately.

Interesting.

• It's slightly less convenient for a few cases when std::string is not supported (additional .c_str() call).

Yeah, this can make the user code noisy if the user decided to store the names in strings. It's related to your string litteral question I guess.

• string_view/string_ref is no option because it's not standard, and it's not SFML's task to rewrite them.
  

About that, I was thinking that there are a lot of precedents for alternative (often simpler to understand for newbies) types not present initially in the standard but provided early by SFML, like time related types and thread stuffs (though the doc clarify that you might want to use the standard if you can). So I'm not sure if having a very simple implementation wouldn't be ok, though you have to take the decision of course :) (or maybe experience maintaining SFML shows that it's not a good idea already).
Boost, chromium/google, llvm/clang, and some other libraries each have their own version which is why it was proposed and quickly accepted in the coming standard (they didn't have the same interface though), and all these implementations seem very simple. So maybe it's easy to provide.
But yeah maintenance might be problematic in the future. Maybe it should not be considered.

• API consistency: SFML uses mostly std::string or sf::String in its API.
  
• When we start with const char*, we can still switch to std::string later without breaking the API. It would however introduce an additional allocation in the cases where std::string was used.
  
• This current redesign of the uniform methods is an opportunity to change things like that. It cannot be done again until the advent of SFML 3.

OK nice