SFML 2.0

[panithadrum]

I'm sorry if this is kind of off-topic, but since it didn't seem appropriate to start a thread just to ask a single question: I'm currently planning to code a little 2d engine and I'm planning to use SFML. Since it's going to take some time to get it ready: should I stick with the 1.x branch and somewhere in the future port the thing to 2.x or should I use 2.x directly?

I don't mind some breakage from time to time, but I don't want to spend most of my time fixing the thing instead of implementing my project

I just use SFML2.0, and I recommend you to do the same. API is not changing on every commit, so I don't have to change nothing more than a few lines per 3 months or so. Also you can stick with an especific revision for a while!

[Merkoth]

Thanks panithadrum, that's all I needed to know

[Kaoron]

I agree with this. Distributed systems like Git / Mercurial make branching and developing your own contribution really easy.

However I don't really want people to start creating branches, developing their own stuff (sometimes huge contributions), and submit it to me. SFML is not a community project, I like controlling and implementing stuff myself, and I like the current system where people write their requests or submit their patches here

I'm quite late, but I'd answer that you're absolutely not forced to do more community management with git/hg than you do with svn, neither do you lose control on what happens (Torvalds himself likes to control everything).
Distributed vcs brings version control to contributors without having them hit the official repo. Imo it's a good thing − look at what happens on the python binding, bastien couldn't hit the svn repo, so he went for mercurial… all in all, version control is needed and contributors contribute.
Regarding huge contribs, just do as you would do with any other vcs stuff : refuse patches that are too big or not debated enough, write a HACKERS file to explain how you want contributions to happen, do the merging stuff yourself and control everything if you want to. A lot of developpers have the same feelings as you about their project, distributed vcs just works fine.  

Not to mention that I hated using Git in my last project...

You should give it another try, it's not that terrible and it's really worth it.

[Groogy]

Torvalds himself likes to control everything

 I like how you address him like if he's a deity...

Anyway. I liked Git/GitHub but it's not something I would recommend for this project. SourceForge is much more suited for this kind. And as Laurent says he likes to stay in control. If someone came and made a complete new branch out of the Ruby bindings I would probably be a bit pissed. If someone wants to contribute or even so do a huge change on my project, it would be nice if they asked first. Also if they go so far to actually wanting to merge their branch with the original then I would say absolutely no. I would have no idea of what they've done to the project. They might have gone against some of my personal rules when it comes to programming and etc. etc. The issues are endless when it comes to programmers interacting

Using TortoiseSVN makes everything easy and suits my needs. Well at least on Windows. So I work with the Ruby bindings on a Virtual Machine Ubuntu installation but commit trough Windows XD

[Kaoron]

Torvalds himself likes to control everything

 I like how you address him like if he's a deity...

Haha, he might not be a deity, but as far as I know of him, he's known to be 3 things :
 - the creator and maintainer of linux, and the only person who can commit to the official linux repo
 - the creator of git
 - a lucky bastard

He has (and keeps) control on just everything goes in one of the biggest software project ever. And he created and uses git for it. Dare to come and say that git is not suited because you want to keep control on your project.

If someone came and made a complete new branch out of the Ruby bindings I would probably be a bit pissed. If someone wants to contribute or even so do a huge change on my project, it would be nice if they asked first..

svn does not prevent forks, neither wild huge contributions. svn does not force developers to get in touch with maintainers before doing what they want.
There's no more control with a centralized vcs than with a distributed one.
The only thing svn prevents is contributors to have their work be version controlled, they have to get commit access to the official repo or set-up their own vcs. The former is less control because you have to trust someone enough to give him commit access, both are tedious.

Also if they go so far to actually wanting to merge their branch with the original then I would say absolutely no. I would have no idea of what they've done to the project. They might have gone against some of my personal rules when it comes to programming and etc. etc. The issues are endless when it comes to programmers interacting .

I'd say no too, and it's arguably a good answer to that kind of contribution. But there's nothing here that advantages svn over git or hg. That's necessary and inevitable community management, traditionnaly done through some file aimed at developers which gives them enough keys to avoid making a faux-pas.

Using TortoiseSVN makes everything easy and suits my needs. Well at least on Windows. So I work with the Ruby bindings on a Virtual Machine Ubuntu installation but commit trough Windows XD

I understand that and I don't want to force anyone, but there was some prejudices on distributed vcs that couldn't stay uncorrected.

[Tank]

And as Laurent says he likes to stay in control.

First, there's a huge difference in the terms of having "control". With SVN, that means to have an authz and passwd file and restrict write and read access to certain persons. Like Kaoron said, this can be a huge security hole (a guy's box gets hacked, sniffed, he gets angry, whatever). With Git you're building a so called "network of trust". Say you're the maintainer of initial creator of a project, and there're 2-3 guys that you know for years who also contribute to your project. You check their changes and if they fit, you throw them into your repository. Those 2-3 guys may also have 2-3 guys they trust, and so goes the hierarchy.

You see, with Git, you are much more in control than with Subversion.

If someone came and made a complete new branch out of the Ruby bindings I would probably be a bit pissed.

Then I'd recommend to stop programming for Open Source software. If you can't tolerate people "stealing" (some people think it's like that, where it isn't in reality) your written down code, then you shouldn't contribute to SFML in any way, because SFML itself is clearly released under a license that's *very* open, and also the maintainer (Laurent) seems to be completely open-minded to any things you're willing to do with SFML (he can't even stop you because of the license ) -- at least that's my impression that I respect very much.

- the creator and maintainer of linux, and the only person who can commit to the official linux repo

That's only partly true. Linus invented Linux, but he only maintains his own copy of Linux. The most people around the world clone his repository, because they like what he does, how he maintains his repository and stuff. But as soon as people think he's an idiot, they will stop pulling from his repository and just move over to another that looks better in their eyes. This is true Open Source in my opinion and Git brings this philosophy to the version control systems.

Using TortoiseSVN makes everything easy and suits my needs. Well at least on Windows. So I work with the Ruby bindings on a Virtual Machine Ubuntu installation but commit trough Windows XD

Okay, I highly doubt you're really talking about SCM systems here, are you? It doesn't care what client you use, the design matters. If it's TortoiseSVN, TortoiseGit, svn CLI, git CLI, gitg, gitk, svnweb, gitweb, ... who really cares? Your sentence "[...]but commit through Windows" brought me to that conclusion.

Personally, I became a big fan of Git (or DSCM in general) and nowadays I think SVN is a bunch of crap. It's so much easier, faster and reliable and I bet you won't regret using it. However in the end I don't care much, because git-svn does its job very well. The only drawback is sending in patches easily with Git, but since Laurent rarely accepts those, I'm fine with it.

[Groogy]

Well I'm so-so to Open Source. Thinks it's a good idea but got it's faults. But it's perfectly suited for something to work on your hobby.
And why I am contributing to the project is because I got tired of waiting for a Ruby binding to get done so I decided to make it myself.

And you missed my point, I don't mind if anyone "steal" from me, as long as they ask first. I will absolutely say yes but it's a courtesy that I... desire? Nah that's the wrong word. But I think you understand my point.

That's why in my original rbSFML post I first ask if it's okay that I pick it up instead. Though I think the original maintainer left the forum ages ago so I've sent an email too.

And I've used GitHub, doesn't have any bad experiences. Just that at my University they use SVN to work in the group projects so you get used to that. So naturally I've started to prefer that over Git. But before I went here I preferred Git over SVN. So it's just a matter of what you are used too. Just like how I "preferred" SDL over SFML before :oops: (Which was mostly because of the Rubygame bindings)

Anyway I think we are getting off-topic.

[Tank]

Thinks it's a good idea but got it's faults. But it's perfectly suited for something to work on your hobby.

What kind of faults? It's not only perfectly suited for hobby programmers, but also for the industry. There's enough software out there that prove that.

And you missed my point, I don't mind if anyone "steal" from me, as long as they ask first. I will absolutely say yes but it's a courtesy that I... desire? Nah that's the wrong word. But I think you understand my point.

I got the point, even in your previous posting. However I still think it's the wrong principle. When you release code under any Open Source-compatible license or whatever, then there's no need for anyone to "ask" for permission, even of kindness. If you want that, choose a proper license.

That's why in my original rbSFML post I first ask if it's okay that I pick it up instead. Though I think the original maintainer left the forum ages ago so I've sent an email too.

I think that's a point that I agree with. If there's code maintained by someone and you want to extend it, the best option is to contact that person. Not to ask if it's okay to modify or extend, but if it's possible to coordinate work. It'd be useless if two people worked on the same code.

So naturally I've started to prefer that over Git. But before I went here I preferred Git over SVN.

Are you serious? I've never heard of one person that liked Subversion more than Git when moving from Git to SVN. Of course it's a matter of taste (in some points...), I'm just wondering.

Anyway I think we are getting off-topic.

I guess that's okay, since the thread is not very active anymore. If it's a problem, Laurent may move our discussion, please.

[Groogy]

Thinks it's a good idea but got it's faults. But it's perfectly suited for something to work on your hobby.

What kind of faults? It's not only perfectly suited for hobby programmers, but also for the industry. There's enough software out there that prove that

Suited for the industry... Not to a 100%... Got real world examples.

Legal issues are a pain. Massive Entertainment got sued for using a Open-Source implementation of Python. Most companies lawyers start to cold-sweat if you mention Open-Source. Several game studios has been and will be screwed by the Open Source resulting in fee's much more expensive than just buying something properly licensed.

Also several Open Source projects are not stable enough for the industry or even the public. OOo is a classical example. Something else would be Open-Source IDE. Most things you find out there does not cut it for at least the Game Development Industry. Also the support for it is not as good as something you pay for.

Open-Source projects are mostly maintained by hobbyists, nonprofessionals, and people who have studied the field but never actually practiced it. *aerhm* my previous teacher *aerhm*. I'm no exception to this rule. I like Open Source, I support the concept. But as the community is now, it can't compete with the non-open-source world.

To quote Niklas Hansson (former Lead Developer at Massive Entertainment): Open Source has it's rare diamonds, but most of it is garbage.

*EDIT*
Will have to note that with "Open-Source" I am of course implying on the community for the most. That's what actually makes up the cons and pros with open source software.

[Xorlium]

What are you talking about? I use almost exclusively open source software and most of it is veeery good and I'm very happy with it.

Have you used an IDE like Code::Blocks or kdevelop? In my opinion, Code::Blocks is just as good as Visual Studio (with the added benefit that it runs on Linux, Mac, whatever), and kdevelop is massively better (although harder to use, once you get used to it, it's waay better).

I do give that closed-source software is generally easier to use for the average user though, but to say "has its rare diamonds, but most of it is garbage" is a very misleading (if probably true) statement. Because there are sooooo many open source projects, and maybe 10% of them aren't garbage, which means there are many, many good open source projects. Sure, they aren't always so easy to find.

Oh, and I agree that open office sucks Fortunately I don't use office software, only LaTeX, and kile is very good too.

[Groogy]

In my opinion, Code::Blocks is just as good as Visual Studio

Apparently you haven't worked that much with Visual Studio. There's nothing on the market that beats it's debugger interface. I would say that anything working with GCC is more appealing, but I have to give it to Microsoft, they really succeeded there. Just like they did with their Office package. If I could, I would fuse Visual Studio with GCC

Because there are sooooo many open source projects, and maybe 10% of them aren't garbage, which means there are many, many good open source projects. Sure, they aren't always so easy to find.

He did mean what you consider the "good" ones.

And the perspective is from Game studios, not myself or how it really is. More like a basic simplification about open source in game studios eyes.

And even if this thread isn't used for anything else. This isn't the place to talk about it. Let's not continue being off-topic. SFML2 begins here again plz.

[nfries88]

- Generalization of data access for loading resources (from files, from memory, ...) with a DataStream framework

Excellent. This is something I miss from SDL.
It may be wise to include FIFOs and sockets as well, if they weren't already planned. Maybe over the HTTP and FTP protocols as well.

- Rewrite of OpenGL contexts handling to make it more elegant, more robust and easier to use

While you're at it, it would be advisable to expose all GL functions through GL contexts rather than direct GL calls. Sounds weird, but it will allow for supporting non-GL backends (perhaps software rendering, DirectX, GDI, XRender, etc) in the future.

- Unlink sf::Input from sf::Window, make it use direct OS calls rather than relying on windows events

Would be useful for some applications, but not terribly many.

[Spodi]

I would assume the reliance on OpenGL is too strong in some places to be able to use a different backend transparently while retaining all the available features. Shaders are a good example.

Not to say that it wouldn't be nice to have, but hard to see it being worth the effort to allow for a variety of backends when they don't play so nicely with one another.

[Laurent]

While you're at it, it would be advisable to expose all GL functions through GL contexts rather than direct GL calls. Sounds weird, but it will allow for supporting non-GL backends (perhaps software rendering, DirectX, GDI, XRender, etc) in the future.

I don't care about other back-ends, OpenGL is widely implemented and every new hardware supports an OpenGL variant by default. And SFML is an OpenGL library by definition, its interface is made to mix nicely with native OpenGL calls.

Would be useful for some applications, but not terribly many.

This is not a feature, it's more a bug fix
The current system is not reliable, for example it can't keep track of what's happening when the window looses the focus.

[Groogy]

I think specializing in OpenGL is the right thing to do. Look at Id Tech 5 and the planned Id Tech 6 game engines are all based on OpenGL and are freaking amazing!

Trying to support some other back end would just consume unnecessary time and effort. Though the idea that we have a OpenGL object oriented interface would be really really nice. Though I would understand if it would be too much to implement.