🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Callbacks etc.
Author
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?
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?
Author
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.
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.
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.
I would argue that you shouldn't be running the script in it's own thread unless absolutly neccessary.
Author
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.
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.
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
