Newgrounds.com — Everything, By Everyone.

C++ Paradox has been through two overhauls now: once to Insanity, partially to change the name, now that I am aware of the existence of Paradox Interactive, a game publishing company, and partially to reorganize the file layout; once more to InsanityCOM, which uses Component Object Model principles to completely divide the interface (used by application code) from the implementation (the actual library code). InsanityCOM was the name I gave it while I was curious about how an implementation with COM would work, but I was still in favor of what is now the "classic" (deprecated) style.

The major bonus to a COM setup is that any headers used in the implementation are completely invisible to application code. For instance, before, the ConsoleDevice would include the iostream header, and this would expose the header in application code, even if the application should use the Insanity API rather than the C++ one.

A side bonus is that having separate source code and header files for Mac-specific implementations allows the use of the .mm file extension I expect will be prevalent.

A downside is that any template code must be implemented as a set of function overloads for all acceptable input types. The effect has only been felt so far with the input-output object interface (IIOObject), which has approximately fifteen overloads for each primary function, these being read, write, and writeLine.

The only template function in the code base so far is IObject::queryInterface(), which takes an explicit template parameter, and returns the calling object as a pointer to the requested type if the interface is supported, or nullptr if not. Anyone well-versed in C++ will point out that this is just a dynamic_cast, and they would be right on the money. All queryInterface does is "return dynamic_cast<_retType*>(this);" I'm sort of not sure why I included it, but the compiler will probably optimize it to dynamic_cast on its own anyway.

As a design consideration, Insanity will be just a platform abstraction framework. Any sort of game engine would be built on top of that. The only thing I've pinned down as definitely engine-level is mesh loading and drawing.

Tried going back to Parallels to iron out some issues in the level compile/decompile code. I think I managed to get them.