Messages

Link updated.

Yes, it is the antimatter-shielded extraterrestrial flying battleship "The Giant Claw":

Starcrash

You can do something like this:

Code: ags

[Serializable]
public abstract class Preference
{
}

[Serializable]
public class Preference<T> : Preference
{
	public string Name { get; set; }
	public string DisplayName { get; set; }
	public string Category { get; set; }
	public T Value { get; set; }
}       

public static IList<Preference> Deserialize(string filename)
{
	using (XmlReader reader = new XmlTextReader(filename))
	{
		reader.ReadToDescendant("ArrayOfString");
		XmlSerializer typeSer = new XmlSerializer(typeof(List<string>));
		List<string> typeNames = (List<string>)typeSer.Deserialize(reader);
		List<Type> types = new List<Type>();
		foreach (var type in typeNames)
		{
			types.Add(Type.GetType(type));
		}

		reader.ReadToDescendant("preferences");

		XmlSerializer deSerializer = new XmlSerializer(typeof(Preference), types.ToArray());
		List<Preference> retvalue = new List<Preference>();
		while (reader.Read())
		{
			switch (reader.NodeType)
			{
				case XmlNodeType.Element:
					if (reader.Name == "Preference")
					{
						retvalue.Add((Preference)deSerializer.Deserialize(reader));
					}
					break;
			}
		}

		return retvalue;
	}
}

public static void Serialize(IList<Preference> preferences, string filename)
{
	List<Type> types = new List<Type>();
	List<string> typeNames = new List<string>();
	foreach (var pref in preferences)
	{
		var type = pref.GetType();
		if (!types.Contains(type))
		{
			types.Add(type);
			typeNames.Add(type.AssemblyQualifiedName);
		}
	}

	XmlSerializer serializer = new XmlSerializer(typeof(Preference), types.ToArray());
	XmlWriterSettings settings = new XmlWriterSettings()
	{
		Indent = true
	};

	using (XmlWriter writer = XmlWriter.Create(filename, settings))
	{
		writer.WriteStartElement("doc");

		writer.WriteStartElement("types");
		XmlSerializer typeSer = new XmlSerializer(typeNames.GetType());
		typeSer.Serialize(writer, typeNames);
		writer.WriteEndElement();

		writer.WriteStartElement("preferences");
		foreach (var pref in preferences)
		{
			serializer.Serialize(writer, pref);
		}
		writer.WriteEndElement();

		writer.WriteEndElement();
		writer.Flush();
	}
}

This will save the concrete 'Preference<T>' types to xml, and then use them to initialize the XmlSerializer on deserialization.

Still waiting for next XCom

2K is going to release a shitty FPS in Q1 2012, they dare to call 'XCOM'.

and Jagged Alliance

bitComposer is currently working on a remake of Jagged Alliance 2, the best turn-based strategy game ever created by men. Of course it's not going to be turn-based.

There's a new Heroes of Might & Magic coming out soon. Haven't checked, but I guess it's going to be a cover-based shooter...

You won't be able to, due to the Native DLL. If the source code to that was available, does Mono have a mixed-mode Managed & Native C++ compiler that could build it?

No, but it would be possible to use a pure native library with a C-style API.

The AGS Editor uses P/Invoke in some rare cases where I couldn't find a way of doing it with managed code. The Named Pipes exception that you mention is in .NET 3.5, but since I want the AGS Editor to continue to support .NET 2.0, we can't use this. (it would be feasible to just use that for a Linux port which would require a 3.5-version of Mono though, of course).

Seems that Mono doesn't support named pipes under Linux at the moment anyway.

Notes on the P/Invokes used by AGS.Editor:
http://pastebin.com/AgTb6N2J

pInvoke is well supported in mono too, it's used by any library that exposes an existing C or C++ library to mono (ie, sdl, wxwidgets and more).

AGS has P/Invokes into WinAPI (kernel32, user32, winmm). It might be possible to use the Wine libraries, but I'd rather replace them with managed code.

Named pipes exist on unix too, the main problem would just be porting between the unix/windows methods for using named pipes.

As I said, there's a managed solution:
http://msdn.microsoft.com/en-us/library/system.io.pipes.namedpipeclientstream.aspx
http://msdn.microsoft.com/en-us/library/system.io.pipes.namedpipeserverstream.aspx

Also, it seems irrklang has support for linux too:

Unfortunately, the wrapper is a mixed-mode assembly (managed+native code) which doesn't work with Mono.
One alternative would be fmod:
http://www.fmod.org/

It at least starts in openSUSE:


Components that need to be modified:
* Debugger (uses PInvokes for named pipes, which are supported in .NET 3.5, not sure about Mono)
* Audio (Irrklang is a mixed-mode assembly)
* SourceControl
plus all the other stuff that relies on native methods.

Small update:
The C++ glue code is included in the zip file.
PluginAPIWrapper.dll is compiled with MinGW, so you don't need the VC++ 2010 redist anymore.

I've uploaded a new version which might fix the problem.

Do you have the VC++ 2010 redist installed?
http://www.microsoft.com/downloads/details.aspx?FamilyID=a7b7a05e-6de6-4d3a-a423-37bf0912db84&displaylang=en

Also copy PluginAPIWrapper.dll to the game's "_Debug" folder, or include the AGS editor folder in PATH.

Please try the updated example.
The error might be caused by the delegate getting GCed.

Install the .NET SDK:
32 bit:
http://www.microsoft.com/downloads/details.aspx?FamilyID=fe6f2099-b7b4-4f47-a244-c96d69c35dec&displaylang=en
64 bit:
http://www.microsoft.com/downloads/details.aspx?familyid=1AEF6FCE-6E06-4B66-AFE4-9AAD3C835D3D&displaylang=en

New version is up.
-Fixed 'AGS_EditorSaveGame' and wrongly marshalled char pointers.
-Most constants are now enums.
-Most properties are now PascalCased.

Would there be any considerable slowdowns in using the wrapper compared to straight C++?

There's a significant overhead involved in calling the AGS API methods.
However, I haven't made any performance tests yet.

Purely proof-of-concept at the moment. Barely anything besides registering new script functions has been tested.

Website

The 'AGSPlugin' class contains the callback methods as described here.

RegisterScriptFunction example:
Declare a method:

Code: ags

private static int AddNumbers(int a, int b)
{
   return a + b;
}

and a matching delegate:

Code: ags

[UnmanagedFunctionPointer(CallingConvention.Cdecl)]
public delegate int AddNumbersDel(int a, int b);

The delegate has to use the UnmanagedFunctionPointer attribute with CallingConvention.Cdecl.

Register the script header in EditorStartup:

Code: ags

public int EditorStartup(IAGSEditor editor)
{
   editor.RegisterScriptHeader("import int AddNumbers(int, int);
");
   return 0;
}

Register the script function in EngineStartup:

Code: ags

private AddNumbersDel del;
public void EngineStartup(IAGSEngine engine)
{
   del = new AddNumbersDel(AddNumbers);
   IntPtr address = Marshal.GetFunctionPointerForDelegate(del);
   engine.RegisterScriptFunction("AddNumbers", address);
}

[128]

the length is encoded in big endian and the upper byte is one bigger.

Looks more like the offset of the footer (little endian).

The footers (256 bytes) contains the offsets of the 128 char descriptions (2 bytes, little endian).

Warning Forever?
Edit: argh, too late.

http://sites.google.com/site/infralicht/Home/ags-2/mediamanager

Code: ags

Path.GetDirectoryName(Assembly.GetEntryAssembly().Location)

or

Code: ags

AppDomain.CurrentDomain.BaseDirectory

should return the AGS dir.

But since Vista and 7 don't like writes to 'program files', and, at least on XP, the AGS installer defaults to a subfolder of that, you should create a new folder in 'application data' and write to that folder.
E.g.:

Code: ags

dir = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData), "PluginInfo");
if (!Directory.Exists(dir))
{
  Directory.CreateDirectory(dir);
}