Integration of GlobalAI C interface into Spring core?

hughperkins · Post by **hughperkins** » 13 Nov 2006, 18:17

There's a C-interface available for Spring GlobalAIs, http://taspring.clan-sy.com/phpbb/viewtopic.php?t=7991

Why use a C interface instead of a C++ interface:
*independence wrt compiler for GlobalAIs
*independence wrt Spring version upgrades for GlobalAIs

It could be interesting to integrate the GlobalAI C interface into Spring core.

Possible method for how this could work:
*we use SharedLibrary to connect to the dll as usual
*we attempt to bind a function IsCInterface
*if we succeed, we bind using a C interface
*otherwise we default to the C++ interface

Thoughts?

AF · Post by AF » 13 Nov 2006, 22:05

Nobody has rebuilt the C++ interface ontop of the C ABI interface. None of the AIs are compatible with ti save CSAI without major refactoring. The ABI AI interface is thus an unfinished product.

Post by **Kloot** » 13 Nov 2006, 22:48

Yes, someone still needs to do that... right now we have three interfaces (the C++ one, the C one and the ABI-C one) and nothing whatsoever behind the second, so perhaps it's best to focus on one at a time rather than trying to finish both in parallel.

hughperkins · Post by **hughperkins** » 14 Nov 2006, 09:43

Edit: removed implementation detail

Post by **jcnossen** » 14 Nov 2006, 13:04

Nobody has rebuilt the C++ interface ontop of the C ABI interface. None of the AIs are compatible with ti save CSAI without major refactoring. The ABI AI interface is thus an unfinished product.

You've constantly been saying that there needs to be a new interface, now someone makes a working version and you're complaining about it again.
Its ment as an addition to the C++ interface, since it's very easy to keep that one in it as well.

hughperkins · Post by **hughperkins** » 15 Nov 2006, 09:06

GlobalAI C interface is now integrated into Spring, and committed to SVN.

AIs that export a function IsCInterface are linked to using the C interface, otherwise the C++ interface is used.

See AI/Global/TestABICAI for an example of a GlobalAI using the C interface.

hughperkins · Post by **hughperkins** » 15 Nov 2006, 20:40

Created C++ wrapper classes, see AI/Global/CSAI/CSAILoader in SVN. The wrapper classes are:
*AbicAICallbackWrapper.h
*AbicFeatureDefWrapper.h
*AbicMoveDataWrapper.h
*AbicUnitDefWrapper.h

Any instance of these classes will have been created with new, so you will need to delete the instances as appropriate.

Properties are accessed via accessor functions, eg:

Code: Select all

AbicUnitDefWrapper *unitdef = aicallback->GetUnitDef( unit );
aicallback->SendTextMsg( unitdef->get_humanName(), 0 );

Certain functions have been modified to make them easier to send across the C interface:

*new function bool IsGamePaused() in aicallback
*new funciton int GetCurrentUnitCommandsCount( int unit ) in aicallback
*new functions GetNumUnitDefs and GetUnitDefByTypeId( int typeid ) replace GetUnitDefList in aicallback
*new functions int GetNumBuildOptions() and char *GetBuildOption( int index ) replace buildOptions in unitdef

AF · Post by AF » 15 Nov 2006, 23:29

jcnossen wrote:
Nobody has rebuilt the C++ interface ontop of the C ABI interface. None of the AIs are compatible with it save CSAI without major refactoring. The ABI AI interface is thus an unfinished product.
You've constantly been saying that there needs to be a new interface, now someone makes a working version and you're complaining about it again.
Its ment as an addition to the C++ interface, since it's very easy to keep that one in it as well.

A total redesign or a complete recreation, not some pseudo re-implementation that does nothing to help the interfaces design but make things awkward to port AIs to it. If anything the interface has gotten awkward and unwieldy with the changes it has had applied to it, ABI compatibility does not require that the interface itself should change. It's perfectly possible to implement it in such a way that very little work needs to be done to port an AI to it.

So its important that any changes help AI devs, whereas the interface presented to an AI a changed such that it hasnt helped but rather created a large workload.

Whatsmore, a redesign would be a complete overhaul with a compltely redesigned interface, not one or two functions change name, a few additions here, and changing a few variables to use getter functions, but a completely different setup, designed with the AI dev in mind not the technical workings that drive it.

How would you like it if a enw OpenGL API was brought out and you had to update your code and every single functions and interface in the API had been changed such that they all basiclly did the same thing but worked in a slightly different way so that you had to go through line by line and hand edit everything, just so that it works as it did before the change with no new features or speed improvements or help?

Post by **Kloot** » 16 Nov 2006, 00:47

e: outdated

hughperkins · Post by **hughperkins** » 16 Nov 2006, 07:20

Note that ABIC/Abic++ binds per-function so:
*adding a new function to aicallback wont break older AIs
*adding a new property to unitdef wont break older AIs

hughperkins · Post by **hughperkins** » 16 Nov 2006, 07:43

AF, you've put a lot of work into NTai over a year and a half and NTai is very impressive.

When NTai is given build time, it can be difficult to beat.

Ever since CSAI has been published, NTai allegedly "doesnt work" and "the most powerful skirmish AIs [have been] reduced to something that barely issues a command" ( http://taspring.clan-sy.com/phpbb/viewt ... highlight= ).

A cynic might imagine that there is an ulterior motive for not publishing a 0.73b1 release of NTai.

Of course, I am not so cynical

hughperkins · Post by **hughperkins** » 16 Nov 2006, 11:42

On a more constructive note... you want to create an AI interface that uses associative arrays. That's an idea that could work and it fits in very well with the way Python works.

You might consider building a Python interface that uses the associative array interface. It's an easy sell, lots of people like Python.

Tobi · Post by **Tobi** » 16 Nov 2006, 12:57

AF wrote:stuff

Note that using the interface is optional. If you don't mind compiling using MinGW once spring is compiled using MinGW, then there's no need at all to use the new ABIC interface. If you want to develop using MSVC, then you can either build spring in MSVC, or you can use the new interface.

So no one is forcing you to spent time to convert your AI or anything...

AF · Post by AF » 16 Nov 2006, 18:54

yes you are if I am to continue using VS2003, since mingw32 doesnt look nice at all.

And if the interface was completely redesigned it would be a matter of porting NTai it'd be a matter of jumping up and down that I can throw NTai away and start a sequel.

A complete 99% reconstruction of the C++ interface can be done over these C bindings, and it is perfectly possible that this can be engineered quite well into a simple #define MyClass Myclass being renamed to #define MyClass AAI or #define MyClass CNTai.

I do have one suggestion though. Currently the C++ wrapper is in the same place as the C wrapper, but this is not very good, because they're both tied together, and it doesnt make the seperation as clear as it could be. Should I use the C++ wrapper I'd rather distribute it with NTai source as a part of NTai like krogs metal class and modify it as I wish. I take it that would be possible? Or are the C++ wrappers inextricably bound and would thus need AI updates etc.....

And, hugh, NTai wasnt broken when CSAI was released, NTai was broken when 0.73 was released, and arguably it had a number of major flaws that broke it in 0.72 too. You where lucky enough never to have seen XE9 RC18/ 19/ 20/ 21/ 22 and saw a rough beta XE9.3 instead. Since when I sent you that last bianry I've made a few changes but I havent finished yet, and I've since been handed a pile of coursework assignments which has limited my time for personal development a lot.

And they where reduced to not doing anything, but they had maintainers and where patched accordingly, though nobody is quite sure what was wrong what changed and how it got fixed, and some simple AI projects got away with not being affected at all...

hughperkins · Post by **hughperkins** » 16 Nov 2006, 19:04

AF wrote:I do have one suggestion though. Currently the C++ wrapper is in the same place as the C wrapper, but this is not very good, because they're both tied together, and it doesnt make the seperation as clear as it could be. Should I use the C++ wrapper I'd rather distribute it with NTai source as a part of NTai like krogs metal class and modify it as I wish. I take it that would be possible? Or are the C++ wrappers inextricably bound and would thus need AI updates etc.....

The C++ wrappers are headerfiles which are currently in AI/Global/CSAI/CSAILoader. You're welcome to copy and paste them into your own code, and modify them as you wish, as long as you conserve the header comments. They are under GPL.

The C++ wrappers are entirely AI-side. Spring has no knowledge of them at all.

Ideally the C++ wrappers should be in a separate directory from the CSAI loader. I'll look at doing that now.

The C interface is integrated into Spring core and is located at rts/ExternalAI/GlobalAICInterface .

hughperkins · Post by **hughperkins** » 16 Nov 2006, 19:15

C++ wrappers have been moved to: AI/Global/CSAI/AbicWrappers .

hughperkins · Post by **hughperkins** » 16 Nov 2006, 20:34

Created an example Visual C++ Express 2005 AI, using Abic++, at AI/Global/AbicWrappersTestAI , within the SVN.

Note that it assumes you're using the scons/mingw build of Spring.

Edit: you can get latests scons/mingw spring build from http://www.osrts.info/~tvo/spring/

Post by **Kloot** » 17 Nov 2006, 00:53

e: outdated

Spring RTS Engine

Integration of GlobalAI C interface into Spring core?

Integration of GlobalAI C interface into Spring core?