Prompted by BAF's complaints against current C# bindings, I've taken it upon myself to write up a relatively simple C# binding for Allegro.

Objective:

To create a C# binding for Allegro with an API familiar to users of both Allegro and .NET, and have the whole project done in time for TINS.

Current Status:

About 25%.

It currently consists of two parts: a tiny C library that translates some of the Allegro API to be .NET-friendly, and the actual C# library.

I've been sticking fairly close to the API, but changing the wording where appropriate to match familiar .NET syntax, and adding scope where appropriate. (ie. Allegro.Init(), Keyboard.Install())

Feature Requests/Comments/Concerns/Gripes against other bindings
(aka the point of this thread)

Post em here. I want to make something everyone can use.

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.

C# puts everything in your project in a namespace by default. (I'm not sure if you can even have code outside a namespace...) The namespace for the project is AllegroSharp, so if you don't resolve it with a using directive, it is AllegroSharp.Keyboard.Install().

Question: What is the most desirable syntax for Datafiles?

// Most verbose...
Bitmap bmp = myDatafile.FindObject("FILE").FindObject("BMP").Cast<Bitmap>();

// Most sugary...
Bitmap bmp = myDatafile["FILE"]["BMP"];

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

Hah! Thats the same thing I wanted to say 3 hours earlier. But, my comment was more like:

Why must it be named AllegroSharp. I mean, you are already programming it in C Sharp, why does that need to be in the name of the binding too?

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!

Perhaps you should reconsider naming that class Allegro, then. From the looks of it, most operations will be on the namespace, not that class.

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're going to make it work in Monodevelop?

I just checked out and tried to build. It fails.
First error at this line in Bitmap.cs
protected virtual IntPtr ptr { get ; set ; }

get must have a body because it is not marked abstract, extern, or partial

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.

And what switch is that?
I googled a bit and can't find it.

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

You can't have methods at namespace level in C#. Even static methods should be in class scope.

I like the name AllegroSharp. Though if you consider it might work as well on VB.Net, maybe it should be called AllegroNet or something like that.

I'm trying it right now on some MSVC# Express edition! It for sure will delay my tests on XNA but I bet it worth!

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?

For most uses, yes. Some Windows.Forms parts have a few kinks, as does the ASP .Net module, but otherwise its quite solid. I develop an opengl simulation for my diploma thesis and I have no problems running the same executable on Mono/.Net. Mono 2.0 should arrive on September and should be a stable implementation of .Net 2.0 (plus some newer parts, e.g. linq).

This is an unmanaged library that smooths out Allegro's API, to make wrapping simpler (without having looked at the source, I'm pretty sure it provides getters/setters for global variables and things like that). This will have to be compiled for each platform (while the C# wrapper needs only to be compiled once).

Once you have an .so, you simply instruct Mono to use this .so instead of the windows dll. Check here for details: http://www.mono-project.com/Config_DllMap

Edit: Btw, the A5 API should be much more wrapper-friendly (no need for intermediate dlls etc).

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!

Have you considered naming the namespace Al4 (then Al5) or similar to distinguish the Allegro versions? Plus it's shorter.

Just a suggestion.

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 think the namespace concerns are a bit of a bike shed, to be honest. It's fine being the name of the library, and it impacts precisely one line of code per source file, in a place most people choose to hide with regions.

That is not representative of real code. By default, you have using System.Data; in your source files, so even if you're a complete idiot and don't add using System.Data.SqlClient; since you're using SQL, you'd only have to type SqlClient.SqlParameter.

Or just type SqlParameter and right click it and choose "Resolve using System.Data.SqlClient" to have VS do it for you.

~~~

Version 0.81

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.