Tweet
Originally posted by SCDARS
I admit I am the one mentioned here. As you can see, I don't post here that much (with just 0.13 posts/day within 3-4 years I can almost compare to Angelo
)
I admit I am the one mentioned here. As you can see, I don't post here that much (with just 0.13 posts/day within 3-4 years I can almost compare to Angelo
)
Originally posted by SCDARS
One of the main design decisions would be the choice of the programming language, since it seems that java principles of security and platform independence could make direct access to ToT memory near to impossible. So the players could be forced to reload the save game regularily, if Angelo can't present us a better idea. (I have never used "native code", could this help?)
One of the main design decisions would be the choice of the programming language, since it seems that java principles of security and platform independence could make direct access to ToT memory near to impossible. So the players could be forced to reload the save game regularily, if Angelo can't present us a better idea. (I have never used "native code", could this help?)
Portability here is not an issue (at least for Tot) since IIRC the only platform on which it runs is Windows, obviously for MGE the thing is different but since, for the reason stated above, i don't think to port CSPL to Java this means that we couldn't exchange code if you choose Java since Tot version will always be C/C++.
Performance: CSPL is an hack, no doubt on this, it tries to change Tot in a way that was not originally designed; to obtain this it must be as efficient as possible (even C++ sometimes is too slow as in the Attack thread implementation), adding the overload of the JVM could make things even worse.
Java can interface with native code through the JNI, i never did something similar but, from what i remember, it seemed not difficult, just writing a C header file with some strange, pre-defined signatures.
Anyway i don't know if it's worth since the hardest part in developing CSPL is the memory-access thing, and you'll have to do it anyway in native code.
Since the major part of CSPL is ANSI C (IIRC aside from memory-access functions the only non-standard functions used were those regarding threads management and a couple of MessageBox calls) it could be modified easily to group non-standard functions in separate files which could be reimplemented on Mac leaving the main core intact (with the same advantages of Java but without the big disadvantage of the JVM)
Originally posted by SCDARS
On the other hand, jaroslav's object-model of the save game for civ2dip is already tested and running fine with MGE saves. So an events language based on it would have a solid and wide groundwork and the main task would be implementing the parser.
On the other hand, jaroslav's object-model of the save game for civ2dip is already tested and running fine with MGE saves. So an events language based on it would have a solid and wide groundwork and the main task would be implementing the parser.
) but like i said the main effort is peeking the data from the memory, and probably that will be the main task of realizing CSPL for MGE.
Originally posted by SCDARS
And although I have not tested it yet, Java 1.4 seems to have introduced support for regular expressions, which could render the task of writing an advanced events parser a lot easier for those familiar with regular expressions (and there would be no need to make the events file xml-compatible as proposed in the other thread).
And although I have not tested it yet, Java 1.4 seems to have introduced support for regular expressions, which could render the task of writing an advanced events parser a lot easier for those familiar with regular expressions (and there would be no need to make the events file xml-compatible as proposed in the other thread).
my conclusion is that for a similar task i definitely vote for C/C++, anyway, since i'm not sure i could be involved in the MGE porting of CSPL (aside from releasing the sourcecode of the Tot version) the final choice is up to you.
Comment