Blitz to non-blitz app comms
Blitz3D Forums/Blitz3D Programming/Blitz to non-blitz app comms
| ||
| Has anyone tried to control Blitz via another application? I'm thinking the best way to do this is with TCP comms. I've created a C++ application that connects as a client to a Blitz TCP server. The client then sends commands that it wants Blitz to perform. Has anyone tried this before or know where I can get examples of this working? I'm having problems with synchronisation. The reason I'm doing this is because I know C++ and would like to use it as the main controlling code and call Blitz graphics functions when necessary. Any comments? |
| ||
| Sounds clumsy, if you want to do this, then you better find a way making the apps share a block of memory. But if I were you, I would just learn basic. |
| ||
| just learn blitz... you don't currently have access to the rendering pipeline directly so you aren't going to get any benefits and you WILL get a lot of headaches. |
| ||
| Hi ! I've tried several ways to do this (code in C++ and just use Blitz for rendering), here are the solutions : - Using TCP : too slow for real time rendering - Using Shared Memory Block : faster than TCP, but too slow (ask Koriolis for infos about that, he wrote a DLL called BlitzBridge that allows c++ apps and Blitz apps to share the same memory block) I think there's no fast enough way to do this... Sorry ! JP PS : If you find a way to do that, I'd like to know about it. |
| ||
| Thanks guys. I might have to learn Basic - I just wanted to make sure there wasn't a good way of controlling Blitz externally before I did. I'll try and give BlitzBridge a go - do you know of a link to it? Kind regards |
| ||
| I did a similar thing using named pipes (or was it mailslots?) Anyway, It was just for fun and I didn't actually test how fast it was. I'll have a look in my pile of code and see if I can dig it up for you... |
| ||
| why don't you just use a 3rd party 3D library with c++? I would think that would give you more control..?!? |
| ||
| LarsG I have tried to find a C++ library that is as simple to use as blitz, but have yet to find one (that is as good). There are plenty of share-ware ones, but they suck. If anyone knows of a C++ 3D library that costs about the same as Blitz and is as good then I'd be happy as larry! |
| ||
| Most people think Basic is easier to learn than C++. If you already know C well I think you'll pick up Basic in no time. And by the way, even if you do that double app thing, it will probably be easiest if you use some Basic as well. |
| ||
| Hi JPL :D For BlitzBridge, actually I think I should as well have stuck to named pipes and not spent time emulating more or less the same functionality with shared memory. Though shared memory is probably slightly faster. The advantadge being that named pipes are standard, and doesn't require any additional DLL. |
| ||
| Koriolis Is there somewhere where I can download BlitzBridge or somewhere that explains how i works? |
| ||
| Still interested? It does nothing more than send/receive a string in some kind of pipe, nothing magical in that. It's then up to you to have the sender send the right messages and the receiver understand it and do the requested operation. Just a quick and dirty DLL (the max number of pipes and max size in messages is even hard coded). I'll send it to you by mail. |
| ||
| Ok - for some reason I thought you'd done it using shared memory. I'd still be interested if you can send it to me. Thanks |
| ||
| I did, but I needed it to handle simple commands (it was for an editor and the editor sent editing commands to the blitz app). So a pipe behaviour was ideal. What I did is implement some kind of pipes using shared memory. As I said I should probably have stuck to good old windows pipes. |
| ||
| Koriolis: How did you create your shared memory block? Searching on google for Shared Memory, all I found was Filemapping using INVALID_HANDLE. But this seems like a slow way to share memory as it uses the pagefile for this. However one method I found seems fast enough. Creating shared variables in a DLL using #pragma data_seg. Then both applications loads the DLL and reads/writes to these shared variables. Possibly using SetEvent/ResetEvent to prevent accessing the variable at the same time.(not mutexes as these has rumors of being "slow") One CodeProject.com, one guy created his own mutex(using the method above) which was VERY fast compared to the standard mutex. I think that his "mutex-version" locked and unlocked the mutex 100000 times in 250 milliseconds while the standard mutex took about 6800 milliseconds. |
| ||
| Yep, I used CreateFileMapping. I had absolutely no problem with the speed, which was expected when you just need to send a few editing commands here and there. As for the fact that it's backed up by the pagefile, *all* the memory is, I don't think there's such a big difference here compared to writing to any memory block. I may be wrong. In any case if you need speed don't assume anything. If you wanna know, make some tests and compare the results :) The method of using #pragma data_seg could be faster, that's not a bad idea. EDIT: And anyway don't take my DLL as a good example of how to do it. As I said it was really a quick and dirty one. |
| ||
| I haven't tested filemapping yet, but instead went straight for the DLL method. It's a very fast and easy method for sharing data between two or several applications, as long as one follow the rules. Don't share pointers and use some sort of syncronization(mutex for example) to keep the applications from accessing the shared mem at the "same time". Of course Microsoft recommends the filemapping method and I will try that. But if the filemapping proves to be "slow" then the DLL method will be my choice. Speed is of high importance in my current little project. |
   |