Jump to content
  • Advertisement
Sign in to follow this  
Rain Dog

Callbacks etc.

This topic is 4908 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm wanting to be able to use some IRC/IM implementations and also some simple GUI features with Angelscript but I'm running into a problem in that the only way I would be able to succcessfully expose these kinds of features to script writers is through the useage of a queuing mechanism. IE: User presses button while script is off doing something, then the script has to come back and read the queue until it is empty and handle the events. The reason why I do not seee that I can use regular call backs and just build/execute a new angelscript on an event is that the currently executing script needs to be notified of the event. For example: The user has a textbox and a button. Whenever the button is pressed, the text from the textbox is inserted into a script defined array. When the user is finished, the script uses the contents of the array for further instruction. Does anyone have a better solution?

Share this post


Link to post
Share on other sites
Advertisement
I would have the script define functions that mapped to the basic actions a control has. For example, on_click. Instead of having the script running and checking a queu, I'd just call on_click in the script when the element was clicked on. Are you saying that your script is always running asynchronously?

Share this post


Link to post
Share on other sites
The script needs to be running always synchronously.

It would do no good to have 1 instance of the script engine handling the on_click function if the other instance was not also notified and aware of the event.

Share this post


Link to post
Share on other sites
Then you have little choice but to use the producer/consumer model, which is what you've already got. The script can't be interupted and told to go handle this other event.

I would argue that you shouldn't be running the script in it's own thread unless absolutly neccessary.

Share this post


Link to post
Share on other sites
Yeah, thats what I was afraid of.

I guess i'll just place the events of the object in a member variable in the form of a queue and just poll the queue until it is empty. It should still be reasonably effective. The GUI element is going to be pretty lightweight anyways.


Share this post


Link to post
Share on other sites
Do you have one script running per GUI element, or one global script?

If it's a global script, you should probably use a global queu, instead of one in each object. If it's one script per object, you could consider changing to a fixed-framerate model. You give the elements a 'tick' function or something, and call it at regular intervals. You could then stick your entire GUI into a single thread, and even use the same event queu for managing the ticks. I imagine this will avoid a lot of the problems that arise with multithreading.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!