Spring RTS Engine

Posted: **24 Oct 2008, 10:36**

i am working on the Java interface now.
that for, i will have to do a C wrapper of the C callback struct.
the original:

struct SAICallback {
   int (__stdcall *handleEvent)(int teamId, int topic, void* data);
   int (__stdcall *Game_getMyAllyTeam)(int teamId);
   ...
}

wrapper code i need:

Code: Select all

SAICallback* clb[];
inline int *proxy_handleEvent(int teamId, int topic, void* data) {
   return clb[teamId]->handleEvent(teamId, topic, data);
}
inline int (__stdcall *proxy_Game_getMyAllyTeam)(int teamId) {
   return clb[teamId]->Game_getMyAllyTeam(teamId);
}
...

i need this to be able to use SWIG to call these methods from Java, as it would be way to complicated to use function pointers (not doable automatically)

i want to use regex to do the wrapper code described above, and as i used that some times already, i think i can do it. as this conversion has to be run whenever the callback changes, i want to automate it with a kind of regex script. the question is, how should i do it?
so far i used vim, and entered things manually. what ""regex script engine" should i use to do that? at best, somethign that comes with a spring dev package already, and works on all OS. if there is nothing like that yet, i would like a very small, portable application to do it. any ideas?

Posted: **24 Oct 2008, 10:57**

..waiiit.. i guess awk is best suited for that, i even used it for JAI "back then"

Posted: **26 Oct 2008, 15:13**

hey there :)

i'm actually running through the whole thread, but it would be nice if you guys did some sort of status of the AI redesign, so ppl could know where it is at without browsing the whole topic.

so where is it at now ?

Posted: **26 Oct 2008, 15:44**

[LBF]Vache: Mostly done as far as I know. Only small changes are happen which are mostly happen because of the none C/C++ interfaces.
hoijui is working on the Java AI interface and I'm working on the Mono AI interface.
Means you can download the branch and start creating a C or C++ AI.
Java or a Mono language is currently not supported.

Posted: **26 Oct 2008, 19:50**

so it is.
what are you interested in, [LBF]Vache?

Posted: **27 Oct 2008, 17:33**

well thanks for the answer guys

i mostly fiddled with reading some of KAIK and AAI code 8 monthes ago, and thought about doing my own set of experiments about skirmish AI's, maybe by participating to one of the existing AIs, since it seemed to be the most realistic way of contributing.

Now i'm studying C and C++, and i need a project, for school, and AI dev seemed to me like a good plan :D

But then i saw that the interface was gonna be redesigned, i wondered about how contributing to old AI's could be done.

I need some enlightenment :

- First, is the new AI interface compatible with the old way of doing things ? Has it some sort of compatibility layer ? Or had the AIs got to be rewritten ?

- Second, where can i find some kind of (even basic or incomplete) doc about the C api ?

If the interface is backward compatible (something i couldnt get thru reading the thread because of major headaches

sorry) then it means that all major Ais would need some kind of rewriting before you start back dev. on them, right ?

That's it, i'll wait for the next row of questions, so i don't appear even sillier

Posted: **27 Oct 2008, 17:40**

Part of the plan was to have such a C++ compatibility layer so that w had AIs to test with the interface and to minimize development costs of porting the existing AIs. I haven't had a proper look yet btu I believe its in place and building. But as I said I haven't had th time to have a look and run that particular branch yet.

Posted: **27 Oct 2008, 17:43**

It is not backwards compatible. You would need to rewrite it for the new interface.
But as I wrote it is lets say 95% done. The last 5% are only some cosmetic or missing things for none C/C++ interfaces.

My motivation for writing the Mono AI interface is kinda null. Maybe I can get some motivation again to get some work done

Btw. do we have any pkg-config files for spring or does someone know how to generate them or do I need to do it by hand?

Posted: **27 Oct 2008, 18:46**

hehe you guys are being contradictory

But that's no big deal since i know what i needed to. => The ai interface is still only in spring sources AI branch , it's not implemented in the mainstream binary release, and you can start coding with the new AI interface.

i'm mainly a C / C++ coder so i guess i don't need any other interface than the C one.

Now i'll get the Spring source tomorrow when i'll be @ home.

Is there a way to get some doc about the Interface meanwhile, or does it even exist in the sources ?

Thanks again

Posted: **27 Oct 2008, 19:45**

Hm, I don't know much about the old interface

.
But I don't think you can get around changing some functions from old interface to new interface.

A bit documentation is located in the code.

Posted: **27 Oct 2008, 23:05**

there is a C++ wrapper which rebuilds the old C++ interface compleetly (using the C interface for communication with the engine). This is finnished and working well.
In short: the new interface comes with a wrapper which serves an interface, 100% compatible with the old C++ one.

there is not real documentation about the new AI interface for developpers yet. for users, it is on the wiki:
http://spring.clan-sy.com/wiki/AIs
"AI Interfaces" is part of the new interface eg.

best for you [LBF]Vache, would be to have a look at rts/External/Interface/ ok the caibranch. everything directly in this directory is the new C interface to the engine, you should not have to look at anything else (the subdir LegacyCppWrapper is.. the 100% compatible wrapper for the old C++ interface i mentioned above)

if you miss some comments, or osme present ones are unclear or insufficient in the files under ExternalAI/Interfaces, please let me know where, and i will try to make them better.

i think i used comments which are .. somehow compatible iwth doxygen, but i never used that so far.. hmm.. maybe i shoudl do that :D
right now, i want ot finnish the Java interface first, but i will put this on my TODO list.

an other thing: Agon helped me a lot with finding "bugs":
files i forgot to add to SVN and other ugly stuff like that. but it is still easy possible that it may not work for you with the first try, ad i dont test too often on other systems then mine. just tell me if it does not work.

Posted: **31 Oct 2008, 17:42**

Could we change the:

Code: Select all

struct SSAISpecifier {
	const char* shortName; // [may not contain: spaces, '_', '#']
	const char* version; // [may not contain: spaces, '_', '#']
};

to

Code: Select all

struct SSAISpecifier {
	const char* shortName; // [may not contain: spaces, '_', '#']
	const char* aiversion; // [may not contain: spaces, '_', '#']
};

or something different than "version"?

Because D (the language) uses the version function to detect which operation system you are running.
An example:

Code: Select all

version(Windows) {

   version(Win64) {
      pragma(lib, "foo64.lib");
   } else {
      pragma(lib, "foo32.lib");
   }

Ah yeah speaking of D instead of Mono means I dropped the Mono AI interface.
But I will help anyone who wants create a Mono AI interface.

Edit:
Oh and we need another directory for Spring AI bindings.
I suggest the following:
Spring/AI/Bindings/*
And for D:
Spring/AI/Bindings/D

Posted: **31 Oct 2008, 23:30**

i had a chat wiht Agon:
for those of you, who do not know the D programming language:
http://www.digitalmars.com/d/

it is basically so:
D code is comparable to C++, C# or Java, and it compiles to native. it has a relatively easy way to interface with C binaries, which works like this:
you can (automatically) generate D module files fomr C headers, through which you can access native stuff form withing D.
these module files are source files, hence only needed during compilation. Agon wants to put them into AI/Bindings/D, as there will be no D AI interface (D AIs will use the C interface) but they still need some common code, that should not be duplicated for each D AI.

this made me realise that the D modules are technically the same for D AIs like the Legacy C++ AI Wrapper code for legacy C++ AIs.
This code is currently under ExternalAI/Interface/LegacyCppWrapper, which .. is just not good, but i didnt know of a better place to put it.
so this code would be under AI/Bindings as well then.
-> i support this proposal

AI/Bindings/D/*.d
AI/Bindings/LegacyCpp/*.cpp/.h

the other stuff about renaming version to aiversion is not needed.

Posted: **31 Oct 2008, 23:55**

two proposals:

1. using no multi dimensional arrays
its some while back now already, so i dont remember anymore hwy i did it, but the C callback uses multi dimensional arrays in some places. i remember tobi saying this is no good (for compatibility or memory management reasons), and i now see that it is also a mayor draw-back when wrapping

well... i dont expect any disagreement on this, as the only negative i can think of is the implementation time to invest, which is of course solely mine

2. using constant global vars instead of #deinfe for constants
currently i use only #define for global constants, but . i think it was trepan who said it is bad practise or something, and it may also help a little when wrapping.
but i need advice here, is this a good idea? what are the pros and contras?
as much as i know, i could simple change this:

Code: Select all

#define MY_CONST 3

to:

Code: Select all

const unsinged int MY_CONST = 3;

and everything should work, right?
though i read that this only works in C, not C++. Though there are parts of the engine (written in C++) that need access to these constants as well. is this a problem? would it still work in C++ if the constants are enclosed in

Code: Select all

extern "C" { ... }

?

Posted: **01 Nov 2008, 00:03**

hoijui wrote:as much as i know, i could simple change this:
Code: Select all
#define MY_CONST 3
to:
Code: Select all
const unsinged int MY_CONST = 3;
and everything should work, right?

Right.

Posted: **01 Nov 2008, 10:38**

I would like this, too.
Less changing for the D bindings.
Btw. the bindings are finished. I only need to test them if they work.
Compiling to a static library (.a) works.
The problem is I can't create shared libraries with the official compiler, so I need to use gdc (gcc for D) or wait for a beta release of ldc (LLVM)....

I haven't seen any function for passing options to AIs is this not implemented?
By options I mean something like a difficult setting or if the AI is allowed to cheat.
We have discussed it before but don't know if we have decided for a solution.

Posted: **01 Nov 2008, 13:20**

passing options to AIs is not yet supported.

support for options is available for AIs as in:
they can specify options and possible values in AIOptions.lua (same ofrmat like Mod-options or Map-options). and unitsync supports reading these options too (in the caiinterface branch only of course).

pasing options to AIs is the only thing left, which should be really trivial.
but.. good you talk about that, i forgot to put it on my todo list.
when done, the options will be an additional member of the InitEvent.

Posted: **02 Nov 2008, 19:18**

hmm I wasnt aware there was demand for a D interface

Posted: **02 Nov 2008, 19:54**

AF wrote:hmm I wasnt aware there was demand for a D interface

I want D bindings because I want to write a D AI and no longer a C# AI.

Tried also Vala but meh gobject is a pain for me and Vala is to early in developing.

Posted: **03 Nov 2008, 09:35**

yeah.. from what i know (what Agon told me) it seems to be no bad idea, to have D AIs. Especially as it seems very easy to do. While Java or C# need their own, relatively complex interface libraries, we only need some source files/bindings to be included with D AIs. Agon already did them (in a few hours i think), just needs testing.
also.. i can't see any bad in adding suport for more languages, as long as i dont have to maintain the interfaces

an other thing: file names of AI and AI Interface binaries.
as we shift AI and AI Interface binares from the "impls" to the data folder, the names of the binaries become less important (from a pure technical poiunt of view).
we could, theoretically have it like this:

Code: Select all

AI/Skirmish/AAI/AIInfo.lua
AI/Skirmish/AAI/AI.dll
AI/Skirmish/KAIK/AIInfo.lua
AI/Skirmish/KAIK/AI.dll
AI/Skirmish/hoijuiAI/AIInfo.lua
AI/Skirmish/hoijuiAI/AI.jar
AI/Interfaces/C/InterfaceInfo.lua
AI/Interfaces/C/interface.dll
AI/Interfaces/Java/InterfaceInfo.lua
AI/Interfaces/Java/interface.dll

or like this (how it is now):

Code: Select all

AI/Skirmish/AAI/AIInfo.lua
AI/Skirmish/AAI/AAI.dll
AI/Skirmish/KAIK/AIInfo.lua
AI/Skirmish/KAIK/KAIK.dll
AI/Skirmish/hoijuiAI/AIInfo.lua
AI/Skirmish/hoijuiAI/hoijuiAI.jar
AI/Interfaces/C/InterfaceInfo.lua
AI/Interfaces/C/C.dll
AI/Interfaces/Java/InterfaceInfo.lua
AI/Interfaces/Java/Java.dll

or the other extreme:

Code: Select all

AI/Skirmish/AAI/AIInfo.lua
AI/Skirmish/AAI/AAI-SpringSkirmishAI.dll
AI/Skirmish/KAIK/AIInfo.lua
AI/Skirmish/KAIK/KAIK-SpringSkirmishAI.dll
AI/Skirmish/hoijuiAI/AIInfo.lua
AI/Skirmish/hoijuiAI/hoijuiAI-SpringSkirmishAI.jar
AI/Interfaces/C/InterfaceInfo.lua
AI/Interfaces/C/C-SpringAIInterface.dll
AI/Interfaces/Java/InterfaceInfo.lua
AI/Interfaces/Java/Java-SpringAIInterface.dll

(i left out version info in these examples, as it is not important for this discussion)

i can change the build system easyly to use any of these three paradigms.
As AIs will have to come in a package which contians at least a binary plus an AIInfo.lua, they will come in a zip containing a folder whihc can be axtracted directly to AI/Skirmish, i guess. therefore, the name of the actual binaries do not really matter.
question is just, what we would like to see.

Spring RTS Engine

Interface Redesign

Re: Interface Redesign

Re: Interface Redesign

Re: Interface Redesign

Re: Interface Redesign

Re: Interface Redesign

Re: Interface Redesign

Re: Interface Redesign

Re: Interface Redesign

Re: Interface Redesign

Re: Interface Redesign

Re: Interface Redesign

Re: Interface Redesign

Re: Interface Redesign

Re: Interface Redesign

Re: Interface Redesign

Re: Interface Redesign

Re: Interface Redesign

Re: Interface Redesign

Re: Interface Redesign

Re: Interface Redesign