Interesting, wasn't aware about RCC++, just knowing internal studios roll those kind of thing in proprietary engines.
Cool idea to roll a separate framework for this.
In Coffee The Engine, I based the whole thing on component/plugin oriented design, working nice and should scale well.
Not sure how it's similar though, will take a look later on.
For communication between DLL's and EXE's using C++ a commonly used technique is to have virtual interfaces to systems, as this way you can pass around a pointer to a structure which holds the pointers to the interface of each sub system. This is the technique we used in Runtime Compiled C++ and it's also how the CryENGINE passes around interfaces using gEnv.
For a look at what a system table looks like see this file.
Exporting classes without using virtual interfaces is not simple in general, for an overview have a look at this post on codeproject. Using a virtual interface makes things alot easier - they don't have to be pure virtual but this does help to eliminate mistakes. Make sure to define a virtual destructor to prevent the memory created in one module being freed in another.
Feel free to use any of the code in RCC++, we use a liberal Zlib license and you can just use which-ever parts you need.
I just knew about Runtime Compiled C++ and must say, wow, amazing idea.
Interesting, wasn't aware about RCC++, just knowing internal studios roll those kind of thing in proprietary engines.
Cool idea to roll a separate framework for this.
In Coffee The Engine, I based the whole thing on component/plugin oriented design, working nice and should scale well.
Not sure how it's similar though, will take a look later on.
The approach in RCC++ is somewhat different from what I'm aware other teams have used in the past, as rather than simply allowing shared libraries (DLLs on Windows) to be reloaded dynamically RCC++ detects changes in files and compiles the minimal set of source files needed into a shared library then links this in. This gives a quicker turn around at the cost of some developer effort in code markup using macros.
I just knew about Runtime Compiled C++ and must say, wow, amazing idea.
Thanks :)
The approach in RCC++ is somewhat different from what I'm aware other teams have used in the past, as rather than simply allowing shared libraries (DLLs on Windows) to be reloaded dynamically RCC++ detects changes in files and compiles the minimal set of source files needed into a shared library then links this in. This gives a quicker turn around at the cost of some developer effort in code markup using macros.
Having instant reload of shared libraries isn't that simple, it's already the same job of having interfaces/macros and lot of tricky stuff... Depends if this is just some plugin system with init/exit method (as standard plugin systems) or full Objects creation/refresh handling (which is what "Runtime C++" means) I guess. Thats not the same, sure you know it, but I wanted to make it clear for others.
. Having full source files change detection is nice, but you loose IDE ability to have output/error reporting (double click to go to the error), not sure about debugging abilities, if some part is failing, what happens?
. Automatically separate the whole project in libs: I thought about it as well, but in Coffee's component based system it makes no point, it's already clearly separated. Rebuilding a simple component takes 1s, and build system already figure out which files need to be rebuilt.
. Coffee already have assets changes detection, that's why I may have extended it to source files as well, but I choose to only take built DLLs into account for the upper reasons.
RCC++ is a nice idea, but it seems hard to integrate it into an existing engine (with the usual existing custom build system, reflection and so on...), but for starting a new project from scratch it seriously looks like a great idea.
But, indeed, that's the future and some nice reason to stick to only one langage for the whole thing...
Having full source files change detection is nice, but you loose IDE ability to have output/error reporting (double click to go to the error), not sure about debugging abilities, if some part is failing, what happens?
All output is piped through a logging interface, and if you copy this to either stdio (on Linux/Mac OS X) or OutputDebugString (Windows) you get full double click to go to error support as well. Debugging is also handled similarly, with the added benefit of the game not stopping due to error catching (though this has issues with gdb which I need to sort out). See http://runtimecompiledcplusplus.blogspot.fr/2011/09/crash-protection.html
but it seems hard to integrate it into an existing engine
It's intended initial use is for scripting style additions to an engine. For this purpose it should be easier to add than adding something like lua or python. The problem at the moment is the lack of documentation, which I do hope to fix.
Okay, so you attach VS to the main exe, then use usual things, great!
Tried SEH years ago but I failed to enable it on whole project (unwinding problems or don't remember).
This looks good, will definitively follow your project.
Okay, so you attach VS to the main exe, then use usual things, great!
Tried SEH years ago but I failed to enable it on whole project (unwinding problems or don't remember).
This looks good, will definitively follow your project.
You can use our system outside of RCC++ with only a small amount of effort - have a look at RuntimeProtector.h and the implementation functions in RuntimeObjectSystem_Platform*.cpp
[Edit] Note that this will likely interfere with any crash handler like Breakpad, but since it's primarily intended for development I'd simply turn it off in shipping code if you use Breadpad in shipping code. I intend to look into a solution at some point.
Looks good, will see how to integrate RCC++ later on (will start with this part) and will see if I can use more as well, since it'll save lot of headache in future platform support.
Thanks.
