Tweaking the XNA runtime

Chounard

I'm pretty new to using Github, but I wanted to try contributing a bit, so I've created my own fork, which you can find here: https://github.com/ThirdPartyNinjas/spine-runtimes

I've made a few modifications to the XNA runtime, and I'd like to get some feedback.

1) I changed the example project to use a content project. I've been away from XNA for quite awhile, but I think this is still the preferred way to handle assets in XNA based projects. It's also important for #2.

2) I created a content pipeline extension to process atlases. I also added support for the json-array and generic-xml exporters from TexturePacker. I made sure to set the textures up as ExternalReferences, so they won't get embedded into the xnbs multiple times. (Lots of little fixes still to make in here. Rotation direction, processor parameters, image path, etc.)

3) I added a new skeleton renderer called SpriteBatchRenderer. My games use SpriteBatch extensively, and using the SkeletonRenderer class would prove difficult for me. There are significant drawbacks to this approach, of course, but I think this is better for my needs.

The next step in my plan is to move SkeletonData over to the content pipeline as well, but that's significantly more involved than the Atlas class, so this seemed like a good point to break.

Chounard

I added SkeletonData to the content pipeline too. I found a nice solution that made it much easier than I expected.

Nate

Interesting! 🙂 I know nothing about XNA content pipelines. I have to maintain it indefinitely, so I should probably understand it if you are interested in contributing back to spine-csharp. 🙂 What is the benefit? I should Google it!

SpriteBatch can't draw skewed images. Skew happens when images are not aligned to the bone they are attached to. See here:
viewtopic.php?p=3228#p3228
If you don't do that, you'll be fine with SpriteBatch. It can be difficult to create the art so it is aligned to the bone, especially if you decide to change the bone position.

Chounard

The content pipeline is mostly used for two purposes:

1) To prebuild assets to binary form for faster loading.
2) To act as an asset cache at runtime, so you only load a single instance of each asset. (Which is a good fit for Atlas and SkeletonData, but not Skeleton.)

Since XNA is mostly a dead technology outside of MonoGame ports, it's only really useful worthwhile to MonoGame users. I should ask Randeroo to take a look here and add his feedback.

The SpriteBatch issue is a bummer, I'll have to investigate that one some more and figure out what I should do.

Chounard

Since I don't think there's many people who would benefit from the content pipeline changes, perhaps it would be better if I moved that stuff over into my own project. (I already moved my SpriteBatchRenderer over, since it was easier to add the features I needed there.) The stuff I'm working on will be open sourced, so we can just point people over to the content pipeline files if they want them.

How would you feel about making a minor change to Atlas.cs? I'd just need an additional constructor:

public Atlas(List<AtlasPage> pages, List<AtlasRegion> regions) 
{
	this.pages = pages;
	this.regions = regions;
	this.textureLoader = null;
}

And a check for null during Dispose:

public void Dispose ()
{
	if (textureLoader == null)
		return;

for (int i = 0, n = pages.Count; i < n; i++)
	textureLoader.Unload(pages[i].rendererObject);
}

Nate

@content piplines, I don't mind leaving it as is, since it is one less thing I need to think about. 🙂

Added your constructor and null check. 🙂

randeroo

I've logged on to post a message in support of adding the content pipeline support, however I see the thread has moved on a bit.

The work Chounard has done to integrate with the content pipeline looks good to me - however I understand that from Nate's point of view this would be more to maintain.

From a beginners point of view, one doesn't need to know anything about the content pipeline in order to use XNA/Monogame - indeed I've never used it because everything I've done has been quite simple. However (as I understand it) the benefits of using the Content Pipeline are as Chounard has already pointed out and come more into play once the number of assets increases and you need to improve the speed of loading.
If you were intending to include Chounard's Content Pipeline code in the official run-time then I'd suggest you have two examples - one using the Content Pipeline and one (as is currently in the repo) loading assets directly from the original file - thus ensuring that a beginner doesn't need to know about the Content Pipeline.

However, it looks like you've agreed to keep Chounard's code separate - so maybe we just need a link under the 'third party' section of the 'run-times' page entitled "monogame/xna with Content Pipeline" that points to Chounard's repo?

Nate

Good idea, added the link! 🙂

Chounard

I moved all the loader code over to my own project, and put that up on github.

Here's a post I made about it, which you're welcome to link to if that's useful:
http://www.esotericsoftware.com/forum/v ... f=3&t=1348

I don't think there's anything else left in my fork of the runtimes, so I'll go ahead and delete it and move back to using the original.

Thanks, everybody.