View previous topic :: View next topic |
Author |
Message |
ChristianK
Joined: 26 Sep 2006 Posts: 159 Location: Berlin, Germany
|
Posted: Tue Apr 17, 2007 8:20 am Post subject: Providing hooks |
|
|
I've written a scenegraph node that detects when the user clicks it and wonder what kind of notification system to give it. We use a variety of styles in arc:
* pull (most notably arc.input)
* push to event handler (arc.physics)
* push via signal (arc.gui, arc.scenegraph.animation)
Currently, I'm in favour of using a signal and get rid of the different way of doing things in the physics module. My original thoughts were that they might be too much of a performance bottleneck for large physics systems and went with event handlers there, but now I believe that might have been a bit of premature optimization and will give the collidables signals instead.
What I'd also like to do is add signals for keyboard and mouse activity to arc.input. The query interface would stay exactly the same, but these signals would be raised whenever states change.
Also, input.d is so annoyingly long, I feel like splitting it up (especially getting those constants into a seperate file) every time I work on it.
Any objections? |
|
Back to top |
|
|
clayasaurus
Joined: 21 May 2004 Posts: 857
|
Posted: Tue Apr 17, 2007 10:52 am Post subject: Re: Providing hooks |
|
|
ChristianK wrote: |
Currently, I'm in favour of using a signal and get rid of the different way of doing things in the physics module. My original thoughts were that they might be too much of a performance bottleneck for large physics systems and went with event handlers there, but now I believe that might have been a bit of premature optimization and will give the collidables signals instead. |
I think signals have performance issues in C++, but in D I think signals are just as per formant as delegates are, which are simply like a function call. It would be nice to do D vs. C++ signal slot comparison tests to see if this is true.
Quote: |
What I'd also like to do is add signals for keyboard and mouse activity to arc.input. The query interface would stay exactly the same, but these signals would be raised whenever states change.
|
So this will allow 2 different interfaces, the...
arc.input.keyPressed('k')
and the
arc.input.connect('k', userfunc())
correct? As long as you don't trash the old interface, I'm for it. I'm kind of wondering about performance/redundancy issues of allowing two different ways to access the same thing, but at the same time I think it is good to have multiple ways to do the same thing, and just let the user pick whichever.
Quote: |
Also, input.d is so annoyingly long, I feel like splitting it up (especially getting those constants into a seperate file) every time I work on it.
|
hrm... multifile is fine, but, where would you put these files? maybe, if we want to split up the stuff accessable from the first arc subdirectory, we should have an
internal/ folder.
otherwise just keep it all in the same file. |
|
Back to top |
|
|
ChristianK
Joined: 26 Sep 2006 Posts: 159 Location: Berlin, Germany
|
Posted: Tue Apr 17, 2007 12:02 pm Post subject: |
|
|
Quote: | So this will allow 2 different interfaces, the...
arc.input.keyPressed('k')
and the
arc.input.connect('k', userfunc()) |
Yeah. I was thinking more of like
arc.input.sigKeyHit.connect(&userfunc);
void userfunc(char key);
as to not have to manage loads of signals, but essentially yes.
Quote: | I'm kind of wondering about performance/redundancy issues of allowing two different ways to access the same thing |
Well, it amounts to calling one signal for every key and mouse SDL event. I don't think it's much overhead if no slots are connected, and if there are - well then the user wants to be notified.
Quote: | but at the same time I think it is good to have multiple ways to do the same thing, and just let the user pick whichever. |
Agreed.
Quote: | hrm... multifile is fine, but, where would you put these files? maybe, if we want to split up the stuff accessable from the first arc subdirectory, we should have an
internal/ folder. |
This is exactly what I did in my local copy! I took large parts of arc.input and put them into arc.internal.input.(constants,mouse,keyboard). |
|
Back to top |
|
|
Brix
Joined: 28 Oct 2006 Posts: 21 Location: EU, Denmark, Lyngby.
|
Posted: Tue Apr 17, 2007 2:34 pm Post subject: |
|
|
wrote: | Yeah. I was thinking more of like
arc.input.sigKeyHit.connect(&userfunc);
void userfunc(char key);
as to not have to manage loads of signals, but essentially yes. |
I like it. In Clanlib it is done exactly the same way.
From the Clanlib docs:
CL_Mouse
CL_Keyboard
Makes my porting alittle easier |
|
Back to top |
|
|
Lutger
Joined: 25 May 2006 Posts: 91
|
Posted: Fri Apr 20, 2007 1:19 pm Post subject: Re: Providing hooks |
|
|
clayasaurus wrote: |
I think signals have performance issues in C++, but in D I think signals are just as per formant as delegates are, which are simply like a function call. It would be nice to do D vs. C++ signal slot comparison tests to see if this is true. |
I have done some research when implementing signals in D, and can say this varies a lot with different libraries in C++. Some incur very little overhead while others, like QT's are a lot slower but provide lots of features.
In D what benchmarks I have done suggest an overhead of 3 to 5 times the cost of array of delegates (for sslot, Phobos.signals may be a little faster), which is not very much actually for what it gives you, if you don't go crazy and replace every function call with a signal. Then again, the same goes for virtual functions calls.
Anyhow I find it very unlikely that for the parts mentioned it will be a problem. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|