Messages

1

Feature requests / Re: Add Compute Shaders Support

« on: July 29, 2016, 02:15:32 pm »

First - For helping I need to see a point of application.

You can contribute at any time.

One can contribute at any time, but given that there are 34 open pull-requests, most of them "undecided" and quite old already indicates that the chances to get such contributions into SFML soon are quite low.

2

Feature requests / Re: Optimize memory layout of SFML classes

« on: April 23, 2016, 08:57:24 pm »

I have pushed this optimization to my fork now: https://github.com/PKEuS/SFML/commit/2a2e4e73cc04e53ccd27ebaeecd02472320ad5a8

Feel free to cherry-pick this commit (btw., there are some other commits on my fork that might be of interest for you, too).

3

Feature requests / Optimize memory layout of SFML classes

« on: April 17, 2016, 10:23:31 pm »

There are several classes in SFML with a non-optimal memory layout, for example sf::Transformable or sf::RenderTarget::StatesCache. If in sf::Transformable members are reordered such that the boolean variables are next to each other, 4 Bytes can be saved (MSVC14, but there will be a size reduction with virtually every available compiler, although the size might vary). The reason is, that for optimization purposes compilers align class members, so that padding bytes are required between members of different size. The amount of padding bytes cannot be optimized automatically, since the compiler must place the members in memory in the same order as they are declared. What do you think about implementing this?

4

General discussions / Re: Deprecated functions

« on: January 14, 2016, 03:15:40 pm »

Ok, SFML_NO_DEPRECATED_WARNINGS provides a way to get rid of the warnings. Good to know.

However, I still think that at the moment the code gets worse if setFillColor is used. It stops to work with SFML 2.0, 2.1, 2.2 and 2.3 for no reason (as long as no feature introduced in next SFML version is used).

it also is not breaking the API

It is breaking the API for projects that use /sdl or something like -Werror.

5

General discussions / Deprecated functions

« on: January 14, 2016, 02:19:14 pm »

Since this commit, SFML started to make use of the SFML_DEPRECATED feature:
https://github.com/SFML/SFML/commit/957cabb816f69a3d7a3909d24b9e773ffc9a65b5

In my opinion, this is a bad idea for two reasons:
- Since the new methods are not available, using the new function setFillColor means breaking compatibility with older SFML versions - even if the new feature outlined text is not used. In general, I think it is a bad idea to mark an old function as deprecated immediately after an alternative was introduced.
- The implementation of SFML_DEPRECATED causes MSVC to issue warnings that turn into compilation errors if /sdl is enabled. This is not what I would call API compatibility, so, the policy until now, that minor releases are backward compatible would be dropped.

Hence, I would recommend to wait a few releases until using SFML_DEPRECATED for sf::Text::setColor().

6

General discussions / Re: A new logo for SFML

« on: April 27, 2013, 10:16:26 am »

Putting the logo on the other side of "SFML" might also be worth considering, since it could move closer to "SFML", because of the space the 'L' provides (in contrast to 'S').

7

General discussions / New graphics API ready

« on: December 05, 2011, 04:53:22 pm »

Will the change have an impact on the performance of existing (thus using the old interface) code?

8

General discussions / [IDEA] Move sf::Rect into System Module?

« on: August 22, 2011, 05:36:18 pm »

I think, sf::Rect is similar to sf::Vector2 and sf::Vector3, which belong to sfml-system. They are all classes which can not be rendered and consist of numbers to be used for calculations. Thus I agree to coolhome and Walker that it should be moved to sfml-system. If you think, sf::Rect should be in sfml-graphics, then sf::Vector2/3 should be in sfml-graphics as well.

9

General discussions / A new logo for SFML

« on: June 05, 2011, 09:40:15 am »

I like the current SFML logo. It is simple, but looks good and has meaningful symbols

+1. Why not just keep the old logo?

10

General / GetDefaultFont causes crash on exit

« on: May 01, 2011, 06:38:26 pm »

I thought, it was fixed since SFML 1, and I have not noticed it for a long time...

11

General / GetDefaultFont causes crash on exit

« on: May 01, 2011, 05:12:17 pm »

Using a Radeon HD 4850 on Windows 7 I get the same issue.

Visual Studio says, the crash happens in GlContext.cpp in function GlContext::Cleanup, first line. It seems like the pointer sharedContext is invalid but not zero.

12

General discussions / Github repository

« on: April 02, 2011, 09:29:46 am »

I have found out something that may be interesting for everyone who can not / does not want to install TortoiseGit on Windows: You can access the Github repository also with SVN.
URL: http://svn.github.com/LaurentGomila/SFML

13

General / SFML won't run with updated ATI drivers

« on: March 15, 2011, 07:51:34 pm »

You can try to statically link SFML.

As far as I remember, the last working ATI drivers are 10.8.

The last working driver is hotfix driver 10.10e

14

General / SFML won't run in Windows 7 64-bit

« on: January 08, 2011, 12:10:00 am »

Do you have Catalyst 10.12 or 10.11 installed? This drivers are incompatible to SFML. Switch back to 10.10e.

15

General / C++ Type conversion

« on: January 03, 2011, 11:14:37 pm »

int(var) is an initialization and creates a new integer object. Its no cast. If you can cast, its probably faster. (Ok, for an integer it makes most likely no difference)
(int)var is a cast (C style). The same as static_cast<int>(var) (C++ style) which is in my opinion the nicer syntax.