FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Providing hooks

 
Post new topic   Reply to topic     Forum Index -> ArcLib
View previous topic :: View next topic  
Author Message
ChristianK



Joined: 26 Sep 2006
Posts: 159
Location: Berlin, Germany

PostPosted: Tue Apr 17, 2007 8:20 am    Post subject: Providing hooks Reply with quote

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
View user's profile Send private message
clayasaurus



Joined: 21 May 2004
Posts: 857

PostPosted: Tue Apr 17, 2007 10:52 am    Post subject: Re: Providing hooks Reply with quote

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
View user's profile Send private message AIM Address
ChristianK



Joined: 26 Sep 2006
Posts: 159
Location: Berlin, Germany

PostPosted: Tue Apr 17, 2007 12:02 pm    Post subject: Reply with quote

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
View user's profile Send private message
Brix



Joined: 28 Oct 2006
Posts: 21
Location: EU, Denmark, Lyngby.

PostPosted: Tue Apr 17, 2007 2:34 pm    Post subject: Reply with quote

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. Smile

From the Clanlib docs:
CL_Mouse
CL_Keyboard

Makes my porting alittle easier Wink
Back to top
View user's profile Send private message MSN Messenger
Lutger



Joined: 25 May 2006
Posts: 91

PostPosted: Fri Apr 20, 2007 1:19 pm    Post subject: Re: Providing hooks Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> ArcLib All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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