It appears my lack of experience (at least when I first attempted it) at getting those features to work under DM was the reason for not working. While I already know some who use Qt with DM, I have finally figured out a way to utilize both threads and widgets under DM conditions.
This method involves either utilizing a static QApplication object or a dynamically created one (used the former for the experiment) and use the two args provided within the function you use inside BYOND. Normally, it involves taking those two args from the int main() function. However, it appears doing it the way I did it worked like a charm regardless of no int main().
Now for threading, make sure to use static QThread objects or a dynamically created one. Do not set up a local variable version or it will cause Dream Seeker (or Dream Daemon) to crash. Once that is done, you should know how to do in terms of threading if you have knowledge of Qt threading. The good news about Qt threading is that upon exiting Dream Seeker (host/server only) or Dream Daemon even for event loops, no crash will occur. This used to not be the case with MSVC++ CRT or Win32 Threading until a few versions after DLL support was included. This is in reference to infinitely looped threads (for the most part), which now causes crashing upon exit.
For widgets, creating any widget will not freeze Dream Seeker (meaning so far from testing, no threading is necessary)! Make sure to setup a static QWidget or dynamically create it. Do not forget to establish a working QApplication at any point in your DLL or it will cause Dream Seeker/Dream Daemon to exit (with no warning). This means one who can utilize proper communication between DM and Qt will be able to achieve great results due to this.
Of course DLL (or SO actually) is still server-side, but thought I would share some working information. If anyone is interested, I will publicly post the experiment source later (both in C++ form created through Qt Creator and DM). Hope y'all who already know Qt (probably know more than myself) will enjoy this bit of information.
ID:620152
 Apr 2 2012, 7:40 pm
|
|
Oh, Bandock kind of just likes trying things out like this. I suppose out of this, one could create server-side UI apps to offer more complex control over the game world than DreamDaemon, generally skin a server-side UI for distribution, etc etc.
| |
Message to Forum_account:
I originally used threading in the past due to the fact if you did not create a thread for certain features or capabilities, it would freeze the entire server until the loop ended (which in some cases, would never end depending on what you're trying to accomplish). That was especially the case with speech recognition using Microsoft's SAPI as well as using Win32 windows (the latter was mostly for experimentation with Win32-created windows). Threading can be very useful for any special tasks that could freeze the server without them. Mainly tasks that can only be done in C++ (not referring to windows per se, since you can use interface elements as you stated for that sort of thing) such as speech recognition (referring to being able to use your own grammar structure that can specified in the XML format thanks to Microsoft SAPI's capabilities). Message to Stephen001: Yep. I like to do this sort of thing. In fact, I might as well let it out that I'm working on a networking engine for BYOND that does this sort of thing. Currently working out a bug though before I open any further testing. Could say the networking portion will not require any DLL/SO to function (handled by DM built-in capabilities). However, you will be able to utilize DLL/SO files through client-side due to this engine. | |
I suppose out of this, one could create server-side UI apps to offer more complex control over the game world than DreamDaemon, generally skin a server-side UI for distribution, etc etc. Which could also be done using the browser so it's remotely accessible. I originally used threading in the past due to the fact if you did not create a thread for certain features or capabilities, it would freeze the entire server until the loop ended (which in some cases, would never end depending on what you're trying to accomplish). That was especially the case with speech recognition using Microsoft's SAPI as well as using Win32 windows (the latter was mostly for experimentation with Win32-created windows). And what's the point of speech recognition? This sounds overly complex for something that has such limited use. It sounds like BYOND initiates a .dll call, but that's where the connection to BYOND ends. Whatever neat things are happening here, it sounds like BYOND is hardly involved. If you can put these features in Java applets you can expose them through the browser control to any client and easily have two-way communication between the BYOND world and the programs running on the clients. | |
Once experimented with speech recognition to give commands without needing to provide verbs. Of course one could go with just the speech recognition by itself without needing any grammar structure since one can just call the verb and any arguments involved. However, just thought it would be neat to utilize a working grammar structure.
And you now got me curious. I'm going to take a look at the Java Speech API now. | |
I can see some application of this going hand-in-hand with his other current project, a server/client architecture built within DM with mostly world.Export(). Being able to utilize an .so on the server and .dlls on the client, it wouldn't be too far of a stretch to utilize this to bypass BYOND's networking (call me silly) in an attempt to optimize, in a way, in places where BYOND's networking falls short from not being able to exactly fit your design. Some possible applications of that:
| |
Bringing back the topic a bit. I am currently thinking of ways to use sockets instead of the current world.Export method (as the latter does perform slowly, especially when called several times). Only reason why I did use world.Export is to see if I can maintain DM capabilities and actually try to merge them.
In reference to the experiments, here is the source I promised (of the current experiments): http://dl.dropbox.com/u/24250760/BYOND/ QT%20DLL%20Experiments%20Source.zip DLL part of the experiment was created through Qt Creator just to let y'all know. A new function has been added and called in world/New() to dynamically allocate memory for a single QApplication object (so it can be used when needed for reason, though untested). The experiment may receive an upgrade or at least another demo of some other features. In the meantime, feel free to play around with other Qt concepts with the experiment. | |
Bandock, does this mean we can try mixing the iPhone with BYOND? :)
| |
Zaltron wrote:
Bandock, does this mean we can try mixing the iPhone with BYOND? :) It is possible to do. I haven't experimented with iOS (since I currently lack any device with that OS), but would be a very nice thing to experiment. | |
Nice! I love using Qt libraries, i'll enjoy playing with this. :)
| |
If you can create something to listen for a socket or some other means let me know and I'll work on something for iOS.
| |
Fine by me Zaltron. :D
| |
It's possible to create socket connections using QTcpSocket and QTcpServer should work.
| |
Yeah. I thought about giving those sockets a try for the reason of allow cross-platform compilation (between creating a DLL file and a SO file).
| |
Here is a fun thought, we could make it so we can download all the contents of a BYOND game onto an iPad and play the BYOND game on the iPad with other users on computers.
| |
Now, that would be cool. A nice cross-platform/device way of playing a BYOND game (even without the need for flash, since I have heard no iOS based device supports flash natively at all).
| |
And would it work for all the iOS devices or just for ipad?
| |
If you want some interface elements that run in a separate thread you can use a browser control. It has much better integration with BYOND and it's not limited to running on the server.