SFML.Net styled events in DSFML?

[auRose94]

I was looking at SFML.Net and I saw the examples and I noticed how they did their events. I was thinking maybe we could do the same thing with DSFML and D. We can use an Array of function pointers and have event handles too! To me we could achieve a lot more with this than with event polling.

So I was wondering if this sounds cool with you guys? I think I could make this as long as you guys think its a excellent idea otherwise I won't do it. Or we could actually have both event polling and event callbacks? Best of both worlds? eh?

[nikibobi]

@Halsys I think it is a great idea, but we will have to see what @Jebbs thinks. He wants to make it as close to the C ++ version of SFML as possible. Maybe after #4 is done, we should start changing it and make it different from the C++ version. Maybe Jebbs can create another branch that will be the changed sfml, but also keep the old one that stays as close to the C++ version as possible. And only update the C++ version if bugs occur. That way we can extend and build on top of sfml. Simly specify in the README that there are two branches and people are going to be ok. And about the documentation ( #33 ), I think that the D-spiced version of sfml should be documented. Because now dsfml is just a translation over the C API. And the standard SFML is very well documented on their site, so people can get hang of it even if it's D code.

@Jebbs I saw when reading the code you commented out Normalize functions of Vector2 and Vector3, because they were not part of the C API. I think you should include them later when you make this new branch.

@Halsys I think you should start working on this(if you want) and when it is done, you can open a pull request, so we can see it. But Jebbs might not immediately merge it into code, but others can see it and merge it if they want to.

[auRose94]

@nikibobi Got it! Going to start working on it somewhere today. Should I keep both kinds of event handling or replace it?

@Jebbs Simple Fast Multimedia Library.... As the name says, its simple!... Why take out features that will make life easier/simple?

[nikibobi]

@Halsys Well I think keep it for now and later we can put your version in the D branch and keep the old in the original version.

[Jebbs]

This is an interesting suggestion actually. The way SFML.Net handles events makes a lot of sense in the context of that language because of the language itself. Event driven programming is essentially built into it. I do want to keep things as close to the C++ API as possible, and since the event system already works I would be loathe to change it. It's one of those, if it ain't broke don't fix it situations. I think the problem we might have with having both would be issues if people try to mix the two. I'm not against the idea, though. Both event systems have good reasons to use them. If we can get something working well and looking nice, it might happen.

@nikibobi The reason I took out the normalize stuff is because I didn't want to confuse people that might use the C++ API thinking that it was a part of regular SFML. It's easy enough to integrate with UFCS though, which is why it is commented out instead of removed all together. Having an extended version of DSFML is a cool idea, though it might be a little confusing for users to decide which one to use. Maybe if we get some more feedback from the other users we can decide if we want to go that way.

[Jebbs]

@Halsys

@Jebbs Simple Fast Multimedia Library.... As the name says, its simple!... Why take out features that will make life easier/simple?

Well, adding in more features reduces the simplicity of the API itself. The more we add, the larger it grows, the more convoluted things can get. The idea behind SFML is to be a low level way of getting some very basic multimedia stuff working. It was never meant to be an engine or a large framework. So when I answer something with "It's not part of the C++ API" it's not just because I want it to match exactly(though I do), it's because I appreciate the simplicity that SFML already has.

Not to say we shouldn't work on improving things, mind you. If you have an idea for something, I would say bring it up with the SFML community and we can talk about it there. That way everyone that uses DSFML doesn't get mad at just me. :P

[nikibobi]

@Jebbs well the another version will be just another branch like Experimental. You can keep the master branch close to C++ SFML and just have the enhanced version on another branch. And it can be clearly and shortly explained in the README what the other branch is about.

[Jebbs]

The experimental branch was for me to see if I could fix some problems with the current way the binding is done though, and it will soon replace the current master branch and I'll go back down to one. If anything, the API is even closer to that of SFML than is was before. :P

[auRose94]

Got the EventDispatcher(Thats what I am calling it) "half" implemented, And I'm making it an attachment to DSFML. It uses the DSFML events and just calls function pointers if the event type matches. It is not a part of the Window or Events, and the user can choose to use either one. I will make a commit with an example when I am done and I'm sure it works.

@Jebbs

Well, adding in more features reduces the simplicity of the API itself.

That really depends on the documentation but I get what you mean... The C++ version can do EventDispatching too, Just on C++0x, which is what SFML is leaning towards... I think!(Needs C++0x Vectors or Boost containers) I wouldn't be surprised if they thought this was a great idea as well.

I also agree we should have a C++ and a D Flavored versions of SFML. The C++ version can be as close to the C++ version as possible and the D version can do the same things plus some more... Like D to C++.... as a metaphor and to rake in more D users(Make it more popular!) :D

[nikibobi]

@Jebbs After Experimental becomes master, you can still make another branch where we could experiment and add more features(not too many so it doesn't get cluttered and confusing) or change things like the event system. That way newcomers will see the master branch and stick with the C++ version, but they can try the D-spiced version too and use whichever they like. @Halsys ha ha, yes I agree with you.

[nikibobi]

In addition to that SFML.Net is also official sfml, because Laurent maintains it. And it uses the C libraries, but changes the style so it fits C#. The same way dsfml is not bound to copying the C/C++ interface, but to interpret it in a way that fits well with the language. After all D was created to fix things that were strange and ugly in C++

Even if you decide not to create such branch, then some of us will create a fork and work on it there like an extension, but since it will be different from yours we will probably announce it in the SFML forums and it will be probably added to the bindings on the site. And if it is added there will be 4 different SFML repositories just for D. Which will probably just confuse new coming users which one should they choose.

That's why I think adding another branch is a great idea.

[Jebbs]

I'm not trying to say it's isn't a good idea. It just seems strange to try to maintain two branches that are basically the same.

You guys are putting me in a awkward position. I want to keep the API as close to SFML as possible, but you all want features that can be added but aren't apart of the regular API and I want to have everyone happy. :P

[Jebbs]

The same way dsfml is not bound to copying the C/C++ interface, but to interpret it in a way that fits well with the language. After all D was created to fix things that were strange and ugly in C++

But SFML is very well designed and doesn't do things in an ugly way IMO.

Anyways, I'll see if we get more feedback on this. Maybe we can make a post about it in the DSFML forums. http://en.sfml-dev.org/forums/index.php?board=13.0

[auRose94]

Well it works but certain things that involve buttons or keys dont tell which key was pressed, instead it says the key is unknown... So I need to figure that out but it does work, and the callbacks are going to be delegates, you will get more freedom that way by implementing the callbacks inside classes so individuals callbacks can be made towards classes instead of doing static function pointer callbacks.

~What works Size Closed GainedFocus LostFocus MouseEntered MouseLeave MouseMove JoystickMove JoyStickConnected

~Everything else doesn't work

[Jebbs]

Cool! Any chance we could see some code? Maybe @nikibobi and I can help.

[nikibobi]

I'm not trying to say it's isn't a good idea. It just seems strange to try to maintain two branches that are basically the same.

Well you can create the second branch after everything is done and there would be nothing more to change. And you will only have to change the original branch if there is a bug, or when SFML changes versions.

Cool! Any chance we could see some code? Maybe @nikibobi and I can help.

@Halsys Yea, I think you should open a pull request. Although it might not be pulled we can discuss the event system there and help with code and advices.

[auRose94]

https://github.com/Halsys/DSFML/commit/61ee45f2fbf6c0d2ae96eb78cb1f5dee19bf7309 Here is a link to the commit, I'm committing it to mine before anything else so we don't risk the issue of tampering with the originals(Jebbs's?). The example will work, Might be a typo in it, maybe not, but the Event Dispatcher does work! Personally, If the user wanted this feature they can make it themselves.... seeing how it didn't take long, however they won't be able to, because the issues with the keys/buttons. I tried everything in my power to figure this out in a way where it didn't look like a hack or felt a bit "Half assed".

Along with the commit though I did have some helpful edits to Window.d. I modified Keyboard.Keys to actually be a "enum : int"(So you can convert integers to Keys or vice versa with casting... good for settings files :D). The Event types can be found through Event.Types(So IDE's won't call it unnamed and the user won't have to go to documentation or flip to window.d to find out that type he/she is thinking of.)

[Jebbs]

You shouldn't have had to do that with the Keys enum. I use enums as ints all the time. You shouldn't need a cast unless something was changed recently I wasn't aware of.

Here is a snippet from the enum page:

If the EnumBaseType is not explicitly set, and the first EnumMember has an initializer, it is set to the type of that initializer. Otherwise, it defaults to type int.

And from another part:

The value of an EnumMember is given by its initializer. If there is no initializer, it is given the value of the previous EnumMember + 1.

When I have a little more time I will look at your code a little better, but I have a couple of comments from what I did see. In your DispachEvents function, I would use a switch statement rather than a if() ladder, and that something like this:

auto KeyEvent = event.KeyEvent();
foreach(ref i; KeyPressCalls)
{
        i(KeyEvent);
 } 

I would write as

foreach(ref eventCall; KeyPressCalls)
{
        eventCall(event.KeyEvent());
 } 

auto KeyEvent = event.KeyEvent() is just an extra copy that you can get rid of, and i isn't a very descriptive name. ;)

Other than that, this looks awesome! Truth be told, it could be something that can be integrated better into the library. Maybe something like Window.addEventDispacher() to associate all of it with a window directly allowing Window.pollEvent() to automatically pass events to any Dispachers it has. What do you think?

[Jebbs]

And just so you guys know, I have been toying with the idea of writing a new multimedia library specifically for D so that it doesn't have to use bindings of an existing one in order to work, and so that static building would be actually possible. Ideas like this are great and would definitely be implemented if I do ever decide to start working on it.

[auRose94]

It was like how you wrote it but I wasn't sure if the next iteration of the foreach loop would feed the same event or not. And chances are.... I might need to just merge it with a windows pollevent and get the raw sfevent and convert it my self and then dispatch it.

I would totally support a D multimedia library if you did it! As long as its like SFML to some degree and follows the same philosophy as D.... oh and it supports at least 2 platforms.(preferably Unix and Windows)

Oh btw... I found out a way to static link DSFML... at least I can do it in Mono-D(my IDE). You just compile Csfml as static and link it with a project along with dsfml. Not exactly precompiled but its not like D compiles slow or anything.

[Jebbs]

It should work fine. Even though it's a ref Event it won't be updated by pollEvents until after you are done updating your Event Dispacher, so it's the same event every time.

And if I did, it would probably be VERY similar to how SFML is designed, since SFML is designed so well. I would take D more into mind, and I also wouldn't be so hesitant to add new things or make changes. :P

And I was under the impression that you couldn't statically build CSFML statically. For most compilers, you can't build a static library consisting of static libraries, or so I thought. I think CMake even gives you errors when you select static build.

[auRose94]

I will try to prove you wrong then. :P Want me to try to make some libs and make a commit for it?

[Jebbs]

Maybe a wiki entry would be better? I was actually going to remove the libs from the repo since I only have the windows ones up there, and they should be kept separate from the source anyhow.

Edit: I'm interested in seeing how you got it working anyways!

[auRose94]

Turns out I was wrong... Which is a little embarrassing. But I felt I was close anyway.... There was a ton of warnings and it would halfway compile then stop around audio... I thought maybe if I made a library in code blocks and compile both CSFML and SFML under one roof it would at least attempt at compiling... and it did attempt(as in some modules compiled) but it had too many warnings... I feel it won't work.

Also I don't know why I thought I was compiling in static on Mono-D.... turns out it was actually shared and I forgot. :| If only dsfml was like how csfml is (...where it was a binding to SFML and not to csfml) You could compile static wise.... But sadly D has only limited support for C++. Anyway... that library you thought about making... Like I said, "Totally behind it!"!

[Jebbs]

We'll see! I have other stuff I really should be working on instead. :P Another thing I might work on next would be a cross platform IDE specifically for D, but the game library would be pretty sweet too.

[auRose94]

What if you made a D IDE where it could help you make games? I'd pay for it! :P

[Jebbs]

I'm not entirely sure what that would entail. :P

I was considering writing a D to Java "compiler" and include that as part of the IDE so that you can write D code that will run on Android devices. Does that count? XD

There's also the debug issue with D that needs to be solved. I have some ideas for that too, but there's just a lot to be done.

[auRose94]

I don't think I can figure out how to fix the unknown key issue and because dsfml is a binding, there is no real way to dig in there and fix it! I'd like to have a feature like this but I don't think I am going to get it. So I am closing this because there is no real way to fix this.

[Jebbs]

I think you were really on to something with this, to be honest.

Even if you dropped this, I think I'll pick up where you left off when I have more time to play with this.