Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / [STICKY] DBPro 9Ex

Author
Message
Rudolpho
18
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 24th Sep 2016 12:06 Edited at: 23rd Oct 2016 18:28
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 fixes
This 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:

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:

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.


Download
Click here to download DBPro 9Ex.
The above link will always point to the latest version.


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.



Changelog
sladeiw
14
Years of Service
User Offline
Joined: 16th May 2009
Location: UK
Posted: 24th Sep 2016 20:50
Great job
Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 24th Sep 2016 23:06
Awesome stuff Rudolpho, we appreciate your efforts both with this and the Ziggurat engine.
The code is dark and full of errors
Bored of the Rings
User Banned
Posted: 25th Sep 2016 10:29
@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'.
Professional Programmer, languages: SAS, C++, SQL, PL-SQL, DBPro, Purebasic, JavaScript, others
Rudolpho
18
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 25th Sep 2016 22:10
Thanks guys, I'm glad you like it

Van B wrote: "Awesome stuff Rudolpho, we appreciate your efforts both with this and the Ziggurat engine."

Yeah, who knows, maybe I'll earn a fancy developer badge if I keep at it too *wink, nudge*
Also thanks for the stickying (I assume you were responsible for that).
Kuper
16
Years of Service
User Offline
Joined: 25th Feb 2008
Playing: Planescape:Torment
Posted: 25th Sep 2016 22:15
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.
Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 25th Sep 2016 22:22
Quote: "Yeah, who knows, maybe I'll earn a fancy developer badge if I keep at it too *wink, nudge* "


Wear them with pride!
The code is dark and full of errors
Rudolpho
18
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 26th Sep 2016 21:25
Van B wrote: "Wear them with pride!"

Why thank you fine sir! I most certainly shall

@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
Kuper
16
Years of Service
User Offline
Joined: 25th Feb 2008
Playing: Planescape:Torment
Posted: 27th Sep 2016 16:13 Edited at: 27th Sep 2016 17:56
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.
Ortu
DBPro Master
16
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 27th Sep 2016 21:46
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.
James H
16
Years of Service
User Offline
Joined: 21st Apr 2007
Location: St Helens
Posted: 28th Sep 2016 21:09
Sweet stuff man thanks

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

Kuper
16
Years of Service
User Offline
Joined: 25th Feb 2008
Playing: Planescape:Torment
Posted: 28th Sep 2016 22:17
@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.
James H
16
Years of Service
User Offline
Joined: 21st Apr 2007
Location: St Helens
Posted: 28th Sep 2016 22:57
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.
Ortu
DBPro Master
16
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 28th Sep 2016 23:08
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.
Ortu
DBPro Master
16
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 28th Sep 2016 23:10 Edited at: 28th Sep 2016 23:13
I found ShaderData.dll in my plugins-user, 132 kb, dated 11-10-2008, and AdvLighting compiled normally.

I don't have Dark Shader, so it can't have come from that, or not solely from it.


A single player RPG featuring a branching, player driven storyline of meaningful choices and multiple endings alongside challenging active combat and intelligent AI.
James H
16
Years of Service
User Offline
Joined: 21st Apr 2007
Location: St Helens
Posted: 28th Sep 2016 23:19
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.
James H
16
Years of Service
User Offline
Joined: 21st Apr 2007
Location: St Helens
Posted: 28th Sep 2016 23:25
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.
Ortu
DBPro Master
16
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 28th Sep 2016 23:37
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.
Ortu
DBPro Master
16
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 29th Sep 2016 19:51
Well, so far I have traced the crash down to the fastsync call at the bottom of DirLight_Render()

I get logging down through Just before the fast sync:

AdvLighting_Update()
DirLight_Render(1.0, 320.0)
fastsync -> crash before this returns

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.
Kuper
16
Years of Service
User Offline
Joined: 25th Feb 2008
Playing: Planescape:Torment
Posted: 29th Sep 2016 21:25
@Ortu
So you have error after compile and .exe file that works well or error report when you launch .exe ?
Ortu
DBPro Master
16
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 29th Sep 2016 21:42 Edited at: 29th Sep 2016 21:49
It seems to most likely be an issue with bone animated objects with AdvLighting.

Palm Trees demo (instanced objects, shader based animations) compiles and runs ok

Bone Animation (bone animated .x object, AL fast bone shaders) crashes. This demo does give me an error just before the crash however:



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:

"Shaders/Surface/Animation/Normalmap.fx"
"Shaders/Surface/Animation/Normalmap_Clip.fx"

The exe runs fine with the bone animated object as long as that effect is not applied, unfortunately, you must use those if you want bone animated objects in AdvLighting


A single player RPG featuring a branching, player driven storyline of meaningful choices and multiple endings alongside challenging active combat and intelligent AI.
Ortu
DBPro Master
16
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 29th Sep 2016 21:45
@Kuper:

error only on launching the exe, and only when it hits the point in the code that it is calling fastsync on a bone animated object with an AdvLighting fast bone shader effect applied.

I get no errors during or following a compile. I am also not seeing any issues with changes not being applied, nor do I have any issues requiring me to close and reopen the editor.


A single player RPG featuring a branching, player driven storyline of meaningful choices and multiple endings alongside challenging active combat and intelligent AI.
Rudolpho
18
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 29th Sep 2016 23:03
Oh wow, thanks for all the testing! Much appreciated.

I haven't had time to look any further into this over the past few days, if lucky maybe I'll be able to for a bit over the weekend though.


Kuper wrote: "Missing DLL Solved: Place NxCharacter,PhysX , USkin and other dlls in "Dark Basic Professional\Compiler" folder and your project folder."

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 EFFECT obj, 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.


Again, thanks for your help and appreciation guys
James H
16
Years of Service
User Offline
Joined: 21st Apr 2007
Location: St Helens
Posted: 30th Sep 2016 21:24
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!
Rudolpho
18
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 30th Sep 2016 23:33
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.
Rudolpho
18
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 1st Oct 2016 23:35
Alright, I've managed to solve a few of the mentioned issues.
Click here to download version 1.0.0.1.

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.
Kuper
16
Years of Service
User Offline
Joined: 25th Feb 2008
Playing: Planescape:Torment
Posted: 2nd Oct 2016 19:34 Edited at: 2nd Oct 2016 20:08
@Rudolpho
Nice work as always!
PS
Is it nessesary to install DBPro Online? I have DBPro from original CD - it will be OK with path names?
Ortu
DBPro Master
16
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 2nd Oct 2016 22:36
Awesomesauce man, thanks for the quick work. I will check out the new version and report further issues if any turn up.


A single player RPG featuring a branching, player driven storyline of meaningful choices and multiple endings alongside challenging active combat and intelligent AI.
sladeiw
14
Years of Service
User Offline
Joined: 16th May 2009
Location: UK
Posted: 2nd Oct 2016 23:46
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.

Compiles ok:


Does not compile (Command out of place at line "next i")


Of course I made sure all my `exit` commands had a comment after them to prevent compiler errors (There are a lot of exits!) and now they all throw the new compiler.
WickedX
15
Years of Service
User Offline
Joined: 8th Feb 2009
Location: A Mile High
Posted: 3rd Oct 2016 18:21
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.



Well, hope I've been some help and can be in the future.

Thanks, again.
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 3rd Oct 2016 21:40
Rudolpho

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?


Powered by Free Banners
Rudolpho
18
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 3rd Oct 2016 23:41 Edited at: 3rd Oct 2016 23:43
Thanks guys

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.
James H
16
Years of Service
User Offline
Joined: 21st Apr 2007
Location: St Helens
Posted: 4th Oct 2016 10:12
Quote: "have you perchance considered version management software?"

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
sladeiw
14
Years of Service
User Offline
Joined: 16th May 2009
Location: UK
Posted: 4th Oct 2016 10:59
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.
Ortu
DBPro Master
16
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 4th Oct 2016 16:56
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.
Jeff Miller
19
Years of Service
User Offline
Joined: 22nd Mar 2005
Location: New Jersey, USA
Posted: 4th Oct 2016 22:20
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.
Rudolpho
18
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 4th Oct 2016 23:15
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.
James H
16
Years of Service
User Offline
Joined: 21st Apr 2007
Location: St Helens
Posted: 4th Oct 2016 23:23
Dark Injector by the_winch (Haven't tried it)
WickedX
15
Years of Service
User Offline
Joined: 8th Feb 2009
Location: A Mile High
Posted: 4th Oct 2016 23:32
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

Login to view attachments
James H
16
Years of Service
User Offline
Joined: 21st Apr 2007
Location: St Helens
Posted: 4th Oct 2016 23:48
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.
WickedX
15
Years of Service
User Offline
Joined: 8th Feb 2009
Location: A Mile High
Posted: 5th Oct 2016 00:06
So! Glad I saved you from that headache. You wouldn't think this a compiler issue. But, it is.
WickedX
15
Years of Service
User Offline
Joined: 8th Feb 2009
Location: A Mile High
Posted: 5th Oct 2016 00:06 Edited at: 5th Oct 2016 03:31
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.
sladeiw
14
Years of Service
User Offline
Joined: 16th May 2009
Location: UK
Posted: 5th Oct 2016 09:37
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)

Oh, and get some sleep!
Jeff Miller
19
Years of Service
User Offline
Joined: 22nd Mar 2005
Location: New Jersey, USA
Posted: 5th Oct 2016 12:21
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. "
Rudolpho
18
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 5th Oct 2016 19:44
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.
Rudolpho
18
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 5th Oct 2016 19:56
Version 1.0.0.2 is now available
Click here to download it

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):

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.
James H
16
Years of Service
User Offline
Joined: 21st Apr 2007
Location: St Helens
Posted: 5th Oct 2016 23:43
Thanks both Indigo and original IDE now working without having to save each compilation.
sladeiw
14
Years of Service
User Offline
Joined: 16th May 2009
Location: UK
Posted: 6th Oct 2016 09:36 Edited at: 6th Oct 2016 09:38
Quick post to say thanks for the update & now compiles successfully. Now on to issues....

All strings are having multiple whitespace reduced to a single space!



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.

Kuper
16
Years of Service
User Offline
Joined: 25th Feb 2008
Playing: Planescape:Torment
Posted: 6th Oct 2016 20:29 Edited at: 6th Oct 2016 20:29

Get this error message when execute .exe and have DarkShader editor open in same time.
Need every time close darkShader and reopen.

Attachments

Login to view attachments
punkyb
7
Years of Service
User Offline
Joined: 8th Sep 2016
Playing: PC and Android Games
Posted: 7th Oct 2016 02:23
Hi,

I would like to know if Advanced Terrain works. I downloaded the standard adv terrain pack, it compiles fine but crashes.

Login to post a reply

Server time is: 2024-03-29 06:35:31
Your offset time is: 2024-03-29 06:35:31