Messages

46

General discussions / Re: SFML Game Development -- A book on SFML

« on: July 11, 2013, 09:54:34 pm »

(and it took me a lot of scrolling to get there, author descriptions and all that go at the end of the book)

Well no. I have tons of programming books and none put the author description at the end, only a shorter one at the back. The reasons is that you want to see if the author is supposed to be an expert in the domain before even considering the book.
As you said you scrolled, I think you used the epub or even pdf version which when read in, say, a Sony Reader or iPad, will begin at the very first page, while if you use the mobi version with a Kindle, you open the book directly to the beginning of the book. It's mostly a packaging issue or a format desing issue or a reader implementation issue.

Whatever, my point is when I received the access and open the book on a Kindle, my first reflex was to go back to check the authors description (I don't know a lot about people around here).

Note that with paper you jump faster to whatever you want.

47

Feature requests / Re: Change Unit of Measure

« on: July 11, 2013, 09:47:29 pm »

Since SFML 3.0 will probably have C++11 support, Laurent might want to try out making use of user defined literals in order to solve this problem . SFML would probably be one of the first libraries to make use of UDL, but you know it sounds too good to pass up .

It don't solve the problem, it just add a shorter syntaxe. You still need some kind of type definitions to use inside the user-defined literals. But yeah that would be cool.

48

Feature requests / Re: Change Unit of Measure

« on: July 10, 2013, 10:03:48 am »

In case you want an example of how to provide both (and use only one internally), Ogre does it nicely. It have two types which can be converted to each other but only in an explicit way, which expose the places where conversion happen. It uses radians internally (to talk directly to DX and OGL with no conversion)  but the user easily can use degrees everywhere in his code and provide it to Ogre which will convert it before processing internally. Also easy to get the degree version of any angle value Ogre provide.
It's also pretty simple to setup. As Degree and Radian are different unrelated types there is no way to mix them without explicit conversion. See https://bitbucket.org/sinbad/ogre/src/0bba4f7cdb953c083aa9e3e15a13857e0988d48a/OgreMain/include/OgreMath.h?at=default for details, you can also see that it could be implemented in a simpler way but the idea is clear. (note that by default Real is float, you can change it to double in Ogre hard config macros)

Not sure if it can be done without breaking SFML 2.0 interface, so assuming it would be for 3.0, I think it's a nice example of design for providing angles values.

49

Feature requests / Re: Procedural Animation/Movement, Steering Behaviour

« on: July 08, 2013, 07:49:43 pm »

In the same time, I'm not actually advocating using time as reference because it would imply providing an update loop.

Instead, I'm advocating providing tools to quickly setup your own tweening by calling some system regularly with an update of where between the beginning 0 and the end 1 of the animation (this is the general term for this) the generated/animated values should be.

That way, it would be easier to setup tweening for your specific context of use of SFML (which carefully avoid providing a framework but just provide building blocks).

50

General discussions / Re: SFML Game Development -- A book on SFML

« on: July 01, 2013, 10:56:10 pm »

Congrats for the book! Looks like I'll be able to get it from the publisher for review. If not I'll buy it anyway!

51

Feature requests / Re: Bézier curves

« on: June 28, 2013, 02:46:53 pm »

Tweeners were once suggested for Thor, maybe the corresponding discussion might inspire you.

I believe a non-time-based solution would be far more generic (but a little less quick to use) for SFML itself than what is proposed there. Then in Thor you could easily plug things together to propose time-based tweeners.

52

Feature requests / Re: Bézier curves

« on: June 27, 2013, 05:00:05 pm »

I was thinking about it but got caught on something else. Give me some time to propose some example. Meanwhile, just think it would be just functions or callable objects that would update a value (either via ref or internal, which should be easier). I'll get back to this soon.

53

Feature requests / Re: Bézier curves

« on: June 25, 2013, 08:41:36 pm »

I also think that it's surprising that there are threading features to SFML if I follow the logic of not adding anything other than basic building blocks of multi media library (and threading is anything but "simple").

This has already been discussed multiple times, and threads are only provided because they are needed in the SFML implementation. That's also the reason why requests for more elaborated multithreading features are constantly rejected.

When SFML ports its code to C++11 one day, sf::Thread will probably be removed.

Ok then, but was networking necessary too for SFML implementation?

Anyway my point was that adding value animation would not be a big addition nor would make SFML fat and is in my opinion the only really needed feature missing. However, it should not be automatic like in other frameworks which provide a main loop and everything is updated automatically. For SFML, just having the algorithms as wrapped values (or something similar) with an easy way to update them when needed would be enough.

54

Feature requests / Re: Bézier curves

« on: June 23, 2013, 05:11:27 pm »

Ok but that's not an argument either. I personally think it would be too much to add another feature than value animation tools, so it's just one feature more I think is really missing. I also think that it's surprising that there are threading features to SFML if I follow the logic of not adding anything other than basic building blocks of multi media library (and threading is anything but "simple").

My argument is: for a multimedia library, it quite lack features helping implementing dynamic changes of the basic bricks it provides. A generic value animation feature would be, in my opinion, a generic tool to quickly plug together all these bricks to make something that change, like moving a sprite through a curve or changing dynamically the music volume, even sprite animation can be implemented using it - all that without defining in SFML how to do these, just providing the tool to animate values (for examples floats or better: aggregates).

EDIT> Just to complete my thinking: I believe it would be a minor addition technically, a set of simple tools, but it would help a lot combine other features with anything that "moves" or is animated.

55

Feature requests / Re: Bézier curves

« on: June 23, 2013, 03:44:09 pm »

The goal of SFML's graphics module is to provide a very simple API to get some 2D graphics going. The fact that we have classes such as sf::Sprite and essentially sf::Transformable and sf::Drawable, is only for convenience, because all we essentially would need now to draw 2D stuff is some kind of render target, a transformation and vertices. How much convenience will get added to SFML is up for discussion, but the only person that can make a final decision is Laurent.

Tweening is not supposed to be a graphic part, it's value-animation. I wouldn't add tweening to SFML graphics library, that would be dumb. Value-animation is a basic brick which is important for tons of different kind of stuffs, the most visible being moving graphics.

Personally I see the benefits of a Tweening class, but I don't think, that it would fit into SFML's "philosophy", because if we would add it, why not add feature x or feature y or feature z? And which point will SFML be blown up so much, that you essentially have to drop the Simple from it's name?

You can dump this argument at each request too, it's not a valid argument. What would be an argument against adding value-animation in a separate library which is part of SFML because it uses it's basic types?

56

Feature requests / Re: Procedural Animation/Movement, Steering Behaviour

« on: June 22, 2013, 10:57:55 pm »

Just to update: I don't think it's ok to have tweening out of the core library, one of the reasons being that it's actually the simplest procedural animation you can make and it's everywhere in any modern multi media library. There are several examples of such successful and easy to use libraries or frameworks like Cocos2D-X, Cinder or Open Frameworks.

In my experience, they all allow faster feedback on the development just because of having immediately at least basic procedural movement bricks to use. However, these ones are not really c++-idiomatic in the design AND they mostly force you to use a complete framework instead of composing your application with totally separate libraries. That is why I prefer to use SFML.

But really, it's deeply annoying to have to setup non-core libraries just to have basic movements, even if it's just for prototyping. Strangely, that's always hitting me each time I make something with SFML.

I really believe this is the only core missing feature/library.

I also believe it's not like it's an experimental feature or that there isn't enough knowledge about the subject or design of such features. It's basically providing an object to update or a starting point and applying a function on each update, the function being one of the general easing equations or anything else really.

57

Feature requests / Re: Bézier curves

« on: June 22, 2013, 10:47:05 pm »

Just a shameless plug to this thread: http://en.sfml-dev.org/forums/index.php?topic=8010.0

Because the more I try to use SFML the more I really think that today a multi-media basic components library without anything for tweening is problematic. (or at least it makes development slower than it could make - and that's only one feature missing in my opinion)

So if Bezier curves implementation manage to convince Laurent that it's worth putting it in the core (and now I am sure it is, but that's my opinion), then tweening should be the next feature. It's simple, there are tons of code already existing in other frameworks that shows how to do it. So basically the problem would mainly be to convince Laurent and having a surprisingly simple, efficient and elegant interface.

Also, as libclaw has been mentioned, see the comment on lilbclaw author working on Boost.Tweener which is a generalization of libclaw.


@Laurent I'm not sure I agree with the float type only argument, in particular when both bezier curves are often used in non-graphic works too (mostly doubles for example in wide space simulations involving multi-scale positionning, or even non-plannar geometry prediction stuffs). But I guess float only would be a good start.

58

General discussions / Re: Anyone else pick up "The C++ Programming Language - 4th Edition"?

« on: June 19, 2013, 10:28:36 pm »

I'll wait for the C++14 version. C++14 is a bugfix-minor-improvement release of the C++11 version, and it will be fixed next year (because they work fixed schedule now). So I don't see the point into getting this one.

59

General discussions / Re: Git repository: ignore file

« on: May 22, 2013, 12:11:07 pm »

Just a quick note that is not an argument but just raw information:
I just remembered why I don't like to have the generated files outside of the source repo directory.
It is indeed not a problem when you're working on something like SFML where most files are already there, adding files is rare.

I have some projects where I add new files almost each day. I'm using visual studio to write the code, so each time I want to create a new file I have to first create the file, then add it to CMake.
By reflex, I will right click in the project file tree into VS and add a new file, say a header.
VS will suggest a directory by default which is the directory where the project file is. So if it is generated by CMake, by default it will be in the generated directories, not in the source directories.
Unfortunately it is not obvious when I do this because I'm so used to just have to create the file and it will be in the right directory that I tend to forget to check where the directory the new file will be created is.

Also, it becomes worse when I'm working on a library which have to have headers separated in an include directory (which can be fixed by some scripting but...)

Any way, this is a minor nuisance because you just have to be more attentive of how you create the file, OR you just create a text file outside VS and run CMake and you're ready.
I tend to believe it's the typical minor details that annoys regularly and can make a developer very angry after some months but it's just a personal belief. I tend to work on removing anything that gets between the developer and the coding because it annoys me too and I just want to work on theproject instead of having to take care on some minimal matters.

Now I'm creating files outside VS. It works whatever IDE you work with. 

60

General discussions / Re: Git repository: ignore file

« on: April 08, 2013, 12:12:14 pm »

I see.

I'm not sure I can do that with all my projects (because of script files).
I tried that before but hit a problem at some point. I Don't remember which one though.

Will check if I can find it again. For working on SFML indeed I'll use this solution.