James H wrote: "Also with 9Ex and M1U plugins I had to place the MSVCP/R71.dll files in the plugins-user folder as well as in the project folder where the exe is or I get the error "The DBPro compiler stopped but the Error Report nor the Executable could be found.""
This should no longer be necessary as of the v1.0.0.1 release.
Kuper wrote: "When DarkShader is open and you use any project which consists "set cube mapping on" command ( for example Palm Tree demo from Evolved )
shader will not work at all."
Hm, yes this does seem to cause trouble; for me the DBPro project will just immediately close rather than the shaders not working though. I've no idea why DarkShader would interface with separate programs, however as it uses a captured DBP program as its render window, I suppose that is somehow related. It would unfortunately be difficult to figure out what to do this without having access to the DarkShader source. On the other hand, the DarkShader editor has always crashed on closing it for me so I believe it is a bit buggy in and off itself.
@Mage: That seems odd indeed.
Would you be able to produce a small code snippet that reliably reproduces this issue? Also have you been able to tie it to any math function such as ATAN, or is it the return value of the function itself that gets messed up (you could check this using print statements from within the function and outside it)?
The one thing that springs to mind is that it somehow reinterprets the floating point value as an integer - 1134759808 corresponds to the bit pattern used by a float value of ~326. So it seems it could be a casting issue where the compiler would suddenly assume your variable# is an integer instead of a float, however it seems odd to think that something like this wouldn't have been obvious long ago - therefore it seems likely that the issue somehow depends on some special circumstance. For this reason, a snippet reliably reproducing it would be a great help in trying to track it down, preferably as small as possible.
Mage wrote: "I am not sure if removing # symbol from these variables changes their datatype. Like from DWORD to Float. It's been so long and I can't find documentation."
It does, the # is a shorthand for "treat this as a float
unless otherwise specified". If you remove it it will be treated as an integer (again unless otherwise specified).
For example this is legal:
myVar# as integer rem This will indeed be an integer, regardless of the '#'
myVar = 5 rem This is a different variable from the above, but also an integer by default
Is it possible that you could have something like that where the same variable name is used for another data type in another part of your project?
Mage wrote: "- A lot of shaders are not working (particularly shader model 1)"
I'm must confess that I'm not particularly familiar with SM1. Have you tried the
USE LEGACY SHADER COMPILER command?
By default DBPro9Ex uses a more strict shader compiler than previous DBP versions did.
Mage wrote: "- d3dfunc plugin not working "
This should hopefully have been fixed in the latest release (see my next post)
Mage wrote: "- Hide/Show Object or Exclude Object On/Off not working. My whole culling system is broken now and glitching out."
I see, thanks for reporting it and your follow-up details!
Kuper wrote: "I don't know if you have tested this but the Advanced Terrain Plugin does not work with this version, maybe someone can confirm on this issue."
Do you have any code to test out? I'm a bit uncertain which one Advanced Terrain is, but if it is the "world" functionality then I can get the second included example to compile and run as intended, however the first one fails on the LOAD BSP function which I could look into.
All in all, thanks for the reports and helping eachothers confirm stuff and everything guys, much appreciated!
Sorry for being a bit absent over the last week; I have been working hard on version 1.0.0.4 though. Hopefully it will fix some of the experienced issues