Wrappers and AIs

Wrappers and AIs

Discussion between Spring developers.
Post Reply
Auswaschbar
Spring Developer
Posts: 1254
Joined: 24 Jun 2007, 08:34

Wrappers and AIs

Post by Auswaschbar »

Because the merge of the caiinterface branch is near, I would like to know how we should handle the bindings (wrappers). Right now, hoijui has a C, a C++ and a 2 Java-bindings.

Now Agon has asked to merge his mono-wrapper. The question is, should we include all wrappers in the main repo?

I could basically think of 2 possibilities:
1. Include them all in spring-repo
pro: easy to do
con: repo will grow, the amount of wrappers might grow, need to merge every change from the forks

2. Submodules (git submodule)
pro: maintainers have full control over their submodule, spring repo will not grow because they are modular and optional
con: never done before, not as easy as 1

Some git submodule tutorial, to see how it works: http://git.or.cz/gitwiki/GitSubmoduleTutorial

Opinions? I would favour trying 2 first, we can still mergethem in the repo later

edit: bibim said I got something wrong, now waiting for him to make a diagramm to explain.
User avatar
hoijui
Former Engine Dev
Posts: 4344
Joined: 22 Sep 2007, 09:51

Re: Wrappers and AIs

Post by hoijui »

i am currently assembling a diagram to explain the code sturcture of the new C Interface. i suggest you all wait till you saw it, before thinking about this.
eta: very soon

;-)
no really, should come today
imbaczek
Posts: 3629
Joined: 22 Aug 2006, 16:19

Re: Wrappers and AIs

Post by imbaczek »

I'm not sure the increase in repo size is big enough to be noticeable. I'm not against trying submodules, but I'm +1 for inclusion in the engine repo anyway (as long as build is optional so I don't have to download epic amounts of dependencies.)
User avatar
hoijui
Former Engine Dev
Posts: 4344
Joined: 22 Sep 2007, 09:51

Re: Wrappers and AIs

Post by hoijui »

Here it is!
CodeStructure.png
(58.05 KiB) Downloaded 59 times
Repo size of the Interfaces:
C 26KB
Java 207KB + 1.5MB Java libs (*.jar files)

+1 for direct inclusion in main repo

An alternative Idea
We could try submodules for upcomming new AIs. Expecially non native AIs (eg. Java or Mono AIs) would be well suitet for this. Code-Wise, they will genereally be very loosly coupled to the engine. For example in the case of Java, they only need AIInterface.jar from the Java AI Interface.
This way, we would aquire practical knowledge about git submodules, and if we see that it would work well with interfaces aswell, we could still put them into such modules later.

An other thing to consider is, that small maintainance work on the interfaces can be done by all spriong devs, if they are in the mian repo, whereas we would have to rely on one or a few maintainers per AI Interface otherwise.

Edit:
for more diagramms concerning the workings of the itnerface, see:
viewtopic.php?p=328843#p328843
imbaczek
Posts: 3629
Joined: 22 Aug 2006, 16:19

Re: Wrappers and AIs

Post by imbaczek »

btw I'm -1 for having jars under version control.
Auswaschbar
Spring Developer
Posts: 1254
Joined: 24 Jun 2007, 08:34

Re: Wrappers and AIs

Post by Auswaschbar »

1.5 mb seems a bit larg'ish, despite the fact there are ubuntu packages for it (also debian / gentoo, rpm's seems missing)
User avatar
hoijui
Former Engine Dev
Posts: 4344
Joined: 22 Sep 2007, 09:51

Re: Wrappers and AIs

Post by hoijui »

As discussed with Agon and Auswaschbar, the java libs will be moved to mingwlibs on windows, and i will write SCons and CMake find scripts to find them under POSIX. For this to work, i will need all possible paths (including filenames) to the *.jar 's from libjna and libvecmath when installed with your package manager, plus the .so from libjna.
so please donate some!
on Ubuntu it is:

Code: Select all

/usr/share/java/vecmath1.2-1.14.jar
/usr/share/java/jna-3.0.4.jar
/usr/lib/jni/libjnidispatch.so
i hope to be able to use regex to find them, so the version does not matter.
Auswaschbar
Spring Developer
Posts: 1254
Joined: 24 Jun 2007, 08:34

Re: Wrappers and AIs

Post by Auswaschbar »

Gentoo:
/usr/share/vecmath/lib/vecmath.jar

No jna because gcc was not built with libffi.
imbaczek
Posts: 3629
Joined: 22 Aug 2006, 16:19

Re: Wrappers and AIs

Post by imbaczek »

those paths should be configurable, preferably during runtime, perhaps by an environment variable or a simple spring config var.
User avatar
lurker
Posts: 3842
Joined: 08 Jan 2007, 06:13

Re: Wrappers and AIs

Post by lurker »

On thing I can't quite figure out. What is the bottom right box labeled AI/Interfaces/Java/..., that is autogenerated?
User avatar
hoijui
Former Engine Dev
Posts: 4344
Joined: 22 Sep 2007, 09:51

Re: Wrappers and AIs

Post by hoijui »

yes, it is auto generated (AWK scripts parsing the C interface and one of the generated .java files). They create a bunch of other .java files that create an OO layer over the basic Java wrapper.
The C interface uses a lot of IDs (unitId, groupId, weaponId, unitDefId, ...) plus, it has a flat hirarchy, obviously, as we cant have classes. the basic Java layer works just like that, it is a direct wrapper over the C interface. When you use this layer, you do only Java, and Jav ais OO only, as we know, ubt it just does not feel like OO. It is like a direct Java wrapper of OpenGL. Just one big class with a few hundred functions. The Java OO wrapper changes this: you should not have to use IDs, but you use the Unit, Weapon, UnitDef, etc. classes. Also, the callback, having function pointers like this in C:

Code: Select all

int (CALLING_CONV *Clb_WeaponDef_Shield_getRechargeDelay)(int teamId, int weaponDefId);
looks like this in Java:

Code: Select all

class AICallback {
   int Clb_WeaponDef_Shield_getRechargeDelay(int teamId, int weaponDefId);
}
And like this in the Java OO wrapper:

Code: Select all

class OOAICallback {
   List<WeaponDef> getWeaponDefs();
}
class WeaponDef {
   Shield getShield();
}
class Shield {
   int getRechargeDelay();
}
Post Reply

Return to “Dedicated Developer Discussion”