@Green Gandalf:
That is good to hear

Adding enumeration functionality for available graphics cards shouldn't be that hard to do; I'll add it to my ever-growing list of things to do for the release of 0.5... I just hope I can exhaust said list and actually get it released sometime!

And for once, something good that was included with Windows 10 and that weren't with Windows 7 then; I recall having to find, install and manually link to that thing back when I first started out with this project. Glad to hear it's working for you!
@James H:
Haha, don't worry about that; who doesn't get things mixed up every once in a while.
As for the license issue it's been a while now; maybe I just misinterpreted it (usually if something is ambigious to the degree that I can't say what it means for certain it seems the safer bet to just assume it's off the table).
That thing about having to include the license agreement rings a bell though - that is a tricky thing since I assume that it by extension means that all programs using my engine would then have to include said license agreement as well. And it would be quite difficult to hold people to making sure to include a dozen or so different README's with every small DBPro program they make and put up for downloading somewhere. Of course I could probably write some terms-of-use document myself that states that I'm not responsible for what users of my engine do or don't on that front but in all honesty I certainly can't write a legally sound such document myself and I won't ask (pay) for help doing it until version 1.0 is ready to go.
Currently there is a license agreement for the Assimp library that is included as a resource in the dll file itself; this should be good enough for that particular library as its agreement stated something along the lines of "this
text has to be included". But legal stuffs are by definition finicky and I wouldn't be surprised if the wording "this
file has to be included" unquestionably means that the literal text file must be supplied alongside the executable / dll.
But as said, it's entirely possible I got that agreement wrong and could in fact have used it after porting it to use DX11 for drawing. And yes, I'm certainly too far down the rabbit hole to change to that now
Green Gandalf wrote: "I've tracked the increase in size down to the presence of your "md5.dll" in the Compiler directory - when I replace that with the original DBPro version, the exe size for my game returns to its original value."
Indeed, the MD5 mod isn't particularly elegant; it will be replaced sometime in the future, either by a rebuilt Compiler.exe or another means.
In any case, the MD5 mod has two purposes:
• It hotpatches DBPCompiler.exe to allow reading more than 1000 string table entries per dll.
• It injects additional function calls in your to-be compiled code that keeps my plugin aware of line numbers and source file names to better report where an error occurred.
The hotpatching is the only "necessary" feature here; without this most functions are available, but there are ~80 that go beyond the arbitrary limit of 1000 functions / dll. As such you cannot call any "new" functions without the MD5.dll hack. Since most functions (all from versions earlier than 0.4.7.5) are below the id-1000 mark, all of the currently available example projects will work without this. As the engine grows and the dll function count grows in the future this problem will get more and more apparent though.
What causes the file size issues is the other feature of the modified MD5.dll.
As mentioned, additional function calls will be added to your source code - these functions all reside in DX11.dll, which means it will be included and add its ~4.4Mb to your final executable size.
I should probably make it search for function calls to DX11.dll and only add these calls then, but as for now you should be able to use this precompiler directive at the top of your source to disable the code injection:
#ZPC DISABLE ERROR LINE REPORTING