61
General discussions / Re: SFML 2.0 tagged in repository
« on: April 08, 2013, 12:07:00 pm »
Aawww 
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
62
General discussions / Git repository: ignore file
« on: April 08, 2013, 11:41:50 am »
Is there a specific reason why there is no ignore file into the repository?
It would help to have one to avoid accidental commit of files generated by CMake (project files too).
It would help to have one to avoid accidental commit of files generated by CMake (project files too).
63
General discussions / Re: SFML 2.0 tagged in repository
« on: April 08, 2013, 11:24:03 am »
I didn't read all the thread, but just wanted to say I have a pull request I'd like to be in 2.0 and forgot to complete, I'll complete it today if it's not too late!
64
General discussions / Re: A new logo for SFML
« on: January 24, 2013, 04:26:32 pm »
Also "basic construct of an engine".
65
General discussions / Re: Some CMake remarks
« on: January 06, 2013, 07:17:50 pm »Quote
Ok. I thought CMAKE_MODULE_PATH was only used by find_package.
Yes, it is and it also makes the registered paths implicit in include.
Quote
I didn't test, but I'm pretty sure that relative paths are broken when you use a macro.
Never heard about that... In my biggest project I use tons of macros that are defined in a directory for cmake modules, then used in tons of sub projects. Never had a problem so far.
What kind of macro-related problems are you thinking about?
Macros should generate code in-place so it should be safe, but maybe I'm missing something.
66
General discussions / Re: CMake add_subdirectory( sfml ) cannot work with SFML2.0 & other CMake problems
« on: January 06, 2013, 01:54:48 pm »It seems that you work with an old revision of SFML 2, I think this kind of stuff is fixed now.
Argh I just found that you're using git now. I totally forgot about that and my version was under SVN so I thought it was the right repository... that explains why I there have been no changes since march of last year...
Ignore my bug report, sorry again. (should have sleep first)
Quote
And I didn't understand your two additional suggestions. Paths, files, modules, ... ?? Would you mind explaining clearly, with examples of what you refer to?
Sorry for the lack of clarity, seems that these remarks are still valid for the git repo.
I was talking about setting the cmake directory as a cmake module path, like this:
If you do this in the root cmake file you just have to do include( ModuleName ) instead of the full path. This is a minor change but it should help maintainability.
For the sources paths, there is a lot of full path to the source files that should just be relative to the current file. What I mean is for example in SFML/Main you have:
Which could be written
I suppose the source directory and the target declaration directory should be the same so it might help modifying the files to remove this noise. I had the same patterns before in my projects, I figured that the CMakeFiles.txt that is associated to the sources will always be moved around with the sources so the day you change the directory organisation you'll have to change all CMakeFiles.txt because they contain full paths to the sources instead of relative paths.
It's really a minor suggestion but I believe it will also help maintainability.
67
General discussions / Some CMake remarks
« on: January 05, 2013, 11:47:52 pm »
I think there is a CMake related bug.
When I use SFML, or any other dependency on a project using CMake, I put a version in my project repository and use CMake
Which build CMake for SFML.
The problem is that the current CMake files assume that it's the only project being built.
First error is line 14 of the root SFML CMakeList.txt file:
${CMAKE_SOURCE_DIR} is the directory of the CMakeLists.txt file that is at the root of the cmake command. So in my case I have:
myproject/CMakeLists.txt
myproject/dependencies/CMakeLists.txt
myproject/dependencies/sfml/*all files in the current V2 branch - I checked out few minutes ago*
So the include cannot find the directory. It shouldn't be relative to the cmake call directory, but to the CMakeFiles.txt being executed directory.
Solution: NEVER use ${CMAKE_SOURCE_DIR} but use ${CMAKE_CURRENT_SOURCE_DIR} instead.
This problem appear at several places in the CMake files, where what you want is not the current file directory, but the root directory of SFML sources.
To solve this the simplest way (that I use in my projects) is to define exactly where it is, in the root CMakeLists.txt file :
In the root directory of the library, then use it in all CMake scripts that need a directory relative to that directory.
I made a patch (attached) that does this, apparently fix the problem on CMake generation but I didn't try yet to compile the generated projects because...well, it's late.
I think it should be reviewed with care before admission.
Also, while I'm on the CMake subject:
- why don't you use module paths declaration instead of including modules by hand? I see you do use module paths sometimes, but only in depths of the files. It would have been simpler to set the module dir in the root scripts and then just use modules where you need them. Is there a specific reason for this?
- there is a lot of paths used that should be just the file name, because the file is in the same directory. Is it voluntary?
Maybe it just need some cleanup from CMake litterate people. It took me a full year to get to the level I can understand some CMake organisation patterns that work, but I'm far from being an expert.
[attachment deleted by admin]
When I use SFML, or any other dependency on a project using CMake, I put a version in my project repository and use CMake
Which build CMake for SFML.
The problem is that the current CMake files assume that it's the only project being built.
First error is line 14 of the root SFML CMakeList.txt file:
${CMAKE_SOURCE_DIR} is the directory of the CMakeLists.txt file that is at the root of the cmake command. So in my case I have:
myproject/CMakeLists.txt
myproject/dependencies/CMakeLists.txt
myproject/dependencies/sfml/*all files in the current V2 branch - I checked out few minutes ago*
So the include cannot find the directory. It shouldn't be relative to the cmake call directory, but to the CMakeFiles.txt being executed directory.
Solution: NEVER use ${CMAKE_SOURCE_DIR} but use ${CMAKE_CURRENT_SOURCE_DIR} instead.
This problem appear at several places in the CMake files, where what you want is not the current file directory, but the root directory of SFML sources.
To solve this the simplest way (that I use in my projects) is to define exactly where it is, in the root CMakeLists.txt file :
In the root directory of the library, then use it in all CMake scripts that need a directory relative to that directory.
I made a patch (attached) that does this, apparently fix the problem on CMake generation but I didn't try yet to compile the generated projects because...well, it's late.
I think it should be reviewed with care before admission.
Also, while I'm on the CMake subject:
- why don't you use module paths declaration instead of including modules by hand? I see you do use module paths sometimes, but only in depths of the files. It would have been simpler to set the module dir in the root scripts and then just use modules where you need them. Is there a specific reason for this?
- there is a lot of paths used that should be just the file name, because the file is in the same directory. Is it voluntary?
Maybe it just need some cleanup from CMake litterate people. It took me a full year to get to the level I can understand some CMake organisation patterns that work, but I'm far from being an expert.
[attachment deleted by admin]
68
General discussions / Re: When is SFML 2.0 gonna be compatible with VC 2012?
« on: November 02, 2012, 11:07:18 am »
Try the last version of CMake, 2.8.10 (in the download page, they didn't put public news on the main page yet). It should work with express.
69
General discussions / Re: Delaunay tringulation
« on: August 14, 2012, 06:46:01 pm »Doesn't boost have all this stuff (in graph or geometry)?
There was a proposal in Boost.Geometry but i dont' see it in the current doc.
70
Feature requests / Re: Procedural Animation/Movement, Steering Behaviour
« on: August 02, 2012, 06:19:08 pm »
Yes it is extracted from Claw but I suggested some changes to make it more generic.
Actually it is a simple library to me. It's not like he is making a compile-time compiler implementation (I'm looking at you Boost.Spirit...) so it's mostly a generalization of the same.
For example the original Tweener in Claw works exclusively with double. I suggested to change it to any scalar type. That way it even works with Boost.Geometry, so it's easy to make it work for Ogre's Vector classes and SFML too. You just need it to be a scalar type.
You can check the code there but it's WIP: http://libclaw.git.sourceforge.net/git/gitweb.cgi?p=libclaw/boost-tweener;a=summary
The discussion on Boost : https://groups.google.com/forum/#!topic/boost-developers-archive/eS5PhphX3D0
Actually it is a simple library to me. It's not like he is making a compile-time compiler implementation (I'm looking at you Boost.Spirit...) so it's mostly a generalization of the same.
For example the original Tweener in Claw works exclusively with double. I suggested to change it to any scalar type. That way it even works with Boost.Geometry, so it's easy to make it work for Ogre's Vector classes and SFML too. You just need it to be a scalar type.
You can check the code there but it's WIP: http://libclaw.git.sourceforge.net/git/gitweb.cgi?p=libclaw/boost-tweener;a=summary
The discussion on Boost : https://groups.google.com/forum/#!topic/boost-developers-archive/eS5PhphX3D0
71
Feature requests / Re: Procedural Animation/Movement, Steering Behaviour
« on: July 30, 2012, 06:46:04 pm »
Hi there.
Someone is writing a tweener library (extracted from another set of libraries) that is candidate for boost.
I will try to help the writer of the library by using the library.
I think that if it's good enough for my project, and it gets released, it could be extracted and imported into SFML. As it is very lean library -it does only interpolation between to values, using a given update function- I think it don't need to be in an extension of SFML and could be a simple way to just tween SFML values and build complex behaviours over it after.
With some functions provided to associate tweening to SFML clocks, it would be very lean code.
I believe however that anything more complex, like steering behaviour, should be out of SFML.
Anyway I will report here later (in few months I hope) about this library.
Someone is writing a tweener library (extracted from another set of libraries) that is candidate for boost.
I will try to help the writer of the library by using the library.
I think that if it's good enough for my project, and it gets released, it could be extracted and imported into SFML. As it is very lean library -it does only interpolation between to values, using a given update function- I think it don't need to be in an extension of SFML and could be a simple way to just tween SFML values and build complex behaviours over it after.
With some functions provided to associate tweening to SFML clocks, it would be very lean code.
I believe however that anything more complex, like steering behaviour, should be out of SFML.
Anyway I will report here later (in few months I hope) about this library.
72
General discussions / Re: Another python binding: python-sfml2
« on: June 07, 2012, 05:21:58 am »The standard library has also a time module that provides everything for handling time, is it a reason not to implement sf::Time, sf::sleep, sf::seconds, etc ?If you mean <ctime>, it doesn't provide high resolution clocks, which is the application field of sf::Clock.
I think he is talking about chrono, not ctime.
See http://en.cppreference.com/w/cpp/chrono and, just::chrono and boost.chrono implementation
73
General discussions / Re: Visual Studio 2012 RC
« on: June 05, 2012, 02:29:48 pm »
Yes but it have all the libraries, that is still an advantage. The problem is more that all compiler don't match on features.
On Mac, XCode comes with the a verison of Clang that is not the same as the last one. So you have to add the last version of clang as a plugin (I didn't try but someone explained to me how to do this on the clang mailing list) or you wait for the next XCode update...
On Mac, XCode comes with the a verison of Clang that is not the same as the last one. So you have to add the last version of clang as a plugin (I didn't try but someone explained to me how to do this on the clang mailing list) or you wait for the next XCode update...
74
Feature requests / Re: Procedural Animation/Movement, Steering Behaviour
« on: May 28, 2012, 01:20:40 pm »
It would also add performance cost at runtime...
I understand fully as I have tried the same several times by the past. Any way, it is simpler to use specific types. Boost have a geometric representation library but I don't know if it is worth using it in a game, I think it's better for graphic design applications.
Anyway, your library seems generally useful, I don't try to say otherwise. I'm focusing on the specific case of projects based on SFML.
Quote
In a first time, Zoost was a meta lib using templates, but It was too complicated to handle... so I had to simplify it.
I understand fully as I have tried the same several times by the past. Any way, it is simpler to use specific types. Boost have a geometric representation library but I don't know if it is worth using it in a game, I think it's better for graphic design applications.
Anyway, your library seems generally useful, I don't try to say otherwise. I'm focusing on the specific case of projects based on SFML.
75
Feature requests / Re: Procedural Animation/Movement, Steering Behaviour
« on: May 27, 2012, 03:07:40 pm »Many important operations on vectors are implemented in Thor, although I focus on 2D vectors, since SFML itself requires 3D vectors only for Audio.
Yes, focusing on 2D would be far enough I think.
- basic time-based movements;Can you elaborate a bit? I mean, time-based movement is used in almost every game, what exactly do you imagine to outsource in a library?
Well examples would be "tweeners" or "easing". In Cocos2d(-x) they have a set of easing classes that might be interesting to look (even if it's really bad C++). There are libraries in ActionScript that provide tweeners.
Here is a good video showing why it is important:
Juicy
- bezier curve movement;In the past, I have already thought about this kind of functionality, also about splines (or interpolations in general). It is a good candidate for a later version.
I don't know Zoost/Zoom yet, but it looks very interesting. Since it has the features you need, you should probably not wait for Thor to provide it
I know other libraries like that but the problem is that they use their own vector types.
It wouldn't be a problem if the code wasn't relying on this type instead of working in a more generic way, assuming only basics about the vector type ( aka a template library ).
An SFML-specific library would be simpler though, that's why I ask here.
That being said, wouldn't the licence allow you to just take the code from zoost/zoom and change it to adapt to SFML types?
Otherwise the "best" way would be to make zoost/zoom a meta library. That would need some work...
(the website needs to be reworked though, it's really hard to read and agressive...)It's the first time I hear that, what's agressive? I thought the design were rather simple with its dark background and the white font.
Well to me the dark texture makes it hard to look in the face, the white is too white and the font is hard to read.
Try with plain colors or gradiants? It's certainly only a texture problem.