Sprites and SpriteBatch extension methods

[WardBenjamin]

Hey Dylan,

I've started some work on a Sprite class and I currently have the simple basics (aka texture, position, bounds rectangle), as well as a SpriteBatch extension. Now, I'd like to discuss the other API that we would like to expose.

What I currently have planned:

• Texture2D Texture
• Vector2 Position
• Vector2 Scale (x-scale and y-scale)
• Color Color
• float Rotation
• Anchoring or an origin? (aka when the sprite is drawn it calculates where it should actually be based on position and an anchor, so the position could be anchored to the top-left, bottom-left, center, etc)

I'd like to talk about the anchoring scheme (an enum?) as well as any other ideas that you had for the base sprite class. After it can be considered complete, I can move on to animation, sprite sheets, etc.

[craftworkgames]

Sounds like you're on the right track.

I find this easier to talk about while looking at some code so here's my thoughts on a Sprite class.

public class Sprite
{
        public Sprite(TextureRegion textureRegion)
        {
             // TODO 
        }
        public Sprite(Texture texture) 
        {
            // TODO
        }

        public TextureRegion TextureRegion { get; set; }
        public Color Color { get; set; }
        public Vector2 Origin { get; set; }
        public bool IsVisible { get; set; }
        public Vector2 Position { get; set; }
        public float Rotation { get; set; }
        public Vector2 Scale { get; set; }
}

This basically matches one of the overloads of the SpriteBatch.Draw methods I think.

You'll notice I'm using TextureRegion instead of Texture. This captures the idea that you might have many sprites packed into a single texture atlas. There's an overloaded constructor for when the whole texture is the sprite.

Origin is an interesting case because MonoGame / XNA default to having the Origin represented in pixels relative to the size of the texture. I find this quite annoying and often want to deal with normalized origins (0.0f to 1.0f) with 0.5f, 0.5f being the center. To support this, maybe we need some alternate ways to set the origin. Not sure if it should be methods SetOriginNormalized or different properties OriginInPixels vs OriginNormalized? I'm also not sure what to call them. You're thoughts on this are appreciated. Maybe we can find another framework that does this?

the anchoring scheme (an enum?)

Not sure what you mean by this?

After it can be considered complete, I can move on to animation, sprite sheets, etc.

Yep. I think the base Sprite class should be kept simple. It can have methods like GetBoundingRectangle etc but it's single responsibility is representing a single sprite.

Animation is a big topic. There's sprite sheets, skeletal, transitions, timelines, tweening and probably other things to think about. We should think about the big picture before diving too deeply into that.

Btw I'm going to start publishing semi-regular "alpha" NuGet packages soon. When that happens we might have to start thinking about release milestones and working in branches.

Also, MonoGame.Extended is getting some traction 👍 I've had 2 or 3 people contact me each week telling me they are using it or interested in it.

One last question, do you think we should have a list of tasks somewhere? We could either use a Trello board or simply dump everything into Github issues?

[WardBenjamin]

do you think we should have a list of tasks somewhere? We could either use a Trello board or simply dump everything into Github issues?

I think a Trello board is a fantastic idea; I regularly use several for my projects.

Not sure what you mean by this?

When I am talking about anchors, I mean something like: https://www.youtube.com/watch?v=IkbRhPJYZcI (same concept that is used when resizing an image in a nice image editing program).

We can further discuss the origin issue at some point later, I can implement both for now.

Btw I'm going to start publishing semi-regular "alpha" NuGet packages soon. When that happens we might have to start thinking about release milestones and working in branches.

Sounds good to me! I already work in feature branches, as you can see by all of the branches in my fork. Milestones are also a very good idea, it'll be nice to have an actual versioning system and changelogs.

[craftworkgames]

Cool.

Well here's the Trello board I prepared earlier. I've been working out of this alone so it's a bit of a random brain dump at the moment. Once we are working in it together we'll keep it more organized.

https://trello.com/b/Xi6Rfqhb/monogame-extended

[WardBenjamin]

@craftworkgames can you please assign this issue to me? I just found out that I can't do that myself.

Also, I haven't been added to the Trello board, so I can't add to it. Add me? My username is @WardBenjamin, just like here.

[WardBenjamin]

@craftworkgames I'm heading out on vacation again today; I'll probably have PC/Wifi access this week though, so there'll most likely be more commits.

I've put quite a bit of work into the feature-sprite branch on my fork. Right now it's a bit broken for some reason that I haven't figured out yet, but it should only take a little bit more work.

[craftworkgames]

I haven't been added to the Trello board

Done. I was hoping you could add yourself, but I can't see a Trello setting for that.

I've put quite a bit of work into the feature-sprite branch on my fork.

Looks good so far. How are you testing it? I'd like to start creating Demos #9 for each feature.

can you please assign this issue to me?

It looks like you need to be a "push" collaborator to be assigned issues. This has been raised before. It's annoying but I wouldn't worry about it at this stage. I doubt anyone is going to start working on something you've already taken.

[craftworkgames]

@WardBenjamin If you get any spare time can I ask you to take a look at the list of github issues I've raised add any comments you think are relevant.

Obviously we won't get around to implementing everything all at once, but I wanted a place to discuss them while we work on other things.

[WardBenjamin]

I'm having some issues figuring out exactly how to use the TextureRegion class correctly. I'll push current progress to my fork, but this might take a bit of debugging to figure out where my Draw extension is going wrong.

[WardBenjamin]

Also, (kind of related to #31), John McDonald has put out this clever bit of code: https://bitbucket.org/jcpmcdonald/sprite-maker/wiki/Home as well as a loader for XNA: https://bitbucket.org/jcpmcdonald/xna-sprite-lib/wiki/Home. They are quite interesting.

[craftworkgames]

I'm having some issues figuring out exactly how to use the TextureRegion class correctly. I'll push current progress to my fork, but this might take a bit of debugging to figure out where my Draw extension is going wrong.

No problem. I'm more than happy to help figure this one out. I've been getting ready to do the 0.2 release. I'd like to include basic Sprite support in it, even if it's only a start.

[WardBenjamin]

I'm more than happy to help figure this one out.

Sounds good.

My initial implementation simply using textures seemed to work correctly, but with the TextureRegion implementation.... not so much. I'll try to do some more debugging today if I have time but I just reinstalled Windows 8 and Arch, so I don't have many tools available yet.

[craftworkgames]

but with the TextureRegion implementation.... not so much.

Okay. How do you want to do it then? Would you like to do a PR and after the merge I'll start working on it?

[WardBenjamin]

We can do that, I guess. My code compiles and runs fine, and shouldn't break anything else. I'll update it with the current changes from master and open a PR.

[craftworkgames]

Sweet. I'll be waiting, I've got a few hours to spare.

[craftworkgames]

I had to fiddle with it a bit but I got the code running and I can see the stump. I'll start doing some refactoring to get texture regions working.

[WardBenjamin]

Sweet! I have to head to work but I'll be around every once and a while to see what's up. Cya then!

[WardBenjamin]

Closing since I know that @craftworkgames got my code to work and refactored it.

[craftworkgames]

Closing since I know that @craftworkgames got my code to work and refactored it.

Yep. I wasn't sure if I missed anything but you're right. Let's close the feature for now and raise a new one if something else comes up. I'm keen to get the 0.2 release out.