Messages

1

Feature requests / SFML 2.0 -> SetPointColor(...)

« on: February 27, 2012, 10:34:21 am »

Very nice reply with the source code, Laurent. Might I suggest using this as example code in the wiki (is there a wiki?), perhaps an "making custom shape classes" article or something similar? I predict this question will arise quite a few times more.

2

SFML projects / TGUI: a c++ GUI for SFML

« on: February 13, 2012, 11:43:12 am »

Checked it out and it looks very nice indeed. I would change the TGUI namespace to lowercase to conform with SFML's (sf::), also it is increasingly becoming the standard convention.

There really isn't much to add, it seems a well designed and easy to use GUI framework and I will definitely test it on!

Could you tell us a bit about your design philosophy and the main differences compared to SFGUI?

:thumbsup:

3

General discussions / Possible SFML Optimisations as Suggested by Profiling

« on: January 30, 2012, 12:12:32 am »

"No more invitation to inline the construction inside the Draw call directly. The new API screams to create the shapes as real entities, and to update / use them instead of creating new ones every time"

That's good to hear and may help new code to avoid some inefficiencies.

Also a nice little reminder for myself that the design of an API can cause inefficiencies or efficiencies not in the way it is works per se, but in how it invites to be employed by the client.

4

General discussions / Possible SFML Optimisations as Suggested by Profiling

« on: January 29, 2012, 10:23:27 pm »

Sure, I understand that the old API might seems like a suboptimal aspect to base suggestions for optimisations on. However, I brought it up for two primary reasons:

1) I assume that you've reused substantial amounts of the old system in the new architecture. Also, the creation expense would come from SFML-side calculations or initialisation, or from creating OGL resources, and these things should still be similar and incur a comparable cost.

2) The new API seems to present a similar usage affordance (how the code and classes suggests/invites to be used). The old static construction methods screamed to be inlined inside Draw() calls, which is why such a hefty cost from that was surprising to me. Therefore, there is a strong likelihood that the new API will be used in a similar way with the same overhead, and which is why it might still be a good place to consider for optimisations and documentation notes.

As for the main focus of SFML bottleneck being sprite rendering, in my use case that wasn't so: only about 1% time was spent actually rendering. However, our game only uses hundreds of sprites on-screen on any single time and I realise that for thousands-of-sprites games and with dense particle systems things will of course be different.

I will upgrade to the stable SFML2 when it is released and will of course post profiling results here if you're interested.

5

General discussions / Possible SFML Optimisations as Suggested by Profiling

« on: January 29, 2012, 06:56:15 pm »

Since Laurent mentioned in another thread that he was interested in suggestions for possible speed optimisations of the framework I thought we could collect our findings from profiling in this thread.

----------------------------------

Yesterday I profiled our 100+ kloc SFML project using Sample Profiling under VS2010. We have not yet performed instrumental profiling, but will soon. Note that we use the build of SFML2 before the new shapes API were put in. The results were slightly surprising to me.

The #1 bottleneck for SFML performance in our application  was the creation of sf::Shape. Previously, for every frame and for every tile I had several sf::Shape::Rectangle created. I also had numerous sf::Shape::Line created in a loop for a grid drawn to the background. The profiling indicated that actual rendering represented a relatively minute portion of processing time (less than one percent) while creating (and to a lesser extent deallocating) sf::Shapes assumed a whopping 10%. I fixed this by buffering and reusing shapes and sharing them between all possible instances. However, because of the expense, this might be a place where SFML itself could try to optimise costs, f.i. by using pools or internally delaying destruction and reusing objects rather than reconstructing and deallocating them. How this would integrate with the new shape API I don't know, but if nothing else perhaps a note about possible expenses could be added to the documentation.

Other bottlenecks were due to client code. I will return with more findings when I've analysed an instrumentation profiling later.

6

General discussions / Image Detection

« on: January 24, 2012, 03:08:06 pm »

If you're asking about automatic pattern recognition you should know that this is an NP-difficult problem and an active academic topic. This journal has .PDF articles on the topic:
http://www.jprr.org/index.php/jprr

It is a very complex problem and you will not get the answer in this forum.

7

General discussions / SFML 2.0 vector of drawable

« on: January 23, 2012, 10:00:22 pm »

The two standard names for objects of this type (a graphical object that combines high-level facilities and act as a virtual base for subclasses) are Glyph and Body. I think there is already a sf::Glyph used for text drawing (and that name is also a bit abstract, specialised, overloaded and potentially confusing for some users) but Body might work. A very precise name would be Pictograph or Pictogram, which meaning in computers is "A symbol which is a picture that represents an object or concept". Otherwise GraphicsBody or GraphicsBase would be less academic or technical terms.

Anyway, even if there is no such intermediary class in SFML it could be achieved through a proxy/adapter class that uses templates and virtual dispatch to handle the concrete instances uniformly.

8

General discussions / New naming convention

« on: January 23, 2012, 06:14:14 pm »

Well, if I can wish: proper and Standard (i.e British) spelling; f.i. Colour (correct) as opposed to Color (incorrect).

Well, if I can wish: proper and standard (i.e. American) spelling; f.i. color (correct) as opposed to colour (incorrect).  :twisted:

There is no such thing as "American English" (it is a colloquialism--or vulgarism depending on your degree of lenience--albeit a ubiquitous one), but there is an US American dialect of English. Admittedly, there is no official "Standard English", but the expression is universally (well, worldwide, at least) accepted as referring to the modern British usage, which just because of that isn't called a "dialect", or at least the "root dialect" of its derivatives.

Unfortunately, you already have your wish, since SFML is using US spelling atm (why I have no idea since Laurent is French, and they learn British spelling in schools, iirc), so it was rather a dull request.

That said, if you want to I will happily concede to the expression "Abominable English" for the US bastardisation of the source language.

Enough banter; have fun flaming this post, any Yanks that feel indignation or slighted.

9

General discussions / New naming convention

« on: January 23, 2012, 11:56:12 am »

So what else do people want?

Well, if I can wish: proper and Standard (i.e British) spelling; f.i. Colour (correct) as opposed to Color (incorrect).

10

General discussions / New naming convention

« on: January 23, 2012, 12:46:48 am »

@Groovy,
There is no half consistency. Like you said, there will be for example no consistency in the naming of classes.

And you only rarely use the standard library? std::vector? std::string? iostreams? std::unique_ptr? std::shared_ptr? And what about boost? What are you using instead?

Though arguing from good intentions, I would claim you are mistaken. Looking at computer languages the language itself often has a radically different "style" than user-defined symbols and code. I've actually said this here already:

Yes, the trend in the industry over the last decade has been a move to lower-case comelCase for methods (Class::myMethod()), upper-case CamelCase for free functions (MyFunction()), all-lowercase without underscores for namespaces, and abbreviations treated as normal words (RenderRttStuff(), Class::rtsAndRttAreAcronyms()).

This is actually tremendously positive for code readability.

The boost and STL code conventions are only used there, but that too can be argued to serve the purpose of showing what is "language" and what is userland calls.

C++ is a language which per design has as much of the language as possible moved to the standard library rather than be integral to the compiler. However, the standard library is part of the same Standard that defines the rest of the C++ language and is not userland code.

So the STL and also Boost are both "language" (yes, even Boost, though it is an external library, is considered the unofficial extension of STL and part of the language) rather than userland (client-side) code. As such it is natural that Boost will stick close to the "language's style". Further, the STL and Boost objects are suggesting the form and usage of integral types--see int and string--which is indicated by the lower-case names and that they are considered final, unlike client objects, which are Upper-cased and usually extendible.

It is normal that unique styles and conventions evolve around the language symbols, and claiming that userland code must or should stay as close to the "language style" as possible is unacceptably restrictive and potentially damaging. It can be argued that userland code in fact should strive to be distinctive compared to integral types and symbols (C, C++, STL and Boost types). As for styles, we have we have a plenitude of those, the most pedagogical and ergonomic being camelCase.

In sum: It is a move for consistency, pedagogics and ergonomics to move SFML to camelCase. Using camelCase is not being inconsistent with the language itself.

11

General discussions / New naming convention

« on: January 20, 2012, 11:01:23 pm »

My existing library code will already be broken next time I download SFML2 trunk due to numerous breaking changes in the API, and I am resigned to and accepting of this, so
(1) I agree with Tex Killer (and myself as per above) that "not breaking existing code" is an irrelevant and misleading statement,
(2) I welcome the chance to make my SFML code consistent with my other 3rd party code and make all my library code consistent,
(3) Alpha code is in development and even should change for the better, which for--again--reasons given above camelCase is in every single comparative aspect.

12

General discussions / New naming convention

« on: January 13, 2012, 11:25:23 pm »

Let's be logical.

1) Consistency is the paramount item of importance. SFML today isn't consistent (f.i. the rect and vector members, which drives f.i. me to distraction).
2) Changing anything for consistency will break code.
3) If breaking code, it is better to make everything consistent while at it rather
than retain inconsistencies or break a bit more with every update.
4) SFML2 is already broken versus 1.6 and many previously installed 2.0 builds. Therefore, there is no better time to fix what needs to be done than now since clients will need to redress their code for 2.0 compatibility anyway.

That is logical. Now, let's change to subjectives, popular impressions and trends.

SFML's current PascalCase is actually a common (as in "occurring" rather than ubiquitous) argument against it, as in when questions about pros and cons of different systems are asked on fora, the code convention of SFML is a recurring drawback.

Compared to the vast majority of current and widespread middleware solutions the convention is apart and SFML code stands out as deviant against other code in a project pulling in several libraries. This goes against the principle of consistency. Just as Laurent says, the trend is definitely for Class::camelCase, void Class::camelCase() and void CamelCase() code formatting.

From a pedagogical perspective, camelCase creates clear and immediate visual distinctions between classes, members, methods and free functions.


For me, Laurent's announcement was a very welcome birthday present, and from a non-subjective perspective I think it is a the correct way forward.

13

General discussions / New graphics API ready

« on: January 05, 2012, 09:34:57 pm »

Well, probably yes, although I'm not a fan of having to write a long chain of members and sub members (like color.data.components.r). Getters might be more interesting then, but at the same time it isn't something that requires immediate changes or attention, considering there are far more interesting things to fix/change first (like OpenGL ES).

Chained member access would be a nuisance, but I don't think that was the suggestion, and not what I would suggest either.

Code: [Select]

struct Colour
{
    union
    {
        struct
        {
            unsigned char r;
            unsigned char g;
            unsigned char b;
            unsigned char a;
        };
        sf::Uint32 rgba;
    };
};


In this you access the members of Colour instance c by c.r, c.a or c.rgba directly.

14

General discussions / New graphics API ready

« on: January 03, 2012, 07:18:08 pm »

The references besides, the union layout seems spot-on. Just put it in public access. There have been some times I could have used an rgba member directly, and a layout like that (but with public members and sans the references) would both be an interface improvement and would allow the writing of more efficient low-level code for those that have a need for such. Also, it serves to document the colour component layout in code, the value of which shouldn't be underestimated.

15

General discussions / The new graphics API in SFML 2

« on: November 08, 2011, 05:09:37 pm »

Aah, ok, that explains it. Thanks for the explanation.

A thought: since creating a large set of textures with all combinations of styles is obviously unrealistic, an alternative possibility might be to request the creation of a font texture with a given (user-specified) combination of styles when a typeface is loaded. A specialised typeface like that would of course not be able to take any other styles, but it would solve principally all problems and satisfy all usage scenarios I can think of, as well as actually reduce memory footprint when only a particular style is needed.

The drawback of this solution is of course that colours would need to be part of the requested style.