Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / Plugins with AGK 2 - how to

Author
Message
Duffer
21
Years of Service
User Offline
Joined: 9th Feb 2003
Location: chair
Posted: 8th Dec 2014 08:45
Could someone direct me to all the info on this?

Presumably, if I created a dll plugin in Windows for an AGK2 application somehow and fed plugin commands in that would work on AGK2, that would only compile/work for Windows apps?

Would there be any way to create the plugin once, in one language, that could then be utilised by AGK2 and compiled to all platforms? ObjC? Again, could someone direct me to the info on this?

thanks in advance!

a long time dabbler with DBC and DBPro with no actual talent but lots of enthusiasm...
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 8th Dec 2014 10:21
You can only do this using C++ or Pascal using a cross-platform compiler. Windows is easy - just a create a DLL and an interface. For Android you will have to produce an .so library file and some probably Java interface. Etc.

iOS forbids dynamic linked libraries.

And, of course, there is no plugin mechanism for Basic. It would be relatively simple to include this for everything except iOS, but that would defeat the cross-platform nature of AGK.

-- Jim - When is there going to be a release?
paulrobson
9
Years of Service
User Offline
Joined: 22nd Nov 2014
Location: Norfolk, England
Posted: 8th Dec 2014 11:16
Indeed. I cannot see how a plugin system is viable, as it would be completely different for all platforms.

A possible slightly more practical alternative would be having some way of having C++ code statically linked into the interpreter/runtime - for example to provide a fast instr() as someone requested elsewhere.
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 8th Dec 2014 14:16
As I've said many times, a Lua interface would solve a whole raft of issues.

This is really a Basic problem. You can do pretty much whatever you like in C++ or Pascal.There is a good case for keeping Basic simple, and leaving the rocket-science to those who have advanced skills.

It seems to me that adding a bit of name-space awareness to the Basic compiler would allow some nice extensions (in source code) that could be sealed off. It just takes a bit of modularisation.

This (before the anti-OOP crowd shout) is not object-orientated. It has been present in languages like Pascal since 1970s. In Pascal a Unit is a file called <something>.pas. It has an interface section and an implementation section. Anything declared in the interface is available (public) to any other unit which uses it. Anything in the implementation section is not available. Things can be global to the interface, but not available outside it.

This would make the Basic better for large programs. And if Lua were available we could write import modules that handled all the Lua and had some neat little functions that beginners could use.

-- Jim - When is there going to be a release?
paulrobson
9
Years of Service
User Offline
Joined: 22nd Nov 2014
Location: Norfolk, England
Posted: 8th Dec 2014 14:20
Modula 2, basically.
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 8th Dec 2014 14:42
Actually - just fundamental Pascal. I wrote Music Maker for CDTV using Oberon- the successor to Modula-2. I wrote Music Machine for the PC using Oberon-2, the successor to Oberon.

Historical note: the PC might never have been so successful without Turbo Pascal and Modula-2.

-- Jim - When is there going to be a release?
paulrobson
9
Years of Service
User Offline
Joined: 22nd Nov 2014
Location: Norfolk, England
Posted: 8th Dec 2014 16:58
Ah, you're old like me

Agreed about TP (and TC as well).

I can't see it being that difficult to implement. Extend identifiers so they have a namespace option (say a full stop) so you would declare function sprite.getx() rather than function spritegetx() would make things look cleaner (I note some AGK2 functions do something like this anyway ?).

Probably the simplest way to have private/public would be to do something like drop all identifiers beginning with an underscore from the identifier table when you leave an include/insert ? You might have to turn this off for backwards compatibility.
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 8th Dec 2014 18:21
Sure.

Bet I'm older than you are!

Yes - <namesspace>.publicThing etc

Currently there are no separate units of compilation - they're just included and lobbed in. So adding a compiler file type like .agu for a unit would do the job. Actually it would only require one new keyword - Private. Assume it's all public until you see this.

C never did "get" this - hence the mess of .h .c .cpp files.

-- Jim - When is there going to be a release?
Duffer
21
Years of Service
User Offline
Joined: 9th Feb 2003
Location: chair
Posted: 8th Dec 2014 22:22
@ JimHawkins & paulrobson,

Sorry, just picking up on this thread again now. Thanks for all the info!

By the sounds of things, there is no (?) universal way to create a plugin totally cross-platform, not even in C++?

In which case, LUA does sound like a good option.

I'd been looking at maybe writing a plugin for Sqlite3. (and I have now given up on the idea! Hopefully TGC will do one!)

a long time dabbler with DBC and DBPro with no actual talent but lots of enthusiasm...

Login to post a reply

Server time is: 2024-05-03 07:48:01
Your offset time is: 2024-05-03 07:48:01