UWP Compatibility.

[Langerz82]

To include it needs to be a .CORE library. Creating a new project and adding the source files it complains about the streams having no close() functions. Thread and Threadpool also throw errors. Please help I'd really love to get this working for Monogame.

[marshallward]

Unfortuantely I'm at a loss here because I work primarily in Linux and (AFAIK) cannot create UWP libraries using Mono.

But I'll see if I can do anything about the close calls, I know there are many outstanding problems with the current Zlib implementation.

These may be solved already in Zlib.Portable; I will revist #16 and see if it solves your problem.

[Langerz82]

I have replaced the closes with dispose and the test case works, however trying to include it in a project it throwing the following error:

An unhandled exception of type 'System.IO.FileNotFoundException' occurred in MonoGame.Framework.dll

Additional information: Could not load file or assembly 'System.Runtime, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

Any ideas?

[marshallward]

Not sure, but it looks like a missing library. Maybe one of the System.Runtime.* libraries is needed? It's been a long time since I built MonoGame (assuming that's where the problem is).

BTW using Dispose() is one of the PCL requirements, so this would be a positive change anyway. I'm currently testing it out.

[Langerz82]

Here is a bit more info on trying to load the minimal.tmx with the closes replaced, and the thread and threadpool error fixed.

http://i.imgur.com/bLGmdvj.png

[Langerz82]

More info: "Unable to cast object of type 'Game1.App' to type 'Windows.UI.Xaml.IApplication2'."

The error occurs as long as any method in your library is called, and it occurs before the execution of the line. I'm guessing that when your library file includes into the game during runtime that is when the error occurs. I am quite sure that the threading is the issue.

Here is the gist of the game class: https://gist.github.com/Langerz82/62e9437cd7f733e254c0973548b6afd6

[marshallward]

I don't think I'm in a position to test the threading issue at the moment (since I can't create UWP without overhauling my Windows machine), and I leave very soon for a 1-week overseas trip, so I may not be much help with this issue for some time.

Have you tried some of the PCL-compatible zlib libraries yet? You can try replacing the zlib directory with these and see if they help.

• https://github.com/icsharpcode/SharpZipLib
• https://github.com/advancedrei/Zlib.Portable

When I last looked at these options, none solved all of the PCL problems but did solve many of them. You may have better luck with these.

I am also open to replacing the zlib code, or removing it and setting up a dependency.

[marshallward]

Or if I am understanding this comment correctly, then we can just skip the first two bytes of a zlib stream and treat it as a gzip file? Which would mean we could use the built-in .NET functions and throw out ZLib altogether?

[marshallward]

To follow up on the previous point:

I can see that the gzip bytestream has a 10-byte header while the zlib has its standard 2-byte header. The zlib footer has a 4-byte adler32 checksum, while the gzip footer is a 4-byte crc32 checksum followed by a 4-byte length counter.

I'd recommend that we alter the zlib bytestream to look like a gzip stream and just use the standard .NET gzip decompression. That way, we can completely eliminate the Zlib source code and focus on the remaining issues within TiledSharp itself.

I am not yet sure how to spoof the checksums and lengths (assuming it is even necessary or possible) but I think this is the right way forward.

[Langerz82]

Got it working as a PCL Library to include to the Monogame UWP Project. Had to make a few changes:

In TiledCore.cs GetEntryAssembly() does not exist. So I made it a static variable and set it prior to the call to Tmxmap.

line 19: public static Assembly ASSEMBLY; line 35: if (ASSEMBLY != null) line 36: manifest = ASSEMBLY.GetManifestResourceNames(); line 46: using (Stream xmlStream = ASSEMBLY.GetManifestResourceStream(fileRes)) {

In zlib/ParallelDeflateOutputStream.cs line 34: using System.Threading.Tasks; line 633: //if (!ThreadPool.QueueUserWorkItem( _DeflateOne, workitem )) // throw new Exception("Cannot enqueue workitem"); Task result = Task.Run(() => _DeflateOne(workitem)); if (result.IsCanceled || result.IsFaulted) throw new Exception("Cannot enqueue workitem");

If you like I will make a proper diff for it, though I changed the close functions and it may be a bit messy.

[marshallward]

Sory for the long silence, I'm currently overseas for work and battling a severe stomach at the same time.

I have a modification on my desktop which relies on DeflateStream and completely eliminates the zlib source, which is probably the most portable solution here. (It loses the checksum support in the zlib data but is otherwise identical.)

Assuming that works, it is probably not necessary to fix up the threading support and just rely on .net (or mono) to handle the dirty work for its particular platforms.

As for the assembly change, I would eventually like to completely remove the references to the resources and use the stream as a direct input, but that can be dealt with separately.

I will push my changes soon after a small cleanup.

[marshallward]

I've just updated the source to remove the zlib support, would you mind giving it a try? (after applying your own assembly changes)

We can talk further about the assembly issues a bit later.