how would you want that to look like?
Like spritebatch?
eg
ShapeBatch.Begin()
ShapeBatch.DrawCircle(…)
ShapeBatch.End()
or
Shape.DrawCircle() only
Aint this already part of the ‘extended’ lib?
Both of these look good, whichever of them fits the underlying architecture of MonoGame best is the one I would want.
I don’t know, I haven’t used MonoGame.Extended myself. However when using MonoGame with students I think using the original MonoGame and not MonoGame.Extended is what I prefer.
Yes, it is.
spritebatch.Line, Circle, etc…
You should try first, then decide 
Installation is easy enough, I managed to do it myself also ^^
hmm, the monogame extended implementation is certainly interesting and probably works best for your case @eddeland
On the upside it’s integrated with spritebatch, so everything can be batched in one go and you can continue to work with it.
spritebatch.Begin()
spritebatch.Draw(tex, …)
spritebatch.DrawString(…)
spritebatch.DrawCircle(…)
spritebatch.End()
So the implementation is very easy to understand and use.
On the downside it’s not as performant as it could be since it uses spritebatch with a texture read per pixel and some rotation math each frame for each segment of a circle for example, BUT it’s still very fast in the overall context.
The per-frame cost is also constant, no caching is going on.
Overall I think it’s a good implementation, which certainly conforms to the default monogame drawing behavior and therefore I’d say it’s a good fit for almost every case.
The reason for prefering MonoGame over MonoGame.Extended is not that MonoGame.Extended is hard to install (since it isnt) but rather that it would feel nice to be able to say
“Now we are going to use MonoGame, a framework used to make Bastion, Transistor, Stardew Valley etc. and it’s easy to use and it has methods and classes for everything that we need”
and not having to say
“We also need this extra part to be able to draw circles, lines and other geometrical shapes”
It would feel more like a complete package if line-drawing and circle-drawing were added to MonoGame. I understand the idea of not adding a physics engine and other entity systems to MonoGame since MonoGame is a framework for drawing to the screen, checking input and playing audio. People may want to implement physics, entity systems and other stuff differently but to my knowledge there’s no reason not to figure out a “best way” to implement drawing of geometrical shapes that everyone could use.
You could also make a nuget package that installs Monogame + Monogame.Extended in one go, so it would be transparent/unnoticeable ?
Many shipped 2D games use Extended I think, but they talk of “Monogame”.
@eddeland All the code for MonoGame.Extended is separated across multiple packages, so for example the Tiled code is not part of the same project as the GUI code. Basically the idea is that MonoGame.Extended is "not an engine"™ allowing you to just include or copy the code you need. In your case you can just copy the one file and have students copy and paste it if you wish.
EDIT: I forgot to mention that I have been working on a SpriteBatch alternative for drawing shapes by using triangle or line primitives but the performance of SpriteBatch is hard to beat. So here’s the spill: at the end of the day its probably best to continue to use SpriteBatch for drawing textured quads (sprites and glyphs) and use a different class specifically for drawing geometric primitives such as PrimitiveBatch which can be found in FarseerPhysics. This however can cause a problem of the rendering order; using the painter’s algorithm either the sprites or the geometric primitives have to be rendered before or after each other. Use of the depth buffer and possible custom shaders might need to be needed if the painter’s algorithm is not suitable. It would be probably advantageous to use the GPU to do polygon triangulation for rendering, but MonoGame does not expose the geometry shader or the compute API for modern GPUs 
.
another idea will monogame make a app for smart tv ? will monogame ever run on smart tv so we can make or play games on the smart tv as a idea
If your smart tv is based on Android you can probably already run MG games compiled for Android. I haven’t tried myself but that just sounds reasonable. I don’t know much about other OS on smart tvs tbh.
OpenGL desktop video player?
Would be extremely nice if you got the android graphics.isFullscreen=true to actually make it full screen, there is ZERO work arounds out there using monogame?
There is literally just 1 line of code that you need to add to your Activity1.cs file to make fullscreen hide the navbar…
how about providing that line
1 Like
as I said, once again the miracle line of code that is supposed to work never turns up, if your talking about changing the line in the theme/style, been there seen it bought the t-shirt, I’ve tried every combination nothing works, to force a full screen, yes getting rid of the status bars ok, but full screen no. As an FYI as well, setting graphics.Isfullscreen=true inside the constructor for a windows GL also won’t work, it has to be set inside either Initialize or OnLoad, only then you get a full screen window, is it even possible to force an android screen to 800x600 res? If it is I wish someone somewhere anywhere would just spill the beans and friggin say HOW!
WOAH horses, take a breather guys and come back tomorrow, we don’t need this kind of attitude on here. it helps nobody.
Let’s keep this thread on topic.
((View)g.Services.GetService(typeof(View))).SystemUiVisibility = (StatusBarVisibility)(SystemUiFlags.Immersive | SystemUiFlags.HideNavigation | SystemUiFlags.Fullscreen);
There is also the Myra UI, which I am finding quite easy to work with so far…