Messages

46

General discussions / Re: The new SFML team

« on: April 21, 2014, 08:04:07 pm »

Wow this sounds great!

I am keen on seeing what may come out of this. probably only good things!

I must say that I had lost my hope there for a while for SFML, when the task list was just growing and growing, and future versions seeming to be years away.

47

General discussions / Re: Rethinking the definition of "Simple"

« on: April 20, 2014, 12:27:38 pm »

For example, I can't say that the audio bug discussion went smoothly.

I agree. However, if you check the thread, you'll see that I wanted to hear more arguments to add a feature (and not only fix the bug, which was already decided in the first answer); while Laurent told from the beginning that it was not added because the demand had been too low to make it a high-priority task, which you interpreted as focusing only on newbies and neglecting advanced users. What followed was a general rant against him and SFML, although we said already on page 2 that we consider adding the feature. Even later, when the GitHub issue was long added, it continued.

I think this happened partly due to misunderstanding, general problems with the handling of feature requests and mixing several discussions (is up vector meaningful, is it a feature or a bugfix, what is its best API, why are SFML feature requests handled like this)... But I also see that we could have been more clear from the beginning. I hope by being more open for feature requests in the future we can avoid such flamewars and keep discussions more objective

Yeah, I agree about the thread and that is your perspective. I can find quotes in that thread where it was stated that having the vector accessible etc was too complicated etc, but I don't want to go there. Again, I am not blaming any side or any individual and I don't objectively claim that our side was more right than the other. I just don't think it is purposeful to argue which side on the discussion started with bad things because you'll always hear different things depending on who you ask. Imo such are best left behind and instead it is more useful to work on how to not get there again.

I do agree that misunderstandings and both sides getting annoyedly stuck with certain statements and such. But I too am positive that if it would be decided that SFML should be more community-contribution-based, we would be able to forget about old disagreements and kind of "start anew" in terms of discussing the future in a way that most people are happy with. If that is the way the library would go.

48

General discussions / Re: Rethinking the definition of "Simple"

« on: April 20, 2014, 08:25:31 am »

I'll just also chip in to the discussion, saying that I too agree with the original post. IMO if the focus on a library like this is newbie friendliness and sacrifices are made for such, then as exploiter (not going to scroll back just to get caps and numbering correct ) said, SFML will only be a "gateway" library, or a newbie haven.

This is tbh something I've already seen and experienced myself. In some cases in my own more "complex" use cases of SFML I've had to consider looking at other alternatives. I have also seen friends of mine and people on IRC do this. I find it a shame since I _do_ like the SFML library. It is the multimedia library with the nicest API out there. Which is why I believe that it has great potential.

SFML is only surviving, and I have no idea what will happen in the future. Probably nothing exciting, given the amount of work that my job, my family and my house gives me every single day. When I see you talking about modern features, I feel like I'm light-years away from these things. This is so frustrating.

My dream would be that everyone in this topic join together and actively take over the development of SFML. Otherwise SFML will probably die slowly.

Well, that dream does not sound too off in my opinion. I am pretty sure that many experienced people in this community would be glad to contribute and improve on the library. I myself would be one of them. But in all honesty (and no offence intended), for that to happen, the way SFML is managed would have to change I think. Because up until now SFML have been very "centrally" controlled by either you, or you + Nexus, and reading discussions on the forum, and participating in one (the audio bug one ), there is not uncommonly a lot of resistance towards certain ideas. For example, I can't say that the audio bug discussion went smoothly. Nor did the discussion about getting the GLEW hack away. But both ended up being implemented anyway. Of course this is just my perspective on things, and maybe the other side of the discussion feels the same. But I do know that others I've talked to (Tank for example) feel the same frustration, and regardless of who is "right", it is not really a contribution-healthy way.

I personally would not feel great contributing if that's the process for many changes. But of course every change cannot be openly accepted straight away either, there has to be some form of control to stop useless requests, and focus on important things etc. Maybe it would be possible to have some kind of "SFML Committee" kind of approach where the most interested people who are enough experienced are the ones discussing and deciding new features and such, and then whoever wants can develop them, and the pull requests get investigated by the committee or something. That way I think things could be speed up quite well. It is also more rewarding to contribute and fix bugs and make things when your pull requests are accepted sooner rather than later. To get some agility in the development of the project is very needed I think.

Now, this is just my idea on how things could be changed to ease/speed up development of SFML, and I would be glad to take part of such a thing too. But if this is far from what you have in mind, Laurent then I guess it is fair enough to go another way about it. You are the creator of this library after all.

49

General / Re: Opengl : the vbo doen't build correctly.

« on: April 07, 2014, 07:14:24 pm »

You are very unlikely to get help since you constantly ignore the advice people give you anyway.

50

General / Re: Opengl : the vbo doen't build correctly.

« on: April 07, 2014, 05:25:00 pm »

Well, maybe that is why fifty thousand people in this forum have advised you to not use manual memory management? And even still, managing arrays is a very very basic thing so I am pretty sure you know such stuff as well.

51

General / Re: Opengl : the vbo doen't build correctly.

« on: April 07, 2014, 04:52:32 pm »

I am sorry, but I thought you knew OpenGL?

VBOs are a very basic thing in OpenGL and it surprises me that you don't know it well since you're a really good coder. :O

I am sure you can find out the answer if you think a bit harder.

52

SFML projects / Re: Feather Kit - A C++ Game Framework

« on: April 06, 2014, 10:21:14 pm »

Why that? I would say users that clone the Git repository expect to have the latest changes.

You can use Git tags to refer to official releases.

Well, I guess it depends on the release cycle of the library. I aim to wrap up and release things rapidly, and fix bugs really quickly etc. Combined with semantic versioning that lets me push bugfixes and feature additions as releases to the master quickly enough to be equivalent to "latest changes". Then if you as user want the experimental non-released stuff you can check out the development branch.

But of course, if you have a way slower release cycle like SFML for example, then you might want to use the other approach.

53

SFML projects / Re: Feather Kit - A C++ Game Framework

« on: April 06, 2014, 02:06:03 pm »

Greetings!

It has been a while since I posted here last time. I have some update news regarding the framework and since a few of you guys seemed interested I'll write them here.

General approach changes
Up until now, version management and such was a mess. But I have now decided to follow semantic versioning. This in short terms mean that you can tell from the versioning number what an update does. 0.0.x is a bugfix/patch update, 0.x.0 is a feature addition update in a way that does not break compatibility and x.0.0 is a compatibility breaking update.

I will also no longer develop on the master branch (which is a very bad thing to do in the first place for a library) so the default cloning of the repo will always be the latest official release and will match the documentation.

From now on every new release will come with changes listed in the changelog.txt and information will be available on how to transition in case of API breaking changes.

New features/big changes
Woo, everyone loves new features!

The biggest addition is a whole new module. The Audio module. This module lets you play audio, music or custom streams in a way fairly similar to SFML. It also lets you apply effects and filters with which you can create realistic room acoustics, muffle the sounds under water or maybe add an echo to a canyon level.

Aside from that, a big part of the Entity System module is now also rewritten to be way more safe. It can also store any data type now, and the API is more convenient to use.

Other changes
However much I like the UK spelling myself, this is far from standard in the programming world. Feather Kit now uses US spelling.

All header files have been renamed to .hpp and the templated ones now hide the implementation in .inl files.

The CMakeLists now makes sure to use the -d prefix for debug builds and the FindFeatherKit.cmake is updated to reflect this as well.

The forum has been updated, but not many people registered there anyway so I am not sure who cares about this.

So what now?
Before the true 1.0.0 release, I will write more tutorials and update the website a bit more. There will also be a showcase application to show what Feather Kit can be used for. When that is done, I will see if I can post about Feather Kit in other places than just here to see if there is an interest.

Oh, the web build is also not working right now in the 1.0.0rc1 version and will be patched as soon as possible.

If you're interested, check the new version out at the website or go directly to the source code.

Feather Kit website
Source code

Thanks for reading!

54

SFML projects / Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)

« on: April 02, 2014, 08:27:25 pm »

Hi!

I have a crash in my code from my cool physics library that I am trying to make. The code is:

int* finaNummer = new int[50];

for(int i = 4; i < 100; i += 2)
{
    if(finaNummer[i] == 4)
        finaNummer[i] += 10;
}

Why does it crash?! I tried to google but there was nothing there.

55

SFML projects / Re: 3DEE

« on: April 02, 2014, 08:39:40 am »

Oh, wow, this sounds quite awesome! Good job.

I have always found the lack of 3D and the complications that arise when using SFML with own rendering code what makes SFML to many a "kindergarten" library where it is awesome to learn and get familiar with things, but is left behind for alternatives that are easier to integrate and gets less in your way when you want to make more advanced things. Perhaps this extension could hold people a bit longer.

Would definitely try it out, but right now I have no fitting project. Will keep it in mind for future reference.

56

Feature requests / Re: scalePosition();

« on: March 23, 2014, 05:19:11 pm »

...but hey, we are lazy

Are we now?

57

SFML projects / Re: [SFML 2.1 and C++] 2D Shooter - Pew (Open Source)

« on: March 23, 2014, 02:42:40 pm »

Haha that is awesome!

I like the cow boss graphics, and the part when it starts spinning around.

The sound effects also give a nice retro feel. Keep it up!

58

Feature requests / Re: Remove GLEW dependency in favour of glLoadGen

« on: March 23, 2014, 04:39:21 am »

Awesome!

I hadn't noticed the -prefix flag myself so that was a point I missed but cool that it has such a flag.

Will this be a SFML 3.x change or could it happen before it?

59

Feature requests / Remove GLEW dependency in favour of glLoadGen

« on: March 22, 2014, 08:51:03 am »

Hello!

This is not purely a feature request, but more like a suggestion. I have no idea if it has been suggested before or not as the search function still doesn't work for me.

Anyhow, I stumbled upon this project called glLoadGen which can be used as a replacement for GLEW and similar libraries. It is not a library in itself, but merely a lua script which accepts parameters telling it which gl version is desired, and which extensions are to be used. Then it spits out a header/source pair which contains the desired functions/enums and they can directly be used in your project. No external linking nor runtime library loading required!

I thought this sounded pretty awesome so I tried it out in my own project and it was super easy to switch. It took me about 15 minutes. I just ran this:

lua LoadGen.lua -style=pointer_c -spec=gl -version=3.2 -profile=core core_3_2

Then I included those, and replaced the glewInit call with ogl_LoadFunctions and then included the generated header instead of glew. No sweat, blood nor tears.

The licensing of the script is MIT licence and I don't think there is any particular licence on the generated files. At least I couldn't find any info on it.

I thought this would fit SFML well since it aims to be simple for newbies, and we all know that newbies hate to deal with external libraries, linking errors and stuff like that, and glew can be pretty nasty on that front. SFML even had special hacky solutions to make this easy in the past, but with this, the dependency could perhaps be dropped entirely.

So is there anything that I have missed in my excitement about this approach? Has this been discussed before? Or is it indeed a good idea?

Let me know.

EDIT: here is a link
The licensing of the script is MIT licence and I don't think

60

Feature requests / Re: Keep mouse in window

« on: March 20, 2014, 05:49:33 am »

I just wanted to add to the discussion that I too have felt the need for a mouse locking feature many times when using SFML. As eXpl0it3r (that name took me more than 10 seconds to write. no tab complete in the forums D:) said, it is a crucial feature for FPS view games. In the cases where I wrote FPS stuff, I just used SDL instead since they have such a functionality.

Now I understand that this feature is already on its way. I just wanted to state this to show that there are definitely people who finds this feature crucial.