I don't use C# but I think you should use an "Allegro scope" for everything. So use "Allegro.Keyboard.Install ()" instead your example. It will avoid collisions better.

Is there some particular reason for it being AllegroSharp rather than Allegro? The name is quite long enough as it is.

Well, you don't normally specify a namespace in C# unless there's a conflict, which has never happened to me.

Besides, it can't be Allegro because I have a static class called Allegro.

For illustration purposes:

using System;
using AllegroSharp;

class Program
{
    static void Main(string[] args)
    {
        Allegro.Init();
        // Supposing I've defined a class called Keyboard somewhere,
        // I have to resolve this.
        AllegroSharp.Keyboard.Install();
        // etc...
        Allegro.Exit();
    }
}

But if you think AllegroSharp is a long namespace, try Microsoft.Xna.Framework!

Well, progress update.

Mostly everything is fully implemented, and about 65% of what's implemented is documented.

The things it still needs are:

• Joystick needs to be redesigned because it's not playing nicely with the interop.

• GUI needs to be implemented.

• Fixed point and 3D math are being left out because there's no use for them.

• Lots of documentation still, went on a coding binge without documenting.

• Translate the rest of the examples. (Currently translated 5 of them)

</li>

Here's ExData, the shortest example I've translated.

Feel free to mock the hell out of the API.

You are using an old Mono version - update to 1.2.6 or higher and use the gmcs compiler with the switch that enables the new C# 3.0 features.

IIRC it's -langversion:linq, which should be enabled by default on Mono 1.9+.

Is the 1.9+ stable enough for usage?

Anyway, just for the heck of it I fixed those errors to see what comes next. And found out it builds with just 28 warnings. But running an example is a different matter. It doesn't find AllegroBridge.dll so I guess one needs to do something about that. I don't know how this stuff works though so someone could maybe explain? I'm guessing I need to have a AllegroBridge.so, but how exactly should it be built, and then referenced in monodevelop?

Sorry guys, I'd love to address the concerns raised here in-depth, but I've got some eye problems and I won't be able to use the computer much for the next couple weeks. Not sure how that's gonna work out with TINS yet, I might get the a-ok by then.

You're correct about AllegroBridge. It's included in the source distribution and a .dll is included in the binary distro, but no .so yet.

Yes, AllegroNet might've been a better namespace, but I didn't want to step on the toes of the Allegro.NET project.

Don't rely too explicitly on the API yet*, I'm looking to change the memory management after TINS to leave unmanaged memory at the threshold of interop instead of carrying it over. I'd tried this before and encountered problems, so I took the "First make it work, then make it work better." approach.

*Just a warning. I don't plan to change the API, but I can't guarantee it won't as a result of this goal.

~~~

I've added solutions and projects specifically for SharpDevelop/Mono.

They should work for Linux, but I don't have a distro at hand so I can't test it at the moment. You will need to compile AllegroBridge yourself, on Linux, which should be easy as pie: Insert source files, receive library.

If you would rather not use dll mapping, you can change ALLEG_DLL and BRIDGE_DLL (in src/Bridge/Bridge.cs) to be *.so instead of *.dll.

It seems there should be a preprocessor directive for determining the platform, but I can't find one.

Happy coding!

It too can. C# is smart enough to figure out the difference between class Allegro, namespace Allegro, and class instance Allegro. Therefor, you can have a class, a namespace and a variable all by the same name, sharing scope.
Long namespace names are not much of a concern though, assuming you're using Visual Studio's Intellisense (which works better with C# than with most other languages). How else would people not get offended by stuff like this: System.Data.SqlClient.SqlParameter param = new System.Data.SqlClient.SqlParameter("@foo", foo);

I know. It's just that long identifier names don't bother me anymore now I have intellisense and all that. What I'm trying to get at is that Visual Studio makes the length of identifier names pretty irrelevant, so people shouldn't be complaining.
In real life, I put "using System.Data.SqlClient" at the top and just type "SqlP", then Enter (or open bracket, or whatever comes next).
What is more irritating is identifier names that share a lot of letters, like "ConfigurationSettings", "ConfigurationManager", etc. etc. - when I want "ConfigurationManager", I need to either type "ConfigurationM" plus hit Enter, or type "Con" and then scroll down the list to find what I want.