Years ago I found a interesting library called TinyCC, which provided a simple and small C compiler with one major twist… it can be embedded inside another application. Because of this, a program can compile new functions for itself at run time and call them using function pointers. In a sense it can be used like an immensely powerful scripting language, with the benefit that there is no speed hit due to interpretation or emulation. Its weakness as a scripting language is that you have to account for portability and security problems due to the execution of these ‘scripts’ running as native code on the host processor.
So far, I have used TinyCC for a few projects in the past and recently in a texture generator as well as my text adventure engine. The reason for this post however, is that TinyCC is not the most intuitive thing to embed into a windows application, so I wanted to take a moment to explain one clean method to do so.
There is no static library for use with visual C++ so that option is out, however since a fully compiled DLL file is included in the download package, it seemed that it would be easiest to dynamically link the DLL through code at run time. This requires loading the DLL and requesting all of the functions that are exported from it which is a fairly easy operation on any platform and generally differnt OS’s have much the same interface for doing so. The only tricky part is actually specifying all of the annoying function pointer casts correctly during binding.
Without farther talk, here is some straight forward code to load TinyCC and bind the interface for you. Which I hope it should all be fairly straight forward and easy to understand.
Today I pointed my browser towards The TIGSource website and saw a fresh post directing readers to a kickstarter for TinyKeep. While I am not exactly interested in the game itself, one thing on the site caught my eye. The team have developed an interactive demo for their random dungeon creation algorithm, and I really like it. It can generate nice looking dungeons, and the concepts it uses seems reasonably understandable. I wasn’t satisfied with just observing the demo to try and infer how it operates so I decided to take a peek under the hood.
I downloaded the flash object and pointed a shockwave flash decompiler at it, to find ~6000 lines of code. I guess that is because the decompiler doesn’t discriminate between linked libraries and regular program code.
Above is a picture taken nearing the end of the generation process. At this point it seems links are added until a minimum spanning tree is available or something, being highlighted by the thicker green lines.
The source is not as immediately helpful as I wanted it to be, but it turned up a few interesting hints. There is a mention of minimum spanning trees, which I remember casually skipping over while digesting my algorithms book. I have however since read that chapter again this morning, and now I have a pretty good idea of how these concepts can be used in this context.
So my task in building the Tengu Engine will be stalled for just a moment while I play with my own implementation and variation of this algorithm. In fact, procedural level creation is something that I haven’t read about actively so perhaps this algorithm is already well known, but being a feet first kind of person, I rather fancy just coding up my own before researching this stuff.