Azurian
The Azurian
what general improvementss will xerces_c do over xmlparser?
DLL development discussions
- Thread starter Koshling
- Start date
It is faster as the msxml that is used in the Debug build and also we had crashes in the Debug Build because of msxml.
The RapidXml used in the Release Build's is just fast and not very reliable also it has no schema validation so it was hard to detect Xml Errors.
And it has alot more to offer...
One big improvement for you as a Xml Modder once it is fully implemented(This will be the second step) we don't need all those schema files we just have one xsd schema for everything.
Dancing Hoskuld
Deity
Does this mean we wont be able to test new schema files? There are a few elements that the dll supports that are not in the core schema files. At least I think there are still a few. The last one added by me was the bDisplayOnly tag. I was able to add it to my schema files and test before updating the core one.
I make one schema c2c.xsd that contains everthing that is in the dll so if a new tag is added in the dll it just must just be added to that schema and you can use it where you want(Core, Modules..).
The dll then uses that schema to validate all the xml files while reading them.
You can use an modern XmlEditor with Xsd Schema Validation to have your files checked while editing them....
All Tags will be optional so if you have for example a building that just uses 10 Tags you just have to put those in the xml.
We also will be able to remove all the emty or default Tags from all Xml Files that will speed up the loading.
I just need a few more days to finish this.
Dancing Hoskuld
Deity
Interesting, your answer fully answered my question but in a way that I did not expect.
Which is fine for C2C but makes sharing stuff with other mods a bit more difficult
Which is fine for C2C but makes sharing stuff with other mods a bit more difficult
Azurian
The Azurian
Xsd Schema Validation makes me
. Does this mean we can have files from GameInfos in Module Folders too?
Dancing Hoskuld
Deity
That probably depends on the WoC implementation. It was not extended to all files just the main modding ones.
Interesting, your answer fully answered my question but in a way that I did not expect.
Which is fine for C2C but makes sharing stuff with other mods a bit more difficult
We don't need to do it but we can. Also it is possible to make the tags non-optional in the schema so they need to be there.
Dancing Hoskuld
Deity
Ah well, my attempt to have limits on growth due to infrastructure using the DoGrowth python callback (USE_CAN_DO_GROWTH_CALLBACK) doesn't work because the dll does growth no matter if you pass true or false back to it from the Python. 
btw this means that Platyping's version of the Avoid Growth options would not work also. Which suggest there may be a problem in the dll.
btw this means that Platyping's version of the Avoid Growth options would not work also. Which suggest there may be a problem in the dll.
Thunderbrd
C2C War Dog
Off the top of my head I can't say. But I could figure it out. Most of the displays you get in the output window have direct wording in the code rather than a reference to text. So what you can do is search the whole project for a solid section of the text output you show on any given output message to lead you to an example of a message output code line.
Ah well, my attempt to have limits on growth due to infrastructure using the DoGrowth python callback (USE_CAN_DO_GROWTH_CALLBACK) doesn't work because the dll does growth no matter if you pass true or false back to it from the Python.
btw this means that Platyping's version of the Avoid Growth options would not work also. Which suggest there may be a problem in the dll.
hmm... It's been mentioned before that Avoid Growth doesn't seem to work. That said, I'd really have to dig to figure out what could be happening there as this wouldn't be an area I'm at all familiar with.
Dancing Hoskuld
Deity
The C2C Avoid Growth is in the dll and works as advertized just not as people would like. It does not stop growth like Platyping's would and people would like ours to. At least I would.
The C2C version may be why use of the python call back does not work for me. Perhaps it replaces the part in the dll that would normally take the result from the call back.
Ah well, my attempt to have limits on growth due to infrastructure using the DoGrowth python callback (USE_CAN_DO_GROWTH_CALLBACK) doesn't work because the dll does growth no matter if you pass true or false back to it from the Python.
btw this means that Platyping's version of the Avoid Growth options would not work also. Which suggest there may be a problem in the dll.
Did you activate the USE_CAN_DO_GROWTH_CALLBACK in PythonCallbackDefines.xml?
The code in the dll looks fine to me but i did not test it, then you return true from doGrowth it sould not grow.
Dancing Hoskuld
Deity
Yes I did. But I return false = don't grow! After all it is "can do growth" so true would normally mean yes and false no. I love C programmers!
Yes I did. But I return false = don't grow! After all it is "can do growth" so true would normally mean yes and false no. I love C programmers!
Yeah i was a bit
by that too but it is like that you can ask Afforess why he did it that way.
Code:
/************************************************************************************************/
/* Afforess Start 12/21/09 */
/* */
/* */
/************************************************************************************************/
if(GC.getUSE_CAN_DO_GROWTH_CALLBACK())
{
PYTHON_ACCESS_LOCK_SCOPE
CyCity* pyCity = new CyCity(this);
CyArgsList argsList;
argsList.add(gDLL->getPythonIFace()->makePythonObject(pyCity)); // pass in city class
long lResult=0;
PYTHON_CALL_FUNCTION4(__FUNCTION__, PYGameModule, "doGrowth", argsList.makeFunctionArgs(), &lResult);
delete pyCity; // python fxn must not hold on to this pointer
[B] if ([COLOR="Red"]lResult == 1[/COLOR])
{
return;
}[/B]
}
/************************************************************************************************/
/* Afforess END */
/************************************************************************************************/I have recently experimented a bit with trying to get the C2C DLL to compile/run with a newer compiler / boost library.
As a newer MSVC compiler means linking against a newer runtime I statically linked both the runtime and the boost library.
Of course that means that exe and dll get different heaps and the new and delete for any object has to happen on the same side.
For a lot of the interface that is fine as only POD, pointers and references are passed.
The main issue are the STL classes that are passed by reference and changed on the other side (which often causes allocation/deallocation) or worse returned by value (which means they are allocated on one side and then deallocated on the other).
There are two possible solutions to that.
One is to have a slim DLL (compiled with the current compiler) in between the exe and the C2C DLL that forwards most calls and packs/unpacks STL classes and similar so the interface to the C2C DLL avoids the problematic stuff.
The other would be to have a helper DLL (compiled with the current compiler) for making some specific calls into the exe and creating / accessing STL classes that will be shared with the exe.
While the second variant would be simpler to set up (as there would be no need to forward all those calls from/to the exe that are fine) it won't work if there is any call from the exe into the DLL that passes an STL class by value or expects one by value in return (unless there is some way to convince the compiler to forward that call to the helper DLL without doing any construction or destruction).
For any of those variants there is a chance that it won't work at all because of some binary incompatibility in how the exe accesses DLL objects like CvPlot.
On the other hand if it works we would gain the power of a newer compiler (like C++11 and better optimizations) and a newer Boost library.
So what do you think? Worth trying?
As a newer MSVC compiler means linking against a newer runtime I statically linked both the runtime and the boost library.
Of course that means that exe and dll get different heaps and the new and delete for any object has to happen on the same side.
For a lot of the interface that is fine as only POD, pointers and references are passed.
The main issue are the STL classes that are passed by reference and changed on the other side (which often causes allocation/deallocation) or worse returned by value (which means they are allocated on one side and then deallocated on the other).
There are two possible solutions to that.
One is to have a slim DLL (compiled with the current compiler) in between the exe and the C2C DLL that forwards most calls and packs/unpacks STL classes and similar so the interface to the C2C DLL avoids the problematic stuff.
The other would be to have a helper DLL (compiled with the current compiler) for making some specific calls into the exe and creating / accessing STL classes that will be shared with the exe.
While the second variant would be simpler to set up (as there would be no need to forward all those calls from/to the exe that are fine) it won't work if there is any call from the exe into the DLL that passes an STL class by value or expects one by value in return (unless there is some way to convince the compiler to forward that call to the helper DLL without doing any construction or destruction).
For any of those variants there is a chance that it won't work at all because of some binary incompatibility in how the exe accesses DLL objects like CvPlot.
On the other hand if it works we would gain the power of a newer compiler (like C++11 and better optimizations) and a newer Boost library.
So what do you think? Worth trying?
I did some testing in that area myself but in the end it was to much work for one person with my level of experience.
For my personal games i compiled the dll with the Intel Compiler but that is not a option because not everyone has it.
We could update to boost 1.44 with the current compiler it is compatible up to that version.
That alone is a big step.
For my personal games i compiled the dll with the Intel Compiler but that is not a option because not everyone has it.
We could update to boost 1.44 with the current compiler it is compatible up to that version.
That alone is a big step.
The newest Boost library should still work with the 2003 compiler (I think they only removed support for 7.0 and not 7.1 by now).
The main problem about going for a new Boost is bypassing the old Boost Python DLL. In my tests (with the new compiler) I was able to statically link the newer Boost Python and then expose the Cy stuff directly into the Python24.dll with one minor code change (I had to get the scope which I guess the exe does when you share the Boost Python DLL). Of course I don't know if it actually works properly as I never got far enough in the loading process that I could verify the state of Python.
It is possible that newer versions work with the 7.1 compiler but i think that some newer libraries might be incompatible, i never tried a newer Version.
The 1.44 was the last one that was fully compatible with vc7.1 newer versions just support it. The safe way to go is 1.44 eyerything newer must be tested before switching.
IIRC Koshling tried this early last year (at least the part about moving the DLL to C++ 11.0) and found that without a LOT of work it wasn't going to go anywhere.
The shim DLL might work, but given that it would, if I'm understanding correctly, deallocate everything the exe sends it, reallocate it in a manner that the c++ 11 DLL would be OK with, and then forward it to another interface I can see preformance issues here. That, and the additional issue of how to handle Python calls to and from the DLL. Another issue would be whether or not the C++ 11 debugger chokes when you and look at something going on in the shim.
The benefits would probably be worth it though. Last year I tested one of alberts DLLs compiled with the Intel C++ compiler and turns went almost twice as fast.
Similar threads
