|
Angelo Scotto
|
|
Milan, Italy
Oct 1999
time: 05:28
|
|
quote:
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  )
|
Tsk, it's still a long way to catch me...
quote:
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?)
|
IMHO for this kind of work Java is not the best choice:
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)
quote:
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.
|
I think that yaroslav's classes could be easily translated in C++ (i still have to see them though, i'm still trying to remove NOSPAM from the address ) 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.
quote:
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). |
This is true, i'm not at all familiar with regular expressions, but i agree that doing a parser will be easier.
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.
|
19-05-2003 13:59
|
|