As there haven't been many (or indeed any) updates to DBPro since it (or rather the internal version pieced together to support GameGuru) went open source about a year ago, I am pleased to present DBPro 9Ex.

This is a pre-built version of DBPro that fixes various issues inherent in the open source'd version (available here on GitHub) and adds some extra features on top. As the name hints, it has also had it's DirectX version updated from 9.0c to 9Ex, which offers better interoperability with the Windows Desktop Manager on Windows Vista and later (while still working the same as 9.0c on Windows XP), enforces better memory management and potentially improves rendering efficiency a bit.
If there is enough interest and bug reports and/or feature requests I will try to keep updating it, though my main project will remain my Ziggurat Engine.

So, what benefits does this version offer compared to the vanilla GitHub version, or the old version 1.7.6 or RC 1.7.7?Bug fixesThis is not a complete list but rather the major ones. Fixed compatibility with most (hopefully all? Let me know if you find any that aren't working!) third party plugins. Fixed a bug where the compiler would experience a stack overflow and crash for large sources that contained too many labels and/or functions. Fixed various memory leaks present in the DBPro source. Removed all references to GameGuru and its documentation / website from error messages and replaced them with the standard DBPro ones, ie. "image does not exist at line xxx" and so on. Fixed a bug where multisampling was broken and would cause a crash if set through SET DISPLAY MODE. Fixed a bug where the icon of compiled executables could not be changed. Included media now works as intended and can be loaded at runtime. Various other fixes to restore standard DBPro behaviour that was altered for GameGuru, such as programs starting with backdrop on and sync off instead of the opposite values and similar.

New features Improved resource management will free up more RAM and potentially increase rendering times a bit (depends on your hardware and program complexity). Display modes can be changed during runtime without having to reload all video memory resources. This includes the possibility to tab in and out of a fullscreen application without having to reload media. (Requires Windows Vista or higher). Improved compilation times (may not apply if using multiple and/or slow third party precompilers). Supports sharing images with my DX11 Plugin, ie. you can render to an image from DX11 and use it as a texture in DX9 or the other way around, or do more advanced stuff like render an image normally in DBPro, then use the DX11 Plugin to utilize compute shading, and then use the final result in standard DBPro again. (This feature will only be available starting with the next release of my DX11 plugin (version 0.5), but the necessary groundwork is present in this version of the DBPro core library). The arbitrary limit of at most 1000 exported commands per third party library has been removed and custom plugins can now have however many functions they please available to DBPro (there is a hard limit of 32767 exported functions per dll imposed by Windows however). Supports third-party precompilers. See below for more information regarding this.

Differences
There are a few small differences between this version and DBPro 1.7+ / the GitHub version that one should be aware of.
There may also be more such differences imposed by the upgrade from DX9.0c to DX9Ex that have yet to be discovered. The currently known ones are as follows: When setting the BorderColor attribute from a shader technique (.fx) file, this now expects a DWORD colour rather than a float4. This is due to a later version of the Effects Framework being used than with earlier DBPro versions.
As such your shaders may not be working as intended until you change this setting. Please refer to the following table for details on how the syntaxes look:+ Code Snippet

// The arguments are floats in the 0..1 range. This was used by previous DBPro versions, but cannot be used with DBPro 9Ex.
BorderColor = float4(red, green, blue, alpha);
// This is the proper way to set a border colour shader attribute with DBPro 9Ex.
// The channel values are bytes in hexadecimal notation ranging from 0x00 to 0xff, where 0x00 = 0.0 and 0xff = 1.0.
BorderColor = 0xaarrggbb;

The bone palette size for meshes has been reduced from 256 to 255 bones per mesh on the CPU side. This is largely irrelevant as shaders only support up to 60 bones per mesh in any case. CharacterCreator model support has been removed. This can be reintroduced if requested, but it appears to be GameGuru specific and just a waste of space in normal DBPro projects. There also is/was no functionality built into the GitHub version of DBPro that supports actually creating CharacterCreator models from DBPro.

Precompiler
DBPro 9Ex comes with a built-in system for adding and chaining up third-party precompilers.
A precompiler is a dll that exports some or all of the following functions:+ Code Snippet

/**
* This function must be exported by all legal precompilers.
* It is used to receive data from the compiler process that are necessary for the
* static library (Precompiler.lib) to function.
*
* @param void* pData - The data received from the compiler module. Must be forwarded to Precompiler.lib using dbpc::SetInternalData().
**/
__declspec(dllexport) void ReceiveCompilerData(void *pData) {
// This needs to be forwarded to the internal implementation of Precompiler.lib.
// We can store it for our own use as well from here if desired.
dbpc::SetInternalData(pData);
}
/**
* This is the main function of the precompiler.
* It will receive a pointer to a dbpc::Project instance that contains the full source¹ of the project being compiled.
* By using the member functions exposed by the Project instance, the source can be altered (added to, removed from or
* otherwise changed) before it gets processed by the compiler.
* You must not manually delete the Project or any of its members; instead use the provided interface to insert or
* remove source code.
*
* (¹) Some preprocessing is carried out prior to any third party precompilers being invoked, namely:
* • All #include directives are resolved and the included source files are added as Source instances to the Project instance.
* The "#include ...." statements are removed from the source that is received here.
* • All comments and empty lines are removed from the sources.
* As such you won't see any comments from a precompiler; nor should a precompiler insert its own comments or #include directives.
* A precompiler that wants to include an external file can do so through the Project::AddSource() member function.
*
* @param Project* pProject - The project instance that is being precompiled. Any changes made to this will be carried on to the
* next precompiler in line (if any) and eventually will be processed by the compiler itself.
* @return bool - If there was an error during precompilation, «false» should be returned.
* This will stop the compilation process and the user should ideally be prompted as to what is wrong such that
* he can change his source and try again.
* If the precompilation finishes successfully, «true» should be returned.
**/
__declspec(dllexport) bool Precompile(dbpc::Project *pProject) {
// Step through all sources and all of their lines
for(size_t s = 0; s < pProject->GetNumSources(); s++) {
dbpc::Source *pSource = pProject->GetSource(s);
dbpc::Line *pLine = pSource->GetFirstLine();
while(pLine) {
// Can check the line contents here and change it, remove the line, insert new lines, and so on.
// See the header files in Compiler/Precompiler/bin/include for more details on the available functionality.
pLine = pLine->GetNext();
}
}
return true;
}
/**
* This is an optional function.
* When exported, its returned string will be used when displaying information pertaining to this precompiler.
* At the current time this is only employed in error messages.
* If a precompiler doesn't export this function, the file name will be used instead in any situations where
* the particular precompiler is referenced.
*
* @return const char* - The name of the precompiler
**/
__declspec(dllexport) const char* GetPrecompilerName() {
return "Example precompiler";
}
/**
* This is another optional function.
* When exported, it sets the priority value that will be used to determine in what order to invoke multiple
* precompilers. A lower value means the precompiler will be run earlier, while a higher value means it will
* be run later. If two or more precompilers share the same priority value their order among eachothers is
* undefined, but they will otherwise appear at the "correct" place determined by said priority value among
* any other precompilers having different values.
* If this function is not exported, a priority value of zero will be used for the precompiler.
* Take note that the priority value can be negative in order to place it before any such zero-priority
* precompilers.
*
* @return int - The priority value of the precompiler
**/
__declspec(dllexport) int GetPrecompilerPriority() {
// This precompiler will be run after any precompilers with a priority
// value of 0 or below, but before any with a priority of 2 or higher
return 1;
}

Precompilers offer a way to alter the source code before it gets sent to the compiler and facilitates certain functionality that cannot reasonably be implemented in a plugin, such as macros or line number reporting to third party dll's.
If you want to write a precompiler there is a static library to link against, as well as a pair of header files included in the download under the Compiler\Precompiler\bin directory. Please refer to the above snippet for the basic functions that your precompiler has to / can export. An open source precompiler example project may be supplied at a later date.

Installation
Simply unpack the archive to your DarkBASIC Professional installation directory, overwriting any conflicting files.You may want to back your original DBPro installation files up first!
There are no additional help or keyword files in this release as it mainly serves to fix and improve on the original DBPro to which you are assumed to already have documentation.
If not, you can download it from the GitHub repository here. Simply install that and overwrite any conflicting files with the ones in the DBPro 9Ex archive.
The new features do not come with new documentation as they are either just updates to previously existing (and documented) functionality or it is handled internally / automatically and not through third party plugins.

Donations
DBPro 9Ex is free to download and use as you please. A mention in the credits of anything you create using it would be nice, but is not required.
If you like my work and would like to contribute towards its future development you can do so through this Patreon page. Or if you prefer, you can send me some money over PayPal to . The Patreon page offers some pledge rewards geared towards my Ziggurat Engine where you can get early alpha testing access to new releases, get an option to disable the splash screen and version watermark, suggest a command or get the product for free once version 1 is released. These same rewards can be agreed upon through PayPal contributions if you contact me.
While I would of course appreciate such contributions, which will first and foremost be invested in obtaining some more up-to-date hardware to further my work on the Ziggurat Engine, it is by no means a requirement. Seeing some new life breathed into the DBPro community would be enough of a reward in itself.

########################################
# Build 1.0.0.1 on 2016-10-01
########################################
# § Fixed a bug where the compiler could crash when trying to release allocated memory.
# § Third party libraries are no longer loaded as executable modules during compilation;
# this prevents them from raising errors about missing external files that will not be
# present during the compilation process.
# § Fixed a bug where using certain shader functionality caused a crash when applying the effect.
# § Added a new function, USE LEGACY SHADER COMPILER, for using the less strict shader compiler
# employed by earlier DBPro versions. This allows to compile certain shaders that don't fully
# adhere to the strict HLSL standard without warnings. It is however adviced that you instead
# update any shaders to adhere to the stricter rules imposed by the newer shader compiler.
########################################
# Build 1.0.0.2 on 2016-10-05
########################################
# § Fixed a bug where the attached SC_Collision.dll was using an older mesh format left over from
# pre-release testing, resulting in crashes if trying to use it.
# § The issue where compilation would fail for whitespace-separated comments following an EXIT
# instruction has been resolved.
# § Added an optional setting to have the precompiler use the IDE-supplied full source dump rather
# than rebuild this from the source files. Add the following to your Setup.ini file (in the
# compiler folder) to control this setting:
# [PRECOMPILER]
# UseIDESourceDump=Yes # Or set it to "No" to disable. Will be disabled by default.
# This setting is disabled by default so unless you want to use it you don't have to alter your
# configuration file.
# This should allow IDEs that don't automatically save on compilation to work with the new precompiler,
# however beware that this will reintroduce the old issues where you will get errors like
# "Failed to xxx at line 29496" and then have you manually figure out that this is in fact line 48 in
# include file #12.
# There may also be issues with using the #include directive with older IDEs that may not properly resolve
# this (I recall the official IDE had this problem a few years back, though it may have been fixed by now).
########################################
# Build 1.0.0.3 on 2016-10-09
########################################
# § Fixed a bug where any combination of multiple whitespace characters inside a string would be condensed
# into a single whitespace.
# § Reintroduced the MESHRADIUS shader constant that was removed in 2011. Fixes issues with shaders using it.
# § Fixed an issue where the ABS() function was missing from previous builds.
# § Fixed an issue where the render target would be cleared in the middle of a two-step reflection shading pass.
# § Visual styles are now enabled for compiled programs, letting your Windows GUI applications use more
# modern themes.
########################################
# Build 1.0.0.4 on 2016-10-23
########################################
# § Issues with various third party plugins that originated from the plugin assuming functionality present in DirectX 9.0c
# that has since been removed in DirecX 9Ex have been addressed by manually implementing emulations of these, seamlessly
# forwarded to the plugin through the D3D interface.
# § Added new keywords to utilize the resource management functionality mentioned above for texture created through the DBPro
# runtime that will later be used by plugins assuming such functionality; these are as follows:
# ENABLE VIRTUAL TEXTURE MANAGEMENT
# DISABLE VIRTUAL TEXTURE MANAGEMENT
# IS VIRTUAL TEXTURE MANAGEMENT ENABLED
# § Now supports plugins that will attempt to access DirectX directly from another thread.
# Use the precompiler directive #USE MULTITHREADED DIRECTX to enable this for your project.
# § Single PRINT commands and the like should now handle dual buffering properly when backdrop clearing is disabled.
# § Fixed a memory leak in the precompiler.
# § The "About" dialog will now display the installed DBPro9Ex version.
# § Changes to the compiler has necessitated a new version of the Precompiler library. This means that any precompilers
# written using the old library will have to be recompiled with the new one to function properly. No code changes will
# be necessary; the changes are all internal.

@Rudolpho-well done, this is really great to see. I will definitely be making a donation to this project. Thanks for the new update, I will try this out, great to see that some of the issues have been resolved such as the dreaded GameGuru Icon and SET DISPLAY MODE issue. Don't come to these forums as much as I used to but it's great to see DBPro being given an 'overhaul'.

God bless you Rudolpho!
Make some quick tests with most plugins I can find.
Errors and issues:
( I install over original registered DBPro )
1) message for missing "physxloaderCHECKED.dll" in DarkDynamix Boned Ragdoll demo
2) BBB Gui also asked for USkin.dll ( but it in the folder with exe ) .Still after that exe is created and run
3) Evolveds Advanced lighting crashed compiler without any info.Still after that exe is created and run ( get fps boost from 179 to 188 )
4) advanced sprites - crashed with no info

Despite to this minor issues I can say its good job!
I pledge some cash in a week.

@Kuper:
Thanks for reporting those issues.
I was unable to replicate the first one. Do you have the PhysXLoaderCHECKED.dll file? I think it has to be placed in a "bin" subfolder relative to where your executable is; that is how it is set up in all the example projects I have at any rate. If it still happens, what version of the Dark Dynamix plugin are you using? Perhaps I have a different one.

BBB Gui seems to be looking for USkin.dll from DllMain. This shouldn't really be done by third party libraries as that one is run whenever the dll is loaded. What is happening here is that all dll's are loaded by the compiler to scan them for what functions they contain. When this happens the compiler's working directory will be used and it won't find that USkin.dll if it is in your program's folder. While the compiler could be changed to use the to-be-built executable's directory instead. A better solution is probably to drop USkin.dll alongside the BBB plugin in Compiler\plugins-user. The best solution would of course be if the plugin could be updated to not load external files from DllMain at all, but rather from the PreConstructor, Constructor or ReceiveCoreDataPtr function. Try to put USkin.dll in the plugins-user folder and let me know whether it helps though.

With Advanced Lighting things get worse. I managed to experience what I assume is the same issue using the Terrain Example from the 2015 version. It appears that this is caused by a heap corruption in the compiler. The executable is still built properly and the crash only occurs when the messed up heap is detected when the compiler process is releasing its allocated memory. This is one of the worst kinds of bugs to resolve as it can basically be caused by any single dynamic memory-accessing operation in the entire program and once the crash come the reason for it is long gone, so this may take some time to resolve. It is odd that it hasn't been detected in any other projects though. I'm currently a bit swamped at work as well, but I will try to look into it when I'm able and should hopefully be able to get it sorted out eventually.

Finally Advanced Sprites crashes with a null dereference from DXS CREATE EMPTY SPRITE. I haven't been able to pinpoint the exact cause for this yet, though that dll accesses DirectX functionality directly so it is possible that it can be an issue caused by some function working differently between the 9c and 9Ex versions.

Again, thanks for bringing this to my attention and for your kind words

Missing DLL Solved: Place NxCharacter,PhysX , USkin and other dlls in "Dark Basic Professional\Compiler" folder and your project folder.
P.S.
Found trouble with DarkLights.Its compiling but get errors in lightmap creation.I think its because darkLights commands were addded
to DBPro source code when Lee start to work on GameGuru.
P.S.S
DarkVideo plugin doesn't work.If anybody remember it? I've checked version 1 and 2.No errors just only sound and no video.

Awesome work as always Rudolph, you are one busy and productive guy! Looking forward to trying this out and I'll see what I can do towards a contribution.

Regarding memory leaks, one of the big ones was with set object effect, all resources were not being released when an object that had shaders applied was deleted without first detaching the textures and effect in very specific orders.

A single player RPG featuring a branching, player driven storyline of meaningful choices and multiple endings alongside challenging active combat and intelligent AI.

I am having trouble with IDE's though to say the least. So I started to tackle this with the editor it comes shipped with. Basically I first noticed this with a simple project I had, just the main source file and couple of additional source files, turns out for every edit I made to one of the additional source files - nothing changed that should have, I was merely adding; print "test" to a subroutine that outputs data to screen. So after messing around a bit I discovered that I had to make the edit, save and then close the editor, delete the bak file and exe, open the editor then open the project again, then when I compiled and ran the edits I made did indeed come into effect. I haven't played round with this nearly enough yet, but I do not wish to continue working on fresh projects until the matter is resolved. I will hasten to find out if there is some hidden indentation or nesting issue causing problems or something else like #include or manual include or which editor was used to save the project files maybe. I just don't have the time right now and I certainly don't want to be making edits, saving reopening after deleting files etc every time I want to write a teeny bit of code. I ditched other editors in favour of Indigo simply because after realising issues related to synergy saving every edit to the project files during compilation process, the original IDE being crappier than crap and only some editors being not fully compatible with newton physics plugin(ie codesurge had control issues for FPS example), well I wanted one that worked across the board, which up until now was Indigo. Basically with testing various versions of dbp ie vanilla digital purchase with various updates, vanilla free version with various updates, gameguru open source version, along with lord knows how many purchased plugins along with the free 3rd party plugins for each version, well I didn't want to obfuscate matters by having to keep tabs on which editor as well! I actually am now keeping tabs to some degree on which editors work best for which projects along with dependencies for the end user such as the newton dll or msvcr/p.dll for M1Utils. I just have a lot of older projects that take a fair amount of effort to work out what will get them running again lol.
I did then go and rem out some key functions of the main source for advanced lighting terrain demo(once I had it working after the whole shaderdata.dll nosense mentioned below in my statement to Kuper). Once again the only way to get any of these edits to take effect was to save, end the IDE, remove bak and exe(might not have to remove exe haven't checked that out yet) then reopen the editor and load in the project and of course recompile. So whatever the issue is it affects the main source file as well as any includes. In the simpler project the includes where added manually and the advanced lighting demo they are included with the #include command. Not that this helps but it is an observation!

Kuper
The Advanced lighting issue - is perhaps a mirage of sorts, the editor compiles then ends silently, but if you check the output window there should be an error message indicating it did not recognise get object effect command. This is because of missing dll - shaderdata.dll which neither the open source(GG edition) or 9Ex come with. I have old dbp as well as dark shader so not sure which of the two is responsible for it's existence but by copying it over(shaderdata.dll) I was then able to compile and run. Before that when I compiled it simply did not create a fresh executable so I think therefore you did not delete the old executable manually. When compilation fails the editor/compiler only seem to delete the old executable if compilation is successful. Much of the whole compilation process we take for granted as to us it is just the F5 key and that is that lol but sometimes we have to work out what went wrong and when before we know why and how to resolve it if possible. Based on this finding I suspect Advanced lighting will work fine with the gameguru opensource edition once the dll is copied over as well.

On the whole though - having read and re-read the OP, I am looking forward to playing around with this a lot - providing I can get a decent solution for an editor that compiles and runs without saving and also without having to go through the rigmarole of making edits/saving/deleting files and reopening for every little change I make before I can recompile and run! I am especially loving the way this is aiming to resolve matters like plugins working, display resolution changes at run time without loss of media, bug fixes of various natures, fixing the included media and icon issues, cleaning up the GG related stuff, well i won't bother to list what you already have listed lol but it does all sound very promising indeed - and we have a faster compiler than vanilla versions that you have managed to improve upon as well! Okay I haven't even began testing but along with that input plugin you have provided - for free - and dx11 support on the way, well the future for dbp is looking a lot brighter and fresher than it was! Many thanks

@James H
I have no message in DBPro output window.In window7 said that I get ntdll.dll as error cause.
Previously I think that something wrong with "get object effect" command.But when I create new small project with it there was no error at all.
Also I pasted "shaderdata.dll" everywhere but it gave nothing.

Well ntdll is an MS file and the command get object effect is from the shaderdata.dll and belongs in the plugins user folder. It simply can't compile if the command doesn't exist? I am fairly sure but not 100% that I installed dark shader and it's dbp runtime component after I upgraded to u7.7rc7 as I am pretty sure Evolved used it in past versions of AL(later updates for dbp MAY have included the shaderdata.dll so there MAY be two versions out there). The file size I have for shaderdata.dll is 132kb - is yours the same size and in the plugins user folder? Where ntdll is concerned the only time I ever had windows throw an error message of this nature was when I updated Nvidia drivers and BF4 took exception to the driver update, I had to revert back to correct it. Without the shaderdata.dll I cannot get it to compile AL - you will duly note that the keywords file with the command syntax is also named shaderdata and I cannot find the command anywhere else...if you have recently updated drivers then perhaps consider reverting back to what they was before the update. If you have nvidia card I can tell you I am using 372.70 driver version which is also available for win7, I have not tried the latest 372.90 though(21st sept). You may also want to try uninstalling drivers for nvidia if you have an nvidia card and reinstalling using the "clean install" option as I have found this messed me up in the past thinking it was a fresh clean install - you may have to choose custom install to get that option though which is where I think I went wrong. If you also use geforce experience and it happens to be their latest overhauled version(gets automatically installed if you had auto update option switched on or choose to update it through geforce experience), then uninstalling that to would be my advice - it messed up my shadow play by means of denying me access to it all together and also threw ntdll errors my way when playing BF4. Instead just download 372.70 drivers and the old geforce experience version is included with that.

played around a little bit today, installed over a copy of the old paid vanilla, U77

my project using AdvLighting, Matrix1, EZrotate, Sparky's, Cloggy's d3d, and Duffers sqlite, some windows dlls, and mabye a few others compiles and runs without issues from the editor.

approx 15k lines of code, I haven't benchmarked the compile times yet, but it does seem a bit faster. final exe comes up the same size as stock U77 at 13345 kb

Interestingly though, If I compile from the command line by passing the .dbpro filepath as an argument to the compiler, it compiles without error, but grows to 13770 kb and crashes with an '... has stopped working' error while loading. this is with the same .dbpro file, same single combined .dba source file produced by the editor, same directories etc.

A single player RPG featuring a branching, player driven storyline of meaningful choices and multiple endings alongside challenging active combat and intelligent AI.

Quote: "played around a little bit today, installed over a copy of the old paid vanilla, U77"

Sweet I will give that a try next, see if it resolves my editor issues.

Quote: "runs without issues from the editor"

Which editor may I ask?

Quote: "I haven't benchmarked the compile times yet"

Where Evolved's AL terrain demo is concerned there is a very large difference at my end, most pleasing. The AL plugin is fast but when it comes to tinkering with the code then it WAS a problem having the compiler take so darn long.

Ortu - yeap same date my end for shaderdata.dll, must come with one of the later updates I think, at least we know for sure DS is not needed so folks should be able to get a hold of it with relative ease.

stock EditorNew, but ah damn, you know what.... I hadn't updated the path to the compiler in the editor options, it was still compiling against the old u77 directory compiler.

pointed it to 9ex compiler, noticeably faster compile times now, but final file size has crept up further to 13777 kb (actually it seems to vary between 13770 and 13777 between compiles) and now gives the same crash while loading.

Later tonight I'll do some debugging to weed out what exactly it is crashing on (at least it's a runtime crash, logging and step through should help), I'll keep you all updated.

A single player RPG featuring a branching, player driven storyline of meaningful choices and multiple endings alongside challenging active combat and intelligent AI.

The terrain demo compiles and runs normally, so the crash is actually something in my project, handled within the sync that isn't present in terrain demo, though my project does not crash here compiled against u77.

Next I will work from the terrain, Palm trees, and fast bone demos, adding in things from my project to see if I can introduce the crash into a known good demo, and narrow down what is doing it.

Here is some compile time benchmarking though, pretty amazing.

Three compiles with each of ~15k lines, AdvLighting, and multiple plugins

U77
54s 990ms
53s 620ms
50s 690ms

GG/9Ex
8s 961ms
8s 813ms
8s 888ms

This pc is to low spec to bench mark runtime performance, but I'll check that on my gaming pc tonight

A single player RPG featuring a branching, player driven storyline of meaningful choices and multiple endings alongside challenging active combat and intelligent AI.

It appears to be referring to compiling the shaders not the exe. The exe is compiled without error, this error comes up at run time then immediately turns over to '...has stopped working' after you click OK

This looks to be a separate issue with points lights (error does not occur if point lights are removed or replaced with a directional light on this demo) The stopped working crash happens when applying either of these shaders to a bone animated object:

Oh hm... does it not work if you put those dll's in Dark Basic Professional\Compiler\plugins-user? If so that should be a pretty easy fix. If not I don't really see how these plugins worked with older compilers either; you can only have one CWD at a time. I may have to take a look at which one the older compilers actually use, should be easy enough to do.

Kuper wrote: "DarkVideo plugin doesn't work.If anybody remember it? I've checked version 1 and 2. No errors just only sound and no video."

I don't have that plugin, is it available from anywhere?

Ortu wrote: "Regarding memory leaks, one of the big ones was with set object effect, all resources were not being released when an object that had shaders applied was deleted without first detaching the textures and effect in very specific orders."

I think you're supposed to unload those manually by calling SET OBJECT EFFECTobj, 0. There is no reason that that couldn't (and shouldn't) be handled automatically when deleting the object though, I'll look into it.

James H wrote: "... This is because of missing dll - shaderdata.dll which neither the open source(GG edition) or 9Ex come with."

This is correct; ShaderData.dll stems from DarkShader, but I think a (possibly stripped down) version came to be included with later DBPro releases as a "standard" library. It's source is not present in the GitHub version however.
Also, as Kuper points out, there is yet another issue that seems to be due to a heap corruption (which tends to eventually raise errors in ntdll.dll) in the compiler even when the ShaderData library is present. Oddly this only seems to happen for some Advanced Lighting projects, so it is hard to pinpoint what may be the cause.

Besides that, would you care to elaborate a bit on these IDE issues you're experiencing? I'm not quite able to tell whether you started encountering these issues with DBPro 9Ex or if they were pre-existing issues?
I haven't made any changes at all to the IDE (indeed I don't even have its source). There is a difference with how the 9Ex compiler handles projects though; while previously the IDE was responsible for concatenating the full source from all includes to a single (temporary) file that was then fed to the compiler, this is now handled by my precompiler framework. In case this may have anything to do with what you refer to as having to "save the source files" before compiling? Though as far as I know all available IDEs should save on compilation anyway (and for blank projects they still create and resave a temporary source file for you).

@Ortu: Hm that is interesting. One of the changes I made to the object module was to remove one of its bone entries to make room for some other data required for backwards compatibility with third party plugins. It feels like it could well be related to this; however at most 60 bones should be available to shaders so I didn't think anybody would actually use 256 bones, even if there were that many available. This warrants a deeper look. Do you perchance have a bare-minimums reduced code snippet that reproduces this issue?
Also about that error message, have you looked at the shader file and verified that it indeed does have a return value on all control paths? It is quite possible that the newer FX compiler is more strict compared to the previously used one.

Ortu - I said I would try overwriting vanilla U7.7RC7 with 9Ex, I did give it a shot and it sort of helped with my IDE issue, basically the only IDE that I can get working with this is EditorNew - not the Github version though. It does mean though I now have to put up with the advert section(navigation to this page error instead of adverts) and of course it bloody well saves every single compile which is not something I like at all - in fact I detest this if truth be known. I tested Codesurge, EditorNew that is shipped with open source Github version(7000kb), EditorNew from vanilla DBP(6947kb), original IDE from vanilla DBP and Indigo. At least I have something to test with now so there's that lol! So big thank you for that idea, I am somewhat backward for not thinking of doing it your way! I can now move forward

Rudolpho -

Quote: "Though as far as I know all available IDEs should save on compilation anyway (and for blank projects they still create and resave a temporary source file for you)"

The original IDE and Indigo don't save to the projects source files for every compilation - which is what I want, too many times I have been caught out with failed undo's and redo's completely messing up code which then means lose all code after the last compilation and mess about with the temp dba which with larger projects can be annoying, of course on some occasions I am speaking of code that to me is complex and my teeny brain struggled to get it written in the first place - when I know deep down it should work as I think a heck of a lot before I will even start coding. I like to save when I want to save, I can then rely on the temp dba should any issues like a fuse box trip occur or as is sometimes the case here, my electric meter needs topping up(pre-pay meter) and I had forgotten to do so.

My IDE issue is and isn't a pre existing issue, well it is pre existing but only because of the obfuscation caused by many variations of DBP - bare with me here...basically there are so many upgrades and compiled versions available to us now, each with their own pros and cons. For various projects I have, there have been issues relating to these pros and cons both past and present. I progress projects in a manner that means I am not boring myself to death so as to avoid procrastination which I do a LOT anyway! A lot of said projects are more like tests of various ideas and I like to keep a library of them in two states - pending and completed.

So I basically have installed each version of DBP(based on compilation version, upgrade and of course various combinations of plugins) in "The Game Creators" folder - each with an ad hoc suffix after the basic name of "Dark Basic Profesional Online). I then have a text file in the same TGC folder, when I change which version of DBP I want to use, I remove the ad hoc suffix from the folder name and save it in the text file, once I am done I reverse the process. Now in each project folder I have another text file named "version info", the version I am using for that project has the ad hoc suffix in said text file along with details of compilation dependencies, end user dependencies and IDE details( for example some newton physics demo's require specific IDE's) along with any notes on said project(in each folder of each version of DBP I have a similar file without the notes). This enables me to pick a project or more often than not a group of projects to work on, find the right DBP version, change the installed folder's name and then double click the project files at will.

Now Indigo is a separate install to the other IDE's in as much as it is not in the DBP install folder as is the case with Codesurge IDE. These require admin rights to be set else I get the failed to load dba error. This is the same for the other IDE's but they are best left alone and simply add admin rights to the Launch.exe. This is because I also have the vanilla FREE version of DBP as well as the paid for version. I have this version in case there are differences between these versions, as you may agree trusting what TGC give to us for free cannot be taken for granted to be trusted to work as we might expect - as we have seen with for example, the advice relating to online registering and being told to overwrite it with everything from GitHub, although so far the only difference I have discovered between paid for and free vanilla is just media and projects - specifically I wanted the dx9 shader example with aiko.x and fast bone shader. Originally when they switched forums I couldn't find newsletters and the search facility was so lame I may not have found which newsletter had the download for the dx9 shader demo so I felt I had a need for free version for this alone(I now know how to find them and use Google to search the forum properly). The problem is it messed up my registry or something as the install folder is named "Dark Basic Professional Free", which caused me to have to switch from having shipped editors with admin rights back to having the Launch.exe with admin rights - because they where having issues finding the compiler and where not saving the compiler path. Every time I opened them they would be set back to look for the vanilla free version of DBP's compiler.

So in the end I renamed the vanilla free version's folder to match the DBP online name. This was basically the only way I could set file associations and everything to work hunky dory with regards to the start of my work flow. To this end Indgo was my main IDE up until I installed the free vanilla version which means i now have to right click the project and choose from the "open with" option which does seem to work for the other IDE's regardless of the fact that they don't have admin rights, perhaps somewhere within Windows the registry is accessed and runs it through the Launch.exe? I dunno but it's really weird lol. To clarify I tend not to switch between DBP versions per project folder per se, many projects relate to each other with the intention of then integrating them into one project after I have ironed out bugs or ideas I wanted to test. Since the free vanilla version install, whenever I choose to open a project from inside the IDE's it never remembers locations from previous project. This slows me down as I store my projects along with a shed load of other stuff on a 1Tb hdd and while I try and recall what group of projects I am working on and where to guide the IDE to, well I tend to forget things relating to ideas I had between relating projects - hence the need to open projects by file quickly by using the open folders navigation quickly.

So as you can see this is definitely an issue local to myself that you need not fuss over. You could argue a fresh start is in order of DBP versions leaving out the vanilla free version, but folks are still only able to get this version instead of GitHub version(hakimfullmetal has hosted it since only the GitHub version was available) and I like to help out if I can as I have taken from this community so much over the years. With new versions on the horizon, old users returning with whatever version they have and of course my horrid need to help people, well it is best if I have all versions lol!!

I actually only rediscovered some of this info since my last post here as I had forgotten the reasons behind my over complicated system to aid workflow which was built up over time, but I have trusted my decisions however bad anyone here thinks they where and so far I have been happy with it especially since the GitHub open source version became available and TGC stopped providing the free vanilla version along with no online verification process. To put it simply my brain is tiny compared to many here, I need a system to rely on like this or else I would forget over time a lot of it as I have already proven!

Ah I see... have you perchance considered version management software? It sounds like it could be helpful in your setup. It might also be easier to work with shortcuts rather than having to rename the folders time and again.

As an update, I've fixed the issue where dll's that depend on external plugins would fail to load them during compilation (BBB GUI, presumably DarkDynamix).
I will keep hammering away at the Advanced Lighting compiler crash tomorrow.

Addressed issues: The compiler crash occurring with Advanced Lighting has been fixed. Third-party libraries will not have their DllMain function called by the compiler anymore unless they export special licensing functions that require them to be loaded at compile time. This solves the issue with plugins like BBB GUI failing to load external files during compilation. A runtime crash that would occur when using extended shader data (such as bone data) has been fixed. This fixes the crashing behaviour in the bone animation Advanced Lighting example. Added a new command, USE LEGACY SHADER COMPILER.

Regarding the bone animation example from Advanced Lighting, it will no longer crash but will still show a message box about incorrect shader syntax.
This is caused by a newer version of fxc (the DirectX shader compiler) being used compared to older DBPro versions. This compiler is a bit more strict when parsing shaders and will for example consider the lack of a return type in the pixel shaders in Shaders\Lighting\Point Shadow\11.fx.
The best course of action is to change any shaders the compiler complains about to conform to the standards it expects, however you can alternatively use the new command USE LEGACY SHADER COMPILER at the beginning of your DBPro code to use the old compiler instead. The new one performs better however, and the errors it reports are still errors in older HLSL versions as well, even if the old compiler just makes an assumption on how to fix it by itself behind the scenes. Furthermore, the October 2006 DirectX runtime must be installed in order to use the legacy shader compiler; the rest of DBPro 9Ex depends on the June 2010 version, so this could potentially make things a bit messier for end users as well.

As for the offending shader from the bone animation example, you simply have to add a default return statement at the end of all three pixel shaders it defines. This is as simple as slapping in a return float4(0, 0, 0, 0); before their closing brackets and everything will work fine with the new shader compiler as well.

Finally a fun fact: there is a misspelled function name in the DBPro compiler called "EnsureMemoryBugEnough". Pretty hilarious when debugging memory-related issues.

I have been testing my ancient (but still in daily use) 50k+ line project with your new compiler. I think I have come across a wierd bug that was present in the original DBpro but is now in a slightly different form. When using `exit` to prematurely end for...next loops, the original DBpro `exit` command would cause a failure to compile unless it had a CR straight after the exit command (ie. no trailing spaces). If there were trailing spaces and then a comment it worked ok again.

Now, a for-next loop using exit will not compile with a comment after the exit command.

Thank you, Rudolpho. Fantastic job you are doing with DBPro 9EX. Aside from not having much time lately for 2.0, I haven't had much time to test DBPro 9Ex.

While working on 2.0, I have been testing the PostProcessCommands project in the Projects\Snippets folder. To get both shaders to work properly, I set the shader compiler to use D3DXSHADER_ENABLE_BACKWARDS_COMPATIBILITY mode. Compiling this project with DBPro 9Ex and setting the USE LEGACY SHADER COMPILER flag, I get the shader error Orto experienced above.

Here are the modifications I made to SetSoundVolume to give it a more linear sounding range.

This looks like another excellent piece of work from you. I haven't tested this yet - and won't be able to for a few weeks yet. It looks like brilliant news for us all.

Just one question. You mention a limit of 255 (or 256) bones in a shader. That doesn't sound right to me as I'm sure there's a total limit of 256 float entries for the constant table that gets passed to a shader and that is the reason for the practical limit of 60 bones each of which requires 4 floats. That makes a total of 240 constants leaving 16 for everything else. Has that limit been changed in DX9ex? [I know nothing about DX9ex ] Or have I confused two quite different things?

Kuper wrote: "Is it nessesary to install DBPro Online? I have DBPro from original CD - it will be OK with path names?"

Hm, how do you mean online?
Everything should work if you just overwrite your current files with the included ones. As far as I know the paths should be the same in all DBPro versions, and all paths are relative so if you move the DBPro installation around that won't be a problem either (unless your IDE is set up to call the compiler from an absolute path in which case you may have to manually tweak that if not installing on top of that directory).

slaidew wrote: "When using `exit` to prematurely end for...next loops, the original DBpro `exit` command would cause a failure to compile unless it had a CR straight after the exit command (ie. no trailing spaces). If there were trailing spaces and then a comment it worked ok again. "

That is a rather odd one indeed. I'll have a look and see what I can do about this behaviour; there is no logical reason that the compiler should get confused by that. What is happening in your example though is that my precompiler is stripping all whitespace and comments before the source gets sent to the actual compiler, so it will act as if your comments weren't there. But the original issue should most likely be addressable.

WickedX wrote: "Thank you, Rudolpho. Fantastic job you are doing with DBPro 9EX. Aside from not having much time lately for 2.0..."

Thank you as well! And sorry for stealing your thunder a bit as it were with your 2.0 version; I had this mostly sitting around for a while, planning to put it up to go alongside the next demo release of my DX11 plugin but as I've gotten a job and currently don't have as much time to spend as I would like, I thought I could put this out separatedly.
Also nice one on rescaling the volume! It might be an idea to allow floating point values instead of integers; as the internal resolution is most likely fairly higher than 100 steps anyway (up to but probably not guaranteed to actually be 10 000 steps) it would be a nice thing to have for smoother fading and such.

WickedX wrote: "While working on 2.0, I have been testing the PostProcessCommands project in the Projects\Snippets folder. To get both shaders to work properly, I set the shader compiler to use D3DXSHADER_ENABLE_BACKWARDS_COMPATIBILITY mode. Compiling this project with DBPro 9Ex and setting the USE LEGACY SHADER COMPILER flag, I get the shader error Orto experienced above."

Really, hm, for me it works as intended with the USE LEGACY SHADER COMPILER setting, but doesn't draw anything without it. There are no displayed error messages at all however. May you be having some additional settings in effect such as using the debug DX runtime?

Green Gandalf wrote: "Just one question. You mention a limit of 255 (or 256) bones in a shader. That doesn't sound right to me as I'm sure there's a total limit of 256 float entries for the constant table that gets passed to a shader and that is the reason for the practical limit of 60 bones each of which requires 4 floats. That makes a total of 240 constants leaving 16 for everything else. Has that limit been changed in DX9ex? [I know nothing about DX9ex ] Or have I confused two quite different things?"

The limit is 256x4 = 1024 floats under shader model 3.
The bone palette defines 256 float4x4's (4096 floats), so indeed this would never fit into the shader constants under any circumstance on DX9. But as you say, using 60 such bone transforms will leave 64 bytes, or 16 floats free for other purposes.
One of the main reasons the GameGuru version wouldn't play nice with third party libraries is that they decided to just haphazardly add to previously defined data structures that plugins were relying on to follow a set format. Most of these had some reserved members in the past such that data could be rearranged or partially externalized and made to fit into a data interface that was still compatible with the old standard, however the mesh data sadly was just too large. Hence I made the decision to cut one of these bones, that as far as I can tell would never be able to reach the GPU in any case, so that I could fit in a pointer to an external storage for more added mesh data. Another possibility could be to reduce the precision of the light range and alpha override settings to 16-bits; this too would free up the necessary space without having to sacrifice that last bone. It would require quite a few changes in other places however so for the time being I chose to go with the reduced bone data.
As for DX9Ex it still uses SM3.0 so no, it changes no shader caps.

I had not but I will look into it, but tbh cut/copying/pasting the ad hoc suffix of a folder name to a text file isn't any trouble at all really. The only issue I have is having to put up with the IDE saving after each compile with 9Ex(because of my setup), which for testing purposes I can put up with. So far of the projects I have tested I haven't come across any issues as of yet

Quote: "
What is happening in your example though is that my precompiler is stripping all whitespace and comments before the source gets sent to the actual compiler, so it will act as if your comments weren't there. But the original issue should most likely be addressable.
"

Yes that's what I assumed the precompiler would do with comments and whitespace. I didn't make it explicitly clear that the examples were on your new version.

So the first example compiles ok on 9ex, the 2nd one does not, even though as you say all whitespace/comments should be stripped.

If there is ONLY whitespace after the exit command then that also does compile and work ok.

I do remember years ago strange issues with commenting out lines which 'broke' loops, function declarations and if/endif blocks. Does "Command out of place" refer to the compiler thinking the loop is already closed?

Great job on the update, I'm hoping to eventually be able to compile with your new version to fix memory leaks which affect my app when it's running for many hours without restart.

Well, I've updated to the new version and am happy to report that I am no longer getting the runtime shader crash

I am sometimes getting a '...has stopped working' crash (2 out of 3 runs so far) when closing the application through the 'end' command however. I will see if I can reproduce on a short snippet.

I am also not seeing box wrapped text printed through cloggy's d3d plugin, I am not sure yet if it is simply not printing, if it is printing in an unexpected location, or if it is getting covered over or discarded in some sort of z-index issue. I will let you know what I find.

A single player RPG featuring a branching, player driven storyline of meaningful choices and multiple endings alongside challenging active combat and intelligent AI.

Did you check compatability with the free third party DLL "Dark Injector" by The Winch? It must be 10 years old or more. It was a DBP preprocessor which could detect in advance certain conditions, such as whether the user had DirectX 9c installed, which DBP required, so I was wondering if it could be used to detect whether the user has 9E installed. I can't find it on the current TGC site with the TGC search engine. I think a lot has been scrapped from the posts database. I have it on one or another retired computer in my garage, I think.

slaidew wrote: "Does "Command out of place" refer to the compiler thinking the loop is already closed?"

More or less yes, it appears that it attempts to parse the "next" keyword as if it were an instruction, but there is no handler for that as it's only used as a separator (ie. everything between for... and ...next is picked and parsed as a block). This appears to be related to the single-line if/else clause that is interpreted as being terminated by the carriage return character by the compiler. I have only managed to glance it over so far but it seems that it expects this carriage return to follow immediately after the last instruction on the line and doesn't like spaces there. I will look into this further to try and figure out the reason.
For now I think this problem has been solved through my precompilation step though; it did not remove spaces before a line comment before but after updating it to do so this problem doesn't occur anymore. I'd still like to see whether I can weed out the root cause for it in the compiler though.

slaidew wrote: "Great job on the update, I'm hoping to eventually be able to compile with your new version to fix memory leaks which affect my app when it's running for many hours without restart."

Thanks, that would be a nice milestone indeed

@Ortu: I'm glad to hear it's working for you.
Those end crashes sound rather ominious though. I haven't encountered this, so if you could piece together a snippet that reliably reproduces this that would be great. The same goes for Cloggy's dll (which I will have to locate it seems... you don't happen to have any link to it?). Thanks for your help!

Jeff Miller wrote: "Did you check compatability with the free third party DLL "Dark Injector" by The Winch?"

I have not no; in fact there are plenty of dll's I haven't been able to test yet, either because I don't have them available or because I haven't thought of them. So any help on localizing issues with various third party libraries is most welcome

Jeff Miller wrote: "[...] so I was wondering if it could be used to detect whether the user has 9E installed."

I'm not sure exactly how it works but it probably can if it could detect DX9.0c.
The 9Ex runtime comes with the June 2010 release of DX9.0c, however the Vista+ features (WDM aware, screen flip support etc.) may require that DX10 or DX11 is installed as well, or at least a DX10-capable graphics card. 9Ex can run without these features however, in which case it is more or less equivalent to 9.0c.
If you don't mind, feel free to dig up that dll and we can have a look.
It would also be quite simple to make the created DBPro executables call some third party library function before initializing DX9 for such a check. Carrying it out from inside the DBPro code itself would be harder as it is very tightly integrated and dependent on DirectX however.

Since your release of the DX11 Plugin, I had an idea your had something like this in the works.

I have been on call pretty much 24-7 for the last 2 months. Getting only an hour or two of sleep here and there with constant interruption. After reinstalling DBPro 9Ex, the shader issue has been resolved. My brain is so fried, I must have mucked something up the first time.

Attached are two demos that are not functioning correctly in DBPro 9Ex. First run the executable (compiled in 2.0) to see how they should appear then compile under DBPro 9Ex. On my 6-7 year old Windows7 and year and a half old Windows 8.1 systems the build in stencil shadow shader seems to actually work better or just as good as any alternative I've found. This fix is simple. Search DBOFormat.cpp for “m_fMeshRadius” and un-comment the assignment and block where found. I haven't a clue what's up with the other demo.

I use the old editor. The only difference I notice with DBPro 9Ex is I have to save the files before compiling, where-as in 2.0 it compiles what's in the editor.

Attachments

Quote: "The only difference I notice with DBPro 9Ex is I have to save the files before compiling"

You just saved me the time of re installing Windows as I figured I was the only one it was happening to - and that it was due to my hap hazard method of switching between versions of DBP as mentioned earlier, it is the same with Indigo as with both Indigo and the old editor they don't save before compilation which is my preference. I was toying with whether I should ask here if anyone else was willing to test the old editor before I hunt out a spare HDD and start over.

After checking the GitHub open source, I realize I've made an error in the fix for the stencil shadow shading. I assumed since this works on the version it is based on that some remnant would be left in tack as it is in the Google Code source, which unmodified works the same as it does in DBPro 9Ex. It still looks like a simple fix. But if you feel it should be fixed, I think it would be simpler for you to compare the DBOData.h and DBOFormat.cpp files in the Google Code source against the GitHub source. If this it not the cause of any other issues, I can do without.

Quote: "For now I think this problem has been solved through my precompilation step though; it did not remove spaces before a line comment before but after updating it to do so this problem doesn't occur anymore. I'd still like to see whether I can weed out the root cause for it in the compiler though."

Sorry to go on because I know this is not really a deal-breaker bug, but are you saying it should be fixed in the current version available to download? Or have you not released that yet, because it still has the same behaviour on the version I downloaded just now. (spaces and a comment = no compile)

I found DarkInjector. I forgot that the words were not separated. It is here:
http://winch.pinkbile.com/wiki/index.php/Main/DarkInjector

I did correctly remember one of its intended uses:
"This is mainly useful if used to inject a user friendly directx version check but it could be used to do anything that you can be done in a dll and needs to be done as soon as possible after the exe starts. "

WickedX wrote: "I have been on call pretty much 24-7 for the last 2 months. Getting only an hour or two of sleep here and there with constant interruption. After reinstalling DBPro 9Ex, the shader issue has been resolved. My brain is so fried, I must have mucked something up the first time."

Ouch, that sounds positively heinous. I hope you'll get off whatever undertaking is claiming that amount of time soon. Glad it turned out to be working after all though!
Also thanks for the examples. I've had a quick look but will need to dig in a bit deeper when I get the time. As for reintroducing the mesh radius member it isn't quite that simple or the struct layout expected by other dll's will be broken, but it should be possible to reorganize things a bit in order to work it out. The other one seems like you have a non-working shader off of the top of my head; it may be something that has been changed with the way effect data is stored. Thanks again for your effort in supplying the examples.

I feel like I should explain a bit further about that saving issue.
It is true that the individual source files are read from disk and parsed by my precompilation system, whereas the DBPro compiler itself would read a temporary, combined source file pieced together by the IDE. The main reason for this is so that both any precompilers, and through that the runtime, will be able to pinpoint both the correct file and line number in said file where it is at in order to output error messages and the like. As you may be aware, the behaviour of standard DBPro is rather to give you something like "Failed to xxx at line 31496", and then it is up to you to figure out that this does in fact point to line 249 in include file 17.
Another reason is that I've occasionally experienced problems where my IDE (the "new" official one) cannot properly resolve #include directives, particularly where one source file #includes another that in turn #includes a third. The general consensus was to just add all include files through the IDE directly instead of using the #include directive, but it is still part of the language and my precompiler fixes this. Granted this issue may not exist with other IDEs. Finally, I must confess that I've never heard of an IDE for any language that doesn't automatically save on compilation, so the fact that this could be an issue never even crossed my mind. Nonetheless, starting with version 1.0.0.2 you can now toggle whether to use the source files or the IDE's source dump (see my next post).

sladeiw wrote: "Sorry to go on because I know this is not really a deal-breaker bug, but are you saying it should be fixed in the current version available to download? Or have you not released that yet, because it still has the same behaviour on the version I downloaded just now. "

That's fine and no, it was just in my test builds. The latest release, which includes this, will be up in a few minutes though

sladeiw wrote: "Oh, and get some sleep! "

Hah, I am; the only problem is that the few days when I technically can sleep an hour or two longer, I've gotten so used to being up early that it just won't work most of the time...

Finally I downloaded DarkInjector but my antivirus decided to go on a rampage about it, so I haven't been able to try it just yet. As said I don't see why it shouldn't work though.

This version addresses a few of the issues reported since the last update: The compilation process no longer fails when encountering an EXIT instruction followed by whitespace and a comment. You can now specify whether you want the precompiler to parse all physical source files (default behaviour) or use the IDE's combined source dump instead. The included build of SC_Collision.dll was broken since pre-release testing and has now been fixed. Thanks to SW3DG for pointing that out.

A new group of settings has been added to the compiler configuration file (DarkBASIC Professional\Compiler\Setup.ini).
Currently there is only one setting, used to control whether to read all included source files or rely on the IDE's combined source dump, but more may be added in the future.
Add these lines to your Setup.ini to use the IDE's temporary source dumps (this abolishes the need to resave your sourec files on compilation):+ Code Snippet

[PRECOMPILER]
UseIDESourceDump=Yes

Beware that there are some drawbacks to this though (see my last post above this one for details), but if you still want to use it it's there now.

Also, there is a crazy flickering going on with default screen setttings (not tested any other settings, I just discovered this while testing the string behaviour above). Just a simple hello world with a wait and the screen will flicker continuously.

On Manifests & visual styles...
Ages ago someone managed to figure out how to modify a DBPro app's manifest to enable visual styles on OS versions after XP. XP would use an external manifest to enable them, but Vista and above ignore it. I can't find the forum post discussing it anymore, but back then I created a quick & dirty hack to modify the compiler manifest that it gives to apps, so that display elements such as BlueGUI give the proper Windows 7 styles. It still works on the new compiler .exe but it's probably better to incorporate it properly rather than the hack.