craftworkgames / monogame.extended Goto Github PK

The NuGet package contains 2 DLLs.

• MonoGame.Extended.dll
• MonoGame.Extedded.Content.Pipeline.dll

The intention is that the MonoGame.Extended.dll is referenced by the game and the MonoGame.Extended.Content.Pipeline.dll is referenced by the MonoGame Pipeline tool. If your game is targeting .NET 4.5 this works as intended. Only the first DLL is referenced by the game and the second DLL is left in the packages folder ready to be referenced by the Pipeline.

This morning I discovered that if the game project is targeting .NET 4.0 (or anything other than 4.5) it will incorrectly reference both DLLs in the game project.

The problem seems to be the way the nuspec file is configured.

<references>
  <group targetFramework="portable-net45+sl50+MonoAndroid10+xamarinios10+MonoTouch10">
    <reference file="MonoGame.Extended.dll" />
  </group>
</references>

Maybe we need to remove the target framework from the group? Or make more groups for each different target? Requires more investigation.

The icon on the NuGet package is currently the boring default.

This is a call out to get some logo designs for the project. The MonoGame logo might be a good starting point. Although, we should ask permission first before using their logo in ours.

Alternately, we could create something unique and interesting. Ideas are welcome.

Lately I've been interested in getting some simple collision detection and response working.

Note Let me just be clear right up front; I'm not talking about the same type of functionality a physics engine provides.

What I'm talking about is providing a library of classes and methods to implement the type of collision detection you might find in a platformer or other type of non-physics game. I believe if we do it right it could be very useful for a number of different style games without getting in the way too much.

There's an awesome tutorial by the creators of N that goes into quite a lot of detail about how they implemented theirs.

There's also a few great stack overflow answers on the topic:

• a physics engine is not a platformer engine
• resolving multiple collisions
• separating the intersecting objects

I very briefly started roughing out a draft of something last night. Then tonight I spent some time reading and researching how to do it properly. I've raised this issue to keep a record of the knowledge.

Hey I find holding proper conversations here on GitHub to be a of a pain and it pollutes the issues page. I think we should set up a forum (I recommend https://disqus.com/) for discussions.

For example we can figure out the best way to handle the text field API on disqus and the enhancement issue could document the agreed up specs for the implementation.

The purpose of the first milestone in the project is simply to start a regular release cycle. By the end of this milestone we'll have at least one "alpha" NuGet package published on nuget.org.

After the NuGet package is published, it can be used in another repository of MonoGame.Extended demos / samples. This will help new users try it out, see what it can do and also act as a set of regression tests.

The release cycle will be short and regular (monthly or less). We will increase the second part of the version number (0.1, 0.2, 0.3, etc) until the API feels stable after which we can promote the project to version 1.0

One feature I've found useful in the past is the ability to pack all my sprites into a texture atlas. Usually I use Code and Web's Texture Packer for this.

They do have official support for MonoGame I believe but I find it easier to just use the generic JSON format most of the time.

To keep things simple, I'm happy to implement the JSON support. Has anyone else has had experience using Texture Packer with MonoGame?

I've been thinking about this for a while. I think it's time we talked about creating some interfaces for common methods and properties.

Updating

The first one is to cover the reuse of an Update method so that many updatables can be added to a collection of List<IUpdate> _updatables. Something like this:

public interface IUpdate
{
     void Update(GameTime gameTime);
}

Personally I've never been a huge fan of GameTime. I'd rather just pass around a float deltaSeconds in most cases because it makes the class reusbale outside MonoGame / XNA. Most people that using MonoGame seem to like GameTime so I guess I can live with that.

Unfortunately, the framework already contains an interface called IUpdatable that looks like this:

  public interface IUpdateable
  {
    bool Enabled { get; }
    int UpdateOrder { get; }
    event EventHandler<EventArgs> EnabledChanged;
    event EventHandler<EventArgs> UpdateOrderChanged;
    void Update(GameTime gameTime);
  }

The problem with the IUpdatable interface is that it has too much going on. A lot of the time when you want to implement an Update method you don't need or want the other crap. Particularly UpdateOrder. Using this interface makes it more complicated to implement the class and IMHO doesn't add a lot of value.

Of course, there's no reason why a class couldn't implement both interfaces.

Drawing

Similarly to the updating I propose we have a simpler IDraw interface.

public interface IDraw
{
    void Draw(GameTime gameTime);
}

This would be the sibling on the IDrawable interface from the framework.

Common Properties

I also think there's a few property based interfaces that are helpful.

public interface IRotatable
{
    float Rotation { get; set; }
}

public interface IMovable
{
    Vector2 Position { get; set; }
}

public interface IScalable
{
    Vector2 Scale { get; set; }
}

public interface ITranfromable : IMovable, IRotatable, IScalable
{
}

public interface IColorable
{
    Color Color { get; set; }
}

The benefit of breaking these up into one interface per property is that we can write nice extension methods, for example in an Animation library you might have some extension methods like this:

public void MoveTo(this IMovable movable,  Vector2 position);
public void RotateTo(this IRotatable rotatable, float angle);
public void ScaleTo(this IScalable scalable,  Vector2 scale);
public void FadeTo(this IScalable colorable,  Color color);

Then these methods become available on any class that have the respective properties. The class can pick which of the properties it wants and leave out the others. For example, it's common to have Position and Rotation without scale or color.

Naming conventions and clashes

I think the advantages of having interfaces like these is clear but naming them is hard. The names I've proposed above are okay, but they could also be called IMove, IRotate, IScale and IColor or something else.

One concern is that game developers trying to use MonoGame.Extended in an existing project might end up with name clashes if they already have similar interfaces defined. Although, we may not be able to do anything about that unless we pick obscure names which I'd really rather avoid.

Thoughts?

A particle system like the Mercury Particle Engine seems like a good addition for completeness.

The idea of splitting up MonoGame.Extended into a few different DLL's and NuGet packages has come a up a few times. I think this is a good idea in principle, but it's also a complex issue.

Let's discuss how the project should be split up and the pros and cons of each option. Initially the primary goal is to keep 3rd party dependencies out of the core library.

Currently, the project is structured like this:

• MonoGame.Extended.dll is the core PCL library and has dependencies on the PCL version of MonoGame and Newtonsoft.Json.
• MonoGame.Extended.Content.Pipeline.dll is a normal .NET 4 DLL that has dependencies on MonoGame.Extended, Newtonsoft.Json and TiledSharp. This DLL is intended to be referenced by the MonoGame Pipeline tool.

During development of features we need art. Sometimes the we create the are ourselves, but most of the time the art is sourced from another place (e.g. GameDevMarket.net).

Firstly, it's important that the original author of the art is credited accordingly. The way I've been doing this is adding a link to the source to a read-me.md file in the Content folder. This is a good start but I'm open to suggestions if there's a better way?

Secondly, some of the art is modified using 3rd party software (e.g. Texture Packer, Tiled, etc). I think it's important that we keep all of the files somewhere in the repository so that other collaborators can make modifications. This is something I haven't been doing very well so far.

I've been working on the Camera2D class a little recently, adding the ability to clamp zoom values #61.

That got me thinking about how to implement another feature. The ability to set a rectangle to keep the camera inside when moving it around. I've seen this kind of thing before but I couldn't find it. A quick google revealed this tutorial which looks related.

I suspect it'll be relatively easy to implement. Rotation might makes things a little more complicated though.

I just discovered @discosultan's excellent penumbra 2D lighting with shadowing effects library.

From what I can see the library already stands on it's own so there's probably nothing to add to MonoGame.Extended for it anyway. I just wanted to raise this issue for discussion just in case there's some way we can help.

A while ago I worked on a project that had a fluent syntax for short animations in code. They are not as powerful as Spine #16 or Spriter #17 but they are very handy for creating quick animations and effects.

They syntax looked something like this:

var transitionParameters = new TransitionParameters(1.0f, EasingFunctions.CubicEaseInOut);
Animations
    .CreateSequence(playButton)
    .MoveTo(new Vector2(50, 50), transitionParameters)
    .MoveTo(new Vector2(700, 400), transitionParameters)
    .MoveTo(new Vector2(700, 230), transitionParameters)
    .MoveTo(new Vector2(400, 250), transitionParameters)
    .Delay(1.0f)
    .RotateTo(0, transitionParameters)
    .Delay(1.0f)
    .RotateTo(MathHelper.TwoPi, transitionParameters)
    .FadeOut(transitionParameters)
    .FadeIn(transitionParameters)
    .Play();

Of course, it doesn't have to work exactly the same way. Hopefully this will be a good starting point though. It might be useful to consider adding Timelines so that animations like this can be created in parallel.

Just about every game needs some sort of GUI these days. There are a few old XNA GUI projects floating around but there seems to be a gaping hole the market particularly with GUI's designed for mobile devices.

This isn't the first time I've attempted to make a GUI system for MonoGame either. There's still an old fork of one of them from ages ago. There's even a more modern one in an experimental game engine I wrote.

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.

Spine is a fantastic 2D skeletal animation tool. They already have an official MonoGame runtime but I still think it would be a good fit for MonoGame.Extended.

Of course, there's no need to re-invent the wheel, especially if it's working, so it may just be a thin wrapper or an addition to the MonoGame Pipeline. Whatever the case, let's investigate and see how it fits.

I just came across this awesome looking level editor. It's written in Java but the website says it's not tied to any specific game engine. This youtube video shows the things it can do.

I haven't managed to get it working on my machine but it could be worth watching.

Looking at the front page of the repository, there's no clear indication of what our features actually are. Should we either add a list to the readme or add some kind of FEATURES.md file with a similar list?

Currently the Zoom property of the camera actually represents the scale of the scene. For example:

• A zoom value of 0.5 appears to put the camera further away from the scene allowing more to fit into the viewport
• A zoom value of 2.0 appears to put the camera closer to the scene allowing less to fit into the viewport.

Obviously this achieves the desired effect but it feels a little odd. It could also be thought that smaller values = closer and larger values = further away. I tried to figure out how other game frameworks do it but it's surprisingly difficult to find detailed documentation on the zoom property.

If we do decide to change the way it behaves this will be a breaking change to anyone already using it. That said, if there is a compelling enough reason to change it, now is the time to do it before the library is more widely used.

This is a discussion about what kinds of things should go into the library.

What it should be

The goal of MonoGame.Extended is to provide extra functionality that MonoGame doesn't provide out of the box, but is often required to develop complete and polished games. It will be published as a portable class library (PCL) NuGet package that can be added to a MonoGame project. The API should feel natural to a MonoGame user.

What it shouldn't be

MonoGame.Extended is not intended to be a game engine. It can provide classes and extension methods that make game development easier, but the developer should be in control of which bits they choose to use from the library.

Some ideas

Here's a list of ideas off the top of my head.

• Camera for 2D games
• Resolution independence
• Texture atlas loading using TexturePacker
• Sprites and SpriteBatch extension methods
• Animations using a fluent syntax, Spine or Spriter
• Particle system
• Bitmap fonts as an alternative to sprite fonts
• Tile map loading (using Tiled, tIDE or another editor)
• Input listeners (to make it easier to handle clicks, touches and other input)
• Sprites (normal and frame animated)
• Scene graphs
• GUI library

Some of these ideas might not belong in this library. It might be better to have a few different NuGet packages, especially if they carry extra dependencies.

Thoughts?

Please keep this discussion on topic and raise new issues for implementing the actual features.

Since both MonoGame and FNA strive to be accurate to the original XNA API any code written for one should work for all of them. I don't know how much work it would be but I think it would greatly expand out potential user base.

Related to Splitting the project into different DLLs and NuGet packages as it would add more work there.

It seems there's some contention #14 about the correct behavior of double click events in the mouse listener.

The argument is about when the events should fire. In WinForms the double click event fires immediately before the mouse up event as can be seen when holding down the mouse button for a couple of seconds before the double click registers.

26/08/2015 11:59:24 AM:MouseDown
26/08/2015 11:59:24 AM:Click
26/08/2015 11:59:24 AM:MouseUp
26/08/2015 11:59:24 AM:MouseDown
26/08/2015 11:59:26 AM:DoubleClick
26/08/2015 11:59:26 AM:MouseUp

This behavior also seems to be consistent in VB.NET and JavaScript.

However, as it's documented here and can be observed when double clicking an icon on your desktop, or double clicking to select some text in a text editor the event registers on mouse down (not mouse up).

In effect, the second WM_LBUTTONDOWN message that would normally be generated becomes a WM_LBUTTONDBLCLK message.

Taking into account the double tap behavior on touch screens, I think the MouseListener should be changed to respond to the double click on mouse down.

We'll have to reconsider what this means for drag and drop events. If they can't be implemented correctly the MouseListener they may need to be removed and reconsidered for a GUI library later.

Awhile ago I wrote a Pull Request to get a circle into MonoGame, though I think general concensus is that it shouldn't be in the core library.

That said, since it looks like we are trying to create an official Monogame Extension Library, I was wondering if this would be something we would be interested in adding to the Extended Library?

Heres the Pull Request where you can see the files
MonoGame/MonoGame#3419

For completeness I'm going to add scene graphs to the list.

They are useful for representing translations, rotations and scales (along with other affine transformations) of objects relative to each other.

I'm not convinced they are a top priority, as we may get similar functionality out of the Spine #16 or Spriter #17 enhancements but they are a nice to have.

As briefly discussed here: http://gamedev.stackexchange.com/questions/108613/monogame-3-4-content-pipeline-extension-missing-reference/108616?noredirect=1#comment189059_108616

Basically a content importer that reads png files, places them into an atlas and makes the assets easy retrievable in the game code. The process works like this:

1. Create a bunch of individual .png images that should end up in the game.
2. Store the images in a directory.
3. Create an xml file: the xml file contains path(s) to the directories containing the images. The xml file also contains a width and height for the atlas image (the "bin" size so to speak).
4. The xml file is added to the content tool, with the spriteatlas importer.

The code contains a dictionary <string,spriteinfo> spriteinfo contains a struct like this:

struct SpriteInfo
{
    Texture2D Spritesheet;
    Rectangle SpriteRectangle;
}

In the code you could now draw sprites like this:

spriteBatch.Draw(Atlas("spritename").Spritesheet,new Vector2(x,y),Atlas("spritename").SpriteRectangle,Color.White);

The content processor uses Texture2D.FromFile to read the png files. The SetData<Color> method is used to pack sprites in their bins according to the packing algorithm (as I expected the draw methods not to be available during the content building process- I may be wrong though). the writer writes the textures and the dictionary to the XNB file.

This decouples the creation of the images from the atlas creation. I used this in my game "80s Racer"

https://www.youtube.com/watch?v=46-Mb2CMopw

The level editor references the same .png images for roadside objects. The content is then created and the game reads the level files and is able to pick the images from the atlas content without having to worry where the images were located.

I got an email this morning with a nice compliement from @Gixen 😄

[Community | MonoGame] [PM] Awesome extensions and bugs?

to dylan
from Gixen
September 17
Hi! I just started using MonoGame.Extended and it's awesome. Well, sofar i've only used the bitmap class but anyway. However, it seem no matter how i build it in the content pipeline, the bitmap fonts and files has to be in the content root directory or they will just not load.

Otherwise, keep up the good work!

To respond, visit http://community.monogame.net/t/awesome-extensions-and-bugs/6330/1 in your browser.

For some reason the link to the topic at the bottom of the email doesn't work.

Sorry, you don't have access to that topic!

Anyway, I thought I'd raise it as a bug here for further investigation.

@Gixen Do you have any more details you'd like to add? How are you trying to setup the Content directory?

Hey Dylan,

I'm interested in contributing a few utility methods for the Camera2D class, mainly some methods to check if a point or rectangle is on screen, but possibly a few others. Your README specified that I should discuss what you think would be good contributions, so here's the discussion 😉

This is just a test issue. It will be deleted shortly.

I have found that the easiest way to serve images is by placing a copy inside of the gh-pages branch, and serving it via github pages (we can also do this with Markdown-formatted text, or HTML). I have done this on my branch, and will add a logo to the README in the master branch using this if/when my gh-pages branch is merged into the one here.

Here's a usage of this, if I'm not being too clear: http://www.jefclaes.be/2012/04/add-images-to-github-readme.html

When working on my Linux system, I had some very odd issues with missing SDL system libraries at runtime, while my other Monogame projects work fine. Hunting through the dependencies, this is because we are compiling against MonoGame v3.1.2.0 rather than the latest, v3.4.0.459. Why is this? Is the PCL outdated?

Update: Looking at Nuget, I see that this is the case. Damn, that's an issue. Linux has quite a few issues that have been fixed in the more recent versions.

Hey Dylan,

In some of my projects, I have created different build configurations for each platform. This means that multiple versions of MonoGame.Framework are referenced via Nuget, and only the platform-specific one that is required by the build configuration is actually used.

Would you be interested in this for the sandbox project? It's not too much work for me, and it would save me hacking together a new csproj file and editing references every time I pull.

We currently have one shape (a circle) in the MonoGame.Extended.Shapes namespace. There's room for a few more. Given that one of the use cases will be collision detection I think it makes sense to look at the shapes found in a typical physics engine.

Farseer Physics has a few including Polygon, Chain and Edge. Although, these are not all technically "shapes" they can be used to make shapes.

Even though a typical use case for the the shapes will be collision detection, we need to be careful not to leak the responsibility of the physics engine into our shape classes. The idea would be to keep our shapes similar to MonoGame's Rectangle.

We may provide another enhancement in the future consisting of extension methods to convert them to and from physics shapes in the future. However, this shouldn't live in the core library as it will take a dependency on Farseer (or whatever) physics engine.

@Emersont1 on gitter asked

if and how culling is done with the TMX support?

I took a look at the code and noticed that it's not doing any optimization in this area. I suspect rendering performance would degrade significantly with large maps. It should be relatively simple to only render tiles that are inside the camera's bounding rectangle.

This looks the relevant code https://github.com/craftworkgames/MonoGame.Extended/blob/master/Source/MonoGame.Extended/Maps/Tiled/TiledTileLayer.cs#L142

I guess those for loops should take rectangle as a parameter and only render tiles that fall inside, or partially overlap the rectangle bounds.

It occurred to me today that some people are going to want to make their own levels editors and things like when using MonoGame.

Embedding MonoGame into WinForms and WPF applications is a bit tricky. I've done it before, and there's certainly things that we might be able to add to the library to help. I'm not sure what those things are yet though. I just wanted to leave this story here for future reference.

Related: http://xbox.create.msdn.com/en-US/education/catalog/sample/winforms_series_1

The MouseListener is intended to mimic events of windows frameworks like WinForms and WPF. Currently, the events seem to be getting fired in a different order. This is not a huge problem, but I think we should fix it early while MonoGame.Extended is still young.

I just wrote a little WinForms application to prove it.

        MouseDown += (sender, args) => Trace.WriteLine(DateTime.Now + ":MouseDown");
        MouseUp += (sender, args) => Trace.WriteLine(DateTime.Now + ":MouseUp");
        Click += (sender, args) => Trace.WriteLine(DateTime.Now + ":Click");
        DoubleClick += (sender, args) => Trace.WriteLine(DateTime.Now + ":DoubleClick");

When the mouse button is pressed then released a few seconds later, the Click and MouseUp events fire together.

26/08/2015 11:55:19:MouseDown
26/08/2015 11:55:22:Click
26/08/2015 11:55:22:MouseUp

Similarly, when the mouse is clicked then clicked again, but this time with a delay between pressed and released of the second click the DoubleClick and MouseUp events get fired together.

26/08/2015 11:59:24 AM:MouseDown
26/08/2015 11:59:24 AM:Click
26/08/2015 11:59:24 AM:MouseUp
26/08/2015 11:59:24 AM:MouseDown
26/08/2015 11:59:26 AM:DoubleClick
26/08/2015 11:59:26 AM:MouseUp

If you run the same test with the MouseListener class in MonoGame.Extended the

A single click produces:

26/08/2015 12:26:10 PM:MouseDown
26/08/2015 12:26:11 PM:MouseUp
26/08/2015 12:26:11 PM:MouseClicked

And a double click produces:

26/08/2015 1:08:33 PM:MouseDown
26/08/2015 1:08:33 PM:MouseUp
26/08/2015 1:08:33 PM:MouseClicked
26/08/2015 1:08:33 PM:MouseDown
26/08/2015 1:08:33 PM:MouseUp
26/08/2015 1:08:33 PM:MouseClicked
26/08/2015 1:08:33 PM:MouseDoubleClicked

We probably also shouldn't fire the MouseClicked event a second time to be consistent.

The standard way to receive input using MonoGame / XNA is polling the state of the input devices during each Update. This works well in some situations, depending on what type of game you're making, but other times it's nice to be able to listen for input events instead.

LibGDX has a good set of input listeners that can be used as a reference.

@ClassicThunder has also done some good work in this area

Currently the Camera2D.GetBoundingFrustum method returns a half pixel offset value.

This was implemented intentionally as follows, but it seems a little odd to me.

    private Matrix GetProjectionMatrix(Matrix viewMatrix)
    {
        // Note: This projection matrix is the same one used inside of the MonoGame SpriteBatch by default.
        var projection = Matrix.CreateOrthographicOffCenter(0, _viewportAdapter.VirtualWidth, _viewportAdapter.VirtualHeight, 0, -1, 0);

        // Half pixel offset.
        // TODO: Check to see if we really should be applying a half pixel offset here?
        projection.M41 += -0.5f * projection.M11;
        projection.M42 += -0.5f * projection.M22;

        Matrix.Multiply(ref viewMatrix, ref projection, out projection);

        return projection;
    }

There are also some unit tests setup that confirm the outputs are indeed off by half a pixel:

    [Test]
    public void Camera2D_GetBoundingFrustum_Test()
    {
        var graphicsDevice = TestHelper.CreateGraphicsDevice();
        var camera = new Camera2D(graphicsDevice);
        var boundingFrustum = camera.GetBoundingFrustum();
        var corners = boundingFrustum.GetCorners();

        const float delta = 0.01f;
        TestHelper.AreEqual(new Vector3(0.5f, 0.5f, 1), corners[0], delta);
        TestHelper.AreEqual(new Vector3(800.5f, 0.5f, 1), corners[1], delta);
        TestHelper.AreEqual(new Vector3(800.5f, 480.5f, 1), corners[2], delta);
        TestHelper.AreEqual(new Vector3(0.5f, 480.5f, 1), corners[3], delta);
        TestHelper.AreEqual(new Vector3(0.5f, 0.5f, 0), corners[4], delta);
        TestHelper.AreEqual(new Vector3(800.5f, 0.5f, 0), corners[5], delta);
        TestHelper.AreEqual(new Vector3(800.5f, 480.5f, 0), corners[6], delta);
        TestHelper.AreEqual(new Vector3(0.5f, 480.5f, 0), corners[7], delta);
    }

And this:

    [Test]
    public void Camera2D_ContainsVector2_Test()
    {
        var graphicsDevice = TestHelper.CreateGraphicsDevice();
        var camera = new Camera2D(graphicsDevice);

        // the edge cases fall on the half pixel boundary
        Assert.AreEqual(ContainmentType.Disjoint, camera.Contains(new Vector2(0.45f, 0.45f)));
        Assert.AreEqual(ContainmentType.Contains, camera.Contains(new Vector2(800.45f, 480.45f)));
        Assert.AreEqual(ContainmentType.Contains, camera.Contains(new Vector2(0.55f, 0.55f)));
        Assert.AreEqual(ContainmentType.Disjoint, camera.Contains(new Vector2(800.55f, 480.55f)));
    }

Indeed, this was intentional, but I question if it's the right thing to do.

We should check the behavior of other frameworks like LibGDX and consider if this should be changed for the 0.3 release.

I've been working on Tiled map loading recently. It's working at a bare minimum level loading the TMX map files with the MonoGame Pipeline tool and rendering the map using SpriteBatch's for each map layer.

There's still lots of things to do:

• Rendering just the visible tiles in the camera's rectangle
• There seems to be an issue with gaps between tiles "tearing", it could be a bug in MonoGame?
• Not all Tiled options are support (e.g. isometric or staggered maps)
• The map renders, but there's no support for "querying" the map (e.g. find tile properties)
• What code can be shared with tIDE maps?
• Should the Tiled code be split into another project? (e.g. MonoGame.Extended.Tiled)
• Probably many other things?

This issue is here to discuss how it should work and how we can split up the workload.

I expected some fiddling with the dependencies and such, but I also ran into an interesting issue with the MonoGame Content Builder and the Sandbox csproj. Since you don't install the Pipeline the same way on Windows as you do on Linux, you cannot rely on importing the .targets file, and then cannot build content the cool new way with just the content project, and instead have to do it manually. Any ideas? Does this effect us at all or should I open up an issue on Monogame's issue list?

I while ago I wrote an FPS counter and posted as an answer to a question on stack overflow. It could be a good addition to the library.

Spriter is another 2D skeletal animation tool (see #16). I don't think there's official support for MonoGame. A quick google revealed this

Ideally it would be good if the animation API is shared between Spriter and Spine where it makes sense. Although, I suspect most people will be using one or the other. I own both these tools so I can do some testing.

Currently MonoGame.Extended depends on a custom build of the MonoGame PCL found in the Dependencies folder. This seems to work pretty well and allows us to keep up to date without depending on the NuGet package, which unfortunately is a few versions behind.

@WardBenjamin You implemented this in #25 and #26. It occurred to me today that if / when we need to do this again, I have no idea how to do it. Could I ask you to write up a guide on how to do this? Bullet points and links are fine.

On a related topic, I've considered setting up an automated process for things like this. I think there'd be some value in providing unofficial release builds of various different libraries (MonoGame, Farseer, etc) for people that don't want to get their hands dirty compiling the source code.

Thanks

Setting Camera2D.Zoom to -1f, for instance, results in a zoom of 1 and a 180 degree rotation. This is probably not intended.

How would we feel about adding in a Timer Class? Its something that MonoGame doesn't have, and something that every Game Dev ends up having to create in all of their projects.

I have two timers which I would be willing to add to the project, I made it a couple months ago for a MonoGame 'Game Engine' which I used in my Capstone Project which I think could fit this bill perfectly

Timer - https://github.com/KillerrinStudios/Anarian-Game-Engine-MonoGame/blob/master/Anarian%20Game%20Engine.Shared/DataStructures/Timer.cs
Clock - https://github.com/KillerrinStudios/Anarian-Game-Engine-MonoGame/blob/master/Anarian%20Game%20Engine.Shared/DataStructures/ContinuousClock.cs

The Timers themselves are event based, so once you set them up all you have to do is call the Update on them to update the time and once the Timer hits its goal (Timer counts down to 0 and Clock reports every x seconds), it fires off the Completed Event to let you know

In my opinion text fields are ubiquitous enough that is is worth bringing them in separate of the more general GUI functionality. I created text fields as part of my GUI Framework and began the process of isolating the TextField from the other systems into a separate library here.

The library is in a bit of a disarray (it was put on hold while I finished up the input library) but I'll try and summarize where it is at.

All of the functionality in terms of selecting, rendering, copying, pasting, and manipulating the text should be complete. However, its not tied into any input system currently. They is where the MonjoGame.InputListeners comes in (and the main reason I really wanted the double click to register on the second mouse down).

Theoretically integrating with the input system, and fleshing out the unit tests is all that is needed to finish up the library. By default it is only multi-line so adding a single line option that figures out an appropriate height is something I want to do. Also worth nothing it simply draws the text, cursor, and a background for the selected text: there is no outline, background or, border.

When do you want to have the .3 release? If its near the end of the month I could probably have the text fields ready by then.

We've all seen 2D animation using the frames of a sprite sheet.

This is reasonably easy to implement but we want to design a clean and consistent API that works well with other types of animation (e.g. skeletal and transitions). Also, be careful not to leak the animation code into the base Sprite classes.

Currently, each time a new feature is created, the code is briefly tested in a "sandbox" project and then discarded. It would be better if we kept these little "demos" in another repository so that they can show off what MonoGame.Extended can do.

The demo / samples repository will also act as a set of manual regression tests. The MonoGame team is interested in something like this too.

Should it be lots of little Game projects or one project with many demos? Maybe it could look like a "game" with a title screen, level select, etc?

Simple question, should there be some tools included in MonoGame.Extended?

Example tools which could be useful are:

• level editor
• spritefont editor
• xnb file previewer (to check if the file is good after compilation, would mostly be good for 3D Models)

One thing that always bugged me about XNA is that it doesn't have a way of drawing basic shapes very easily.

libgdx for example has ShapeRenderer for that: https://libgdx.badlogicgames.com/nightlies/docs/api/com/badlogic/gdx/graphics/glutils/ShapeRenderer.html

tIDE is a fully-featured, .NET-based tile editor that allows level designers to easily create content for tile-based games. tIDE supports a custom XML-based map format, a custom binary format (tbin), Tiled TMX, Mappy FMP and Flixel. Additional formats may be included via the .NET-based plugin system within tIDE.

This is somewhat related to #11