CleanUp the code

[abYzzX]

I want to use your library, but honestly it is such a big copy and paste mess - sorry to say this.
I start clean up the code and got so many WTF moments.

• There is a PrimitiveBatch wich uses PrimitiveDrawing and on the other hand there are extensions for SpriteBatch. Which to use and why?
• Writing entire classes new just to use it for a single part in the library.
  • There is a LineSegment and a Segment2. Both by definition are LineSegments...why create an extra class only for triangulation?
• Create a Matri3x2 - why not simply use the Matrix from MonoGame?
• No straight namespace usage
  • Polygon under Shapes namespace, RectangleF, CircleF...are under Math namespace. Why?
• Some filenames are X.Extensions.cs other XExtensions.cs
• Extensions class containing util functions (ColorHelper and ColorExtensions)

And, sorry to say this, many more issues. So my idea is to just clean up the code. It could be an awesome extension for MonoGame with some project structure.

[lithiumtoast]

There is a PrimitiveBatch wich uses PrimitiveDrawing and on the other hand there are extensions for SpriteBatch. Which to use and why?

SpriteBatch uses quadrilaterals with vertices of type VertexPositionColorTexture to render graphics. PrimitiveBatch uses vertices of type VertexPositionColor. This means that effectively PrimitiveBatch is meant to render shapes without using an image. The extensions for SpriteBatch are ways to render shapes but it's not optimal as the image is basically a 1x1 white pixel. I can't find that logic anymore though? Might have been removed. Also PrimitiveBatch is usually used to render debug information for collisions and physics.

There is a LineSegment and a Segment2. Both by definition are LineSegments...why create an extra class only for triangulation?

Looks like LineSegment was added as part of triangulation feature. @AristurtleDev could comment more on that. However I added Segment2 a long time ago based on this book as describe in the comments: http://www.r-5.org/files/books/computers/algo-list/realtime-3d/Christer_Ericson-Real-Time_Collision_Detection-EN.pdf.

Matri3x2 - why not simply use the Matrix from MonoGame?

Matrix in MonoGame is a 4x4 matrix. If you don't need to 3D transformations it's simpler and faster to use a 3x2 Matrix instead for 2D transformations. It's equivalent to Matrix3x2 from Microsoft here: https://learn.microsoft.com/en-us/dotnet/api/system.numerics.matrix3x2?view=net-9.0. Wether to use System.Numerics is subject to MonoGame and not MonoGame.Extended (would require a fork of MonoGame).

Polygon under Shapes namespace, RectangleF, CircleF...are under Math namespace. Why?

Math is probably a better namespace for everything as not everything is a shape but the reason is that they were added at different times. Also using object oriented programming (OOP) using classes for every shape (e.g. a class for Triangle a class for Rectangle and have them inherit from a interface like IShape) is generally a bad idea unless you need to do logic with the vertices. Instead most "geometric shapes" don't actually need vertices to do math stuff like a rectangle can be defined as X, Y, Width, Height, or a circle can be defined as a centre point and a radius. To do this they serve different purposes and why there is two namespaces.

Some filenames are X.Extensions.cs other XExtensions.cs
Extensions class containing util functions (ColorHelper and ColorExtensions)

Added at different times and also potentially by different people.

And, sorry to say this, many more issues. So my idea is to just clean up the code. It could be an awesome extension for MonoGame with some project structure.

Some of the issues you pointed out are just a lack of understanding the purpose of the code (E.g. PrimitiveBatch and Matrix3x2). I understand that one way to learn the code, especially with fresh eyes, is look at the top-level structure and drilling down. To that there is definietely some improvements that could be done as you pointed out (E.g. as you pointed out with XExtensions.cs).

[AristurtleDev]

I apologize for missing this conversation originally @abYzzX.

I see that @lithiumtoast has addressed the specific technical questions. I wanted to speak to the broader code cleanup concerns you've raised.

You're right that there are inconsistencies in the codebase. MonoGame.Extended has evolved over several years with contributions from many developers with different maintainers, and that history shows in the code structure. We're actively working to address this, though it's a gradual process.

The current approach is to clean up each subsystem as we work on it; whether for major updates or bug fixes. For example, the particle system recently received an overhaul that included code cleanup. As we continue working through other areas of the library, they'll receive similar treatment.

To ensure consistency going forward, we have established Coding Guidelines that define the standards for file naming, namespace organization, extension method placement, and other conventions. All new PRs are expected to follow these guidelines, and they are applied when refactoring existing code.

This is ongoing work, and we appreciate your patience as we continue improving the library's quality and consistency.