Welcome, Guest. Please login or register. Did you miss your activation email?

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.


Topics - Laurent

Pages: 1 2 3 [4] 5 6
46
General discussions / Extended API for sf::Thread in SFML 2
« on: November 20, 2010, 02:26:31 pm »
Hi

I changed the sf::Thread class in SFML 2 to make it more flexible. I removed the Run() virtual function (so, no more inheritance from sf::Thread) and added a bunch of template constructors instead.

So now you can do this:
Code: [Select]
void f();
sf::Thread t(&f);

Code: [Select]
void f(int arg); // arg type can be anything
sf::Thread t(&f, 5);

Code: [Select]
class Task
{
public:

    void run();
};
Task task;
sf::Thread t(&Task::run, &task);

Code: [Select]
struct Functor
{
    void operator()();
};
sf::Thread t(Functor());

Code: [Select]
struct Functor
{
    void operator()(std::string arg);
};
sf::Thread t(Functor(), "toto");

Code: [Select]
sf::Thread t(boost::bind(...));

So the previous scenarios are still possible, plus a lot of new ones.

47
General discussions / Last important modifications in SFML 2
« on: November 05, 2010, 03:08:15 pm »
Recently I broke many things in SFML 2, here is a list so that you won't get completely lost :)

1. The major version number no longer appears in the libraries names, they got their initial name "sfml-xxx" instead of "sfml2-xxx". The only exception is for Windows DLLs: they are named "sfml-xxx-2.dll". This is necessary because Windows can't properly handle different versions of the same library.

2. The projects/makefiles for Code::Blocks, Visual Studio, XCode and make have officially been removed, I was wasting too much time maintaining them for nothing. So now you must use CMake (I remind you that I've written a tutorial for that, don't panic).

3. SFML_DYNAMIC is no longer necessary for dynamic builds, now it's for static builds that you need to define SFML_STATIC. This is smarter, since dynamic builds are more "standard", and that OSes other than Windows will probably never have static builds.

48
General discussions / Moving bindings directories on the repository
« on: November 05, 2010, 02:41:00 pm »
I was thinking about moving all the bindings into a "bindings" directory, instead of leaving them directly at the root of the repository. I also wanted to rename "CSFML" and "DSFML" to "c" and "d", for consistency.

Does anyone have something against this (especially people working on bindings)?

49
General discussions / CMake tutorial added
« on: October 30, 2010, 12:10:25 am »

50
SFML website / Switching from phpBB2 to SMF
« on: August 28, 2010, 12:43:21 am »
Hi

I've finally decided to replace this good (?) old phpBB2 with a more recent forum.

I was thinking about using SMF (Simple Machines Forum), but I don't know it very well. Maybe some of you can give me more feedback about it? The thing I'm most worried about, is the fact that SMF 1 seems to be pretty old and SMF 2 is not officially released yet; however there are usable release candidates (current is RC3, RC4 is supposed to be released soon).

Note that I tried it on my computer, and it successfully installed and imported the phpBB2 database with no error in just a few clicks :)

Of course, you can also tell me that phpBB3 and SMF are both bad, and that I should rather use some other forum :)

51
General discussions / CMake support added
« on: August 19, 2010, 06:04:14 pm »
Hi

My huge commit from today adds support for the CMake build system, as well as renaming some parts of the repository tree.

Things to know:
- I haven't written CMake files for CSFML yet, this is my next task
- there's no tutorial yet, this is my second next task
- the old project files and makefiles are still maintained, but at some point before the public release they will be removed; so you'd better switch to CMake as soon as you can
- although I've spent a rather big amount of time on the CMake makefiles, there are probably mistakes and things to improve, so don't hesitate to give your feedback

52
Hi

This time I'm not going to talk about SFML, but rather about another project that I'm working on: CAMP.

CAMP is an open-source library (under the LGPL license) that allows to emulate reflection features in C++, like you can find in Java, .Net, etc. In short, reflection allows to manipulate classes, functions, properties and objects dynamically without having to know about (at compile time) their existence, their name or even their prototype.

So what can you do with CAMP? Well, for those who know Qt and its QObjects with abstract signals, slots and properties, you can basically do the same thing with CAMP. But it's not limited to that, we can also imagine a variety of applications based on meta-information: automatic serialization in XML or other format, a generic object editor, writing bindings to script languages in a few lines of code, ...

For example, I think about all the GUI libraries based on CAMP that are being written: they could potentially use CAMP to handle their signals, slots and properties and use them to write XML import/export of widgets, or a designer with a widget editor, etc.

We recently published a brand new website for the community, with a forum, a wiki, a bug tracker, a file repository, etc. :
http://dev.tegesoft.com/projects/camp

Don't hesitate to give me your feedback, and to ask questions if you don't understand everything of CAMP :)

53
General discussions / SFML 2 API documentation online
« on: June 12, 2010, 12:16:53 am »
Hi

I've finally finished rewriting the entire documentation of the SFML 2 API, and it's now available online.

Now starting to rewrite the tutorials... :mrgreen:

54
General discussions / Switching to CMake
« on: June 04, 2010, 09:19:34 pm »
Hi

I'd like to know your opinion about using CMake as the build system for SFML. I've hesitated for a long time, but it would really make things much easier for me.

Here is a list of cool things about CMake:
- I can make a new release (compiling + packaging for all compilers) in one click, thus I'd be able to release more versions, more often
- No more unsupported compilers/IDEs (like VC++ 2010, MinGW makefiles, Eclipse project files, Borland workspaces, ..)
- No more troubles with the supported compilers/IDEs
- Users can customize their own build options (compile only some modules, disable samples, ...)
- Dependencies auto-detected, and you get a clear error message at configure-time if one of them is missing

The main drawback, of course, is that all the users that regularly compile SFML from sources will have to install CMake and use it :)
For those compiling with an IDE, the generated projects are not very "attractive" and look very messy, but in my opinion when you build with CMake you don't need to use the IDE anymore.

So what do you think ?

55
General discussions / sf::Rect modifications in SFML 2 (important!)
« on: April 09, 2010, 03:09:58 pm »
Hi

Today I decided to fix all the bad stuff about sf::Rect. I mainly applied what was said there:
http://www.sfml-dev.org/forum/viewtopic.php?t=1745

Here is a list of what has changed:
- sf::Rect now uses Width/Height instead of Right/Bottom ; this is extremely important because you'll have to change the construction parameters of all your rectangles (sorry)
- Coordinates are now handled consistently: the top-left corner is included in the rectangle's area while the right-bottom corner is excluded
- Rect::GetSize, Rect::Offset and Rect::GetCenter were no longer necessary and were removed

Tell me what you think, and if it's the right solution regarding everything that was said before :)

56
General discussions / Improvement of the network module in SFML 2
« on: March 23, 2010, 11:07:41 am »
Hi

I've changed a couple of things in the network module in SFML 2. A lot less than I expected, but I inform you anyway so that you don't spend hours to fix the compile errors :)

- sf::SocketTCP and sf::SocketUDP were renamed to sf::TcpSocket and sf::UdpSocket
- The Listen and Accept function were moved from sf::SocketTCP to a new sf::TcpListener class
- sf::IPAddress was renamed to sf::IpAddress
- sf::Selector<T> was changed to a single sf::SocketSelector class that can handle mixed types of sockets
- I added function to retrieve the local and remote port/address of a socket
- Important: socket classes have now entity semantics, they are not copyable anymore and close themselves automatically when they are destructed
- I updated the API documentation of the whole module

I have changed a lot of code, so some new bugs may appear :)

57
General discussions / SFML 1.6 released soon
« on: January 26, 2010, 10:52:13 am »
Hi

I'm going to release SFML 1.6, which is mainly a bug fix release. Is there anything that you would like to be improved/fixed in this release? Did I miss something?

58
Hi

The automatic batching system was great, but after using it for a while and collecting feedbacks, I realized that it was creating new problems that were very tricky to solve.

I've totally rewritten this part, and there's no batching and delayed rendering anymore. There's now just a render states cache, which gives even better performances than before.

The only drawback is that user code that uses OpenGL directly must explicitely take care of the current states, with the new SaveGLStates() and RestoreGLStates() functions. By giving explicit control to the user, I'm able to perform many optimizations in the internal code. You can have a look at the OpenGL sample to see how to use these new functions.

I'm waiting for your feedback, about both performances and bugs :)

59
General discussions / Joystick fix in SFML 1.6
« on: January 05, 2010, 06:02:00 pm »
Hi

I've just commited a fix for joysticks in the SVN trunk, and I need you to test it.

There are 3 things to test:
- Ensuring that everything works (buttons and axes)
- Comparing the value returned for the POV on Linux and Windows (the Y axis may be inverted)
- Test joysticks 3 and 4, as I added support for them

The Mac OS X implementation is not up-to-date yet.

Thanks to all the future testers :)

60
General discussions / New implementation for sf::Font in SFML 2
« on: December 13, 2009, 04:51:12 pm »
Hi

I've written a new implementation for sf::Font in SFML 2, in order to make it more flexible :
- no more need for a fixed character set (glyphs are loaded dynamically on demand)
- no more need for a fixed size (all the requested sizes are handled in a single font)
- proper handling of kerning
- proper handling of line spacing

This should normally have almost no effect on text rendering (once glyphs are in the cache, it works basically the same as before), the only major impact that I can see is an increase in the number of glyph textures produced.

I need the usual feedback : does it crash, is it slow, do you like it, etc. :)

Thanks

Pages: 1 2 3 [4] 5 6